不同角色在產品各端的操作及整個流轉環節的單據生成和關係是怎麼樣的呢？本文作者以一次外賣的業務流程為例，從使用者層到內部業務層進行分析，一起來看一下吧。

說清楚一件事容易，但是說清楚一個體系難；難不代表說不清楚，我們將承接一張小票看透清結算（上）

我們重點講了很多計費的邏輯和流程，下我們將重點講不同角色在產品的各端的操作以及整個流轉環節的單據生成和關係；這兩篇文章放到一起看，資訊會更全面和完整。

大家對外賣都很熟悉，因為基本每天都會點外賣，所以像（上）一樣，我們依然以外賣場景為例，分析外賣交易全鏈路；從使用者層的“使用者下單，商家接單，分配騎手，騎手取餐，配送，使用者取餐”到內部業務層的“訂單，計價，配送，清分，記賬，結算，付款”等方面講清楚每個環節的邏輯和內容。

01 一次外賣的業務流程

一次外賣體驗會涉及到非常多的參與者以及過程，每個參與者都有自己的一個子流程，這些子流程共同串起了整個外賣交易的複雜流程體系，這個流程裡涉及到了每個角色的行為。

比如：

使用者選品、下單、支付、取餐、評價

商家的接單、製作

騎手的接單、到店、取餐、配送、確認送達

平臺的訂單建立，計價計費、支付提交、分配騎手、記賬結算

我們將這些不同角色、不同行為、不同節點所形成的一個複雜的流程繪製成下圖，便於我們動態地審視整個交易鏈條的全部事件；這也有利於後續我們去設計抽象清結算的業務節點。

02 搞清楚這些單據

上面說的過程中會產生很多的單據，每類單據會給到不同的參與者，每類單據記載著不同的但又相互關聯的資訊，我們要了解這些主要的單據，並知道其用途、關聯關係和設計方法。

使用者訂單，作為外賣的發起者，使用者的外賣訂單資訊記錄了購買的商品、商品價格、優惠資訊、支付資訊、配送資訊、商家資訊等全部內容，這個資訊是外賣平臺給使用者提供的交易資訊。

商家小票，我們收到餐以後餐盒上都會附帶一個紙質小票，也記載著該單商品的基本資訊，這個資訊是商家給使用者提供的商品和服務內容以及收費情況。

商家賬單，外賣平臺給商家提供在平臺上的經營資料，賣了多少餐，掙了多少錢，給商家付了多少款的資訊。

騎手賬單，外賣平臺給騎手提供的其在平臺的服務資訊，包括訂單資訊，收入資訊，獎懲資訊，付款情況內容。

內部單據，而外賣平臺自己內部存在著眾多業務系統，這些系統共同協同完成這行個外賣業務，像訂單系統記錄訂單，計費系統記錄計費結果，賬務系統記錄賬務資訊等，這些系統依賴各種單據完成記錄工作，以及透過各種單據相關連結傳遞資訊。

我們將各角色，各類單據，各系統之間的關係用下面的結構表示：

清楚了外賣的全流程，以及流程中涉及到的單據以後，我們再看，每個環節都是什麼樣的邏輯，相關單據是如何產生的，單據的具體內容是什麼。

03 使用者下單

使用者下單是一次外賣旅程的開始，我們對這個過程再熟悉不過了，就不過多贅述。

使用者選擇商品，我們假設購買了如下的菜品，本次下單享受的優惠，要支付的資訊等，為了便於分析我們讓訂單更加簡單一些，但是其所涉及到的面是完整的；使用者看到的訂單資訊如下：

對於一個訂單首先我們要支付其商品有哪些，買了多少數量。

營銷優惠，選購了商品以後我們需要知道這一單在這些商品情況下會有什麼活動，有多少優惠，本單有如下優惠：

我們再把優惠資訊增加到表格中得到了如下的資訊，該訂單的優惠比較簡單，都是針對整單的優惠，沒有針對單品的優惠，未來完整起見我們將單品優惠也放進去，只不過優惠金額為0。

交易計價，該過程是要計算出使用者下的這一單應該付多少錢，這個計價包含很多內容，比如計算優惠，計算商品總價，計算配送費，結算優惠後的訂單金額，計算使用者應付金額等，計算完成以後反饋給交易。

對於我們例子中的訂單的計價是比較簡單的，日常我們點的外賣有時候會非常複雜，那麼計價過程也相對複雜很多，只不過無論複雜與簡單，原理都是一樣的；我們將計價結果記錄到表格中：

使用者完成了訂單的填寫和提交，內部系統完成了交易的計價，此時交易系統請求訂單系統完成訂單的建立，下一步使用者就可以進行支付了。

04 使用者支付

從上面我們知道使用者應付金額是47。6，整個支付過程的起點是使用者點選去支付，然後跳轉到收銀臺，這個過程我們在收銀臺設計設計方法中介紹的比較清楚，這裡就不詳細說明了。

05 商家接單製作

使用者支付成功以後商家在其後臺就可以看到該筆訂單，然後選擇接單，進行菜品的製作和打包；以下資訊不是我們案例中訂單的資訊，大家可以腦補一下本單資訊填充到以下的商家賬單資訊中即可；賬單中展示了商品資訊和數量，打包費，優惠資訊以及優惠的承擔方。

06 騎手配送

一個訂單可以平臺分配給騎手，也可以騎手自己搶單，有很多中方式；這裡關於運力的排程和策略不過多贅述，不是本文的重點。

騎手在騎手端可以看到附近使用者下的全部訂單並可以做出決策要不要槍這一單，對於騎手來說距離越短，掙得越多，肯定就越喜歡。

覺得這一單的配送費很高，還有獎勵活動，那麼點進去看一看，從地圖裡可以看出這一單的店鋪在哪要配送到哪裡，肯定是越近越好，目的地的單量越多越好。

同樣騎手可以看到這一單涉及到的菜品資訊，詳細的配送費資訊等內容，便於騎手做要不要搶單的決策。

騎手搶了訂單就去店裡取餐吧，使用者也可以看到騎手的實時位置和配送狀態，這樣可以極大地緩解使用者等待的焦慮。

07 管控業務

整個訂單過程中會存在各種的事務，比如使用者把訂單取消了，商家拒單了，騎手拒單改派了，騎手把使用者的餐弄丟了等等，都需要進行一個判責，是誰的責任，要不要罰錢，封禁等。

使用者下了單，商家制作了餐，騎手完成了配送，使用者完成了評價，訂單就正式完結了。

整個訂單過程中，發生了突發事件被管控，以及訂單完結以後，每個環節都可能需要記賬，而有些記賬業務之前需要完成計費和清分，比如完單以後商家傭金的計算，過程中騎手獎懲的計算，商家的結算收入，騎手的結算收入等業務，以下部分便進入了清結算範疇。

08 費用項體系

業務在發生的過程中不同的節點，不同的使用者，不同的菜品或者活動都會產生各種不同的費用，該費用是業務層資訊到賬務層資訊轉換的非常關鍵的要素，比如商家賣了一些菜品，這些菜品就是商家的菜品收入；平臺為商家提供的交易撮合平臺和配送服務，所以平臺也會收取商家的佣金，這樣就需要一個佣金的費用。

同樣財務需要基於業務做會計記賬，那麼不能直接以業務資料入賬，而是以費用視角入賬，比如抽商家的佣金記為“平臺收入”。

這樣我們就形成了一個費用體系，業務的新增和變化，都需要針對性的建立新的費用，每個費用也就有了其依賴的業務場景，就如我們的工資一樣；而針對這一單外賣來說我們會用到如下的費用：

09 清分計費

業務完成以後或者過程當中我們要進行計費，其實在交易計價環節已經完成了一些費用的計算，比如使用者實付金額，這也是資金記賬的依據。

計費的邏輯和流程我們在清算系統設計方法中介紹的非常詳細這裡就不在贅述了，總之透過計費以後我們就獲得了所有費用的金額。

這裡我們約定商家的抽傭為20%，這裡我們按照菜品原價進行抽傭：2007商家傭金=54。6*20%=10。92。

整個計費結果如下：

10 記賬場景定義

我們知道記賬是在整個交易過程中分多次記錄的，使用者支付成功以後要記賬，商家接單以後要記賬，騎手搶單以後要記賬，完單以後要記賬；這樣我們就需要跟業務層約定業務場景的識別，而業務場景就對應了記賬的場景。

我們根據業務的發生流程，這裡應該包含正向及逆向，訂單類，管控類，獎懲類等場景，只不過我們本文不涉及逆向過程，大家可以自己思考逆向的過程。

在外賣場景裡我們可以將業務劃分成這樣的場景並給與定義，並且我們要約定好用什麼資訊去判定該場景已經發生，比如可以用訂單狀態，工單流轉等進行定義。

11 場景發生與記賬設定

定義好了業務場景以及費用，那麼我們就需要設定什麼場景發生了需要記什麼費用，這些費用要記哪些賬，因為一個費用的發生不一樣只記一筆，而是要計入多個賬戶，我們需要設定每個類場景要記什麼賬。

當然每個場景發生以後記那些賬不僅僅由訂單狀態這個場景決定，還需要其他要素參與，比如01支付成功，我們還需要知道這個是什麼型別的訂單，另外需要不需關注渠道，因為不同渠道的訂單可能需要記跟渠道的分成。

12 記賬互動

業務場景發生以後，後端清分系統需要知道業務發生了，這裡需要一個互動資訊的方式，可以透過MQ的手段，比如訂單支付成功了，訂單層就發一個MQ，清分系統監聽到該MQ以後透過訂單狀態欄位判斷訂單狀態，如果是“01”怎知道這是“01使用者支付”成功發生了。

如果說該MQ裡包含了記賬需要的全部金額那麼可以以MQ為依據生成業務單據，如果MQ內沒有過多資訊，就需要訂單業務給一個查詢資料的服務，比如查詢介面或者SQL，去獲取記賬需要的資料。

13 記賬規則

在每個業務場景發生以後我們需要記哪些賬在上面已經完成設定，那麼這些賬怎麼記呢，計給哪些物件，計入哪些賬戶呢？這就是我們的記賬規則了，比如我們介紹01支付成功以後的記賬：

有了規則以後，業務發生了就可以透過規則判定該場景需要記哪些賬，然後獲得相應的資料；獲得資料以後先生成業務最原始的憑證存下來，然後進行清分處理；這裡記賬單據我們按生成的先後順序，依賴關係分成三類：

14 業務原始憑證

是業務發生以後完成計費以後最原始的資料，比如訂單支付成功以後獲得的記賬資料儲存在清分系統，這筆資料裡包含了01使用者支付成功需要記賬的全部資訊：

15 清分憑證

上面我們介紹了“01使用者支付成功”場景發生以後，我們需要記錄3個費用“1001、3005、30010”，這樣我們根據業務憑證的資料進行清分，並根據記賬規則知道每個清分出的費用、金額、物件就有了，清分結果如下：

16 賬戶流水

有了清分明細以後，我們就可以根據記賬規則計入對應賬戶，更新賬戶餘額，記錄賬戶流水了。

17 計稅開票

計稅模式可以按照每個費用進行計稅、也可以按照每個結算週期進行計稅；同樣需要知道是什麼稅，個人所得稅還是增值稅。

假如我們按照費用進行計稅，也就是每入一筆賬都需要計稅；入賬成功以後賬務系統將入賬明細推送給稅務子系統，稅務子系統根據稅種、稅基、稅率等配置計算該筆入賬的稅額，並推送賬務系統進行稅務的扣除。

18 結算付款

按照約定我們需要完成給商家和騎手的結算，將商家的應收和騎手的收入打款給商家。

這裡不同的城市，不同的商家可能有不同的結算週期，有的按照日結，有的按照月結，有的按照周結。

結算的依據可以是賬戶的當期餘額，也可以是當期的賬戶流水，結算到指定的結算賬戶或者生成結算單進行打款，這裡我們就不詳細介紹了，詳細介紹可以參考結算系統設計方法

19 清結算架構總結

在一張小票看透清結算架構（上）等多篇文章中介紹了不同的架構，這裡針對上面介紹的內容進行規則，可以得到下面的架構圖，便於理解清結算的業務流程以及單據之間的關聯和互動。

專欄作家

陳天宇宙，微信公眾號：陳天宇宙，人人都是產品經理專欄作家。多平臺支付領域專欄作者，十年資深產品；天使投資人；專注為10萬支付產品經理和支付機構以及企業提供深度支付內容和服務！

本文原創釋出於人人都是產品經理。未經許可，禁止轉載。

題圖來自Unsplash，基於CC0協議。

該文觀點僅代表作者本人，人人都是產品經理平臺僅提供資訊儲存空間服務。