Many companies, in addition to self mall, there are other channels (such as Lynx, Jingdong, etc.), how to order multiple channels of centralized performance? Order fulfillment whole process like? Then the story of small Q, you announced a multi-platform system design ideas order fulfillment system. Due to space relations, the article explains the compliance process forward, reverse the process to place a subsequent article updates ~

"Here is the story and the characters are fiction author, if any similarity is purely coincidental:

Small Q: Internet a pharmaceutical company background, product manager, started planning the reconstruction of the company's supply chain and back-end electricity supplier-related systems. "

Thirty-nine cold, the night the north wind, the circle of friends have friends all over the country in 2019 to celebrate the debut of Snow, expect to have a good look forward to the coming year, except over the Royal Park a lonely, cold wind raging rampage plus haze, the air filled with the arrogance of influenza, cold temperatures more than yesterday, visibility is a lot lower. Hum swept north pressure surface, from the neck to the hair, all the limb portions are exposed as the ice Knife body, frozen stinging; Hachu white gas mouth like a sword fight back, in the air solidification, followed slowly dissipate the haze reduced to slavery; nasal cavity filled with dust haze of burnt smell, just chew one can feel the sand between his teeth sizzles. While wearing a down jacket, still feel the chill outside to inside steadily penetration, but for a cotton cap and duck Body, as a Southerner with such a small Q bad weather simply no match for 10 minutes.

01 order fulfillment system architecture and core functions

This time the task is to travel to Beijing to explain their technical GG order fulfillment system requirements.

"The so-called order fulfillment, after the transaction is generated from order to final users receive the goods, including the sale of the entire process. Therefore, the main achievement of our order fulfillment system's goal is to complete the efficient and transparent order fulfillment whole process, to ensure that users experience . "

"Prior to the official explanation demand, we first look at the business situation of the company," a small Q that even the programmers, but also very necessary to first understand what business background with demand as the starting point, to design a more fitting service system, and it will be more a sense of participation.

"① We have two categories of business: tripartite business platform and proprietary platforms; our tripartite platform is open on the Lynx, Jingdong and other electricity providers store platform, the platform is our own self-built mall, and a number of external sdk, API and other channels;

② Downstream we have multiple warehouses across the country, all over the different distribution areas;

③ self on the platform, as well as our new retail business, allowing users to shop from mentioning, as well as rapid delivery distribution business. "

"The combination of these status quo, let us explain the order fulfillment system architecture design", opened the first small Q written prd.

▲ order fulfillment system architecture design

"From the data, the vertical transfer channel orders, order fulfillment entire downward directed from the 3-layer system: the center line conversion, order fulfillment center, warehouse routing center.

Order fulfillment system upstream of the conversion order is the center for all sales docking platform, because the order structure of different platforms, in order to unify the management of orders in compliance systems to ensure the standardization of internal order flow, not because of a adjust and move the platforms of the main structure, the configuration different adapter for each platform in order conversion centers, the order will then communicate with the future standardization system performance. Adapter required information includes merchandise, address, order status, logistics companies.

Downstream performance storage system is the routing center to interact with each new retail stores and warehouse system, order routing will be distributed to the target warehouse for production, while the Treasury's target shipping information is collected and transmitted back to order fulfillment center;

Order fulfillment system handles the entire process of order fulfillment, and to synchronize information on orders placed through the conversion center and sales platform, the next route through the warehouse center will pass down the order information, internal inventory through central scheduling, distribution system and other peripheral systems order information layer assembly and dismantling, orders processing performance to satisfy the condition executable instructions.

According to the above structure, to tease out the order fulfillment system's core functions are as follows:

▲ order fulfillment system core function "

02 order fulfillment whole process Detailed

"From the system perspective, a kind of order receipt from a single class under the sales platform to end users will experience the performance of more than 10 nodes, involving sales platform, order conversion center, compliance systems, central inventory, distribution systems, storage routing multiple system Center, warehouse / retail new systems, so the core demands fulfillment processes are coordinated and smooth, only the systems work together, the order of execution from start to finish is very smooth finish each node, in order to ensure complete compliance within the agreed age, which any node appears stuck, aging will lead to compliance stretch, affecting customer confidence in the platform. "

Physical order fulfillment whole process ▲

“ 1.新订单：订单系统接到新单的状态。此处根据业务分为两块逻辑处理：三方平台（如天猫、京东）的订单，客户在销售平台上完成了交易，由订单系统接到销售平台同步的订单后的状态；自营平台的订单，客户提交订单后，订单系统便生成一张新订单，不过此订单需判断若为在线支付订单，需付款以后才能继续往下流转。

2.订单拆分：为了更好的购物体验，大部分电商平台支持合并提交支付，在订单生成以后，需按照商家、仓库、商品、金额、物流等规则进行订单拆分，分为多个子订单发货。

3.订单预分仓：为防止超卖，已经下单的订单需尽快进行库存预占，以免库存被其它订单占用。分仓过程由中央库存提供服务。订单预分仓可以提前锁定订单发货仓库，若订单核心信息发生变化，再重新分仓。若业务上允许一个订单被拆分为多个库房发货，订单需再次拆分。需要注意的是，只有实物库存满足的订单才能预分仓成功，预售类的订单，可在订单拆分后进行截停等待，待真实库存采购入库以后再进行分仓流转。

4.订单拦截处理：某些不符合业务规则的订单，如疑似恶意订单，在订单系统中打上拦截标记，待人工审核通过后才能继续放行。若明确为恶意订单，则将订单取消。

（订单拦截规则因为行业、公司、业务不同，要根据实际业务情况进行梳理，不在这里详述。

另外，到底是先分仓预占，还是先拦截订单？木笔认为应该先进行分仓，虽然恶意订单可能会占用部分库存，但处理完以后，订单会被取消释放库存，此种处理方式好过一些疑似但不是恶意的订单因为被拦截了而没有分仓，导致后续库存被其它订单占用而引起超卖的情况。）

5.合并订单处理：为降低运费成本和库房作业成本，在一定时段内，满足合并条件的订单，在订单系统中合并为一单下发库房/门店发货。

6.订单审核：某些业务规则下，会要求订单在人工审核处理后方能继续流转，例如被拦截的订单、客户有特殊需求的订单等。为提升履约效率，其它订单可自动审核而无需人工一一处理。当然此审核功能可以直接放在履约系统中供客服使用，也可以提供服务供客服系统调用。

7.订单重新分仓：若在人工审核处理环节，客服修改了订单收货地址、商品及数量等分仓相关信息，从而影响了预分仓的结果，需要重新进行分仓预占，并清除原预分仓结果。

8.订单分物流：由于全国各仓的物流是单独签约，根据仓库所处的位置不同，签约的物流可能不尽相同，所以在明确了发货库房以后，履约系统调用物流配送系统提供的物流服务进行物流商的匹配，以及调用物流公司接口获取电子面单相关信息。

9.下发库房：物流公司分配完成以后，订单履约需要的信息已组装完全，订单履约系统根据订单距离和物流信息试算履约时效（履约时效主要用于服务承诺，为库房波次提供参考），并将订单下传仓储路由中心，经此系统路由至目标库房或门店生产发货。

10.波次下发：仓库/门店系统接到订单后，根据配送方向、时效承诺、订单类型等因素将订单生成波次，并按照出库策略对波次进行定位，生成库房拣货任务。在此过程中，若仓库零散货位库存不足而整件货位库存充裕，会产生波次补货。

11.生成批拣单：系统或库房操作员将定位成功后可以一起拣货的订单（如相同物流公司、相同拣货区域等）打包生成一张批拣单，在非自动化作业模式下，一张批拣单中含多少订单合适？一般按照拣货员推着拣货容器一次性能放下的拣货箱上限即可。例如一个拣货小车上能放下12个拣货箱，则可以设定1张批拣单含12张订单。

12.订单打印：打单员按照批拣单将每张订单的面单、纸质发票、发货清单打印出来并按订单顺序整理存放。

13.拣货：拣货员按批拣单领取拣货任务（纸单或PDA），并按拣货路径完成拣货任务（若拣货区域过大，可将批拣单再拆分为多个拣货任务，按区域完成拣货）。若是边拣边分模式，拣货员一边拣货一边将批拣的商品分拣到每个拣货箱,拣货完成也分拣完成；若是先拣后分模式，待拣货员拣货完成后再集中进行集货分拣。

14.复核打包：复核员按照订单的下单明细对商品进行复核确认，无误后交由打包员打包并粘贴物流运单。

15.订单发货：发货员将包裹交由快递员揽收，并在系统中操作发货，代表订单从库房发出。发货以后，若实际发货物流有变化，回传实际的物流公司及物流单号至履约系统，履约系统再通过订单转换中心将物流信息回传销售平台。

若是新零售下的自提业务，则由门店店员打包以后，等待客户上门自提。

16.物流揽件：物流公司快递员收到包裹后，在系统中操作揽件，揽件操作信息可由配送系统调用物流公司提供的接口获取，解析完后回传订单系统。

17.物流运输：包裹从物流公司的分拣中心分拨发出。

18.物流派件：包裹到达配送站点，派件员按照路线进行派件上门。

19.物流签收：包裹送达客户手中，完成签收。

以上便是一个实物订单的履约全流向，虚拟订单因为不涉及到库房发货和物流配送等环节，需走另外的系统流程。”

03 订单属性

“一张订单在订单履约全流向中，需要调度各个系统获取履约的各种信息，所以订单信息应该越全面越好，这里展示一些订单的核心属性：

1.基本信息：订单编号、来源编号、销售平台与销售店铺、下单时间、订单状态、支付方式（在线支付/货到付款）、买家留言、配送方式（物流配送/自提）、下单账号、订单类型（实物订单/虚拟订单）；

2.财务信息：付款方式（微信、支付宝、银行卡、现金…）、支付平台、支付账户（微信账号、支付宝账号）、商户订单号、支付流水号、订单应付总金额、已支付金额、货到付款金额、商品总金额、运费、客服增加/减免金额；

3.收货信息：收货人、收货人手机\电话、收货人省份、收货人市、收货人区\县、收货人乡镇、收货人详细地址；

4.发票信息：开发票的订单，应包含发票抬头和发票明细信息：

发票抬头信息：发票类型（纸质/电子）、发票号、抬头、发票税号、公司地址、电话号码、开户行、银行账号、发票金额、开票人
发票明细信息：明细类目明细、包装规格、包装单位、数量、含税单价、含税金额、税率；

5.促销信息：促销类型（优惠券、积分、满减等）、促销ID、金额；

6.物流信息：发货库房、系统指派物流公司、系统指派电子面单号、实际发货物流公司、实际发货物流单号、物流公司月结账号、大头笔信息；

7.商品明细信息：sku编码、sku名称、商品规格、销售单价、实付单价（各种优惠折扣计算完以后的单价）、数量、实付金额（实付单价*数量）；

8.订单全程跟踪信息：记录订单履约的每一步的操作人、操作时间及操作内容 ”

04 订单履约系统状态

“订单履约系统应该是所有订单的集散地，统一管理订单履约的全流程，按照订单的履约过程，我们梳理了履约系统的全部状态，以及对应到用户侧的显示状态，如图所示：”

▲ 订单履约状态说明

05 订单取消

“在电商系统中，取消场景主要有3类：

①、顾客发起的取消：客户在用户端发起的取消；

②、客服代为取消：客服代替顾客取消订单，此操作一般在后台客服系统或者在订单履约系统中直接操作；

③、系统取消：若客户下单后超时未支付，或系统判定为恶意订单，会自动取消订单。

由于订单取消会由多个环节触发，在系统设计的时候应该考虑到通用性，将订单取消做成一个公共服务，可供多个系统和场景按需调用。这也是符合SOA设计理念。”

▲ 订单取消服务

“根据订单在取消时可能存在于订单系统工作流、仓库作业、配送等多个环节，取消订单时需根据订单所处不同的状态执行不同的系统处理逻辑：

1.订单处于预分仓之前的状态：直接取消，更新订单状态为“已取消”，并判断是否需要退款触发退款流程；

2.订单已分仓，但尚未下发库房：取消订单，并通知中央库存清除订单预占；

3.订单已下发库房，但尚未发货：由履约系统对仓储系统发起询问，若仓储系统未发货且拦截订单成功，履约系统再取消订单，并通知中央库存清除订单预占；

4.订单已发货但尚未签收：若是自营配送，或者配送系统已与物流公司接口打通，则发货以后仍可以取消订单，履约系统询问配送系统，若配送系统拦截包裹成功，则履约系统更新订单状态为“已取消”，此阶段无需处理库存；

5.订单已签收：已经签收的订单，不支持取消，若想将货退回，只能走售后退货流程。”

06 订单拆分

“订单拆分是将一张订单拆分为多张子单独立发货的过程。订单履约过程中非常核心的一个环节，和订单取消一样，订单拆分会出现在订单履约的多个环节中，可以是系统自动拆单，也可以是人工拆单。所以订单拆分也应该设计为一个公共服务。常见的拆分业务如下：

▲ 订单拆分服务

拆分以后，父单作废，子单继续完成履约过程。但在前台和履约系统中需要有很明晰的父单和子单的对应关系。拆分过程中，对订单的处理逻辑如下：

1.基本信息（下单人、收货人、渠道等公共信息）：将父单信息复制到子单。

2.财务信息： 订单应付总金额/已支付金额/发票金额/物流运费=按照各子订单的商品总价比例进行分摊，最后一个订单金额为剩余未分配金额。建议保留2位小数。

3.商品信息：按照需要拆分的sku或者数量进行拆分，保证所有子单的sku及数量之和与父单一致。

4.促销信息：针对整单的促销（例如整单优惠、满减、平台优惠券、积分抵扣等），拆分时按照订单中sku金额比例分摊；若是针对单sku的促销，拆分时仅考虑参与促销的单sku维度，其它sku 不参与促销分摊。”

07 订单合并

“将相同客户的多张订单合并一起发货，有诸多好处，于客户而言，多张订单一起送货，只需要签收一次包裹；于公司而言，可以节省库房的作业成本和配送的物流成本。所以订单履约系统中增加订单合并功能是很有必要的。

履约系统设计时可以设置订单集中等待10到15min，在此等待时间内进入履约系统的订单，若符合合并条件，可自动进行合并；超过等待时期进入系统的订单，可由客服手工合并。

▲ 订单ABC合并为D

订单合并条件：同销售平台、同下单会员账号、同收货地址、同收货人、同手机号、同支付方式（在线支付/货到付款/到店支付）、同出库仓库、同订单类型（如普通订单、预售订单）、同客户备注（客户备注一样or无备注）、同开发票方式（都开发票，且抬头信息一样；或者都不开发票）、同配送方式（自提/配送）

合并以后，各原单作废，合并后生成一张新单继续完成后续履约过程，但要求在销售平台上客户仍看到的是多张订单，仅发货时的物流公司和物流单号都是一样的。合并订单的处理逻辑如下：

1.基本信息（下单人、收货人、渠道等信息）：取任意一张子单（因为信息都一样）

2.财务及发票信息：订单应付总金额/已支付金额/发票金额/物流运费=各子单金额相加

3.商品信息：所有需要合并的子单SKU及数量进行汇总

4.促销信息：将所有子单促销明细集中至父单中 ”

08 订单反审核

“在订单履约过程中，已经审核过的订单，常常会被要求修改信息（例如客户要求修改地址、库房要求拆包裹发货等），客服需要将订单拉回至审核之前的状态，然后修改之后重新审核下发，此动作即为反审核。

反审核的系统处理逻辑为：

①将原订单做取消处理；

②根据要求修改后生成一张新订单重新下发完成履约流程。

新订单是否需要生成新的单号？取决于下游的仓库/门店系统是否兼容多个相同的订单号。若兼容，则无需更改单号，若不支持，则生成一个新订单号。订单在未下发仓库系统之前，原则上无需重新生成单号，系统记录一条反审日志即可。”

09 订单暂停与加急

“在某些业务场景下，需要临时将正在履约过程中的订单暂停处理，一般由客服发起，若订单在库房发货之前，可暂停成功，将订单拦截在仓库里，等待客服下一步操作（取消暂停/取消订单/反审核等），暂停的系统流程如图所示：

▲ 订单暂停逻辑

与暂停功能类似，某些订单需要临时提升出库优先级，加急出库，故订单履约系统需提供加急功能供客服使用，一旦订单被加急，库房在出库作业环节中均优先处理。优先级越高，出库越靠前。加急的系统流程如下：

▲ 订单加急逻辑

以上暂停和加急功能主要供客服内部使用，无需对客户开放。”

此次来北京出差，小Q从酒店出发步行到办公室，区区10分钟路程，好像走了半个世纪，看着形形色色的上班一族在寒潮和雾霾中穿梭，每个人都包裹的严严实实，棉衣棉帽棉口罩是标配，只留一副凝重的眼神与寒风对峙，像怀揣着救世使命一般神秘。不远处一位很时尚的女孩儿因为赶路太匆忙被路旁的共享单车绊倒，刚买的热包子和红豆粥洒落一地，白色的羽绒服被污染了一大片，女孩趴在地上30秒后，红着双眼慢慢爬起来，掏出包里的纸巾将自己脸上和身上收拾干净，又礼貌的将掉在地上的包子拾起来丢进了旁边的垃圾桶，然后满脸泪痕又故作坚强的前行。小Q望着女孩不停抬手擦拭眼泪的背影，陷入了沉思….

众生皆苦，万般无奈。所有的美妙光鲜背后，都有着不为人知的难言苦楚。不过因果交加，如果不是一次次的艰难困苦，人生又当如何进阶？眼前的坎，掉下去了叫入坑，自己爬起来抹平了，就变成了自己的路。要相信所有让我们变好的选择，过程都不会很舒服。

尼采说：凡不能毁灭我的，必使我强大！

=>更多文章请参考：《中国互联网业务研发体系架构指南》

https://blog.csdn.net/Ture010Love/article/details/104381157

=>更多行业权威架构案例、领域标准及技术趋势请关注微信公众号 '软件真理与光'：