不同角色在产品各端的操作及整个流转环节的单据生成和关系是怎么样的呢？本文作者以一次外卖的业务流程为例，从用户层到内部业务层进行分析，一起来看一下吧。
说清楚一件事容易，但是说清楚一个体系难；难不代表说不清楚，我们将承接一张小票看透清结算（上）
我们重点讲了很多计费的逻辑和流程，下我们将重点讲不同角色在产品的各端的操作以及整个流转环节的单据生成和关系；这两篇文章放到一起看，信息会更全面和完整。
大家对外卖都很熟悉，因为基本每天都会点外卖，所以像（上）一样，我们依然以外卖场景为例，分析外卖交易全链路；从用户层的“用户下单，商家接单，分配骑手，骑手取餐，配送，用户取餐”到内部业务层的“订单，计价，配送，清分，记账，结算，付款”等方面讲清楚每个环节的逻辑和内容。
一次外卖体验会涉及到非常多的参与者以及过程，每个参与者都有自己的一个子流程，这些子流程共同串起了整个外卖交易的复杂流程体系，这个流程里涉及到了每个角色的行为。
比如：
我们将这些不同角色、不同行为、不同节点所形成的一个复杂的流程绘制成下图，便于我们动态地审视整个交易链条的全部事件；这也有利于后续我们去设计抽象清结算的业务节点。
上面说的过程中会产生很多的单据，每类单据会给到不同的参与者，每类单据记载着不同的但又相互关联的信息，我们要了解这些主要的单据，并知道其用途、关联关系和设计方法。
用户订单，作为外卖的发起者，用户的外卖订单信息记录了购买的商品、商品价格、优惠信息、支付信息、配送信息、商家信息等全部内容，这个信息是外卖平台给用户提供的交易信息。
商家小票，我们收到餐以后餐盒上都会附带一个纸质小票，也记载着该单商品的基本信息，这个信息是商家给用户提供的商品和服务内容以及收费情况。
商家账单，外卖平台给商家提供在平台上的经营数据，卖了多少餐，挣了多少钱，给商家付了多少款的信息。
骑手账单，外卖平台给骑手提供的其在平台的服务信息，包括订单信息，收入信息，奖惩信息，付款情况内容。
内部单据，而外卖平台自己内部存在着众多业务系统，这些系统共同协同完成这行个外卖业务，像订单系统记录订单，计费系统记录计费结果，账务系统记录账务信息等，这些系统依赖各种单据完成记录工作，以及通过各种单据相关链接传递信息。
我们将各角色，各类单据，各系统之间的关系用下面的结构表示：
清楚了外卖的全流程，以及流程中涉及到的单据以后，我们再看，每个环节都是什么样的逻辑，相关单据是如何产生的，单据的具体内容是什么。
用户下单是一次外卖旅程的开始，我们对这个过程再熟悉不过了，就不过多赘述。
用户选择商品，我们假设购买了如下的菜品，本次下单享受的优惠，要支付的信息等，为了便于分析我们让订单更加简单一些，但是其所涉及到的面是完整的；用户看到的订单信息如下：
对于一个订单首先我们要支付其商品有哪些，买了多少数量。
营销优惠，选购了商品以后我们需要知道这一单在这些商品情况下会有什么活动，有多少优惠，本单有如下优惠：
我们再把优惠信息增加到表格中得到了如下的信息，该订单的优惠比较简单，都是针对整单的优惠，没有针对单品的优惠，未来完整起见我们将单品优惠也放进去，只不过优惠金额为0。
交易计价，该过程是要计算出用户下的这一单应该付多少钱，这个计价包含很多内容，比如计算优惠，计算商品总价，计算配送费，结算优惠后的订单金额，计算用户应付金额等，计算完成以后反馈给交易。
对于我们例子中的订单的计价是比较简单的，日常我们点的外卖有时候会非常复杂，那么计价过程也相对复杂很多，只不过无论复杂与简单，原理都是一样的；我们将计价结果记录到表格中：
用户完成了订单的填写和提交，内部系统完成了交易的计价，此时交易系统请求订单系统完成订单的创建，下一步用户就可以进行支付了。
从上面我们知道用户应付金额是47.6，整个支付过程的起点是用户点击去支付，然后跳转到收银台，这个过程我们在收银台设计设计方法中介绍的比较清楚，这里就不详细说明了。
用户支付成功以后商家在其后台就可以看到该笔订单，然后选择接单，进行菜品的制作和打包；以下信息不是我们案例中订单的信息，大家可以脑补一下本单信息填充到以下的商家账单信息中即可；账单中展示了商品信息和数量，打包费，优惠信息以及优惠的承担方。
一个订单可以平台分配给骑手，也可以骑手自己抢单，有很多中方式；这里关于运力的调度和策略不过多赘述，不是本文的重点。
骑手在骑手端可以看到附近用户下的全部订单并可以做出决策要不要枪这一单，对于骑手来说距离越短，挣得越多，肯定就越喜欢。
觉得这一单的配送费很高，还有奖励活动，那么点进去看一看，从地图里可以看出这一单的店铺在哪要配送到哪里，肯定是越近越好，目的地的单量越多越好。
同样骑手可以看到这一单涉及到的菜品信息，详细的配送费信息等内容，便于骑手做要不要抢单的决策。
骑手抢了订单就去店里取餐吧，用户也可以看到骑手的实时位置和配送状态，这样可以极大地缓解用户等待的焦虑。
整个订单过程中会存在各种的事务，比如用户把订单取消了，商家拒单了，骑手拒单改派了，骑手把用户的餐弄丢了等等，都需要进行一个判责，是谁的责任，要不要罚钱，封禁等。
用户下了单，商家制作了餐，骑手完成了配送，用户完成了评价，订单就正式完结了。
整个订单过程中，发生了突发事件被管控，以及订单完结以后，每个环节都可能需要记账，而有些记账业务之前需要完成计费和清分，比如完单以后商家佣金的计算，过程中骑手奖惩的计算，商家的结算收入，骑手的结算收入等业务，以下部分便进入了清结算范畴。
业务在发生的过程中不同的节点，不同的用户，不同的菜品或者活动都会产生各种不同的费用，该费用是业务层信息到账务层信息转换的非常关键的要素，比如商家卖了一些菜品，这些菜品就是商家的菜品收入；平台为商家提供的交易撮合平台和配送服务，所以平台也会收取商家的佣金，这样就需要一个佣金的费用。
同样财务需要基于业务做会计记账，那么不能直接以业务数据入账，而是以费用视角入账，比如抽商家的佣金记为“平台收入”。
这样我们就形成了一个费用体系，业务的新增和变化，都需要针对性的建立新的费用，每个费用也就有了其依赖的业务场景，就如我们的工资一样；而针对这一单外卖来说我们会用到如下的费用：
业务完成以后或者过程当中我们要进行计费，其实在交易计价环节已经完成了一些费用的计算，比如用户实付金额，这也是资金记账的依据。
计费的逻辑和流程我们在清算系统设计方法中介绍的非常详细这里就不在赘述了，总之通过计费以后我们就获得了所有费用的金额。
这里我们约定商家的抽佣为20%，这里我们按照菜品原价进行抽佣：2007商家佣金=54.6*20%=10.92。
整个计费结果如下：
我们知道记账是在整个交易过程中分多次记录的，用户支付成功以后要记账，商家接单以后要记账，骑手抢单以后要记账，完单以后要记账；这样我们就需要跟业务层约定业务场景的识别，而业务场景就对应了记账的场景。
我们根据业务的发生流程，这里应该包含正向及逆向，订单类，管控类，奖惩类等场景，只不过我们本文不涉及逆向过程，大家可以自己思考逆向的过程。
在外卖场景里我们可以将业务划分成这样的场景并给与定义，并且我们要约定好用什么信息去判定该场景已经发生，比如可以用订单状态，工单流转等进行定义。
定义好了业务场景以及费用，那么我们就需要设定什么场景发生了需要记什么费用，这些费用要记哪些账，因为一个费用的发生不一样只记一笔，而是要计入多个账户，我们需要设定每个类场景要记什么账。
当然每个场景发生以后记那些账不仅仅由订单状态这个场景决定，还需要其他要素参与，比如01支付成功，我们还需要知道这个是什么类型的订单，另外需要不需关注渠道，因为不同渠道的订单可能需要记跟渠道的分成。
业务场景发生以后，后端清分系统需要知道业务发生了，这里需要一个交互信息的方式，可以通过MQ的手段，比如订单支付成功了，订单层就发一个MQ，清分系统监听到该MQ以后通过订单状态字段判断订单状态，如果是“01”怎知道这是“01用户支付”成功发生了。
如果说该MQ里包含了记账需要的全部金额那么可以以MQ为依据生成业务单据，如果MQ内没有过多信息，就需要订单业务给一个查询数据的服务，比如查询接口或者SQL，去获取记账需要的数据。
在每个业务场景发生以后我们需要记哪些账在上面已经完成设定，那么这些账怎么记呢，计给哪些对象，计入哪些账户呢？这就是我们的记账规则了，比如我们介绍01支付成功以后的记账：
有了规则以后，业务发生了就可以通过规则判定该场景需要记哪些账，然后获得相应的数据；获得数据以后先生成业务最原始的凭证存下来，然后进行清分处理；这里记账单据我们按生成的先后顺序，依赖关系分成三类：
是业务发生以后完成计费以后最原始的数据，比如订单支付成功以后获得的记账数据存储在清分系统，这笔数据里包含了01用户支付成功需要记账的全部信息：
上面我们介绍了“01用户支付成功”场景发生以后，我们需要记录3个费用“1001、3005、30010”，这样我们根据业务凭证的数据进行清分，并根据记账规则知道每个清分出的费用、金额、对象就有了，清分结果如下：
有了清分明细以后，我们就可以根据记账规则计入对应账户，更新账户余额，记录账户流水了。
计税模式可以按照每个费用进行计税、也可以按照每个结算周期进行计税；同样需要知道是什么税，个人所得税还是增值税。
假如我们按照费用进行计税，也就是每入一笔账都需要计税；入账成功以后账务系统将入账明细推送给税务子系统，税务子系统根据税种、税基、税率等配置计算该笔入账的税额，并推送账务系统进行税务的扣除。
按照约定我们需要完成给商家和骑手的结算，将商家的应收和骑手的收入打款给商家。
这里不同的城市，不同的商家可能有不同的结算周期，有的按照日结，有的按照月结，有的按照周结。
结算的依据可以是账户的当期余额，也可以是当期的账户流水，结算到指定的结算账户或者生成结算单进行打款，这里我们就不详细介绍了，详细介绍可以参考结算系统设计方法
在一张小票看透清结算架构（上）等多篇文章中介绍了不同的架构，这里针对上面介绍的内容进行规则，可以得到下面的架构图，便于理解清结算的业务流程以及单据之间的关联和交互。
专栏作家
陈天宇宙，微信公众号：陈天宇宙，人人都是产品经理专栏作家。多平台支付领域专栏作者，十年资深产品；天使投资人；专注为10万支付产品经理和支付机构以及企业提供深度支付内容和服务！
本文原创发布于人人都是产品经理。未经许可，禁止转载。
题图来自Unsplash，基于CC0协议。
该文观点仅代表作者本人，人人都是产品经理平台仅提供信息存储空间服务。
此内容由惯性聚合(RSS阅读器)自动聚合整理，仅供阅读参考。 原文来自 — 版权归原作者所有。