联营结算平台建设之路

联营结算平台概述

线下店的经营方式，一般分为自营、联营、和租赁模式。所谓联营模式，就是商家借用线下店门店内部场地进行经营，由线下店门店统一管理的经营模式。

本文档旨在给出一种联营模式下商家结算的业务通用解决方案，其中自营模式和租赁模式，不在此文的研究范围内，但实际上，设计上是可以放在一起的。本文档只给出一个该业务模式下，一种可行的解决思路，并不提供设计的细节，更多细节请参考《联营结算详细设计》。

商户入驻结算

商户入驻结算概述

这里研究的商户入驻，只关心与结算相关的部分。按照概述中所描述，线下店有自营、联营、租赁模式。自营和联营，涉及到商家上的区别，自营一般是平台方从供应商采购商品，平台采购后，进行了物权的转移，物权从供应商转移到平台方，利润所得归属平台方。而联营商实际物权，还是归属联营商家本身，当订单销售时，需要将利润进行清分计算，并按一定的规则结算给相关参与方。

随着电商的发展，商业形态开始多元化，多元化的商业合作模式，带来了结算的复杂化，这里简要举几个常见的形态，力在表述这些形态给系统层面带来的变化，比如：供销模式、门店销售模式、租户模式。

供销模式 ：供销模式的本质是，一个订单的结算，订单虽然属于分销商销售，但是此订单在某些商业场景内需要给供应商进行分润，增加了分润的关系，一般分润的关系，会通过计费系统进行清分计算。这种模式主要是引入了商家类型的多元化，由原始单一类型商家结算，变化为多类型商家结算的支持。相关的计费结算出的明细类似如下表格：

门店模式 ：如现在比较火的线下零售店，线下店由联营商进行联合营运，而联营商在入驻不同门店时，实际上签署协议的时候很可能分门店进行合同签署，而不同门店的销售情况联营商也希望能分别结算到不同的账户，并且提供不同的流水支持。相关的计费结算出的明细类似如下表格：

租户模式 ：多租户模式（英语：multi-tenancy technology），在SAAS化场景下，多租户模式一般有三种数据存储方式，数据库库分开；数据库相同，schema不同；同一数据库，同一schema，只是用租户编号进行区分。每一种都有自己的优缺，这里不赘述，这里的目的主要是引申出租户模式对商家账户的入驻与创建机制所带来的影响，这里以最简单的方式，也就是同一数据库、同一schema存储的方式进行表述，相关的计费结算出的明细类似如下表格：

而现实的商业模式中，一个公司实际上可以经营多个范围，那他在平台允许的情况下，可以建立多个商家，有时候，为满足个性化的促销需要，每个商家的下属门店又会根据订单的销售情况，给店内的导购员等进行分佣，现在这个表格看起来像是这样：

上文中提到的这些角色，都一某种形态进行了业务的参与，必然会产生资金的归属划分。那这些参与方要产生对资金的结算，必然要维护自己的结算银行信息，现在这个表格看起来像是这样：

我们可以看到随着着业务形态不断的变化，业务表在不断的庞大，如何在商户入驻的时候，解决这种结算关系，使业务系系统与结算平台解耦，是业务系统入驻结算时核心要解决的问题。这里提供一种可行的方案，我们可以将影响业务结算的这一组关系抽象出来，我们把这个抽象关系叫做结算的主体，这样结算平台的计费信息、结算信息、账务信息，都基于这个抽象的主体号进行数据流转，而不侵染具体的业务，后续结算、收付费、发票开具都通过此主体进行开展，做到自身的平台化。而这层关系的保存，也可以做到业务的回溯。

结算主体创建的触发，要放在商家与平台合作关系正式创建时进行触发，一般是资质和合同审核通过后，触发结算平台按照一定的规则创建结算账户。

商户入驻结算整体架构图

商户入驻结算整体架构图描述

顺序的描述架构设计图中的几个核心组件：

合同消息接收 ：接收各业务平台商户合同审核通过的消息，对消息进行合法性校验，校验完成后触发结算主体的创建工作。

结算主体的创建 ：结算主体的创建，是强业务相关的，他关联一组关系，他强烈依赖于合同怎么签署，这一部分的规则策略，可以渐进迭代的设计，不建议一开始就抽象很高，后面通过公司运营方式的不通而逐步抽象完善。

通知商家维护资金信息 ：结算平台账户服务发送提醒商家维护收款方式，商家登录自己的管理端后进行收款方式及信息的维护。

资金信息存储 ：将商家选择的收款方式（微信、支付宝、银行卡）进行维护，并更新结算主体信息的结算方式，通过此方式路由具体的资金信息，之后发起商家资金信息的有效性验证。

商户入驻结算交互序列描述

商户入驻结算交互序列图

更多业务关联关系表和结算账户详细设计与缘由，参考《结算账户体系设计》

联营商计费

计费概述

联营计费系统的职责是订单在销售过程中，产生的金额能够给参与方正确的清分。以联营计费来说，当用户订单完成时，它需要将该订单商家所得、平台方所得，进行正确的计算，大多数电商平台业所支持的业务，计费一般都是由业务系统在某个时点触发计费，一般都是通过MQ的方式异步通知计费系统进行计费操作，而金额的计算，计费系统又需要从各个业务系统中获取计费的因子，比如货款的计算公式为： 货款 = 商品价格 - 优惠券 ，该公式所需要的商品价格和优惠券又需要从不同的系统获取。

我们可以看到，计费系统本身与外界业务系统具有强耦合性，他需要业务系统对计费进行触发，而金额计算公式所需要的因子，又根据业务的不同，通过不同的系统获取。那么如何降低这种耦合性，如何 快速支持不同类型业务的快速计费的接入，正确的对费用进行清分计算 ，是计费系统核心要解决的问题。

计费整体架构图

计费整体架构图描述

顺序的描述架构设计图中的几个核心组件：

101 消息校验、生成指令任务 此组件核心解决的问题是，接收业务系统的消息，做必要性校验，校验不通过的消息，直接做异常告警处理，通过的消息，将原消息落入es存储，并调用指令接收器。

102 指令接收器 由于大多数电商平台的业务计费都是在某个时点触发，此组件核心解决的问题是将外界系统与计费系统的耦合性，隔离在计费引擎之外，生成一条任务，在订单计费生命周期内进行调度。

103 计费引擎 计费引擎核心解决的是，提供一个通用的自动化计费装置，通过少量的设置即可进行自动化计费。引擎由3大核核心组件组成: 业务规则服务、数据快照服务、以及费用的计算执行服务,调度任务控制订单经过消息校验、计费引擎然后将订单的参与方的费用进行清分，生成可以结算计费明细。

103-01 计费引擎-业务规则匹配器 业务规则匹配器核心解决的是，业务系统的数据推送过来之后，如何识别并匹配到系统计费引擎中已经支持的业务规则。

103-02 计费引擎-业务规则配置服务 计费引擎业务规则的配置服务，配置计费引擎中可以支持的业务规则，业务规则实现后，供 103-01 计费引擎-业务规则匹配器 使用。

103-03 计费引擎-数据快照服务 数据快照核心解决的是获取计费过程中需要的计费要素（计费公式中的因子），例： 货款 = 商品价格 - 优惠券 ，商品价格和优惠券是计费公式中的因子，快照的保存也为计费结果出现问题时可以回溯。

103-04 计费引擎-数据策略服务 核心提供了计费公式中锁依赖的计费因子的获取来源关系，例：A业务的计费逻辑，其中某一费用的计算拿上边货款的计费公式来说， 货款 = 商品价格 - 优惠券 ，其中商品价格需要从 商品系统 获取，优惠券需要从 优惠券系统 系统获取，这个时候，我们为每个系统配置一套数据策略，策略的实现中获取计费的因子，这样当一个业务流转到快照服务时，系统通过业务编号，获取业务与数据策略组，并执行数据策略组，返回计费公式所依赖的计费因子值。

103-05 计费引擎-计费要素数据字典服务 主要是计费要素的定位，我们称之为计费因子，计费因子通过计费因子服务来获取，每一项其实就是计费因子的定义。

103-06 计费引擎-费用计算执行器 核心完成的功能是接收前几步的机构，调用计费公式配置服务，获取计费计费公式进行计费并输出结果。

103-07 计费引擎-计费公式配置服务 主要维护各业务需要计算的费用的信息包括：费用状态（是否启用），费用类型，费用计算公式等。该数据主要存储在MySql当中。

104 结算中心 计费系统将结果进行相应的转换然后将明细推送给结算系统给商家进行结算。

计费引擎交互序列图描述

计费引擎交互序列图

更多联合营商计费详细涉及与缘由，参考《联营商计费设计》

结算

结算概述

联营结算系统根据合同中与商家签订的结算周期，为商家生成结算单，当计费中心的数据推送过来时，按照计费的业务完成时间，关联到该商家相对应的结算周期的结算单中，有一点很重的事，当业务复杂时，不同业务的不同费用，比如上边计费中我们所说的，业务:A业务；费用：货款，都有可能用不通的结算主体进行结算。这个配置关系看起来是这样：

然后我们根据配置关系，找到相应的结算主体，在结算单的周期结束时，我们关闭单子，然后进行结算单金额的计算，这里如果费用时收支两条线的时候，我们需要计算应收应付，然后根据结算主体和应收应付的不通，拆分为不同的收付款单据，进行收付款操作。

那我们看到，结算系统核心要解决的问题是：如何关联到正确的结算单、如何正确的找到自己的结算主体，一般称这个过程为清算分账（清分）、如何正确的进行费用的实时统计和关单后的全量统计。

结算整体架构图