大家对外卖都很熟悉，因为会经常点外卖，我们以外卖场景为例，分析外卖的整个交易链路，从用户下单、商家接单、分配骑手、骑手取餐、配送到用户取餐，从订单、计价、配送、清分、记账、结算到付款，讲清楚每个环节的逻辑和内容。
从一张外卖的小票入手进行分析，研究支付微观层面的业务流转、单据的生成等支付细节，最后抽象出一个可通用的支付清结算体系架构出来。
4.1一张小票
看下面外卖盒上的纸质小票：牛肉拌饭1份一共39元、餐盒费1元，没有配送费，合计40元，优惠了19元，实付21，实收17元；
再看外卖平台（以下简称“平台”）APP中的订单信息：烤肉饭1分39元、打包费1元、配送费原价7元现价2元、平台会员15元；其中红包减7元、满减优惠14元，总优惠26元，订单合计36元，如图4-1所示：
图中可以看出来，商家的小票信息和平台的订单信息之间有不少的差异，特别是优惠的明细展示、优惠总额和应付总额之间存在差异。下面我们就顺藤摸瓜，分析背后的玄机。
4.1.1外卖单据
外卖过程中会产生很多的单据，不同环节的单据会提供给不同的参与者使用，不同单据记载着不同的但又相互关联的信息，我们需要了解这些主要的单据，并知道其用途、相互之间的关联关系和设计方法。这些单据主要包括用户订单、商家小票、商家后台账单、骑手账单、平台内部单据等，接下来逐一分析。
用户订单：在外卖的客户端里，用户的外卖订单信息记录了购买的商品、商品价格、优惠信息、支付信息、配送信息、商家信息等全部内容，这些信息是外卖平台给用户提供的交易记录，如图4-2所示。
商家小票：用户收到的餐盒上都会附带一个纸质小票，也记载着该单商品的基本信息，这个信息是出餐商家给用户提供的本单餐品的服务内容以及收费情况，如图4-1（右）所示。
商家账单：是平台提供给商家的在平台上的经营数据，例如卖了多少餐、挣了多少钱、给商家付了多少款等信息，如图4-3所示。
骑手账单：是平台提供给骑手的在平台的上的服务信息，包括接单信息、收入信息、奖惩信息、付款情况等内容，如图4-4所示。
平台内部单据：是平台自己内部存在很多业务系统，这些系统协同完成整个外卖业务。例如订单系统记录订单，计费系统记录计费结果，账务系统记录账务信息等，这些系统依赖各种单据完成记录以及推动流程的进行，并通过各种单据互相传递信息，如图4-5所示为后台订单管理。
4.1.2外卖业务模型
我们先明白一个关系，订外卖的用户跟商家没有直接的关系，平台跟商家是结算关系，也就是平台帮助商家代收餐费，并向商家结算收入。简而言之，用户付钱给平台，平台抽一部分佣金，剩余部分结算给商家，如图4-6所示。
这个过程大致是这样的，用户先到平台选择喜欢的“餐品”，然后“下单”，生成交易“账单”，用户选择支付方式进行“支付”，支付成功后平台要履行承诺把餐送到，“履约”完成以后平台就开始进行各方利益的“清分”，计算清楚应给谁多少钱，并“记账”，最后将款项“结算”给商家，这个过程如图4-7所示。
当然，一次外卖业务会涉及到非常多的参与者和过程，每个参与者都有自己的一个子流程，这些子流程共同串起整个外卖交易。比如用户选品、下单、支付、取餐、评价；商家接单、制作；骑手接单、到店、取餐、配送、确认送达；平台创建订单、计价、支付处理、分配骑手、记账结算等。
将上述的不同角色、不同行为、不同节点所形成的一个复杂的流程绘制出来，以方便我们动态地审视整个交易链条的全部事件，这也将有利于后续我们去设计抽象清结算的业务节点，如图4-8所示。
基于上面的业务分析，接下来分析开头那张小票在每个环节是怎么处理的，都生成了什么单据，单据中包含哪些信息。
4.2用户下单
用户下单是一次外卖旅程的开始，我们对这个过程再熟悉不过了。用户选择菜品，平台计算本单相应的优惠，计算应该支付的金额等内容，用户完成支付。
为了便于分析，我们让订单更加简单一些，仅分析展出最核心的字段，但是所涉及到的订单结构是完整的；本单用户看到的订单信息如图4-9所示。
图4-9 本次下单的订单信息
4.2.1商品
商品概念广泛应用于电商，在o2o领域可能叫“服务”多一点，站在吃货的角度来看，订外卖，买了一份商品也可以说的过去；一个简单的商品模型如图4-10所示。
本案例中的这单外卖共有3个商品以及配送费，我们将商品信息、商品原价、购买数量、配送费等内容整理到表格中，如表4-1所示：
表4-1：外卖单的商品信息
这里需要特别说一下平台会员，这是平台推出的一个会员服务，相当于花钱买了多张优惠券，如图4-11所示，所以购买平台会员获得优惠券也是一次交易，而且本交易要先与外卖单，因为外卖单的支付用到了这批券。
4.2.2优惠
选购了商品以后，需要知道这一单有什么优惠，本单的优惠主要有3个：配送费5元减免、平台红包减7元、满减优惠减14。把优惠信息增加到表4-1中得到了包含了优惠信息的表格，该订单的优惠比较简单，都是针对整单的优惠，没有针对单品的优惠，未来完整起见我们将单品优惠也放进去，只不过优惠金额为0，如表4-2所示。
表4-2 优惠信息
4.2.3计价
该过程是要计算出本单应该付多少钱，计价包含很多内容，比如计算优惠、计算商品总价、计算配送费、结算优惠后的订单金额、计算用户应付金额等，计算完成以后反馈给交易，常见的计价模块架构如图4-12所示。
对于例子中订单的计价相对比较简单，有时候点的外卖菜品多，计价会复杂一些，从而计价过程也相对复杂很多，但无论计价场景复杂还是简单，基本原理是一样的。我们将计价结果增加到表格中，如表4-3所示。
表4-3 计价信息
用户完成了订单信息的填写和提交，内部系统完成了交易的计价，接下来就是下单了，交易系统请求订单系统完成订单的创建。
4.2.4订单生成
交易系统请求订单系统创建订单，因为不清楚平台和商家之间的清结算协议，所以暂且认为所有优惠由平台提供给用户，后续平台再基于协议跟商家之间做优惠的分摊，将上述商品、优惠、计价等信息集成到一起，就得到了完成的订单信息了，如表4-4所示。
表4-4：订单集成信息
订单信息中平台红包是基于15元购买了平台会员以后才能使用的优惠，因此这一单，需要用户先购买会员获得优惠券，然后在本单使用从而获得红包优惠。虽然在用户看来是同一个订单，但在交易处理层，至少需要做2次处理，一个是对购买平台会员的交易处理，另一个是对本单整单的交易处理；所以订单需要拆成2个子单，一个是外卖单，一个是平台会员购买订单，如表4-5所示：
表4-5：父子订单信息
商家的小票中显示商品总价是40，总优惠是19；跟订单11101之间的26元优惠存在7元的差额，是什么呢？其实就是平台红包7元，本单配送费的5元优惠和满减14是商家优惠，所以商家总优惠19元，而平台红包优惠7元，本单总优惠26元。
但是，发现商家实收17元，那么这4元是什么呢？这里有2个推断，一是平台抽佣4元，另一个可能是商家承担了7元平台红包优惠中的4元；如果是取中间可能的话，那么实际的清分结果可能是如下模型：
4元=x+y
x=平台抽佣；x∈[0-4]元
y=分摊平台红包优惠；y∈[0-4]元
4.2.5交易处理
完成了订单创建以后就需要创建支付账单了。根据上述分析，本单的交易处理相对比较复杂，因为要先处理平台会员的购买交易，然后处理外卖订单交易，这个过程如图4-12所示。
因为有2个子单，所以我们生成2个交易账单，但是在支付的时候进行合并支付，这样做的好处是可以解耦2个交易处理流程，账单信息如表4-6所示。
表4-6：账单信息
有了账单信息以后，基于账单生成支付请求，这里的支付渠道是广义的，其中优惠券、满减等都视为一个支付渠道，也就是在支付信息层都算做一种支付方式，如表4-7所示。
表4-7：账单中的支付信息
4.2.6支付处理
账单生成以后，请求支付系统生成支付单，用户在客户端上通过收银台发起支付请求，其中微信支付请求支付系统；优惠类支付我们等待微信支付成功以后请求营销系统，完成优惠券的核销，这样就完成了整个账单的支付了，此时账单变为已支付，订单支付状态变为已支付，订单的履约状态变为待配送，支付信息如表4-8所示。
表4-8：支付流水信息
4.3履约过程
用户支付成功以后进入履约过程，整个过程包括了商家的接单出餐、骑手的派单和配送、用户的确认收餐以及整个过程的管控。
4.3.1商家接单
商家在其后台可以看到该笔订单，然后选择接单，进行菜品的制作和打包，等待骑手来取餐。以下信息不是我们案例中订单的信息，大家可以自行把本单信息填充到以下的商家账单信息中即可。从图中可以看出账单中展示了商品信息和数量、打包费、优惠信息以及优惠的承担方，如图4-13所示。
4.3.2骑手配送
一个订单可以平台分配给骑手，也可以骑手自己抢单，有很多种方式；这里关于运力的调度和策略不过多赘述。
骑手在骑手端可以看到附近用户下的全部订单，并可以做出决策要不要枪这一单，对于骑手来说距离越短、挣得越多、肯定就越喜欢，抢单页如图4-14所示。
如果觉得这一单的配送费很高，还有奖励活动，那么可以点进去看一看，从地图里可以看出这一单的店铺在哪要配送到哪里，肯定是越近越好，目的地的单量越多越好，配送地图如图4-15所示。
在抢单详情页，骑手也可以看到这一单涉及到的菜品信息、详细的配送费信息等内容，便于骑手做要不要抢单的决策，如图4-16所示。
骑手抢了订单后就可以去店里取餐了，同时用户在客户端也可以看到骑手的实时位置和配送状态，这样可以极大的缓解用户等待的焦虑。
订单变为待配送时，会生成服务订单，也就是配送订单，例如由骑手小王01抢单了，此时服务单信息如表4-9所示：
表4-9：服务单信息
之后的过程包含了取餐、送餐、确认已送达、服务单完成等，服务单完成以后将订单推送至清算中心进行清分计算，以结清各方利益。
4.3.3 管控业务
整个交易过程中会存在各种的突发事件，比如用户把订单取消了、商家拒单了、骑手拒单改派了、骑手把用户的餐弄丢了等等，这时都需要进行一个判责的处理，是谁的责任，要不要罚钱，需不需要封禁等。
4.4清算
用户下了单，商家制作了餐，骑手完成了配送，用户完成了评价，订单就正式完结了，过程中，如果发生了突发事件会被管控。每个环节都可能需要进行记账，而记账业务之前需要先完成计费和清分，比如完单以后商家佣金的计算、过程中骑手奖惩的计算、商家的结算收入、骑手的结算收入等计费业务，这就是接下来要介绍的清算业务。
4.4.1费用
费用是业务层信息到账务层信息转换的非常关键的要素。交易过程中不同的节点、不同的对象、不同的菜品或者活动都会产生不同的费用，比如商家卖了一些菜品，属于商家的菜品费；平台为商家提供了交易平台和配送服务，所以平台也会收取商家的佣金，这样就需要一个佣金的费用。
同样，财务需要基于业务做会计记账，那么不能直接用业务数据直接入账，而是以费用视角入账，比如抽商家的佣金费转换为“平台收入”计入会计收入类科目。
这样我们就需要建立一个费用体系，业务的新增和变化，都需要针对性的建立相应的费用，每个费用也就有了其依赖的业务场景。而对于这一单外卖来说我们需要到如下的费用，如表4-4所示。
表4-10 费用管理
4.4.2清分
清算系统接收到的清算请求数据包含订单信息、账单信息、支付信息、履约信息等。在计费环节有几个关键的模块以及之间的关系如图4-17。
计费模型就是基于订单业务应该计算出什么样的费用出来，例如本单其实有2个业务，一个是外卖业务，一个是平台会员业务。计费模型是平台外卖业务需要计算商家应结算金额、抽佣金额、优惠分摊金额；平台会员计费模型需要计算出平台会员费。再基于业务类型，去查找对应的计费规则，即计费参数、计费基数、计费模式等；本单的计费规则和结果如表4-11所示。
表4-11 计费规则和结果
4.5账务
整个交易过程都需要进行账务的记录，无论是用户支付了多少钱、菜品是多少钱还是优惠了多少钱，以及计费得到的应结商家收入和骑手配送收入，甚至是给商家、骑手代扣代缴的税费。
4.5.1记账场景定义
我们知道记账是在整个交易过程中分多次记录的，用户支付成功以后要记账，商家接单以后要记账，骑手抢单以后要记账，完单以后要记账；这样我们就需要跟业务层约定业务场景的识别，而业务场景就对应了记账的场景。
根据业务的发生流程，这里应该包含正向及逆向、订单类、支付类、管控类、奖惩类、结算类等场景。我们将业务划分成这样的场景并给于定义，并且我们要约定好用什么信息去判定该场景已经发生，比如可以用订单状态，工单流转等标记业务事件，如表4-12所示。
表4-12 业务场景定义
4.5.2记账设定
定义好了业务场景以及费用，就需要设定什么场景发生了需要记什么费用，这些费用要记哪些账，因为一个费用的发生不一定只记一笔账，可能要计入多个账户，我们需要设定每个类场景要记什么账。
当然每个场景发生以后记那些账不仅仅由订单状态这个场景决定，还需要其他要素参与，比如01支付成功，我们还需要知道这个是什么类型的订单，另外需要不需关注渠道，因为不同渠道的订单可能需要记跟渠道的分成，如表4-13所示。
表4-13 场景与记账设定
4.5.3记账交互
业务场景发生以后，后端清分系统需要知道业务发生了，这里需要一个交互信息的方式，可以通过MQ的手段，比如订单支付成功了，订单层就发一个MQ，清分系统监听到该MQ以后通过订单状态字段判断订单状态，如果是“01”就知道这是“01用户支付”成功发生了。
如果该MQ里包含了记账需要的全部信息，则可以以MQ为依据生成业务单据，如果MQ内没有过多信息，就需要订单业务给一个查询数据的服务，比如查询接口或者SQL，通过该服务获取记账需要的全部数据，如图4-18所示。
4.5.4记账规则
每个业务场景发生以后，需要记哪些账在上面已经完成设定。那么这些账怎么记呢？计给哪些对象，计入哪些账户呢？这就是记账规则的职能了，比如我们介绍“01支付成功”以后的记账规则，如表4-14所示。
表4-14 记账规则
有了规则以后，业务发生时就可以通过规则判定该场景需要记哪些账，然后获得相应的数据；获得数据以后先生成原始的业务凭证存下来，然后进行清分处理；这里记账单据我们按生成的先后顺序和依赖关系分成三类：业务凭证，清分明细，账户明细，会计凭证。
4.5.5业务凭证
是业务发生后完成计费以后的最原始的数据，比如订单支付成功以后获得的记账数据存储在清分系统，这笔数据里包含了“01用户支付成功”需要记账的全部信息，如表4-15所示。
表4-15 业务凭证
上面我们介绍了“01用户支付成功”场景发生以后，我们需要记录3个费用“1001，,3005，,30010”，这样我们根据业务凭证的数据进行清分，并根据记账规则知道每个清分出的费用、金额、对象就有了，清分结果如表4-16所示。
表4-16 清分明细
4.5.6账户流水
有了清分明细以后，我们就可以根据记账规则计入对应账户，更新账户余额，记录账户流水了，如图4-19所示。
为了简单起见，这里只对商家的结算和骑手的结算进行记账，生成的账户流水，如表4-17所示。
表4-17 账务流水明细
入账成功后，更新账户余额，账户余额信息如表3-13所示。
表3-13：账户余额信息
4.6结算
结算就是将应付商家和骑手的收入支付出去的过程，可以将商家和骑手的收入直接付款至他们的银行卡中，整个结算过程包括了计税、开票、结算处理、付款处理等过程。
4.6.1税票
计税模式可以按照每个账务明细进行计税、也可以按照每个结算周期进行一次性计税；计税过程需要知道税种是什么、税基是什么、税率是多少等计税规则。
假如我们按照账务明细进行计税，也就是每入一笔账就需要计税；入账成功以后账务系统将入账明细推送给税务子系统，税务子系统根据税种、税基、税率等配置计算该笔入账的税额，并推送账务系统进行税务的扣除，这里要考虑平台是否需要代扣代缴，如果不需要代扣代缴就不需要进行税务的扣除，可以仅进行计算，提供给商家和骑手进行税务什么用，如图4-20所示。
4.6.2结算付款
按照约定我们需要完成给商家和骑手的结算，将商家的应收和骑手的收入打款给他们。不同的城市、不同的商家签订了不同的结算周期，例如日结、周结、月结；结算的依据可以是账户的当期余额，也可以是当期的账户流水；结算的方向可以是指定的平台虚拟账户或者生成结算单付款至指定银行卡。商家和骑手可以在钱包里看到账户余额，然后发起提现；生成提现订单，请求打款中心完成出款，整个清结算的流程框架如图4-21所示。
4.7清结算架构
通过上面对一张外卖小票的详细分析，使得大家对全链路有了清晰的认识，包括交易流、支付流、账务流、结算流等环节。最后，我们将抽象出一套可复用的支付清结算架构出来。
4.7.1外卖清结算架构
外卖业务框架应该包含不同端的操作流程，内部平台的交易流程以及内部系统之间的交互，另外还应该包含接入的外部服务渠道，比如支付渠道、开票渠道等。对外卖业务流程架构抽象如图4-22所示。
再将各角色、各类单据、各系统之间的关系细化以后，可以得到外卖业务的支付清结算产品架构，如图4-23所示。
4.7.2支付清结算架构
依据上面的案例，剔除外卖业务场景以后，可以抽象出一个典型的支付清结算架构，可以应用于更多的业务场景，例如打车、电商、家政等，如图4-23所示。
本页的评论功能已关闭