图22开牌

这时本局以陈老师豹子牌点最大而获胜，获得了桌面全部筹码，不好意思桌面的所有牌都归我了，如图23所示：

图23结束后的桌面清算

9. 全局多边净额清算

天色已晚，大家都困了，这时候协商不玩了，改日再战，这时候开始进行多边清算了，以每个人手里的花生基数为清算依据，每个人需要支付人民币购买他人的花生以获得20枚期初的花生数量，或者卖出手里的花生获得人民币以实现期初的20枚花生，清算后大家手里的花生又回到了期初的20，只不过这次清算是需要进行人民币进行清偿推动的，如图24所示：

图24全局多边净额清算

以上的清算过程存在一些小的错误，感兴趣的可以找出，并在留言处回复讨论，这个过程就是对账的过程，那么就需要对账系统来实现了。

10. 游戏总结

清算系统模型，如果要设计一套支付清算系统，那么从上面我们可以看出至少需要有如下的子系统和元素组成，清算账户、支付系统、交易系统，货币体系，交易场景等。

• 清算基础：我们可以从上面看出清算的基础就是清算账户账户，对整个过程提供账户资金头寸管理以及实现资金的支付清算。
• 清算模式：上面我们用到了实时多边净额清算模式，除此之外还有实时全额清算模式，实时双边清算模式。

11. 如梦清醒会心一笑

此时天塌地陷紫金锤，游龙出海惊天变，一阵天动地摇之后，有一道白光……这时候陈老师一个琅跄差点打翻了牌桌上的茶杯……说时迟那时快之间张三上来扶住了我说到“陈老师怎么了，是不是又起早写文章有点低血糖啊”。

此时我稍作镇定，会心一笑“哈哈 哈哈 没事 今日必定大胜 开牌……”新年的钟声敲响了，屋外已经飘起片片雪花，投眼望去依然灯火通明，每一个窗户透出的灯光里白雾下可能都是我们对2022年幸福的期许……

现在很多平台都有个人商家或者说是服务者，就像外卖平台的骑手，货运平台的司机，家政平台的阿姨，这些个人劳动者在平台提供服务，平台进行收入的结算。虽然有很多灵活就业平台都有成熟的解决方案，或是使用标准的清结算平台完成这部分的服务收入结算，这篇文章将介绍可能不常见的设计方法，但是里面的一些设计思路可能会有一些启发。

1. 结算信息

我们假定为一个货运平台设计司机的收入结算，每个司机按照不同的周期进行结算，特级司机按日进行结算，高级司机按周进行结算，普通司机按月进行结算；结算方式是按照约定周期主动打款给司机签约的银行卡当中，所以我们要有一个基础的结算信息数据，如表3所示：

表3 结算对象信息管理

2. 结算单

该结算单跟我们之前讲的账户有点区别，这个单据更像一个工资条，但是其中有些字段具备账户的部分属性，该结算单的信息更加多，而且每个司机每个结算周期会创建一个本周期的结算单据。该结算单据包含一些统计类的字段，用于记录一些金额，就像我们工资条中的公积金，养老保险，税，应付工资等，例如我们筛选出王五近半年结算单据，如表4所示：

表4 结算单记录

实发收入不能为负，但是实际情况肯定有场景出现本期纯负收入的场景，为了保证这个字段不为负，我们设定另外2个字段，一个是本期欠款，来记录本期总实发的负额部分；上期欠款则是结转上期的欠款金额，本期的上期欠款等于上期的“本期欠款 上期欠款”。

3. 结算信息创建

司机签约认证以后由司机crm来申请创建该司机的结算账户，也就是我们上面的结算信息，并且为其创建第一条结算单据。

4. 结算单据的生成

按照司机的结算周期定期的创建本周期的结算单据，并且实时的根据清分结果更新结算单据的相关数据清分司机在完成一单收入时，由订单系统推送订单到清分系统，完成该单据相应费用的计算，比如本单平台佣金，税等，然后计算本单的司机所得，基于计算结果去更新该司机的结算单据；奖金和罚款同理。

5. 期末账务处理

因为借宿那单据中有几个字段需要在本期完结以后才能进行统一处理，比如欠款的处理。所以在一个结算周期结束的第二天凌晨，打款之前，我们要完成期末账务的处理，比如汇总生成本期欠款，汇总生成本期实发等等。

6.打款

到了结算周期结束的第二天凌晨基于结算单据的“实发收入”生成打款订单，请求打款系统进行打款。

7. 学习会越来越有效率

我想前面我们有大量的介绍清结算账户等相关的内容，大家现在应该很容易理解任何一种结算手段和方式，学习肯定是越来越轻松，接收内容的效率越来越高。

就像我最近看很多支付类书籍，速度越来越快，因为你单单看到标题，然后扫描一下正文中的关键字眼基本就知道他在讲什么，已经了解的东西，就一扫而过，快速地扫描一下，大脑提取一次同类知识点，补充书中的新内容即可。所以说学习的越多，后面的升级效率越快……量变终会引起质变。

最舒服的工作，可能不是工作本身，而是你对工作的把控力；如果任何一次需求、任何一次沟通，只要对方说出某几个关键字，你已经有了最好的答案，我想这就是最舒服的工作，因为你从不会因为“难度”而痛苦，加油，让自己面对的一切都变得简单，即使在别人眼里，它是巨大的挑战！

我们都知道清结算，因为课堂刚刚完结了这个专栏的20节课；我想我们很多人也都知道中台，因为这个概念活了很长时间。那么什么是“清结算中台”呢？我想也很容易理解，无非就是用“中台的理念”建设“清结算体系”。

那这样的话，要想做好中台，首先就要理解什么是中台，中台的核心是什么？清结算的相关系统如何向中台靠拢，做成中台的样子…..这是这篇文章要介绍的内容。

可以说我们在创造一种事物或者系统建设的理念和方法，那么抽取这个理念和方法首先就需要挖掘其最核心最突出的特征。清结算业务或者相关系统本身跟商品系统、购物车、订单、服务履约等系统，除了功能模块不同以外本质没有实质性差别，都是基于某项业务将功能集成了一个系统。

所以说在系统本身没有最突出的特征，最突出的特征就必然从“中台”这个系统建设理念上去挖掘。

什么是中台呢，中台又有什么最核心的特征？我们常说的抽象通用能力，规避重复建设等这些是中台的目的。而我们分析中台的核心特征可以概括为这样一个模型：三层式。

如果将清结算体系规范成“三层式”去建设，那么就是“清结算中台”，这三层如图25所示：

图25三层式结算清结算中台架构

1）业务层

清结算中台要关注业务场景，为业务场景提供系统服务，多业务线、复杂的业务场景中的清结算业务是清结算中台服务的对象，所以说清结算不再是独立的一个个后台系统，而是一个服务集群，我们要基于“服务”去建设系统。

2）服务层

服务层是基于服务对象抽象出来的服务单元，就像我们去银行办事，大厅的接待员会接待你。传统上来说她是个接待员，但是站在服务的角度，她提供了“接待服务”，虽然她还是她，虽然接待还是接待，但是已经大不同。基于接待服务去思考，我们会更关注服务本身，而不是她这个接待员。

所以清结算中台，我们不再关注清结算体系内单独的系统本身，而是去关注这套系统能向外提供的服务，以服务论影响。既然是“服务层”，那么我们就需要去抽象这些服务，定义这些服务，以及设计这些服务的准入标准、流程、规范，以及这些服务的提供方式，API，MQ，SQL还是……

3）基础层

这一侧就如“接待员”一样，是我们对外提供服务的能力基础，所以我们可以称之为“能力基础层”，这一层是以系统能力为建设对象，比如清算计费的能力、账务记录的能力、账户冻结的能力。这些能力简单的说就是我们曾经的叫“功能”的另一个说法，为了显得我们是一个专业的中台，我们对外宣称，我们这不是简单的功能，而是能力集群。

这三层之间的关系，我们不如用一段描述来定义。公司的业务复杂，为了规避重复建设，搭建通用的系统，可以多业务线复用，未来新业务可以复用；我们基于业务场景进行抽象，抽象出原子化的服务单元；这些服务单元需要一系列的系统功能来支撑，而这些系统功能抽象出通用的系统服务能力，将这些服务能力进行封装，构建成了一个能力集群，所以说清结算中台的未来要关注三个东西，如图26所示：