很多公司，除了自营商城以外，还有其它渠道（如天猫、京东等），多个渠道的订单该如何集中履约？订单履约全流程是怎样的？接着小Q的故事，为您揭晓多平台订单履约系统的系统设计思路。
以下故事情节及人物均为作者杜撰，若有雷同，纯属巧合：
小Q：某互联网公司后台产品经理，着手规划重构公司的供应链及电商后台相关系统
三九酷寒，一夜北风吹，朋友圈里全国各地网友都在喜迎2019年的首场瑞雪，期待来年有个好盼头，唯独帝都上空一片寂寥。
寒风肆虐外加雾霾横行，空气充斥着流感的嚣张气焰，气温比昨日越发阴冷，能见度也低了不少。北风呜呜的压面扫过，从发丝到脖子，凡是暴露在外的肢体部分都如同冰刀刮体，冻的生疼。嘴里哈出的白气像一把反击的利剑，在空中凝固，随之慢慢消散沦为雾霾的奴役。鼻腔里充斥着尘霾的焦味，随便嚼一口都能感觉到牙缝里的沙子滋滋作响。
虽然穿着羽绒服，仍然能感受到寒气由外向内节节渗透，要不是有棉帽和鸭绒护身， 作为南方人的小Q与这般恶劣的天气根本斗不过10分钟。
01 订单履约系统架构及核心功能
此番来北京出差的任务是给技术GG们讲解订单履约系统需求。
“所谓订单履约，就是从订单交易产生以后，到用户最终收到商品，包括售后的整个过程。所以我们的订单履约系统的主要实现目标是能高效且透明的完成订单履约全过程，保证用户体验。”
“在正式讲解需求之前，咱们先来了解一下公司的业务现状，”，小Q觉得即便是程序员，也非常有必要先了解一下业务背景。以需求为出发点，才能设计出更贴合业务的系统，而且也会更加有参与感。
“咱们有两大类业务：三方电商平台和自营平台；三方平台是咱们在天猫、京东等平台上开的电商店铺，自有平台是咱们自行搭建的商城，和一些对外的sdk、API等渠道；咱们下游有多个仓库，遍布全国各地，各地配送区域不同；自营平台上，咱们还有一些新零售业务，支持用户到店自提，以及急速送达的配送业务。”
“结合这些现状，我给大家讲解一下订单履约系统的设计架构”，小Q打开了先行写好的prd。
▲ 订单履约系统架构设计图
以下为小Q分享内容：
从订单数据上下传通道来看，整个订单履约从上往下涉及3层系统：订单转换中心、订单履约中心、仓储路由中心。
订单履约系统的上游是订单转换中心，用以对接各个销售平台。因为各平台的订单结构不尽相同，为了能统一在履约系统中对订单进行管理，保证订单内部流转的标准化，不至于因为某个平台的调整而动了主体结构，所以在订单转换中心中针对各个平台配置不同的适配器，将订单标准化以后再与履约系统进行通讯。
需要适配的信息包括商品、地址、订单状态、物流公司等。
履约系统的下游是仓储路由中心，用以与各个仓库系统和门店新零售系统进行交互，将订单路由分发至目标库房进行生产，同时将目标库房的发货信息收集并回传至订单履约中心。
订单履约系统负责处理订单履约的全过程，对上通过订单转换中心与销售平台进行信息同步，对下通过仓储路由中心将订单信息上下传，内部通过调度中央库存、配送系统等多个外围系统对订单信息进行层层拆解和组装，将订单加工为满足履约条件的可执行指令。
02 订单履约全流程详解
从系统层面看，一张实物类的订单从销售平台下单，到最终用户签收，会经历10余个履约节点，涉及销售平台、订单转换中心、履约系统、中央库存、配送系统、仓储路由中心、仓库/新零售系统等多个系统。
所以，履约流程最核心的诉求是协同和顺畅，只有各系统相互协作，订单自始至终很流畅的执行完各个节点，才能保证在约定时效内完成履约。其中任何一个节点出现卡壳，都会导致履约时效拉长，影响的是客户对平台的信任。
▲ 实物订单履约全流程
1. 新订单
订单系统接到新单的状态，此处根据业务分为两块逻辑处理：三方平台（如天猫、京东）的订单，客户在销售平台上完成了交易，由订单系统接到销售平台同步的订单后的状态。自营平台的订单，客户提交订单后，订单系统便生成一张新订单，不过此订单需判断若为在线支付订单，需付款以后才能继续往下流转。
2. 订单拆分
为了更好的购物体验，大部分电商平台支持合并提交支付，在订单生成以后，需按照商家、仓库、商品、金额、物流等规则进行订单拆分，分为多个子订单发货。
3. 订单预分仓
为防止超卖，已经下单的订单需尽快进行库存预占，以免库存被其它订单占用，分仓过程由中央库存提供服务。
订单预分仓可以提前锁定订单发货仓库，若订单核心信息发生变化，再重新分仓。若业务上允许一个订单被拆分为多个库房发货，订单需再次拆分。
需要注意的是：只有实物库存满足的订单才能预分仓成功，预售类的订单，可在订单拆分后进行截停等待，待真实库存采购入库以后再进行分仓流转。
4. 订单拦截处理
某些不符合业务规则的订单，如疑似恶意订单，在订单系统中打上拦截标记，待人工审核通过后才能继续放行。若明确为恶意订单，则将订单取消。
（订单拦截规则因为行业、公司、业务不同，要根据实际业务情况进行梳理，不在这里详述。另外，到底是先分仓预占，还是先拦截订单？木笔认为应该先进行分仓，虽然恶意订单可能会占用部分库存，但处理完以后，订单会被取消释放库存。此种处理方式好过一些疑似但不是恶意的订单因为被拦截了而没有分仓，导致后续库存被其它订单占用而引起超卖的情况。）
5. 合并订单处理
为降低运费成本和库房作业成本，在一定时段内，满足合并条件的订单，在订单系统中合并为一单下发库房/门店发货。
6. 订单审核
某些业务规则下，会要求订单在人工审核处理后方能继续流转，例如：被拦截的订单、客户有特殊需求的订单等。
为提升履约效率，其它订单可自动审核而无需人工一一处理。当然此审核功能可以直接放在履约系统中供客服使用，也可以提供服务供客服系统调用。
7. 订单重新分仓
若在人工审核处理环节，客服修改了订单收货地址、商品及数量等分仓相关信息，从而影响了预分仓的结果，需要重新进行分仓预占，并清除原预分仓结果。
8. 订单分物流
由于全国各仓的物流是单独签约，根据仓库所处的位置不同，签约的物流可能不尽相同。所以，在明确了发货库房以后，履约系统调用物流配送系统提供的物流服务进行物流商的匹配，以及调用物流公司接口获取电子面单相关信息。
9. 下发库房
物流公司分配完成以后，订单履约需要的信息已组装完全，订单履约系统根据订单距离和物流信息试算履约时效（履约时效主要用于服务承诺，为库房波次提供参考），并将订单下传仓储路由中心，经此系统路由至目标库房或门店生产发货。
10. 波次下发
仓库/门店系统接到订单后，根据配送方向、时效承诺、订单类型等因素将订单生成波次，并按照出库策略对波次进行定位，生成库房拣货任务。在此过程中，若仓库零散货位库存不足而整件货位库存充裕，会产生波次补货。
11. 生成批拣单
系统或库房操作员将定位成功后可以一起拣货的订单（如相同物流公司、相同拣货区域等）打包生成一张批拣单，在非自动化作业模式下，一张批拣单中含多少订单合适？一般按照拣货员推着拣货容器一次性能放下的拣货箱上限即可。例如一个拣货小车上能放下12个拣货箱，则可以设定1张批拣单含12张订单。
12. 订单打印
打单员按照批拣单将每张订单的面单、纸质发票、发货清单打印出来并按订单顺序整理存放。
13. 拣货
拣货员按批拣单领取拣货任务（纸单或PDA），并按拣货路径完成拣货任务（若拣货区域过大，可将批拣单再拆分为多个拣货任务，按区域完成拣货）。若是边拣边分模式，拣货员一边拣货一边将批拣的商品分拣到每个拣货箱,拣货完成也分拣完成；若是先拣后分模式，待拣货员拣货完成后再集中进行集货分拣。
14. 复核打包
复核员按照订单的下单明细对商品进行复核确认，无误后交由打包员打包并粘贴物流运单。
15. 订单发货
发货员将包裹交由快递员揽收，并在系统中操作发货，代表订单从库房发出。发货以后，若实际发货物流有变化，回传实际的物流公司及物流单号至履约系统，履约系统再通过订单转换中心将物流信息回传销售平台。
若是新零售下的自提业务，则由门店店员打包以后，等待客户上门自提。
16. 物流揽件
物流公司快递员收到包裹后，在系统中操作揽件，揽件操作信息可由配送系统调用物流公司提供的接口获取，解析完后回传订单系统。
17. 物流运输
包裹从物流公司的分拣中心分拨发出。
18. 物流派件
包裹到达配送站点，派件员按照路线进行派件上门。
19. 物流签收
包裹送达客户手中，完成签收。
以上便是一个实物订单的履约全流向，虚拟订单因为不涉及到库房发货和物流配送等环节，需走另外的系统流程。”
03 订单履约系统状态
订单履约系统应该是所有订单的集散地，统一管理订单履约的全流程，按照订单的履约过程，我们梳理了履约系统的全部状态，以及对应到用户侧的显示状态，如图所示：
▲ 订单履约状态说明
04 订单取消
在电商系统中，取消场景主要有3类：
- 顾客发起的取消：客户在用户端发起的取消；
- 客服代为取消：客服代替顾客取消订单，此操作一般在后台客服系统或者在订单履约系统中直接操作；
- 系统取消：若客户下单后超时未支付，或系统判定为恶意订单，会自动取消订单。
由于订单取消会由多个环节触发，在系统设计的时候应该考虑到通用性，将订单取消做成一个公共服务，可供多个系统和场景按需调用。这也是符合SOA设计理念。
▲ 订单取消服务
根据订单在取消时可能存在于订单系统工作流、仓库作业、配送等多个环节，取消订单时需根据订单所处不同的状态执行不同的系统处理逻辑：
- 订单处于预分仓之前的状态：直接取消，更新订单状态为“已取消”，并判断是否需要退款触发退款流程。
- 订单已分仓，但尚未下发库房：取消订单，并通知中央库存清除订单预占。
- 订单已下发库房，但尚未发货：由履约系统对仓储系统发起询问，若仓储系统未发货且拦截订单成功，履约系统再取消订单，并通知中央库存清除订单预占。
- 订单已发货但尚未签收：若是自营配送，或者配送系统已与物流公司接口打通，则发货以后仍可以取消订单，履约系统询问配送系统，若配送系统拦截包裹成功，则履约系统更新订单状态为“已取消”，此阶段无需处理库存。
- 订单已签收：已经签收的订单，不支持取消，若想将货退回，只能走售后退货流程。
05 订单拆分
订单拆分是将一张订单拆分为多张子单独立发货的过程。订单履约过程中非常核心的一个环节，和订单取消一样，订单拆分会出现在订单履约的多个环节中，可以是系统自动拆单，也可以是人工拆单。
所以，订单拆分也应该设计为一个公共服务。
常见的拆分业务如下：
▲ 订单拆分服务
拆分以后，父单作废，子单继续完成履约过程。但在前台和履约系统中需要有很明晰的父单和子单的对应关系。
拆分过程中，对订单的处理逻辑如下：
- 基本信息（下单人、收货人、渠道等公共信息）：将父单信息复制到子单 。
- 财务信息： 订单应付总金额/已支付金额/发票金额/物流运费=按照各子订单的商品总价比例进行分摊，最后一个订单金额为剩余未分配金额。建议保留2位小数。
- 商品信息：按照需要拆分的sku或者数量进行拆分，保证所有子单的sku及数量之和与父单一致。
- 促销信息：针对整单的促销（例如整单优惠、满减、平台优惠券、积分抵扣等），拆分时按照订单中sku金额比例分摊；若是针对单sku的促销，拆分时仅考虑参与促销的单sku维度，其它sku 不参与促销分摊。”
06 订单合并
“将相同客户的多张订单合并一起发货，有诸多好处，于客户而言，多张订单一起送货，只需要签收一次包裹；于公司而言，可以节省库房的作业成本和配送的物流成本。所以订单履约系统中增加订单合并功能是很有必要的。
履约系统设计时可以设置订单集中等待10到15min，在此等待时间内进入履约系统的订单，若符合合并条件，可自动进行合并；超过等待时期进入系统的订单，可由客服手工合并。
▲ 订单ABC合并为D
订单合并条件：同销售平台、同下单会员账号、同收货地址、同收货人、同手机号、同支付方式（在线支付/货到付款/到店支付）、同出库仓库、同订单类型（如普通订单、预售订单）、同客户备注（客户备注一样or无备注）、同开发票方式（都开发票，且抬头信息一样；或者都不开发票）、同配送方式（自提/配送）
合并以后，各原单作废，合并后生成一张新单继续完成后续履约过程，但要求在销售平台上客户仍看到的是多张订单，仅发货时的物流公司和物流单号都是一样的。
合并订单的处理逻辑如下：
- 基本信息（下单人、收货人、渠道等信息）：取任意一张子单（因为信息都一样）。
- 财务及发票信息：订单应付总金额/已支付金额/发票金额/物流运费=各子单金额相加。
- 商品信息：所有需要合并的子单SKU及数量进行汇总。
- 促销信息：将所有子单促销明细集中至父单中 。
07 订单反审核
在订单履约过程中，已经审核过的订单，常常会被要求修改信息（例如客户要求修改地址、库房要求拆包裹发货等），客服需要将订单拉回至审核之前的状态，然后修改之后重新审核下发，此动作即为反审核。
反审核的系统处理逻辑为：
- 将原订单做取消处理；
- 根据要求修改后生成一张新订单重新下发完成履约流程。
新订单是否需要生成新的单号？ 取决于下游的仓库/门店系统是否兼容多个相同的订单号。若兼容，则无需更改单号，若不支持，则生成一个新订单号。订单在未下发仓库系统之前，原则上无需重新生成单号，系统记录一条反审日志即可。
此次来北京出差，小Q从酒店出发步行到办公室，区区10分钟路程，好像走了半个世纪。看着形形色色的上班一族在寒潮和雾霾中穿梭，每个人都包裹的严严实实，棉衣棉帽棉口罩是标配，只留一副凝重的眼神与寒风对峙，像怀揣着救世使命一般神秘。
不远处一位很时尚的女孩儿因为赶路太匆忙被路旁的共享单车绊倒，刚买的热包子和红豆粥洒落一地，白色的羽绒服被污染了一大片，女孩趴在地上30秒后，红着双眼慢慢爬起来，掏出包里的纸巾将自己脸上和身上收拾干净，又礼貌的将掉在地上的包子拾起来丢进了旁边的垃圾桶，然后满脸泪痕又故作坚强的前行。
小Q望着女孩不停抬手擦拭眼泪的背影，陷入了沉思….
众生皆苦，万般无奈。所有的美妙光鲜背后，都有着不为人知的难言苦楚。不过因果交加，如果不是一次次的艰难困苦，人生又当如何进阶？眼前的坎，掉下去了叫入坑，自己爬起来抹平了，就变成了自己的路。要相信所有让我们变好的选择，过程都不会很舒服。
尼采说：凡不能毁灭我的，必使我强大！
由于篇幅关系，内容略有精简，若需了解全部内容，可前往公众号查看原文。若对供应链全流程或者小Q的故事感兴趣，可参考前序文章：
作者：木笔，产品一俗生，深耕于供应链领域，公众号：供应链产品笔记
本文由 @木笔 原创发布于人人都是产品经理。未经许可，禁止转载
题图来自Unsplash，基于CC0协议。
