一张小票看透清结算架构（下）
说清楚一件事容易，但是说清楚一个体系难；难不代表说不清楚，我们将承接一张小票看透清结算（上）
我们重点讲了很多计费的逻辑和流程，下我们将重点讲不同角色在产品的各端的操作以及整个流转环节的单据生成和关系；这两篇文章放到一起看，信息会更全面和完整。
大家对外卖都很熟悉，因为基本每天都会点外卖，所以像（上）一样，我们依然以外卖场景为例，分析外卖交易全链路；从用户层的“用户下单，商家接单，分配骑手，骑手取餐，配送，用户取餐”到内部业务层的“订单，计价，配送，清分，记账，结算，付款”等方面讲清楚每个环节的逻辑和内容。
01 一次外卖的业务流程
一次外卖体验会涉及到非常多的参与者以及过程，每个参与者都有自己的一个子流程，这些子流程共同串起了整个外卖交易的复杂流程体系，这个流程里涉及到了每个角色的行为。
比如：
- 用户选品、下单、支付、取餐、评价
- 商家的接单、制作
- 骑手的接单、到店、取餐、配送、确认送达
- 平台的订单创建，计价计费、支付提交、分配骑手、记账结算
我们将这些不同角色、不同行为、不同节点所形成的一个复杂的流程绘制成下图，便于我们动态地审视整个交易链条的全部事件；这也有利于后续我们去设计抽象清结算的业务节点。
02 搞清楚这些单据
上面说的过程中会产生很多的单据，每类单据会给到不同的参与者，每类单据记载着不同的但又相互关联的信息，我们要了解这些主要的单据，并知道其用途、关联关系和设计方法。
用户订单，作为外卖的发起者，用户的外卖订单信息记录了购买的商品、商品价格、优惠信息、支付信息、配送信息、商家信息等全部内容，这个信息是外卖平台给用户提供的交易信息。
我们再把优惠信息增加到表格中得到了如下的信息，该订单的优惠比较简单，都是针对整单的优惠，没有针对单品的优惠，未来完整起见我们将单品优惠也放进去，只不过优惠金额为0。
交易计价，该过程是要计算出用户下的这一单应该付多少钱，这个计价包含很多内容，比如计算优惠，计算商品总价，计算配送费，结算优惠后的订单金额，计算用户应付金额等，计算完成以后反馈给交易。
对于我们例子中的订单的计价是比较简单的，日常我们点的外卖有时候会非常复杂，那么计价过程也相对复杂很多，只不过无论复杂与简单，原理都是一样的；我们将计价结果记录到表格中：
用户完成了订单的填写和提交，内部系统完成了交易的计价，此时交易系统请求订单系统完成订单的创建，下一步用户就可以进行支付了。
04 用户支付
从上面我们知道用户应付金额是47.6，整个支付过程的起点是用户点击去支付，然后跳转到收银台，这个过程我们在收银台设计设计方法中介绍的比较清楚，这里就不详细说明了。
05 商家接单制作
用户支付成功以后商家在其后台就可以看到该笔订单，然后选择接单，进行菜品的制作和打包；以下信息不是我们案例中订单的信息，大家可以脑补一下本单信息填充到以下的商家账单信息中即可；账单中展示了商品信息和数量，打包费，优惠信息以及优惠的承担方。
09 清分计费
业务完成以后或者过程当中我们要进行计费，其实在交易计价环节已经完成了一些费用的计算，比如用户实付金额，这也是资金记账的依据。
计费的逻辑和流程我们在清算系统设计方法中介绍的非常详细这里就不在赘述了，总之通过计费以后我们就获得了所有费用的金额。
这里我们约定商家的抽佣为20%，这里我们按照菜品原价进行抽佣：2007商家佣金=54.6*20%=10.92。
整个计费结果如下：
10 记账场景定义
我们知道记账是在整个交易过程中分多次记录的，用户支付成功以后要记账，商家接单以后要记账，骑手抢单以后要记账，完单以后要记账；这样我们就需要跟业务层约定业务场景的识别，而业务场景就对应了记账的场景。
我们根据业务的发生流程，这里应该包含正向及逆向，订单类，管控类，奖惩类等场景，只不过我们本文不涉及逆向过程，大家可以自己思考逆向的过程。
在外卖场景里我们可以将业务划分成这样的场景并给与定义，并且我们要约定好用什么信息去判定该场景已经发生，比如可以用订单状态，工单流转等进行定义。
11 场景发生与记账设定
定义好了业务场景以及费用，那么我们就需要设定什么场景发生了需要记什么费用，这些费用要记哪些账，因为一个费用的发生不一样只记一笔，而是要计入多个账户，我们需要设定每个类场景要记什么账。
当然每个场景发生以后记那些账不仅仅由订单状态这个场景决定，还需要其他要素参与，比如01支付成功，我们还需要知道这个是什么类型的订单，另外需要不需关注渠道，因为不同渠道的订单可能需要记跟渠道的分成。
12 记账交互
业务场景发生以后，后端清分系统需要知道业务发生了，这里需要一个交互信息的方式，可以通过MQ的手段，比如订单支付成功了，订单层就发一个MQ，清分系统监听到该MQ以后通过订单状态字段判断订单状态，如果是“01”怎知道这是“01用户支付”成功发生了。
如果说该MQ里包含了记账需要的全部金额那么可以以MQ为依据生成业务单据，如果MQ内没有过多信息，就需要订单业务给一个查询数据的服务，比如查询接口或者SQL，去获取记账需要的数据。
13 记账规则
在每个业务场景发生以后我们需要记哪些账在上面已经完成设定，那么这些账怎么记呢，计给哪些对象，计入哪些账户呢？这就是我们的记账规则了，比如我们介绍01支付成功以后的记账：
有了规则以后，业务发生了就可以通过规则判定该场景需要记哪些账，然后获得相应的数据；获得数据以后先生成业务最原始的凭证存下来，然后进行清分处理；这里记账单据我们按生成的先后顺序，依赖关系分成三类：
- 业务凭证
- 清分明细
- 账户明细
- 会计凭证
14 业务原始凭证
是业务发生以后完成计费以后最原始的数据，比如订单支付成功以后获得的记账数据存储在清分系统，这笔数据里包含了01用户支付成功需要记账的全部信息：
15 清分凭证
上面我们介绍了“01用户支付成功”场景发生以后，我们需要记录3个费用“1001、3005、30010”，这样我们根据业务凭证的数据进行清分，并根据记账规则知道每个清分出的费用、金额、对象就有了，清分结果如下：
16 账户流水
有了清分明细以后，我们就可以根据记账规则计入对应账户，更新账户余额，记录账户流水了。
17 计税开票
计税模式可以按照每个费用进行计税、也可以按照每个结算周期进行计税；同样需要知道是什么税，个人所得税还是增值税。
假如我们按照费用进行计税，也就是每入一笔账都需要计税；入账成功以后账务系统将入账明细推送给税务子系统，税务子系统根据税种、税基、税率等配置计算该笔入账的税额，并推送账务系统进行税务的扣除。
18 结算付款
按照约定我们需要完成给商家和骑手的结算，将商家的应收和骑手的收入打款给商家。
这里不同的城市，不同的商家可能有不同的结算周期，有的按照日结，有的按照月结，有的按照周结。
结算的依据可以是账户的当期余额，也可以是当期的账户流水，结算到指定的结算账户或者生成结算单进行打款，这里我们就不详细介绍了，详细介绍可以参考结算系统设计方法
19 清结算架构总结
在一张小票看透清结算架构（上）等多篇文章中介绍了不同的架构，这里针对上面介绍的内容进行规则，可以得到下面的架构图，便于理解清结算的业务流程以及单据之间的关联和交互。
作者
陈天宇宙，微信公众号：陈天宇宙。多平台支付领域专栏作者，十年资深产品；天使投资人；专注为10万支付产品经理和支付机构以及企业提供深度支付内容和服务！
版权声明
本文来自互联网用户投稿，文章观点仅代表作者本人，不代表本站立场。本站仅提供信息存储空间服务，不拥有所有权，不承担相关法律责任。如若转载，请注明出处。如若内容有涉嫌抄袭侵权/违法违规/事实不符，请点击 举报 进行投诉反馈！
