本文所描述的記帳，非企業ERP等專業財務軟體記帳場景。適用於公司自研以及採購的類電商系統後臺記帳設計。在電商場景下，涉及訂單管理、交易流水、資金流水等多種不同口徑的管理需求。
平臺型電商記帳特色
常見平臺型電商如淘寶、拼多多、美團，京東、亞馬遜也有一部分業務為平臺型。所謂平臺型電商就是搭建一個電子商城，引商家入駐。平臺主要起著撮合交易的角色。常見模式如下圖：
平臺型電商的這種業務模式也決定了其必須要適應不同商戶角色的不同需求。
運營關注訂單流水（訂單支付成功與否）店主關注交易流水（收入多少，支出多少）財務關注資金流水（實付金額、手續費等）三者概念模型關係如下：
（三者都可以加上支付渠道屬性）
訂單流水
常見支付訂單有如下幾種狀態：待支付、支付失敗、支付成功、部分退款、已退款、已撤銷。
待支付：下單成功，喚起支付後，尚未完成支付。支付失敗：密碼錯誤或者餘額不足引起的渠道扣款失敗。支付成功：扣款成功部分退款：發起退款，但沒有退全款。已退款：退全款已撤銷：傳統POS系統中，指的是交易撤銷，退全款；線上交易，指使預支付失效。
訂單狀態流轉關係
業務含義：以客戶與商戶之間達成交易的狀態為核心，表達交易是否完成。
生成條件：和業務訂單發起支付同步生成。
案例
A商戶訂單支付成功，無分帳。B商戶交易分帳，分帳接收方分別為C、D。E商戶的訂單已經退款。
交易流水
店鋪的經營情況的主要指標。交易流水不關心賣了什麼，只關注各個商戶收了多少錢，退了多少款。交易流水不關注訂單的狀態和訂單的交易時間，只關注交易的類型和時間。
交易流水類型為：
『1』：支付『2』：退款（不計算費率因素）
業務含義：商戶經營情況。
生成條件：以訂單結算商戶為核心，參考支付訂單、分帳訂單、退款訂單、撤銷訂單為觸發條件。
案例
根據上述「訂單流水」的例子，可生成如下交易流水信息。
B商戶雖然有訂單，但是因為其分帳給C、D，所有其無交易流水。C、D商戶參與B訂單的分帳，所有C、D商戶各有一條交易流水。E商戶的訂單支付成功後，又退款成功，所以涉及兩條交易流水。（如果是部分退款，就會關聯多條退款流水）
資金流水
資金流水是我們財務意義上真正的「記帳」。
資金流水要在交易流水的基礎上考慮費率的因素。在每個結算周期結束時，根據資金流水來計算應結算金額。以目前支付行業相關規定，支付成功的訂單在1年以內都可以操作退款。且渠道會退回手續費。我們以常見費率0.6% 為例，請看案例：
（註：應結算金額=收入-支出）
案例
A商戶加上費率因素，涉及兩條資金流水；B商戶無資金流水；C、D各涉及兩條資金流水；E涉及4條，因為其訂單在支付和退款兩個狀態切換時，各會涉及兩條記錄；
資金流水信息一般要同步到企業財務系統。在退款時一定要記錄手續費的收入。因為支付渠道在操作退款時，會用之前所收取的手續費抵扣掉今天所產生的手續費。
總結
做電商系統後臺時，切不可把訂單流水、交易流水、資金流水混為一談。否則會陷入無止境的數據核對和口徑問題中。最好的辦法就是三者解耦和，根據事件觸發去保證三者的關係。三者各司其責，各有獨自的業務含義和統計意義。
訂單流水、交易流水、資金流水 此為作者本人習慣叫法，切勿去扣訂單、交易、流水等詞彙標準含義。因為支付行業是發展很快，詞彙含義也同步演化。大家可以根據各自系統特點叫不同的名稱均可。
本文由 @俠之大者 原創發布於人人都是產品經理，未經作者許可，禁止轉載。
題圖來自Unsplash，基於CC0協議。