金融支付財務融合業務-實踐分享1:訂單、賬單、交易流水、賬套知識解構、原理解析

9 評論 9393 瀏覽 65 收藏 17 分鐘

本文作者從實際工作實踐出發,結合案例等分享了電商金融支付財務融合中的基本概念和相關原理解析,包括:訂單、賬單、交易流水和賬知識解構,供大家一同參考和學習。

從事電商、進銷存、金融、支付、財務的產品同學,是否對訂單記錄、交易記錄、賬單、賬等概念給弄糊涂?或者當我們談及對賬時,是否知道對賬背后的記賬邏輯?只有知道了這些底層概念,我們方才可以理清業務邊界、明確上述概念之間的邏輯關系,業務理清了,邏輯關系農透了,我們方可游刃有余,而非稀里糊涂、淺嘗輒止、依貓畫虎~

本篇是根據我們在“電商-支付-金融-財務”融合項目方面的推進中的一些實踐經驗和復盤總結,向大家分享“金融支付財務融合業務-實踐分享”系列篇的第一篇,也即“訂單、賬單、交易流水、賬知識解構、原理解析”,歡迎大家一起討論。

訂單、賬單、交易流水、賬知識解構、原理解析

1. 訂單記錄:面向業務發生的一個經營管理概念(記錄工具)

  1. 側重業務:只要有業務發生,就必然產生訂單記錄;
  2. 訂單有兩個狀態:訂單履約狀態、訂單支付狀態,也有將支付狀態作為履約的前置狀態;
  3. 訂單側重業務分析:如訂單渠道、購買人、交付時間、交付方式等;
  4. 不必然產生交易:訂單記錄不必然產生交易記錄或財務記錄,譬如咨詢訂單。
  5. 金額是中性:訂單中的金額基本不會出現正負號——當日金融業務場景中,充值訂單這種場景例外(下文例子會覆蓋);

下圖為常見訂單表結構圖示意:

2. 交易記錄:面向交易發生的一個資金管理概念(記錄工具)

  1. 財務金融屬性:交易記錄是金融或財務領域的一個概念,交易記錄的出現,必然伴隨資金賬戶場景;
  2. 側重交易:往往發生真實的資金流動,如充值流水、提現流水、投資流水、還款流水等;
  3. 與余額掛靠:一旦發生交易,其必然影響賬戶余額的變動(這里不討論失敗場景);
  4. 邏輯關系:交易記錄屬于“賬單記錄”的子場景,也即有交易發生,必然會產生對應的1對1賬單記錄,交易記錄屬于“廣義訂單”的子場景,只所以引入“廣義訂單”這個概念,可以用如下例子來予以說明,譬如用支付寶購物2個鼠標合并付款,訂單記錄是2個鼠標,交易記錄是1筆支付流水;而向支付寶充值100元,就沒有訂單記錄只有交易記錄一說或者說交易記錄就是訂單記錄。

下圖為常見交易記錄表結構圖示意:

3. 賬:面向財務的一個收支管理概念(記賬工具)

  1. 側重賬:發生財務往來就要入賬,或者我們可以說“即使不涉及資金流動也會產生賬”,譬如賒賬,商戶A從商戶B以賒銷的方式進貨100件,每件價值10元,欠賬1000元,這里發生了交易,但無資金流動產生。訂單記錄插入訂單流水、交易記錄不插入交易流水、但賬單記錄要插入財務流水(賒賬記錄);
  2. 復試記賬:業務帳是收付實現制的單式記賬,財務帳是權責發生制的復式記賬;
  3. 側重交易對手:有借必有貸、借貸必平衡。而交易記錄、訂單記錄側重單方記賬,賬單記錄通常用復式記賬;
  4. 時間粒度:賬的時間粒度一般都比較粗,粒度一般為日;
  5. 與業務賬(業務流水)區別:業務賬側重于雙方業務系統、物流數據和訂單數據,主要用作購銷雙方是否發貨;財務賬側重付款和開票情況,主要用于結款。

下圖為常見賬表結構圖示意

4. 賬單:面向用戶的一個收支管理概念(記賬工具)

  1. 側重單:賬單賬單,顧名思義是把“賬”合并成單、有匯總之意,當然一個賬單可以是一筆交易、也可以是幾筆交易的合并;
  2. 與賬的關系:賬的粒度是一筆一筆,賬單的粒度是合并匯總(極端場景是一筆一個賬單);
  3. 側重賬:同上述“賬”關于此點的描述;
  4. 側重進、出:同上述“賬”關于此點的描述;
  5. 側重交易對手:同上述“賬”關于此點的描述;
  6. 實務簡化應用:實務中,賬單面向的用戶多是普通用戶而非專業級財務人員,故此我們看到的支付寶、微信以及我們的銀行的賬單記錄是閹割版的“財務記賬記錄”——也即只向用戶呈現用戶資金賬戶增減的變動及交易對手,而未對交易對手再進行財務記賬(實際也記錄了,只是未開放給用戶,畢竟用戶不是會計,開放太多信息用戶會蒙圈)。

下圖為常見賬單表結構圖示意:

下圖為常見賬單用戶場景示意圖(微信、支付寶):

原理實踐實例復盤

1. 微信零錢明細和賬單的區別是什么?為什么要做這種區分?

一個優秀的產品經理應習慣對自己日常用到的產品細膩觀察、透徹了解、刨根問題或者至少發起疑問,這是為什么呢?

通過梳理我們可以發現:

微信零錢明細只記錄“微信零錢”里的收入、支出; 而微信賬單不僅包含微信零錢的收入、支出記錄,還包含綁定的銀行卡的收入、支出記錄。

用賬套來講(非嚴格定義):微信賬單是微信用戶的一級賬套,記錄微信用戶通過微信支付發生的每筆進出資金的日志;微信零錢是二級賬套,記錄微信零錢這個資金池發生的每筆進出資金的日志; 大家可以很自然的得出微信零錢的明細一定會出現在微信賬單里,但微信的賬單里的大部分交易記錄是不會出現在微信零錢里。

2. 微信零錢明細每筆交易都帶有余額,而微信賬單的每筆交易不帶有余額,這又是為什么呢?為什么要做這種區分?

一個優秀的產品經理應該會對自己日常應用的產品了解非常之透徹或者至少發起疑問,這是為什么呢?

前面用了一個不嚴格的定義也即微信賬單是一級賬套、微信零錢明細是二級賬套。只所以說不嚴格,是因為微信賬單沒有期初余額、期末余額的概念,不是嚴格意義上的賬套。

微信只所以這樣做,是因為微信支付是一個支付工具(通道),不是一個資金賬戶(池子=賬套),所以無法引入“期初余額”、“期末余額”的概念,如果非要引入也是可以的——通過虛擬記錄來自洽,譬如用微信支付通過招行卡充100話費,現在的策略是顯示1條100元的充值記錄,如果走賬套策略,需要用如下來表達:

  1. +100元招行充值;
  2. -100元話費購買。

3. 隨手記、挖財記賬等記賬工具可以刪除,微信支付的“賬單”怎么可以刪除呢?

一個優秀的產品經理應該會對自己日常應用的產品了解非常之透徹或者至少發起疑問,這是為什么呢?

由于微信支付的賬單記錄不是嚴格概念上的賬套,無借貸平衡的內生要求,僅是一筆記賬日志,所以微信支付、支付寶的賬單記錄都是可以刪除的(用戶視角),也就不難理解了。因為他是站在用戶的角度出發的,刪除背后的訴求是用戶本人不希望別人看見我的這筆消費,而不是我很在乎這筆記錄是否真實發生或者刪除之后賬單數據是否自洽。

4. 微信零錢通的零錢明細-交易記錄也可以刪除,這是為什么呢?

一個優秀的產品經理應該會對自己日常應用的產品了解非常之透徹或者至少發起疑問,這是為什么呢?

微信零錢與支付寶的余額、銀行的賬戶等屬性基本相同,是一個嚴格的賬套,經然也提供了刪除功能,這很讓人費解!!!

我認為這是微信支付團隊的一個產品bug,或許是負責這個模塊產品經理的一種偷懶——直接復用了微信支付“賬單”里面的刪除邏輯(上述3提到,微信支付里的賬單提供刪除是可以理解的,因為“賬單”無借貸平衡的內生要求,也即無期初余額、期末余額的邏輯自洽要求),而未站在“賬套”或“資金賬戶”的角度去思考,交易記錄是不能隨意刪除的,一旦刪除,站在可視角度,賬務就不能自洽了。

下圖為“微信-賬單”、“微信-零錢通-交易明細”、“支付寶-賬單”、“支付寶-余額-交易明細”的對比圖

5. “賬單”合并“交易明細”場景之支付寶實踐分析

細心的產品經理(不是用戶)會發現下圖中的同一個支付寶賬戶,未做過任何刪除操作,“余額寶-交易明細”、“余額-交易明細”都有6月10日322.94的交易流水,唯獨“支付寶-賬單”中無這筆記錄(這里未用交易流水表述),難道支付寶的產品經理也像上述微信的產品經理犯糊涂了么?

一個優秀的產品經理應該會對自己日常應用的產品了解非常之透徹或者至少發起疑問,這是為什么呢?

答案是沒有,支付寶是互聯網金融的祖師爺,其對業務的理解深度要比微信團隊深刻,其對業務的理解和用戶的拿捏把握是值得我們學習的。

那具體原因是什么?想必大家看了下面的復盤分析,就明白本篇作為“支付金融財務”融合領域的前置知識掌握的必要性和本篇第一章節對“業務流水、交易流水、賬、賬單”的概念解構和原理分析的價值。

  1. 根據螞蟻花唄的清算指令,系統自動從用戶的余額寶扣款322.94元,“余額寶賬套”體系產生一條-322.94的出款入賬記錄,見上述圖1;
  2. 處于合規需要,余額寶的錢無法直接與花唄賬單進行對沖,必須經過余額搭橋;
  3. 故此“余額賬套”中會自動插入兩條入賬記錄,即:進賬+322.94元(余額寶轉入余額),出賬-322.94元(余額轉出到花唄),見上述圖2;
  4. 對于用戶而言,當天還花唄賬單的實際還款金額是1503.32元(通過螞蟻金服的清算引擎,在最后還款日有系統代替用戶自動完成了1503.32元的還款——322.94元通過余額賬戶取自余額寶、1180.38元通過支付寶劃扣通道取自我的招行借記卡),無論資金來自哪里都是一件事“還款”,故在“支付寶賬單”中顯示為一筆1503.32,見上述圖3、圖4。

嚴格意義上講,支付寶的這種賬單處理邏輯不算嚴謹,會增加用戶的理解成本,如這里的余額賬單、余額寶賬單在支付寶賬單中無法直觀匹配的情況。

但當我們理解了前面提到的“交易記錄”、“賬”、“賬單”的底層概念及原理區別之后,支付寶給用戶提供的“賬單”是“賬單”而非“賬”。“賬單”是一種合并的表達方式,從簡化用戶理解的角度講,顯示為一筆也許理解成本更輕。

以上是我在支付金融財務融合項目中的一些實踐總結,限于文采拙劣和篇幅原因,未能精細呈現,海涵,歡迎大家交流切磋!

不同的行業、不同的業務場景、不同的崗位角色,會面臨不同的產品任務。但萬變不離其宗,方法相通,只要我們有產品盤感、業務敏感、邏輯嚴謹、靈通好學、干練帶風、狠下功夫,放到哪我們都一樣熠熠生輝。

產品之路很艱辛,也更能鍛煉人,尤其是中后臺、尤其是“中后臺+財務”這種大量底層的項目!在此祝廣大產品兄弟姐妹們不辱“產品”之title,做出好產品!

 

作者:九天牧人,個人微信unifarm

本文由 @九天牧人 原創發布于人人都是產品經理,未經許可,禁止轉載

題圖來自 Unsplash,基于 CC0 協議

給作者打賞,鼓勵TA抓緊創作!
1人打賞
更多精彩內容,請關注人人都是產品經理微信公眾號或下載App
評論
評論請登錄
  1. 寫的比較專業和詳細,有幾點問題可以分享 探討下
    第一:3.2 復試記賬:業務帳是收付實現制的單式記賬,財務帳是權責發生制的復式記賬;
    這里描述有問題業務帳是流水數據,可以簡單認為是單式記賬,但不是收付實現制的 ,但是從財務的視角概念是不一樣的。
    收付實現制和權責發生制,都是可以用復式記賬法,只是記錄賬簿時間的點不一樣
    收付實現制是實際債券債務履約的時候進行記賬
    權責發生制是發生債券債務關系時,進行記賬,所以有應收,應付和 分攤等
    第二:在交易訂單之后 一般會有 對應的 支付訂單,支付訂單有對應清算指令,同步賬戶進行憑證記錄。
    比如一筆交易采用多種支付方式,常見電商平臺的紅包促銷等,100微信 支付90,紅包 支付 10快 ,需要拆分2筆 支付訂單 ,或者系統做的比較好的也可以是 一筆支付 訂單,但是里面會涉及到2套支付指令的記錄,生成2套憑證記錄,交易訂單對應的原始憑證信息。
    第三:賬單 這個其實是賬戶余額變動明細 ,是設計賬戶的時候都會記錄發生額,期初和期末,借貸方向,同時可以關聯到原始交易信息

    回復
  2. 專業

    回復
  3. 間隔一段時間前后看了兩三遍您這篇文章,受益匪淺,非常感謝!不過在工作中仍對于電商業務場景中,面向商戶側的流水和賬單展現有些疑惑,比如流水是否可以有狀態,還是說等流水交易完成后才做記錄和展示呢?
    以及如果存在多個內部的賬戶體系,各自應該如何處理比較好呢?是各自視為一個賬套去做嗎?可以大致參考上述的支付寶余額和余額寶的關系嗎?
    賬單的統計匯總區分成收入支出兩大塊就好了嗎,是否可以參考微信賬單需要把充值體現等納入其他這第三種大類里呢?
    不知您是否有這方面產品設計上的考慮要點的建議呢?期待您的回應!謝謝!

    回復
  4. 謝謝,寫的非常好,自己用支付寶和微信也會經常思考和作者同樣的問題,看看他們怎么記賬。作者的思路和思考方向和我一樣。只是我不能跟作者一樣表達的這么清晰。

    回復
  5. 你好,我簡單的理解來說。
    凡是涉及到金錢相關的,都需要有記錄,不允許踏雪無痕的存在。
    而詳細的記錄,可以根據不同的角度來呈現。
    例如給用戶看的賬單,可以合并起來簡單一點。
    給專業財務看的,可以以另外一種形式。
    但總的來說,需要詳細記錄,有數據才能計算和匯總。

    回復
  6. 您好,平臺上的交易記錄是否與余額掛靠應該是需要根據場景來的吧
    比如很多平臺是允許在線支付和余額支付同時存在的,在線支付產生的流水就和余額賬戶無關了

    回復
    1. 您好,平臺上的交易記錄是否與余額掛靠,的確是根據場景需要來決定。

      您舉得例子可以翻譯成我們用京東購物,方式1:走京東錢包支付(涉及京東錢包的余額變動);方式2:直接走銀行卡或第三方支付(不涉及京東的錢包余額變動)。

      余額概念出現的前置條件是【賬套】,上述舉例中的支付方式2,在用戶測,不涉及“京東錢包”賬套,在用戶測不存在“余額”概念。用戶的這筆銀行卡或第三方支付購物,在京東平臺測的“財務賬套”中就涉及余額。

      回復
  7. 請問訂單沒有負數,那帳單有負數么?

    回復
    1. 訂單是業務概念,金額是描述訂單這一票對應的金額,是個中性的數字,無正負之分。
      賬單是財務概念,在狹義場景中,譬如吃飯的賬單,他永遠是正值,基本上=訂單金額。在廣義的場景中(譬如涵蓋財務場景),是有進出概念的,有正負之分。

      回復