結算產品中，計費模塊如何設計
本文作者根據他做結算產品的工作經歷，圍繞計費展開三方面的分析，希望對你有幫助。
做結算產品三兩年了，基本結算相關的應收應付場景都見過，主要是圍繞計費這塊寫點東西，分享一下，可探討，可噴，大廠同學請繞路，因爲這東西可能你們的團隊已經實現了。
公司現在業務相當於平臺，業務抽象來說比較簡單，有點像電商的POP模式，用仨字兒概括就是算分成，背景如下：
- 幾個商戶（角色）入駐你這個平臺
- C端支付個訂單
- 平臺把該收誰多少錢，該給誰多少錢算好
- 信息提交至銀行做清分
各位看官淡定，以上幾個步驟我們都是合法合規的，跟銀行合作的，這塊可不要開噴。
以上就是業務背景，可能圍繞計費這塊，做過電商的或者平臺類的朋友會遇到運營或者各部門提的需求，舉個例子：
我每年需要收年費，可能A供應商每年收1000，B供應商每年收2000，等等。每個訂單我平臺要抽成，每個商家，甚至於每個商品類目，收取的都不一樣，費用，費率都不一樣，收取的方式天花亂墜。某些商戶我可能不間斷的還會給他階梯優惠，等等。
每衍生出一個費用需求，接下來就是技術一頓改，一頓出問題，一頓修復。
所以，需要一個可配置的模板，每新增一個費用需求，不需要改代碼，可以通過配置，來解決以上的問題。
一、基本要素
個人理解，決定費用項目的幾個基本的要素就以下幾個：
- 計費業務線：每個公司都不一樣
- 計費對象（角色）：就是入駐你這個平臺的商戶是幹嘛的，給它規個類
- 費用類型：比如，年費，每單的抽成，佣金，等等
以上仨要素，或者更多要素，基本能決定入駐平臺的這個商戶的類型以級費用類型。
二、費用規則
1. 計費的基準值
常見的兩種：
- 按照（訂單/商品）售價收
- 按照差價收，相當於(賣出價-進貨價),目前我們平臺暫時就做了這兩種
這裏暫時留個的個問題：萬一特殊的業務，出個其它規則呢，所以這裏要要解決的問題是在不變更代碼的情況下，讓業務人員可配置基準值。
2. 計費規則
基本上以基準值*比例或者固定值提現，比如每單固定抽成20塊，或者每單抽取銷售額的百分之5。
3. 計費區間
時間段內： startTime< D < EndTIme.
時間段外： D>startTime 或者 D>EndTIme.
等於什麼時間：D=XXTIme或者D=XXTIme，等等
4. 小結
其實基本的歸根究地就是，5W原則，什麼時候收誰，收多少，怎麼收。這個足以構成模板的橫向元素。
首先，實現計費模板實現的前提，就是在結算系統，有一個類似於“訂單快照”的模塊，簡單來說就是包含所有結算用的，訂單商品維度的一個大表，包含訂單號，售價，實付，結算價，確認收貨時間等等。快照作爲後續結算甚至財務統計的BASE。
三、具體的配置以級相關聯的功能點
計費業務線：
比如，金融業務，物流業務等。
計費對象（角色）：
可以決定商戶屬性的角色，比如自營，POP商戶，視實際業務場景而定。
計費類型：
年費，手續費，技術服務費，等等的費用。
不過多描述了，幾個字典表相關聯可以搞定。
計費的基準值：
比如售價，結算價，售賣，等等的基準值，均來自於訂單快照，且可計算。
基準值的作用有以下兩點：
- 就作爲基準值：比如某類業務需要收取 銷售額的百分之5，實際支付金額的6%，等等
- 作爲階梯價的標準，比如售價達到多少時，改變什麼金額，結算金額達到XXX時，結算價發生變化，售賣天數達到XX天時，做什麼，等等
這裏我想表達的需求是，訂單快照相關的所有結算數據，都可以配置爲基準值，我可以把銷售額作爲基準值，可以把數量作爲基準值，可以把售賣天數作爲基準值等等，而且基準值可以算加減乘除。
舉個例子：
我某類商品需要按（賣出價-買入價）的3%收取平臺服務費，那麼配置個基準值：取名叫——利潤=賣出價-買入價（不要糾結這個名字）
這裏衍生出一個功能點：在不需要改代碼的情況下，讓基準值進行可配。
所以技術上要實現兩點：
- 公式的解析，舉例：利潤=賣出價-買入價，賣出價是結算數據的哪列，買入價是哪列
- 業務人員不懂數據庫，不可能讓他們直接把列名輸出成公式，所以需要一個然他們能看的懂的輸入界面來編輯公式。
以上兩點就由產品及技術自己發揮了。
基準值一般應該是不復雜的元素，售價，結算價，數量等等的要素或者要素經過簡單計算得出的結果，可以作爲基準值，比如（賣出價-賣入價），如果基準值包含了數字的比例計算，那就需要注意，是不是錯誤的把某項費用當做基準值來配置了
接下來是費用比例以及封頂值：
費用比例比較特殊，規則簡單的，可以配置到角色維度就可以了，比如平臺統一收取角色爲服務商的商戶每筆訂單 10%佣金，這類的配置到角色層級即可。
規則複雜的，以電商平臺爲例，比如某某商品佣金按6%收取，某某商品佣金按3%收取那這個就是商品的維度，也就是在基礎佣金規則存在的前提下，按照供應商商品維度，再次進行編輯，至於要編輯多少次，是不是每條商品都需要編輯規則，那就看產品設計咯。
封頂值有三種：固定金額封頂，非固定金額封頂，無封頂。
- 固定金額封頂：舉例：年費每年收1w
- 非固定金額封頂：前三個月銷售額達到XX的百分之10，免收佣金(例子不太恰當，理解就行了）
- 無封頂：永久收取的費用
計費區間：
就很簡單了，不過多說了，至於把或且非的關係如何配置，那就自由發揮了。
綜上，階梯價場景以外的規則，通過以上這些元素橫向組成，任何基本的計費場景以及規則都可以橫向配置出來，而且是可以配置到商品維度，節省了絕大多數因爲計費規則變化而增加的開發工作量。
最後就是階梯價：
階梯在大大小小的公司都是令人頭疼的事，一般的我見過的比較“笨”的做法是在結算時點，生成結算單數據後，統一刷一遍，然後再重新計算。
上文提到的計費區間+封頂值構成了階梯價的數據。
這裏就用到了之前提到的基準值，基準值一旦配置，就會在結算系統進行累加，按單，或天維度，所以在商戶入駐平臺同時，根據業務場景可能衍生的階梯價規則就需要在基準值進行配置。
舉個最簡單的階梯價場景：
A供應商，x商品，結算價爲50，售賣之日起三個月內，如果銷售額達到50w，後續結算價變爲40。
這裏以時間，銷售額爲階梯，按照模板配置兩條：
- 費用類型：平臺應付XX費
- 基準值：銷售額
計費區間，2020-01-01<=D<=2020-03-31，封頂值：50w。
到達封頂值後，清結算系統識別階梯價改變任務改變結算價去繼續執行後續計費即可。
然後在配置一條計費區間>=2020-03-31，無封頂值的就可以了。
以上的場景偏向於按單計提，意思就是以訂單商品維度來收取（支付）費用。
最後就是一次性收取的費用，這種最簡單，比如年費，服務費，等等，配置好以後，這種本身跟訂單弱關聯的的，清結算系統生成任務事件推給供應商前置生成B2B訂單去繳納就是了。
舉個小栗子：年費，按年收取的，業務人員一年在費用模板做一條，當然了這是比較笨的方式，最好的就是依賴配置自動生成。
小結：
以上描述的“計費”比較狹隘，目前公司所應用的場景是清分，也可以把它稱之爲“分成”模塊，就清結算系統邊界內講，這個模塊的前置是支付模塊，BASE數據也就是上文提到過的“訂單快照”均依賴於支付模塊生成。
如果計費平臺化，那麼…..
計費是一個可逆的場景，不是任何的業務線，場景都存在一個“永不變更”的場景，例如階梯價的計算，什麼時間什麼時點，計入銷售額，如果計入後發生了退款，什麼時點扣除，等等細節還有很多。
更細的不說了，歡迎大家指正與探討。
本文由@卡歐里 原創發佈於人人都是產品經理，未經許可，禁止轉載。
題圖來自Pexels，基於CC0協議
