清算系統設計方法

編輯導語：所謂清算，是支付指令的交換和計算，其中的核心便是清分過程；承載清分過程及記賬過程的就是清算系統，協助了利益分配的完成。那么作為常見的業務系統之一，清算系統應當如何設計？本文作者就對清算系統設計做了相關闡述，一起來看一下。

我們都知道一筆支付最終都是要進行清算的，業務一般都會有眾多參與者或者利益方；事做完以后，算清楚相關的利益關系，完成利益分配，今天我們就來講一講這個算清楚賬、完成利益分配的系統“清算系統”。

一、清算系統概述

我們先看下清算的定義以及銀聯的清算的含義。

《支付清算組織管理辦法》規定：

支付清算是指支付指令的交換和計算；支付指令是指參與者以紙質、磁介質或電子形式發出的，辦理確定金額的資金轉賬命令;支付指令的交換是指提供專用的支付指令傳輸路徑，用于支付指令的接收、清分和發送；支付指令的計算是指對支付指令進行匯總和軋差；參與者是指接受支付清算組織章程制約，可以發送、接收支付指令的金融機構及其他機構。

銀聯的支付清算包括淸分和資金劃撥兩個環節：淸分是指對交易日志中記錄的成功交易，逐筆計算交易本金及交易費用（手續費、分潤等），然后按清算對象匯總軋差形成應收或應付金額。簡言之，就是搞清楚今天應該向誰要多少錢？應該給誰多少錢？

資金劃撥是指通過特定的渠道和方式，完成應收應付資金的轉移。簡言之，就是明確通過何種渠道，拿回應收款、付出應付款。

從上面的定義可以看出，清算最核心的其實就是清分這個過程，也就是算清楚各方應收應付的這個過程。今天我們重點講的就是這個過程，以及記賬的過程。而承載這個過程的系統，我們稱為清算系統。

二、清算系統的位置

我們在一張支付小票這篇文章里提出過“311架構模型”，在這里我們可以看到清算系統的位置，在交易系統之后。

這樣的話我們可以理解為，清算系統在訂單、交易、支付之后。

上述三者都有可能基于本身的業務來請求清算，比如基于訂單清算商家結算款、基于交易計算卡券營銷等成本、基于支付計算通道成本等。

三、清算業務架構

清算系統整個結構由以下幾部分組成，之前在O2O清結算實戰中我們詳細講過一次。

主要包括上游請求系統、商家模型子系統、計算核心、計費子系統、賬務前置模塊，后面會詳細講解每一個模塊的職能以及設計關鍵點。

四、上游請求系統

簡而言之，有清分需求的業務系統都可以稱為清算系統的上游，向清算系統發起清算請求，比如訂單、交易、支付。

上述三者都有可能基于本身的業務來請求清算，比如基于訂單清算商家結算款、基于交易計算卡券營銷等成本、基于支付計算通道成本等。

五、對象模型

對象模型就是你算出來的應收應付的債權對象，以及對象之間的關系。

比如外賣平臺的一個訂單，可能會涉及到眾多的利益對象，比如外賣平臺要抽傭，提供飯餐的商家要餐費，騎士小哥要快遞服務費，騎士小哥的保險費，這些需要完成訂單的分賬。而外賣平臺還可能有很多渠道或者合伙人，需要給渠道和合伙人進行分潤等。

分賬就是將一款項分成多份給多方，而分潤其實就是平臺將計算所得例如分給多個分潤方。

一個公司的業務可能不同的業務會有不同的對象模型，比如單一的商家、有合伙人的商家、有渠道商的商家，還有服務商平臺商的商家。所以每一類訂單會有不同的商戶模型，進行計算時，計算的維度會有不同。

那么我們抽象出常見的集中對象關系模型，還有更復雜的模型，這里就不再列舉了。

在商家注冊時，或者入駐時，在對象模型子系統生成他的對象模型，以及模型對應的對象關系。

比如你通過了好友的邀請注冊了一個網站，那么好友就成了你的合伙人了，那么你的對象模型就是“合伙人——用戶模型”。當你有了消費時，會去計算給你好友作為你的合伙人的分成。

六、計費規則子系統

計費子系統核心職能就是維護計費規則，基于算賬服務的請求返回計費模式以及參數值。

比如單商家模型需要計算平臺的信息服務費，那么通過基礎參數請求計費子系統獲得信息服務費的計費模式（按比例、固定金額，按單筆階梯還是累計階梯），拿到計費規則以后便可以計算出信息服務費數值。

所有最核心的就是要基于業務特點抽象出計費規則的模型。

一個是匹配的模式，就是你要用什么方法去到規則池里找到規則。

比如條件法，就是一組參數去匹配到規則，這個也是最常用的，那么你就需要為不同的計費類型設置不同的匹配條件組。比如例子中通過“類目+城市”去找規則，這樣的話在匹配條件里可以設置靈活的條件組。

然后就是規則的設置。一條規則應該有哪些維度組成，這樣我們將每一個費用的計算認為是一個函數：

分成費用=f(x)=g{ j(a) , k(b,c) , l[y,z, p(e,r,u) ] }

那你規則就需要能夠使這個符合函數得到 f(x) 的值。比如下圖中我們將規則抽象出了以下幾個維度；紅字部分就是函數 f(x) 的公式。

分成模式：固定金額、固定比例、按單筆階梯、按累計階梯、遞減等。

下面是在選擇了模式以后要配置的規則參數：

• 頻率：就是在遞減時，遞減的頻率是按月還是按日還是按年；
• 首月：我們設定一個首月的數值，也就是遞減的期初值；
• 遞減金額：每次減多少；
• 最低金額：減到多少就固定下來了。

基于上面的一個配置器，我們可以配置出非常多的規則，那么基于不同的費用的配置模板我們就可以配置出無窮個計費的規則了。

七、算賬服務

一個清算請求來了以后，不同的清算類型我們的計算任務是不一樣，計算的模式也是不一樣的，計算的結果也會不一樣。

所以算賬模型我們同樣需要設計抽象出來，比如首先是通過清算類型確定清算的模板，基于清算模板我們就知道了應該計算哪些費用以及做什么任務，然后逐個地去計算每一個費用即可。對于整個計算流程里如果需要做一些處理的進行處理即可。

算賬過程

其實我們在3里已經講了一個處理的過程，這里就不再介紹了。

關于分潤和分賬，基于不同的對象模型，我們可以知道哪些是要算分潤，哪些是要算分賬，我們用下面的這個代理商、商家、分賬方來看。

八、清分結果

我們在這篇文章里一張小票看透支付清結算架構講了清分計費的結果是什么樣的了，比如下面，我們算出來這筆外賣單的相關應收應付以及所屬主體對象。

這是清分明細，那么是不是需要匯總軋差？這個看業務需要，一般情況下我們可以選擇單筆入賬的，也就是算出一筆入一筆。

九、記賬服務

清分完成以后，我們就需要做入賬處理了。這個我們在《賬戶系統設計從入門到精通》講得比較清楚，大家可以復習一下。

#專欄作家#

陳天宇宙，微信公眾號：陳曉光，人人都是產品經理專欄作家。10年產品設計經驗，曾任職于某頭部金融，某頭部支付機構，云對賬創始人獲千萬融資。

本文原創發布于人人都是產品經理。未經許可，禁止轉載

題圖來自Unsplash，基于CC0協議