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

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

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

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

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協議。

該文觀點僅代表作者本人，人人都是産品經理平台僅提供信息存儲空間服務。

,

更多精彩资讯请关注tft每日頭條，我们将持续为您更新最新资讯!

查看全部