解构电商、O2O：电商系统的CPU-交易系统
编辑导语：交易系统就是用户在确定购买内容后和电商平台签约并生成订单的过程，主要功能是负责处理用户提交的信息。本篇文章系统地分析了电商平台的交易系统主要流程和功能，一起来看看。
交易系统，顾名思义负责完成用户交易过程的系统。交易的过程主要指通过各种交易的先决条件来判断应该如何确定最终交易的内容、事项、金额等信息，整合后提交订单系统完成订单生成的工作。
通俗地来说就是用户在确定购买内容后和电商平台签约并形成书面合同（也就是订单）的过程。
所以合约签订的计算、判断、处理工作都需要交易系统来完成，所以把交易系统可以称得上是电商平台的运行“CPU”了。
交易系统的主要功能就是负责处理用户提交的信息以及针对这些信息进行预处理计算，最后完成订单提交。从流程上来看交易系统负责的是生成订单以前的所有环节，而订单系统则负责订单生成后直到履约完成的过程。
在一些平台也会将订单系统包裹在交易系统之内，订单管理作为大交易系统的一个子模块。我们这里把两个系统作为平行的关系进行了拆分，拆分以后的系统对于职能边界上来说更为清晰些。我们可以用户下单的整个过程以订单提交为节点前面部分属于交易系统，而后面的部分属于订单系统。
这里特别要单独说一下购物车，购物车原则上属于前台系统，但由于他的特殊性，也会涉及到大量的促销计算和运费计算的逻辑。购物车的后台可以通过调用交易系统的服务来实现上述计算。如图：
就像买房买车一样在签订合同之前销售人员会针对你的情况和购买的商品做很多预先的准备工作，比如资质的评估、费用的评估、是否有优惠的力度等等。这些信息都会通过核对沟通最终达成一致后录入到合同当中。
在电商平台也是一样，我们在确定下单之前交易系统也会充当销售人员的角色根据用户填写信息进行核准判断、交易金额的明确、促销情况的明确等，确认通过后完成订单的下单提交。所以在用户端负责对接交易系统进行订单确认的页面一般也叫订单确认页或者结算页。
接下来我们来看看订单合同一般都需要对那些事情进行处理和预先确认。
根据上述对于订单合同的描述我们可以将事项分为几个部分：信息的录入核准、费用的计算核准、履约形式的确认。交易系统的主要功能包括几项：
记录用户信息如名称、收货人地址（姓名、联系方式、地址）、可收货时间、收货方式、支付方式、发票等。信息记录看起来是比较简单的功能，但这些信息与后面一些计算逻辑是有密切相关的。举个例子，收货人地址电商平台目前业内通用的都是五级地址，即国家、省、市、县（区）、镇（街道）、详细地址。
通过这五级地址可以计算出仓库配货的情况，是否有移仓等信息。而用户账号的信息可以判断是否享受VIP价格等优惠。
在计算商品金额之前，我们需要优先把促销优惠的金额计算出来。促销优惠根据促销载体来看会分为商品促销和集合促销两种情况。
商品促销指的是将优惠的金额直接在商品的价格上做减免或打折，那么当前商品的销售价格应该为促销的价格或者折后的促销价格。
而集合促销指的是多个商品捆绑进行优惠，比如满减、满折等。在计算这种促销时候需要根据促销的优惠规则将优惠的金额按照商品价格占比摊到每个商品上。
假定本次购买有N件商品参与优惠，分摊的逻辑为:
优惠券作为一种特殊的促销形式也需要按照上述促销的思路进行计算。最终所有的优惠金额都会在商品和订单两个维度体现出来。
促销、优惠券在计算时还需要考虑两者之间的关系，即是互斥还是共享。在促销上我们将促销分为限时抢促销和其他促销，因为原则上限时抢属于单品范畴的最低价格。
而券种上除了一般意义上的红包优惠券外，我们将线下单独售卖的储值卡单独分开判断。加上单品的VIP价格我们共有五种优惠方式需要参与计算。
在判断是否是共享还是互斥的大体思路是尽量避免在同一个细分维度比如品类、单品上做两次以上促销减扣，同时核销方式不同的促销形式可以进行一定程度的叠加。
这样来看我们互斥和共享的情况如下：
当然在O2O的场景下单品如果已经执行了特价则订单不能再进行优惠券的使用，这也是为了避免有同一方承担双重补贴的问题。
商品金额计算是指计算当前订单需要消费的金额情况，这部分的明细内容同订单系统是一样的。订单的最终消费金额 =Sum(商品售卖价格） – 促销优惠金额 – 优惠券优惠金额– 储值卡优惠金额 – 其他抵扣 + 运费 + 保险费用。
其中运费的判断来自于是否满足运费减免条件，一般平台的减免掉件都是金额门槛满足即可减免运费。其他抵扣指的是可能出现的虚拟货币的抵扣，比如积分抵扣等。
商品金额计算时候要做最小容错校验，订单的最终金额不能出现负数。当订单金额小于等于0时考虑核销的原因订单金额一般记录为0.01。有可能出现的场景为多个优惠减免导致，则落订单时由于已经减免到最小值所有将所有优惠减免项按照优先级判断使用哪个。
运费是指使用配送服务后需要用户成单的运输费用。现在大多数的电商平台或者店铺都会通过满足一定订单金额减免运费，但运费依然是订单金额的一个有效组成部分。
运费金额主要是根据配送区域和配送方式来计算的，所以运费的计算依赖于收货地址的确定。同时运费的计算维度一般是按包裹单进行计算的（关于包裹单的概念后面配送逻辑会讲解）。这几个维度都会决定运费金额的差异。
运费金额一般是通过运费模板来进行设置的，设置的时候就会从这些维度来进行细分，包括但不限于按照收货地、发送方式、商品件数、金额、是否分合包裹、发出仓、顾客身份等。此外配送方式的多种多样决定了运费也会不同，平台一般会配置多套运费模板来设定对应运送方式下的运费规则用以计算使用。配送方式包括：
在支付方式的选取上也需要进行一系列的校验和判断处理，一般来说电商平台的支付方式包括以下几种：第三方在线支付、银行卡、余额、白条、储值卡、优惠券、积分抵扣、COD。
如果选择COD需要根据收货地址判断是否支持，而储值卡或者优惠券在单个订单上只能使用一张。多种支付方式则需要在生成订单时将金额对应到品上以便订单可以进行后续的操作。
配送逻辑包括配货逻辑和预计送达时间计算，这两块逻辑是紧密关联的。根据配货时远近、商品在库库存是否充足、是否需要移仓调拨来满足订单等信息，最终预估出预计送达时间。所以送达时间计算的前提是配货逻辑。
在讲解配送逻辑前我们先理解下配送的维度是基于什么维度进行作业的。一般来说我们通常讲配送订单都理解为按照订单维度进行作业，但实际上订单也有几层关系：交易单、订单、包裹单。
交易单是指顾客一次提交订单中的所有商品集合，由于电商平台下单形式是加入购物车后二次选择进行提交，所以单次提交的商品中可能包括不同商家或者店铺的商品。有一些平台级别的集合促销行为也是基于这个维度进行计算金额的。
交易单不作为配送的标准订单，系统会按照商家加配送方的维度将交易单拆分成若干的订单，订单的判断依赖于几个维度：收货人信息、配送方式、支付方式、发票。这个维度的订单是属于用户的，但实际配送的时候还会根据实际情况进行合拆单。
合拆单是按照配货逻辑的不同来判断是否可以一次进行配送即打包成一个包裹，所以这个维度的订单也叫包裹单。这个订单是真正意义上可以追踪的用户订单，在这个维度用户可以进行售后、评价等行为的处理。
理论上商家的配送方式和发货仓都是统一的，所以订单和包裹单一般情况数量会是相等，但如果出现同一笔订单有不同的发货方式或发货仓则就会出现一笔订单多个包裹单的情况。我们讲的配货逻辑是针对于最终的包裹单来说的。
配货逻辑定义是根据顾客购买地、购买商品品种和库存计算包裹发出仓和发送方式的逻辑。不同的结果会影响到预计送达时间的变化。配货逻辑的计算基准是基于收货人信息五级地址中的第四级也就是我们通常说的行政区。
如果平台在同一个城市有多个仓则会按区域划分不同的配送方，但如果同一个城市只有一个仓则可以按照三级城市来进行判断。一个仓库可以对应多个区域或者城市进行配送的设置。仓库我们按照收货地址的远近分为本地仓（或者本区域仓）或者外地仓。
如果本地仓无法完成全单配送，则需要通过移仓逻辑完成调动或者判断是否通过外地仓进行配送。在仓配模式上有几种情况：
子母仓指在全国范围内指定部分母仓来覆盖几个区域，每个区域有子仓。配货时优先查看子仓是否全单满足，如果不满足则从母仓调拨。如果母仓全单满足，则直接从母仓发货不做调拨。
子母仓的结构要确保母仓商品品类丰富充足，母仓即可以当做子仓的供应方又可以作为子仓的补足快速发货减少移仓时间和成本。子母仓的结构在时下比较流行的新零售领域被称为大仓和前置仓的概念，逻辑上也是类似。
网状仓指每个母仓都覆盖多个区域，可以为不同区域的子仓进行调拨，满足子仓的订单出库。网状母仓之间覆盖会有一定的区域重合，配送时选择哪个母仓调拨优先考虑物流成本和时效。中央仓直发，指[h1]在建立一个全品类的中央仓，中央仓建立在物流较为便利的城市中。
通过中央仓直发商品来解决兜底无法配送的问题。在配置仓库时无论是母仓还是子仓原则上还是遵从就近原则，尽可能减少运输成本和移仓次数。
确定配货逻辑后就可以根据配送情况估算配送时效即预计送达时间了。预计送达时间的处理是根据顾客的收货地址、下单时间、发送方式、送货时间、发货仓库、支付方式、截单时间计算预计送达时间。按照上述发货的方式分为直发订单时间预估和移仓转发订单时间预估。
交易系统作为购买流程的中枢系统之一，承担着所有订单的计算判断。很多相关业务系统都可以通过调用交易系统的服务来实现交易环节的功能。上述描述的都是交易系统的核心功能，也是交易系统对外提供的服务能力。
交易系统和订单系统作为电商平台的运行枢纽，负责搭建承前启后的工作。用户端大量的处理计算逻辑需要通过交易系统进行处理操作。搭建好交易体系是一个电商平台稳定运行的开端。
高晖，微信号公众号：产品老高，人人都是产品经理专栏作家。10余年IT经验，互联网老兵。多年电商公司经历，曾参与过B2B/B2C/O2O等多个方向的电商项目，熟悉电商全流程产品线情况。
本文原创发布于人人都是产品经理。未经许可，禁止转载。
题图来自 Unsplash，基于CC0协议
