本文作者從實際工作實踐出發，結合案例等分享了電商金融支付財務融合中的基本概念和相關原理解析，包括：訂單、帳單、交易流水和帳知識解構，供大家一同參考和學習。
從事電商、進銷存、金融、支付、財務的產品同學，是否對訂單記錄、交易記錄、帳單、帳等概念給弄糊塗？或者當我們談及對帳時，是否知道對帳背後的記帳邏輯？只有知道了這些底層概念，我們方才可以理清業務邊界、明確上述概念之間的邏輯關係，業務理清了，邏輯關係農透了，我們方可遊刃有餘，而非稀裡糊塗、淺嘗輒止、依貓畫虎~
本篇是根據我們在「電商-支付-金融-財務」融合項目方面的推進中的一些實踐經驗和復盤總結，向大家分享「金融支付財務融合業務-實踐分享」系列篇的第一篇，也即「訂單、帳單、交易流水、帳知識解構、原理解析」，歡迎大家一起討論。
訂單、帳單、交易流水、帳知識解構、原理解析
1. 訂單記錄：面向業務發生的一個經營管理概念（記錄工具）
側重業務：只要有業務發生，就必然產生訂單記錄；訂單有兩個狀態：訂單履約狀態、訂單支付狀態，也有將支付狀態作為履約的前置狀態；訂單側重業務分析：如訂單渠道、購買人、交付時間、交付方式等；不必然產生交易：訂單記錄不必然產生交易記錄或財務記錄，譬如諮詢訂單。金額是中性：訂單中的金額基本不會出現正負號——當日金融業務場景中，充值訂單這種場景例外（下文例子會覆蓋）；下圖為常見訂單表結構圖示意：
2. 交易記錄：面向交易發生的一個資金管理概念（記錄工具）
財務金融屬性：交易記錄是金融或財務領域的一個概念，交易記錄的出現，必然伴隨資金帳戶場景；側重交易：往往發生真實的資金流動，如充值流水、提現流水、投資流水、還款流水等；與餘額掛靠：一旦發生交易，其必然影響帳戶餘額的變動（這裡不討論失敗場景）；邏輯關係：交易記錄屬於「帳單記錄」的子場景，也即有交易發生，必然會產生對應的1對1帳單記錄，交易記錄屬於「廣義訂單」的子場景，只所以引入「廣義訂單」這個概念，可以用如下例子來予以說明，譬如用支付寶購物2個滑鼠合併付款，訂單記錄是2個滑鼠，交易記錄是1筆支付流水；而向支付寶充值100元，就沒有訂單記錄只有交易記錄一說或者說交易記錄就是訂單記錄。下圖為常見交易記錄表結構圖示意：
3. 帳：面向財務的一個收支管理概念（記帳工具）
側重帳：發生財務往來就要入帳，或者我們可以說「即使不涉及資金流動也會產生帳」，譬如賒帳，商戶A從商戶B以賒銷的方式進貨100件，每件價值10元，欠帳1000元，這裡發生了交易，但無資金流動產生。訂單記錄插入訂單流水、交易記錄不插入交易流水、但帳單記錄要插入財務流水（賒帳記錄）；複試記帳：業務帳是收付實現制的單式記帳，財務帳是權責發生制的複式記帳；側重交易對手：有借必有貸、借貸必平衡。而交易記錄、訂單記錄側重單方記帳，帳單記錄通常用複式記帳;時間粒度：帳的時間粒度一般都比較粗，粒度一般為日;與業務帳(業務流水)區別：業務帳側重於雙方業務系統、物流數據和訂單數據，主要用作購銷雙方是否發貨；財務帳側重付款和開票情況，主要用於結款。下圖為常見帳表結構圖示意
4. 帳單：面向用戶的一個收支管理概念（記帳工具）
側重單：帳單帳單，顧名思義是把「帳」合併成單、有匯總之意，當然一個帳單可以是一筆交易、也可以是幾筆交易的合併;與帳的關係：帳的粒度是一筆一筆，帳單的粒度是合併匯總（極端場景是一筆一個帳單）；側重帳：同上述「帳」關於此點的描述；側重進、出：同上述「帳」關於此點的描述；側重交易對手：同上述「帳」關於此點的描述；實務簡化應用：實務中，帳單面向的用戶多是普通用戶而非專業級財務人員，故此我們看到的支付寶、微信以及我們的銀行的帳單記錄是閹割版的「財務記帳記錄」——也即只向用戶呈現用戶資金帳戶增減的變動及交易對手，而未對交易對手再進行財務記帳（實際也記錄了，只是未開放給用戶，畢竟用戶不是會計，開放太多信息用戶會蒙圈）。下圖為常見帳單表結構圖示意：
下圖為常見帳單用戶場景示意圖（微信、支付寶）：
原理實踐實例復盤
1. 微信零錢明細和帳單的區別是什麼？為什麼要做這種區分？
一個優秀的產品經理應習慣對自己日常用到的產品細膩觀察、透徹了解、刨根問題或者至少發起疑問，這是為什麼呢？
通過梳理我們可以發現：
微信零錢明細只記錄「微信零錢」裡的收入、支出； 而微信帳單不僅包含微信零錢的收入、支出記錄，還包含綁定的銀行卡的收入、支出記錄。
用帳套來講（非嚴格定義）：微信帳單是微信用戶的一級帳套，記錄微信用戶通過微信支付發生的每筆進出資金的日誌；微信零錢是二級帳套，記錄微信零錢這個資金池發生的每筆進出資金的日誌； 大家可以很自然的得出微信零錢的明細一定會出現在微信帳單裡，但微信的帳單裡的大部分交易記錄是不會出現在微信零錢裡。
2. 微信零錢明細每筆交易都帶有餘額，而微信帳單的每筆交易不帶有餘額，這又是為什麼呢？為什麼要做這種區分？
一個優秀的產品經理應該會對自己日常應用的產品了解非常之透徹或者至少發起疑問，這是為什麼呢？
前面用了一個不嚴格的定義也即微信帳單是一級帳套、微信零錢明細是二級帳套。只所以說不嚴格，是因為微信帳單沒有期初餘額、期末餘額的概念，不是嚴格意義上的帳套。
微信只所以這樣做，是因為微信支付是一個支付工具（通道），不是一個資金帳戶（池子=帳套），所以無法引入「期初餘額」、「期末餘額」的概念，如果非要引入也是可以的——通過虛擬記錄來自洽，譬如用微信支付通過招行卡充100話費，現在的策略是顯示1條100元的充值記錄，如果走帳套策略，需要用如下來表達：
+100元招行充值；-100元話費購買。3. 隨手記、挖財記帳等記帳工具可以刪除，微信支付的「帳單」怎麼可以刪除呢？
一個優秀的產品經理應該會對自己日常應用的產品了解非常之透徹或者至少發起疑問，這是為什麼呢？
由於微信支付的帳單記錄不是嚴格概念上的帳套，無借貸平衡的內生要求，僅是一筆記帳日誌，所以微信支付、支付寶的帳單記錄都是可以刪除的（用戶視角），也就不難理解了。因為他是站在用戶的角度出發的，刪除背後的訴求是用戶本人不希望別人看見我的這筆消費，而不是我很在乎這筆記錄是否真實發生或者刪除之後帳單數據是否自洽。
4. 微信零錢通的零錢明細-交易記錄也可以刪除，這是為什麼呢？
一個優秀的產品經理應該會對自己日常應用的產品了解非常之透徹或者至少發起疑問，這是為什麼呢？
微信零錢與支付寶的餘額、銀行的帳戶等屬性基本相同，是一個嚴格的帳套，經然也提供了刪除功能，這很讓人費解！！！
我認為這是微信支付團隊的一個產品bug，或許是負責這個模塊產品經理的一種偷懶——直接復用了微信支付「帳單」裡面的刪除邏輯（上述3提到，微信支付裡的帳單提供刪除是可以理解的，因為「帳單」無借貸平衡的內生要求，也即無期初餘額、期末餘額的邏輯自洽要求），而未站在「帳套」或「資金帳戶」的角度去思考，交易記錄是不能隨意刪除的，一旦刪除，站在可視角度，帳務就不能自洽了。
下圖為「微信-帳單」、「微信-零錢通-交易明細」、「支付寶-帳單」、「支付寶-餘額-交易明細」的對比圖
5. 「帳單」合併「交易明細」場景之支付寶實踐分析
細心的產品經理（不是用戶）會發現下圖中的同一個支付寶帳戶，未做過任何刪除操作，「餘額寶-交易明細」、「餘額-交易明細」都有6月10日322.94的交易流水，唯獨「支付寶-帳單」中無這筆記錄（這裡未用交易流水錶述），難道支付寶的產品經理也像上述微信的產品經理犯糊塗了麼？
一個優秀的產品經理應該會對自己日常應用的產品了解非常之透徹或者至少發起疑問，這是為什麼呢？
答案是沒有，支付寶是網際網路金融的祖師爺，其對業務的理解深度要比微信團隊深刻，其對業務的理解和用戶的拿捏把握是值得我們學習的。
那具體原因是什麼？想必大家看了下面的復盤分析，就明白本篇作為「支付金融財務」融合領域的前置知識掌握的必要性和本篇第一章節對「業務流水、交易流水、帳、帳單」的概念解構和原理分析的價值。
根據螞蟻花唄的清算指令，系統自動從用戶的餘額寶扣款322.94元，「餘額寶帳套」體系產生一條-322.94的出款入帳記錄，見上述圖1；處於合規需要，餘額寶的錢無法直接與花唄帳單進行對衝，必須經過餘額搭橋；故此「餘額帳套」中會自動插入兩條入帳記錄，即：進帳+322.94元（餘額寶轉入餘額），出帳-322.94元（餘額轉出到花唄），見上述圖2；對於用戶而言，當天還花唄帳單的實際還款金額是1503.32元（通過螞蟻金服的清算引擎，在最後還款日有系統代替用戶自動完成了1503.32元的還款——322.94元通過餘額帳戶取自餘額寶、1180.38元通過支付寶劃扣通道取自我的招行借記卡），無論資金來自哪裡都是一件事「還款」，故在「支付寶帳單」中顯示為一筆1503.32，見上述圖3、圖4。嚴格意義上講，支付寶的這種帳單處理邏輯不算嚴謹，會增加用戶的理解成本，如這裡的餘額帳單、餘額寶帳單在支付寶帳單中無法直觀匹配的情況。
但當我們理解了前面提到的「交易記錄」、「帳」、「帳單」的底層概念及原理區別之後，支付寶給用戶提供的「帳單」是「帳單」而非「帳」。「帳單」是一種合併的表達方式，從簡化用戶理解的角度講，顯示為一筆也許理解成本更輕。
以上是我在支付金融財務融合項目中的一些實踐總結，限於文採拙劣和篇幅原因，未能精細呈現，海涵，歡迎大家交流切磋！
不同的行業、不同的業務場景、不同的崗位角色，會面臨不同的產品任務。但萬變不離其宗，方法相通，只要我們有產品盤感、業務敏感、邏輯嚴謹、靈通好學、幹練帶風、狠下功夫，放到哪我們都一樣熠熠生輝。
產品之路很艱辛，也更能鍛鍊人，尤其是中後臺、尤其是「中後臺+財務」這種大量底層的項目！在此祝廣大產品兄弟姐妹們不辱「產品」之title，做出好產品！
作者：九天牧人，個人微信unifarm
本文由 @九天牧人 原創發布於人人都是產品經理，未經許可，禁止轉載
題圖來自 Unsplash，基於 CC0 協議