我们知道,每一笔支付最终都要进行结算,一般会有众多参与者或利益方,在完成之后,算清相关的利益关系,完成利益分配。本文作者对完成利益分配的“清算系统”进行了详细的阐述分析,一起来看一下吧。
支付完成以后进行履约,履约完成以后就需要清算各方利益并最终进行结算,清结算体系与支付体系并行是支付范畴另一个非常庞大的体系。
一、清算系统设计
我们都知道一笔支付最终都是要进行清算的,业务一般都会有众多参与者或者利益方,事做完以后,算清楚相关的利益关系,完成利益分配。今天我们就来讲一讲这个算清楚账完成利益分配的系统“清算系统”。
1. 清算系统概述
我们先看下清算的定义以及银联的清算的含义。
《支付清算组织管理办法》规定:
- 支付清算:支付指令的交换和计算
- 支付指令:参与者以纸质、磁介质或电子形式发出的,办理确定金额的资金转账命令
- 支付指令的交换:提供专用的支付指令传输路径,用于支付指令的接收、清分和发送
- 支付指令的计算:对支付指令进行汇总和轧差
- 参与者:接受支付清算组织章程制约,可以发送、接收支付指令的金融机构及其他机构
银联的支付清算包括淸分和资金划拨两个环节:
1)淸分
对交易日志中记录的成功交易,逐笔计算交易本金及交易费用(手续费、分润等),然后按清算对象汇总轧差形成应收或应付金额。简言之,就是搞清楚今天应该向谁要多少钱?应该给谁多少钱?
2)资金划拨
通过特定的渠道和方式,完成应收应付资金的转移。简言之,就是明确通过何种渠道,拿回应收款、付出应付款。
从上面的定义可以看出,清算最核心的其实就是清分这个过程,也就是算清楚各方应收应付的这个过程。今天我们重点讲的就是这个过程,以及记账的过程。而承载这个过程的系统,我们称为清算系统。
2. 清算系统的位置
我们在一张支付小票这篇文章里提出过“311架构模型”,在这里我们可以看到清算系统的位置,在交易系统之后;这样的话我们可以理解为,清算系统在订单,交易,支付之后。上述三者都有可能基于本身的业务来请求清算,比如基于订单清算商家结算款,基于交易计算卡券营销等成本,基于支付计算通道成本等,如图1所示:
图1 结算系统所处位置
3. 清算业务架构
清算系统整个结构由以下几部分组成。之前在O2O清结算实战中我们详细讲过一次,主要包括上游请求系统、商家模型子系统、计算核心、计费子系统、账务前置模块。后面会详细讲解每一个模块的职能以及设计关键点,如图2所示:
图2 清算系统架构
4. 上游请求系统
简而言之,有清分需求的业务系统都可以称为清算系统的上游,向清算系统发起清算请求,比如订单、交易、支付。上述三者都有可能基于本身的业务来请求清算,比如基于订单清算商家结算款,基于交易计算卡券营销等成本,基于支付计算通道成本等。
5. 对象模型
对象模型就是你算出来的应收应付的债权对象,以及对象之间的关系。比如外卖平台的一个订单,可能会涉及到众多的利益对象,比如外卖平台要抽佣,提供饭餐的商家要餐费,骑士小哥要快递服务费,骑士小哥的保险费,这些需要完成订单的分账;而外卖平台还可能有很多渠道或者合伙人,需要给渠道和合伙人进行分润等。
分账就是将一款项分成多份给多方;而分润其实就是平台将计算所得例如分给多个分润方。
一个公司的业务可能不同的业务会有不同的对象模型,比如单一的商家,有合伙人的商家,有渠道商的商家,还有服务商平台商的商家。所以每一类订单会有不同的商户模型,进行计算时,计算的维度会有不同。
那么我们抽象出常见的集中对象关系模型,如图3所示:
图3 常见对象关系模型
在商家注册时,或者入驻时,在对象模型子系统生成他的对象模型,以及模型对应的对象关系。比如你通过了好友的邀请注册了一个网站,那么好友就成了你的合伙人了,那么你的对象模型就是“合伙人-用户模型”,当你有了消费时,会去计算给你好友作为你的合伙人的分成。
6. 计费规则子系统
计费子系统核心职能就是维护计费规则,基于算账服务的请求返回计费模式以及参数值。比如单商家模型需要计算平台的信息服务费,那么通过基础参数请求计费子系统获得信息服务费的计费模式(按比例,固定金额,按单笔阶梯还是累计阶梯),拿到计费规则以后便可以计算出信息服务费数值。
所有最核心的就是要基于业务特点抽象出计费规则的模型。
一个是匹配的模式,就是你要用什么方法去到规则池里找到规则,比如条件法,就是一组参数去匹配到规则,这个也是最常用的,那么你就需要为不同的计费类型设置不同的匹配条件组,比如例子中通过“类目+城市”去找规则,这样的话再匹配条件里可以设置灵活的条件组。
然后就是规则的设置,一条规则应该有哪些维度组成,这样我们将每一个费用的计算认为是一个函数。
分成费用=f(x)=g{ j(a) , k(b,c) , l[y,z, p(e,r,u) ] }
那你规则就需要能够使这个符合函数得到f(x)的值。
分成模式:固定金额,固定比例,按单笔阶梯,按累计阶梯,递减等。
下面是在选择了模式以后要配置的规则参数:
- 频率:就是在递减时,递减的频率是按月还是按日还是按年
- 首月:我们设定一个首月的数值,也就是递减的期初值
- 递减金额:每次减多少
- 最低金额:减到多少就固定下来了
看一个计费规则配置的示例,如图4所示:
图4 合伙人分成计费规则配置
基于上面的一个配置器,我们可以配置出非常多的规则,那么基于不同的费用的配置模板我们就可以配置出无穷个计费的规则了,如图5所示:
如图5 合伙人分成计费规则列表
7. 算账服务
一个清算请求来了以后,不同的清算类型我们的计算任务是不一样,计算的模式也是不一样的,计算的结果也会不一样。所以算账模型我们同样需要设计抽象出来,比如首先是通过清算类型确定清算的模板,基于清算模板我们就知道了应该计算哪些费用以及做什么任务,然后逐个去计算每一个费用即可,对于整个计算流程里如果需要做一些处理的进行处理即可。
关于分润和分账,基于不同的对象模型,我们可以知道哪些是要算分润,哪些是要算分账,我们用下面的这个代理商,商家,分账方来看,如图6所示:
图6 分账与分润
8. 清分结果
我们在一张小票看透支付清结算架构中讲了清分计费的结果是什么样的了,比如下面,我们算出来这笔外卖单的相关应收应付以及所属主体对象,如表1所示:
表1 清分明细
这是清分明细,那么是不是需要汇总轧差,这个看业务需要,一般情况下我们可以选择单笔入账的,也就是算出一笔入一笔。
9. 记账服务
清分完成以后,我们就需要做入账处理了,这个我们在账户系统设计从入门到精通讲得比较清楚,大家可以复习一下。
二、结算系统设计
每个月公司要给员工结算工资:陈老师在京东开了一个店铺,定期京东需要给我结算货款;你请了一个保姆,每个月要给阿姨结算服务费….等等,结算场景我们并不陌生,但是怎么设计一个结算系统,你知道么!今天我们就好好聊一聊(最后有原型页面)。
1. 什么是结算
定义:将平台的代收款支付给平台商家的资金转移过程。
展开来讲就是现在有很多平台比如滴滴,货拉拉,京东商城,作为一个服务平台上面有很多商家(我们将滴滴司机也成为商家),用户在平台购买商品或者服务,服务完成后,平台需要按照协议约定将服务款抽取一定费用后的剩余部分结算到商家的平台结算账户中或者直接付款支商家银行账户的资金划转过程。
结算名词解释,如表2所示:
表2 结算常见名词解释
2. 结算的模式
结算我们常见的有2种模式:
- 结算到银行卡:直接将结算款项直接付款到商家签约的结算银行卡账户中
- 结算到虚拟户:将虚拟结算款结算入账到商家在平台开通的结算户中,后续可以商家自主提现
像微信支付宝在开通支付产品时都会获得一个商户号,每个商户号会有一套账户用于收款和结算,并且签约绑定一张结算卡,次日会将上一日的结算款先结算之虚拟户在一笔结算之绑定的对公户。当然结算到对公户的比例可以自己设定,可以全额结算也可以部分结算,将一部分资金留在虚拟户里,用于次日的退款或者其他付款需求。
3. 关于结算产品
结算产品其实就是指支撑不同类型结算模式的结算能力:
- T1结算:工作日结算,当天的服务款,在下一个工作日结算
- D1结算:日然日结算,当天的服务款,在下一个自然日结算
- D0结算:日然日结算,当天的服务款,在当天结算
- S0结算:交易完成后即可结算,按照订单号逐笔进行结算,像借贷的还款,一般逐笔
结算功能,用户可以选择系统自动结算,也可以选自主发起结算。
- 自动:系统按照结算协议,在约定时间自动将服务款支付给结算卡
- 自助:商家需要自主的在服务平台完成可结算周期内的款项的结算申请
结算签约,商家入驻平台时会进行资质认证以及签约一款适合自己的结算产品。
4. 结算场景
上面还是比较抽象,我们列举几个容易理解的结算场景:
- 支付公司将收单款结算给商户
- 电商平台将交易款结算给商家
- 滴滴平台将打车钱结算给司机
- 电影院将票房结算给各方
- 公司将工资结算给员工
所以,简而言之,结算就是将属于别人的钱给到别人。
5. 如何评价结算产品的好坏
评价结算系统的好和坏一个是站在公司角度,另一个是站在用户角度。
- 站在公司角度:准确率高,资金安全,能容用户满意,投诉少
- 站在用户角度:支持银行多,服务好就是后台好用,到账快,成本低
6. 结算的业务架构
业务完成后,到了结算节点,账务系统按照结算周期将已经入账待结算数据打包后推送给结算系统,结算系统对结算数据进行处理加工后生成结算记录和结算明细;然后请求账务系统进行结算打款,账务系统请求账户中心扣款之后调用打款中心进行打款申请,如图7所示:
图7结算的业务流程
版权声明:本文内容由互联网用户贡献,该文观点仅代表作者本人。本站不拥有所有权,不承担相关法律责任。如发现有侵权/违规的内容, 联系QQ15101117,本站将立刻清除。