清算系统设计方法（清算）

编辑导语：所谓清算，是支付指令的交换和计算，其中的核心便是清分过程；承载清分过程及记账过程的就是清算系统，协助了利益分配的完成。那么作为常见的业务系统之一，清算系统应当如何设计？本文作者就对清算系统设计做了相关阐述，一起来看一下。

我们都知道一笔支付最终都是要进行清算的，业务一般都会有众多参与者或者利益方；事做完以后，算清楚相关的利益关系，完成利益分配，今天我们就来讲一讲这个算清楚账、完成利益分配的系统“清算系统”。

一、清算系统概述

我们先看下清算的定义以及银联的清算的含义。

《支付清算组织管理办法》规定：

支付清算是指支付指令的交换和计算；支付指令是指参与者以纸质、磁介质或电子形式发出的，办理确定金额的资金转账命令;支付指令的交换是指提供专用的支付指令传输路径，用于支付指令的接收、清分和发送；支付指令的计算是指对支付指令进行汇总和轧差；参与者是指接受支付清算组织章程制约，可以发送、接收支付指令的金融机构及其他机构。

银联的支付清算包括淸分和资金划拨两个环节：淸分是指对交易日志中记录的成功交易，逐笔计算交易本金及交易费用（手续费、分润等），然后按清算对象汇总轧差形成应收或应付金额。简言之，就是搞清楚今天应该向谁要多少钱？应该给谁多少钱？

资金划拨是指通过特定的渠道和方式，完成应收应付资金的转移。简言之，就是明确通过何种渠道，拿回应收款、付出应付款。

从上面的定义可以看出，清算最核心的其实就是清分这个过程，也就是算清楚各方应收应付的这个过程。今天我们重点讲的就是这个过程，以及记账的过程。而承载这个过程的系统，我们称为清算系统。

二、清算系统的位置

我们在一张支付小票这篇文章里提出过“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协议

阅读剩余 70%

原创文章，作者：PHCYFZ，如若转载，请注明出处：https://www.beidanyezhu.com/a/4762.html