自然月結算是什麼意思

編輯導語：如今一些企業會開發服務的平臺，對於這些平臺，一些產品的服務會產生收費的模式和標準，根據不同的年月日等規定進行計費；本文作者分享了關於企業服務平臺中的交易模式——計費結算的設計，我們一起來看一下。

企業服務專案，產品策劃分為兩部分。

本系列主要講技術服務開放平臺的產品策劃怎麼做，對企業服務產品感興趣的可以來看看。

上一章，我們講了產品和平臺使用者，這一章，我們主要講交易：計費&結算。

一、核心交易流程簡述

首先，我們來捋一下一次交易的過程，看看核心操作有哪些？

1。 生產產品——>定價

根據產品不同服務形式（產品型別）確定計費模式，一般是按量收費，需要確定計量項（最小計費單位）和單價。

如API按呼叫次數/按QPS每天計費；SDK按永久授權終端裝置數量計費；獨立部署按年收費等，然後單價可能有預設價格和優惠價格。

2。 BD找到客戶——>報價——>提供免費測試

建立客戶賬號，並配置該產品有限期內有限次數免費呼叫。

客戶進行測試。

3。 簽訂合同，分配資源

測試透過，正式合作，BD與客戶確定付費模式，預付費或後付費。

預付費一般為包年包月的購買形式，需要預先確認購買資源量；資源包購買後，即將相關資源分配給使用者，直到過期失效。

後付費，即先使用，後付費，在結算時按實際使用量計費，需要確定結算週期，一般按日/月結算。

4。 客戶消費

客戶呼叫API，或者使用SDK，系統搜尋該客戶該產品的訂單列表（可能同時有多個訂單），根據特定策略篩選出訂單，如果該訂單是預付費的資源包，則需判斷剩餘資源數量是否足夠；如是後付費方式，則進行累計計費。

5。 對賬結算

預付費模式，下單完成後就生成賬單；賬單支付後，才分配資源。

後付費，到達結算週期時，生成賬單，並提供用量明細；使用資源後，才支付。

總結如上圖，透過對核心流程的梳理，我們對交易系統的認知開始有了輪廓。

二、功能模組設計

基於上述的輪廓，我們繼續思考系統的核心功能模組設計。

我們根據是否生成賬單，劃分為兩大塊：計費和結算。

1。 計費

概念：按照計費規則計算出單個產品要收取的費用，並且按照結算週期聚合所有服務的計費明細 生成賬單。

企業服務的計費模式一般分為預付費和後付費。

1）預付費

一般就是包年包月的購買形式：客戶可根據自身對資源的使用需求選擇資源包，下單完成後會生成賬單。要注意資源到期提醒或者欠費預警。

2）後付費

指的是先使用後付費，在到達結算周可期時，生成賬單的計費模式。客戶需要在約定時間內完成繳費；也涉及欠費管理。這種方式，對客戶方來說，用多少付多少，沒有資源浪費，更靈活。

對還處在發展早期的平臺更適合，或者客戶是大客戶，議價權較強的時候，一般都是後付費。流程如下：

3）配置計費規則

這個模組既要支援配置資源包，也要支援後付費的計費規則。

①資源包

配置資源包的有效期起止時間，計量項，總量，以及分配規則和結轉規則。根據分配規則和結轉規則可分為「按月分配不結轉/按月分配可結轉/一次性分配不結轉/一次性分配可結轉」，影響下發和抵扣。

②後付費計費規則

計費規則主要是根據產品的服務形式確認計費週期，最小計費單位（計量項），以及單價。

演算法：需要支援階梯式演算法，即時間視窗內用得越多單價越便宜。

要注意，在設計這一模組的時候，儘可能高度抽象，以保證靈活度。因為To B業務，客戶是甲方爸爸，客戶可能會提出其他的計費規則，也需要我們系統能支援。這裡可以考慮留一個口子，讓銷售人員或者運營人員手工錄入。（手工錄入或者是價格管理，優惠管理這一塊，都會涉及到審批流管理模組設計，這裡不額外展開）

4）優惠管理

支援運營配置優惠方案，如優惠券等。

5）計費順序策略

客戶使用同一產品，可能同時既有免費額度，也購買了預付費資源包或按量付費 ，這就涉及到計費順序的問題，也需要先確認好；比如：預付費QPS>預付費資源包>免費額度>按量付費。

如果購買了多個資源包，抵扣順序可以是從已購買的次數包中按照購買時間順序由早至晚，按照規格由小至大依次扣除相應次數。

6）到期提醒/欠費預警

資源包到期前/資源包即將用完/後付費觸發授信額度，需要提醒使用者續費，否則將停止服務。一是以郵件、簡訊、站內信的方式推送給客戶。二是通知負責該客戶的銷售，銷售透過線下的方式推動客戶。

2。 結算

概念：對賬及發生實際的資金流轉。

1）結算觸發規則

預付費：是下單購買時就會立刻觸發結算，生成賬單，發給客戶確認，無誤後，就會向客戶提供發票，對方支付後，就會下發對應的資源到對方賬戶上。

後付費：到達結算週期，觸發結算，聚和賬單，發給客戶確認，無誤後，提供發票，對方支付。

2）聚合賬單

企業客戶可能有多個子賬號。有幾種方式。

子賬號不單獨計費；子賬號使用主賬號的資源或使用量記在主賬號上。由主賬號負責結算。

子賬號單獨計費；預付費時，主賬號涉及資源分配。由主賬號負責結算。

子賬號單獨計費，獨立結算；一般是組織架構複雜的集團，要求子公司財務獨立核算。

3）對賬

賬單生成後，可能會因為業務上的一些問題需要調整。

4）付款

企業服務，不面向個人開發者時，一般都是線下對公匯款。預付費，匯款完成，即下發對應資源。後付費，匯款完成，即與賬單對應的計費流水進行核銷。

5）欠費管理

如果是預付費，購買時立即支付的方式；當客戶的資源包已經用完，就會進入欠費流程，但是一般不會直接停服；超出資源包的部分可以以按後付費的方式結算，這裡就需要有一個欠費授信管理的策略，需要結合客戶的風險程度，設定一個欠費額度上限。超過上限後，再進入下一步：停服。

如果是後付費，那企業客戶一般有賬期，比如下個月初結算上個自然月的帳，對賬完成後，客戶在30天內支付完成即可；那這個賬期內，也是不停服的，同意需要授信管理策略，超過上限後，則停止服務；後付費，還有一種減少欠費的方式，即客戶使用前先要求對方充值一定的資金用以凍結，使用後再結算，不過一般是大廠才（敢）這麼做。

三、業務資料模型

大框架，頂層設計有了，我們可以提煉出來業務過程中關鍵物件的關係，進而抽象出底層的業務資料模型。

只有業務資料模型清楚了，正確了，建立在這之上的更細節的業務邏輯，流程，功能設計才會清晰無誤；且資料模型的設計會影響到資料庫表結構，欄位的設計，是產品設計的根基，是設計之初就要想清楚的事情。

我之前的文章也提過，從專案的完整生命週期來看，資料表結構決定了拓展性；上線後，如果要改底層的資料表結構，成本會很高。

以計費流程為例，關鍵物件有：客戶、賬號、產品、訂單、賬單、計費模式、計量項、單價、計量（使用量）。

這些物件的關係是什麼樣的呢？我們用ER圖來梳理一下。

簡單介紹一下ER圖：

ER圖概念：ER模型，全稱為實體聯絡模型、實體關係模型或實體聯絡模式圖（Entity Relationship Diagram），提供了表示實體型別、屬性和聯絡的方法，用來描述現實世界的概念模型， 它是描述現實體物件之間關聯關係經典方法。

ER圖三個核心要素：

實體：表示一個物件，可以被（粗略地）認為是名詞，比如會員，優惠券，公司

屬性：物件所具有的屬性，特性。比如會員可以有暱稱，生日，註冊時間等屬性

關係：表示物件與物件之間的聯絡。比如老師這個物件和學生的實體之間的聯絡。

ER圖中關聯關係有三種：

1對1 ：指實體集A與實體集B，A中的每一個實體至多與B中一個實體有關係；反之亦然。

1對多：指實體集A中的每一個實體與B中至少有1個以上的實體有關係；且B中每一個實體至多與A中一個實體有關係。

多對多 ：指A中的每一個實體與B中至少有1個以上的實體有關係；反之亦然。

一般來說，我們設計的時候，如非必要，儘量避免多對多的關聯關係。

這裡只是簡單介紹對ER圖感興趣的同學，可以自行搜尋瞭解更多；另外說一點，ER圖的呈現方式很多，產品不必拘泥於某一個特定形式，描述清楚物件和關係即可。

關於資料，安全，請看下一次更新。

作者：石青；微信公眾號：石青自習室

本文由 @石青 原創釋出於人人都是產品經理。未經許可，禁止轉載

題圖來自 unsplash，基於 CC0 協議