订单管理是一个常见的管理问题，包含在企业的订单处理流程中。由于客户/用户下订单的方式多种多样、订单执行路径千变万化、产品和服务不断变化、发票开具难以协调，这些情况使得订单管理变得十分复杂。
订单管理的本质就是处理订单的过程。
在前文的 库存管理与系统设计 中，我们系统的梳理了三层库存模型，本文则着重探讨如何根据订单流向设计从下单到发货的全流程订单管理系统。
事实上，在早期excel表格是最常用的订单数据处理方式之一，主要用于输入、输出、显示、处理和打印数据，可以制作各种复杂的表格文档，甚至能帮助用户进行复杂的统计运算和图表化展示等。今天的订单管理系统也依然基于这一基本逻辑。
01
订单属性
所谓订单履约，就是从订单交易产生以后，到用户最终收到商品，包括售后的整个过程。所以我们的订单履约系统的主要实现目标是能高效且透明的完成订单履约全过程，保证用户体验。
一张订单在订单履约全流向中，需要调度各个系统获取履约的各种信息，所以订单信息应该越全面越好，这里展示一些订单的核心属性（尽管订单在客户/用户的眼中好简单得多）：
1.基本信息：订单编号、来源编号、销售平台与销售店铺、下单时间、订单状态、支付方式（在线支付/货到付款）、买家留言、配送方式（物流配送/自提）、下单账号、订单类型（实物订单/虚拟订单）；
2.财务信息：付款方式（微信、支付宝、银行卡、现金…）、支付平台、支付账户（微信账号、支付宝账号）、商户订单号、支付流水号、订单应付总金额、已支付金额、货到付款金额、商品总金额、运费、客服增加/减免金额；
3.收货信息：收货人、收货人手机\电话、收货人省份、收货人市、收货人区\县、收货人乡镇、收货人详细地址；
4.发票信息：开发票的订单，应包含发票抬头和发票明细信息：
发票抬头信息：发票类型（纸质/电子）、发票号、抬头、发票税号、公司地址、电话号码、开户行、银行账号、发票金额、开票人
发票明细信息：明细类目明细、包装规格、包装单位、数量、含税单价、含税金额、税率；
5.促销信息：促销类型（优惠券、积分、满减等）、促销ID、金额；
6.物流信息：发货库房、系统指派物流公司、系统指派电子面单号、实际发货物流公司、实际发货物流单号、物流公司月结账号、大头笔信息；
7.商品明细信息：sku编码、sku名称、商品规格、销售单价、实付单价（各种优惠折扣计算完以后的单价）、数量、实付金额（实付单价*数量）；
8.订单全程跟踪信息：记录订单履约的每一步的操作人、操作时间及操作内容。
02 订单系统架构
一般来说，电商平台有两大类业务：三方电商平台和自营平台。三方平台指的是在天猫、京东等平台上开的电商店铺，自有平台是企业自行搭建的商城，和一些对外的sdk、API等渠道。
同时一定规模的企业，都可能会开设多个门店，多个仓库，遍布全国各地，各地配送区域不同，甚至有些门店的还能够支持用户到店自提，以及急速送达等多种配送业务。
所以，通常来说订单履约系统的架构可以这样设计：
▲ 订单履约系统架构设计图
订单履约系统负责处理订单履约的全过程，对上通过订单转换中心与销售平台进行信息同步，对下通过仓储路由中心将订单信息上下传，内部通过调度中央库存、配送系统等多个外围系统对订单信息进行层层拆解和组装，将订单加工为满足履约条件的可执行指令。
从订单数据上下传通道来看，整个订单履约从上往下涉及3层系统：订单转换中心、订单履约中心、仓储路由中心。
1、订单履约系统的上游是订单转换中心，用以对接各个销售平台，因为各平台的订单结构不尽相同，为了能统一在履约系统中对订单进行管理，保证订单内部流转的标准化，不至于因为某个平台的调整而动了主体结构，所以在订单转换中心中针对各个平台配置不同的适配器，将订单标准化以后再与履约系统进行通讯。需要适配的信息包括商品、地址、订单状态、物流公司等。
——这个思路可以参考此前关于多租户的设计思路。
2、订单履约系统的下游是仓储路由中心，用以与各个仓库系统和门店新零售系统进行交互，将订单路由分发至目标库房进行生产，同时将目标库房的发货信息收集并回传至订单履约中心。
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
订单履约过程
订单履约系统是所有订单的集散地，统一管理订单履约的全流程，按照订单的履约过程，我们可以梳理出整个履约系统的全部状态，以及对应到用户侧的显示状态，如图所示：
▲ 订单履约状态说明
在订单的整个履约过程（全生命周期）中，至少都应该包含订单的接收、审核、拦截、拆分、合并、修改、取消和执行8个状态节点。
本文着重讨论订单的取消（退款退货）、分拆、合并四个环节。
01 订单取消
在电商系统中，取消场景主要有3类：
①、顾客发起的取消：客户在用户端发起的取消；
②、客服代为取消：客服代替顾客取消订单，此操作一般在后台客服系统或者在订单履约系统中直接操作；
③、系统取消：若客户下单后超时未支付，或系统判定为恶意订单，会自动取消订单。
由于订单取消会由多个环节触发，在系统设计的时候应该考虑到通用性，将订单取消做成一个公共服务，可供多个系统和场景按需调用。这也是符合SOA设计理念。
▲ 订单取消服务
根据订单在取消时可能存在于订单系统工作流、仓库作业、配送等多个环节，取消订单时需根据订单所处不同的状态执行不同的系统处理逻辑：
1.订单处于预分仓之前的状态：直接取消，更新订单状态为“已取消”，并判断是否需要退款触发退款流程；
2.订单已分仓，但尚未下发库房：取消订单，并通知中央库存清除订单预占；
3.订单已下发库房，但尚未发货：由履约系统对仓储系统发起询问，若仓储系统未发货且拦截订单成功，履约系统再取消订单，并通知中央库存清除订单预占；
4.订单已发货但尚未签收：若是自营配送，或者配送系统已与物流公司接口打通，则发货以后仍可以取消订单，履约系统询问配送系统，若配送系统拦截包裹成功，则履约系统更新订单状态为“已取消”，此阶段无需处理库存；
5.订单已签收：已经签收的订单，不支持取消，若想将货退回，只能走售后退货流程。
02 退货与退款
订单的取消，必然带来后续的退款退货作业，不管该取消的触发动作是用户/客户直接在线上发起，还是通过客服从后台发起的订单取消申请。
如果企业的业务还同时存在自营平台和三方POP商家两种业务模式，以及在线支付和货到付款两种支付方式的订单，其退款退货的操作会更加复杂。
整体的业务场景蓝图可以梳理如下：
▲ 退货退款场景罗列
如上图所示，我们可以根据退货退款触发的不同时机，将退货退款流程分拆为订单发货前、订单发货后、订单签收后3大节点，单独设计系统流程。
1.订单发货前的退货退款
用户下单以后，在实物订单未出库之前，用户尚未拿到实物商品，订单也还处于正向履约流程中，还不涉及到逆向物流场景。在此场景下发起的退货退款，在系统层面的操作动作为两个：取消订单；退款。
▲ 订单发货前的取消及退款流程
根据订单所处的履约节点，系统处理逻辑再细分为3个子节点：
（1）订单未支付：特指货到付款订单已提交，和在线支付订单已提交未付款的场景。此时由于尚未支付，所以只需要取消订单即可，不涉及退款；
（2）订单已付款，但尚未下发库房/商家：此时订单还在中台订单履约系统中，实物尚在库房未动。在操作层面需处理两个动作：
①取消订单；
②在线支付的订单，由系统或者人工生成退款单，审核通过后将订单实付金额原路退回用户支付账户（货到付款的订单未付款，无需退款）。
（3）订单已下发库房：此时订单已产生波次进行发货生产了，所以退款之前需确保实物商品尚未真实发出，将商品还货上架。
为防止系统信息流转过程中存在滞后性，故在取消订单前，最好核实一下库房/商家实物的真实情况。所以，在业务操作上需要至少完成三个步骤：
①尝试取消订单，若商品未发货，则可取消成功。否则取消失败，退款失败；
②库房将已取消订单拦截并还货上架；
③在线支付订单，生成退款单，审核通过后原路退款至用户支付账户。
2.订单发货后的退货退款
订单发货以后，实物已经在运输途中，但用户尚未签收，此时，若用户拒绝签收，则产生了拒收。货到付款的订单，拒收时并未收费，也无需退款。
所以，更为准确的描述是：用户拒收后的退货退款
▲ 订单拒收退货及退款流程
用户拒收后，业务上有两种做法：
（1）客服核实拒收原因，若用户还想继续要，则联系物流公司对包裹进行再投，正常签收订单。此过程仍为订单正向流程，未涉及售后流程。
（2）若协商同意退货，则由客服发起一个退货申请下发至库房（自营业务）或者商家端（三方POP商家业务），等待包裹被物流送回以后，核实确认无误后，将在线支付订单原路退款，货到付款订单因尚未收款，无需退款。
此处需要说明的是，自营平台订单，一般在库房操作WMS系统，退货入库状态可与上游系统实时互通，故在库房退货入库以后可自动触发退款；而商家系统最好由商家明确确认收到实物以后（多了一步商家确认的动作），再触发退款。
平台退款以后，与商家进行结算订单应收时需排除已退款订单。
3.订单签收后的退货退款
订单签收以后发起的退款，与签收前主要有两点不同：
（1）货到付款订单此时已收款，所以涉及到订单退款；
（2）签收前的退货都是整单维度，签收后可支持部分退货。
▲ 订单签收后的退货退款流程
订单一旦被签收，必须经由用户/客户或者客服发起退货申请，平台或商家审核退货申请以后，该流程才正式生效。系统应该能够提醒用户及时将原货物原路退回。
而且只有当库房/商家收到用户/客户寄回包裹后，系统才能生成退款单，按照约定路径将货款退回用户账户。原则上要求按原路返回，但部分为现金支付的货到付款订单，或者其它情况，可以协商其它线上退回路径。
订单的取消以及有此引起的退货退款处理是非常复杂的业务，一般而言，一张订单可能会产生多次退货，每次退货会生成一张退货单。同时，一张订单也有可能触发多次退款。所以，在退货单、退款单的设计上务必保持清醒，将退货单、退款单与订单库彼此独立又相辅相成是一种更为合理的设计。
▲ 订单、退货单与退款单
实际业务中，并不是每一张退货单都会生成退款单，更不是每一张退款单都会有退货单。
例如货到付款的订单退货，就只会有退货单，不需要退款单；有些情况下，客服会针对某些订单只为客户退款，而无需退货，例如承诺超时赔付等。
所以，退货单和退款单只有在常规退货退款场景下才是一对一的关系，在特定的场景下并不具备强关联关系。
在系统上，退货单的操作也必定具备待审核、待入库、入库完成、驳回 4个状态：
①待审核：在订单逆向过程中，客户或客服新发起退货申请，系统生成退货单的初始状态；
②待入库：退货单审核通过，同意退货的状态。此时，等待客户包裹寄回；
③入库完成：包裹寄回仓库，库房已完成入库；
④驳回：退货申请被驳回的状态。
▲ 退货单状态图
同样的逻辑，按照退款节点，退款单的状态设计也有待审核、待退款、退款完成、驳回 4个操作状态：
①待审核：退款申请刚提交的初始状态；
②待退款：退款单由财务审核通过，同意退款；
③退款完成：由财务手工或系统自动触发退款，退款成功后的状态；
④驳回：退款申请被驳回的状态。
▲ 退款单状态图
与退货相比，更复杂的业务是退款，它涉及一系列的负责计算规则，至少需要考虑三种业务场景：
1、订单签收前的取消和拒收引起的退款，都是整单退货（全退）；
2、签收以后的退货，经常由于部分商品问题，所以会存在部分退货（半退）；
3、如果在订单下单时使用了优惠券、抵扣金、积分等，也需要考虑退回用户账户。
全退情况的退款处理比较简单，①可按订单实付总金额退款；②未过期的优惠券、积分等优惠信息原路返回。
而半退情况下的退款处理相对复杂：
①若无组合优惠信息，按商品实付金额退款；
②若使用了组合优惠信息（如整单满减券），有两种主流处理方式：
a.优惠按照商品金额比例分摊，按照分摊后的实付金额退款；
b.退款时需考虑剩余商品是否满足优惠，重算优惠后退款。
为加强理解，举例说明：
a.优惠按照商品金额比例分摊，按照分摊后的实付金额退款。(参考：淘宝)
假设某用户购买商品A\B\C各1个，使用了满150减20的优惠券，按比例分摊后的实付金额如下:
如上，若退A，则退款90元；退B，则退款54元；退C，则退款46元。
此规则简单易实现，但存在凑单刷优惠券的风险。存在用户为了凑单使用优惠券，签收后又将其它不需要的SKU退货的情况。一般规避方案为：①用户责任导致的退货运费由用户承担；②恶意刷优惠券退货的行为，将用户做降级处理、或加入黑名单。
b.退款时重新计算优惠，若剩余SKU继续满足优惠，则按原价退款；否则扣除优惠后再退款，若扣退款金额尚不够优惠，则不能单独退此商品。参考：京东
假设某用户购买商品A\B\C各1个，使用了满150减20的优惠券，实付金额如下：
①若退C，则剩余A和B，原金额合计160，仍然满足优惠条件，故退款40元；
②若退B，则剩余A和C，原金额合计140，不再满足优惠条件，需扣除优惠，故退款金额=60–20=40元。
如某用户购买商品A\B各1个，使用了满100减50的优惠券，实付金额如下：
①若退A，剩余B（原金额为40），不再满足优惠条件，需扣除优惠，可退款金额=60-50=10元
②若退B，则剩余A（原金额为60），不再满足优惠条件，需扣除优惠，但因B的原金额（40）小于已优惠金额（50），故不允许单独退B。
此规则可预防刷优惠券的情况，但规则较复杂，解释成本和系统实现成本较大。
03 订单拆分
订单拆分是将一张订单拆分为多张子单独立发货的过程。订单履约过程中非常核心的一个环节，和订单取消一样，订单拆分会出现在订单履约的多个环节中，可以是系统自动拆单，也可以是人工拆单。所以订单拆分也应该设计为一个公共服务。
常见的拆分业务如下：
▲ 订单拆分服务
拆分以后，父单作废，子单继续完成履约过程。但在前台和履约系统中需要有很明晰的父单和子单的对应关系。拆分过程中，对订单的处理逻辑如下：
1.基本信息（下单人、收货人、渠道等公共信息）：将父单信息复制到子单 。
2.财务信息： 订单应付总金额/已支付金额/发票金额/物流运费=按照各子订单的商品总价比例进行分摊，最后一个订单金额为剩余未分配金额。建议保留2位小数。
3.商品信息：按照需要拆分的sku或者数量进行拆分，保证所有子单的sku及数量之和与父单一致。
4.促销信息：针对整单的促销（例如整单优惠、满减、平台优惠券、积分抵扣等），拆分时按照订单中sku金额比例分摊；若是针对单sku的促销，拆分时仅考虑参与促销的单sku维度，其它sku 不参与促销分摊。
04 订单合并
将相同客户的多张订单合并一起发货，有诸多好处，于客户而言，多张订单一起送货，只需要签收一次包裹；于公司而言，可以节省库房的作业成本和配送的物流成本。所以订单履约系统中增加订单合并功能是很有必要的。
履约系统设计时可以设置订单集中等待10到15min，在此等待时间内进入履约系统的订单，若符合合并条件，可自动进行合并；超过等待时期进入系统的订单，可由客服手工合并。
订单合并条件：同销售平台、同下单会员账号、同收货地址、同收货人、同手机号、同支付方式（在线支付/货到付款/到店支付）、同出库仓库、同订单类型（如普通订单、预售订单）、同客户备注（客户备注一样or无备注）、同开发票方式（都开发票，且抬头信息一样；或者都不开发票）、同配送方式（自提/配送）
合并以后，各原单作废，合并后生成一张新单继续完成后续履约过程，但要求在销售平台上客户仍看到的是多张订单，仅发货时的物流公司和物流单号都是一样的。
合并订单的处理逻辑如下：
1.基本信息（下单人、收货人、渠道等信息）：取任意一张子单（因为信息都一样）
2.财务及发票信息：订单应付总金额/已支付金额/发票金额/物流运费=各子单金额相加
3.商品信息：所有需要合并的子单SKU及数量进行汇总
4.促销信息：将所有子单促销明细集中至父单中
物流IT圈
联系客服
