订单要做到集中处理就需要用到OMS系统，本篇文章笔者为大家总结介绍了OMS能处理的业务，仅限发货前的订单处理，供大家参考学习。

笔者一开始接触电商的时候做的就是订单系统，包括C端的订单管理和商家端的订单管理，涉及到简单的正向流程和逆向流程，当时对商家接收到这些订单之后在平台之外是如何处理订单的知之甚少。

后来开始接触OMS，发现跟OMS相比，之前做的订单管理简直是小巫见大巫，C端跟商家端只是简单的信息与流程处理，复杂的业务全在OMS系统。如果有同学正在接触OMS系统，建议可以由点及面地逐步理解企业关于订单的业务运转内在逻辑和关联。

我们知道当前商家可选择的卖货平台很多，像淘宝、天猫、京东、苏宁、拼多多、小红书等等，也可能有自营平台，那么这众多平台的订单如何集中处理，就需要用到OMS系统了。

所以本次想给大家总结的OMS能处理的业务（仅限发货前的订单处理），是以以上场景为基础的。

订单管理系统架构

用户在各大平台上产生的订单，会经过订单翻译中心，将平台订单翻译为ERP订单，后续的订单处理都是基于ERP订单，订单处理完成会推送至仓库进行拣货发货。

订单翻译

所谓订单翻译，就是将各大平台订单转换为ERP订单的过程。

订单翻译过程会做些什么？

1. 将平台商品翻译为ERP商品

平台商品：即用户在C端直接购买的商品；

ERP商品：即仓库的实物商品，即用户实际会收到的商品。

商家在真实售卖过程中，平台商品跟ERP商品有可能不是一一对应的，比如：用户购买的商品是某品牌面膜60片一盒，仓库实际给用户发货时有可能发的是2盒30片面膜，即一件平台商品对应了两件ERP商品（这就是通常听到的“组合商品”售卖场景）；而仓库发货时仅会认ERP商品，仓库是不知道运营在C端是怎么向消费者售卖商品的，所以就需要翻译中心将平台订单中的商品翻译为ERP商品。

如何知道平台商品对应的是哪个ERP商品？

各大平台的商品信息中有个字段是“商家编码”，这个字段以前刚接触电商的时候没明白是干嘛的，现在知道了，是用来填对应的ERP商品编码的，通过这个信息，可以知道平台商品所对应的ERP商品，如果ERP商品本身是组合商品，就需要再通过组合关系对组合商品进行拆分。

2. 获取平台订单中的基本信息

获取因企业内部业务需要的订单基本信息，如收货人、下单/支付时间、订单实付、商品单价、商品数量、商品实付、商品优惠、会员平台用户名、用户/商家备注等等，其中跟商品相关的数量、金额（包括优惠、实付、单价）需考虑组合商品拆分时的影响。

退款翻译同订单。

举个例子（例子仅涉及商品相关部分）：

翻译前

翻译后

订单处理

订单处理中涉及的业务项很多，最终目的都是告知仓库该发或者不该发什么商品。

订单处理的本质是对订单和订单明细中的字段作出更改。

其中所包括的业务项如下图所示：

添加赠品

添加赠品本质是在ERP订单明细中添加商品明细行。

什么情况下会在OMS系统中添加赠品？

一般情况下各个平台会有赠送赠品的营销工具，那什么情况下会在OMS系统中为用户添加赠品呢，笔者总结了几点：

• 平台无法满足的部分送赠品场景，如天猫不支持赠送多SKU商品
• 运营期望给用户惊喜时（在平台上送赠品，用户会提前看到）
• 部分不方便在平台给用户直接展示的赠品
• OMS送赠品可以提升运营人员工作效率时（如在平台上，运营需每个店铺单独设置送赠品活动，但是在OMS系统运营可以同时为多个店铺设置送赠品活动）

赠品添加的方式：

1. 单笔订单单独赠送赠品

售前客服为了提升转化率，承诺给某个用户赠送赠品、售后为了补偿某个用户，承诺给用户赠送赠品等情况都会需要客服在某笔订单上为用户单独添加赠品。

2. 通过活动规则为订单添加赠品

此处的活动规则跟各大平台上赠送赠品的规则类似，不过可满足同时为多店铺设置且可赠送平台限制型赠品。

通过活动规则为订单添加赠品应该在什么时候添加？

笔者认为在订单翻译完成后就可判断订单有无满足的送赠品活动规则了，即此时可为订单添加赠品，后面预分仓时可带着赠品一起预分仓。而且添加赠品应该跟平台维度保持统一，在渠道订单的维度添加，即判断渠道订单是否满足送赠品条件而不是ERP订单是否满足送赠品条件，这样可以避免拆合单时赠品不知道如何处理的情况发生。

活动规则不仅可为未来订单添加赠品也可为历史订单添加赠品：

现实运营中，偶尔会遇到运营漏送赠品的情况，这个时候再添加像平台一样的送赠品规则就不行了，因为已经产生的订单（且未发货）需要补送赠品，这种场景也是平台无法满足的，但是OMS为了真实场景需要可以满足，在活动规则中配置是否需要影响已有的订单即可。

删除赠品

赠品有添加的需求就会有删除的需求。删除赠品的本质即在ERP订单明细中删除商品明细行。

什么情况下会删除赠品？

• 客服手误添加了错误的赠品
• 运营促销规则建错，赠送了错误的赠品（在平台或OMS添加了错误的规则）

如何删除赠品？

1. 单笔订单单独删除赠品

同单笔订单添加赠品类似，可以提供方便客服删除赠品的功能。

2. 批量删除赠品

筛选符合条件的订单，批量删除赠品。

3. 自动删除赠品

一定时间内，符合条件订单下载下来后自动删除赠品（运营在平台上促销规则设错的场景适用，可以不用等所有问题订单全下载完再去删除赠品）。

批量删除赠品可与自动删除赠品结合，通过批量删除赠品规则实现，跟换货类似，通过规则去触发删除赠品还可以方便查看赠品删除历史，有删除错误的情况，可以撤消删除。

指定仓库

订单什么时候可以指定仓库？

订单翻译完成即可指定仓库，这时指定仓库可以即时占用仓库库存，防止超卖。

订单指定仓库的依据是什么？

• 仓库是否有货
• 哪个仓库的快递到达用户收货地址体验最好（依据指定快递公司标准判断）

订单指定仓库后哪些情况会导致重新分仓？

订单指定仓库后不是一直不变的，如果部分信息发生变更，订单需要重新分仓，大致有如下几种情况：

• 收货地址变更
• 商品明细变更（添加/减少商品、商品换货）
• 更改快递公司（原来的仓库可能不支持指定的快递公司）

指定快递公司

订单什么时候可以指定快递公司？

订单指定仓库的时候可以同时指定快递公司，毕竟指定仓库时的依据之一就是快递公司。

指定快递公司的依据是什么？

• 商品类别（如较轻易损坏的发快递，较重不易损坏的发物流）
• 快递时效
• 快递成本
• 快递索赔成功率

库存占用

订单翻译完成之后即可占用库存，此时占用的库存是虚拟层的库存，等到订单下发给仓库，占用的是WMS层的实物库存，关于库存占用详细业务下次再详细介绍。

缺货处理

虚拟层库存不够占用时，会导致订单缺货。

处理订单缺货需依赖客服、采购、运营三方协作的结果。

仓库库存增加时，会触发冲销订单缺货明细。

详细的缺货处理业务下次跟库存一起介绍。

订单拦截

所谓订单拦截，即订单在流转过程中可能受到多方面的干预或检测，导致订单不能正常顺畅地往下流转，等到风险解除后订单方可正常流转的过程。

什么情况下会需要拦截订单？

• 下单客户是黑名单用户（恶意下单者或职业打假人等）
• 订单中有系统无法处理的客户/客服备注，需要客服人工处理时
• 订单各项金额校验不通过时
• 订单毛利过低时
• 临时通知某个地区快递禁发时
• 订单中的商品正在盘点时
• ……

订单拦截情况会有很多，具体也可以根据公司具体情况设定。

订单拦截后的处理方法：

1. 拦截给客服人工审核

订单未审核时遇到系统无法自动审核的情况（如下单客户是黑名单客户或有系统无法处理的备注等等）需要拦截分配给客服人工处理。

2. 因系统判定导致的拦截，需锁定订单，待技术或系统处理完成后方可解锁

如订单金额校验不通过，收货地址无法正常解析等情况下，需要通过拦截将问题订单暴露出来，方便技术统一处理，处理完成后，可手动批量或系统自动标记处理完成，标记时订单可自动检测问题是否仍存在，若问题已解决，则可解锁拦截。

3. 回滚订单至上游某个状态，重新流转

订单需要重新分配快递，或者已审核的订单其他信息发生变更（如收货地址、添加/删除赠品时等等），需要作废原有的WMS单据，将订单回滚至上游，重新流转下发给WMS。

订单拦截的实现方式：

1. 人工拦截

客服人工修改订单信息时（如收货地址，快递公司）会触发订单拦截（已下发给WMS的情况下）。

2. 系统拦截

订单符合系统设定的拦截条件时，会被拦截（如黑名单等）。

3. 拦截规则拦截

人工添加特定的拦截规则，将符合条件的订单进行拦截。原则上系统拦截的大多数条件也可以通过拦截规则配置实现。

订单换货

订单换货的本质是更改订单中的商品明细。

什么情况下需要换货？

• 顾客主动提出想换货（前提是货物之间的价值近似）
• 顾客买的商品缺货，与顾客沟通后换货
• 运营失误（填写的ERP商家编码有误或后台送赠品促销规则有误），需换成正确的商品

换货需要注意什么？

换货可能造成商品件数和商品种类的变化（如一个A换成一个B+一个C），因此需要对换货后商品的单价、优惠、实付需要重新分摊。

如何换货？

1. 单笔订单换货

针对单笔订单中的商品进行换货操作。

2. 批量换货

筛选符合条件的订单，批量进行换货。

3. 自动换货

一定时间内，符合条件订单下载下来后自动换货（运营商家编码设错的场景适用，可以不用等所有问题订单全下载完再去换货）。

批量换货可与自动换货结合，通过批量换货规则实现，订单的很多处理都可以通过规则去处理，换货也是一种使用场景。通过规则去触发换货还可以方便查看换货历史，如果有换错的情况，还可以撤消换货。

订单备注

什么情况下需要给订单添加备注？

• 订单未被审核前，售前如接收到用户的任何需求，都是通过加订单备注，标记在ERP订单上，添加的订单备注交由系统或审核客服处理
• 审核客服遇到的其他需要标记订单的情况，如跟客户沟通延迟发货等等

订单备注如何处理？

一部分备注只是客户给订单加的标记，方便回头查订单时溯源，是无需特殊处理的；

一部分备注是承载了客户的要求，如指定快递，指定发货日期，更换收货地址等等，这部分需要交由系统或人工处理，系统处理的方式是通过语义分析识别文字想要表达的含义然后再自动处理，下文会小小介绍下语义分析。

订单备注添加的维度？

因为审核客服是在ERP订单的维度处理订单，下发给仓库也是以ERP维度下发，所以备注的添加是基于ERP订单维度，即为当前发货单添加备注信息，不过这样要注意订单拆合对备注的影响（不能因为订单拆合导致备注丢失）。

售中工单：

所谓售中工单就是订单在审核后但未发货前，客户对订单仍有修改需求的，由售前通过售中工单提交给订单处理客服进行处理。

售中工单的处理方式：

1. 语义分析

跟普通备注一样，售中工单也会先通过系统的语义分析识别文字想要表达的含义然后再自动处理，系统无法识别的交由人工处理。

2.. 人工处理

即人工按照售中工单的内容处理订单。

语义分析

订单处理的过程中哪些地方需要用到语义分析？

• 消费者提交订单时添加了备注
• 订单未审核前，售前为消费者通过备注的方式提交了订单需求
• 订单审核后未发货前，售前为消费者通过售中工单的方式提交了订单需求

总结下来，语义分析就是分析客户或售前给订单提交的修改需求。如果没有语义分析，全靠客服人工处理订单，处理量会相当大。

通过语义分析处理订单时，需借助成熟的语义分析系统和公司本身建立的词库，去识别语义的含义类别，如将“请发中通快递”维护在公司本身的词库后，语义分析遇到这种完全一样的备注时，就知道这种是要指定快递，便可调用订单修改快递公司接口修改快递公司。

订单开票

消费者在购买商品时或购买商品后，可能有开具发票的需求，一般会在平台上通过申请发票入口向卖家申请发票，或者通过平台聊天工具找到卖家向卖家索取发票。

商家可选择的开票方式：

1. 接入平台的开票服务进行开票

这个需要商家所使用的平台开票服务均比较完善的情况下才可使用，否则部分平台可开票，部分平台未提供开票服务操作起来就比较麻烦。

2. 商户自行开票

商户统一收取各个平台用户的开票需求，统一路径开票。收取的方式包括：通过平台接口获取用户在平台上所填写的开票需求；通过客服人工录入用户的开票需求

发票类型：

1. 纸质发票

如果商家开具的是纸质发票，在发货前开具的，可跟发货商品一起发出，在发货后开具的，需单独用快递寄出。无论在哪种场景下，都会增加线下人员的操作成本，发货后开具的还会增加企业的快递成本。

2. 电子发票

电子发票的出现解决了纸质发票遇到的问题，如果商品尚未发出，电子发票可在商品发出时开具，如果商品已发出，可即时开具。需要注意的是，开具完电子发票要及时通知用户发票已开具，可通过将开票信息回传至平台告知，或给用户发短信告知。

开票需求录入维度：

开票需求是基于ERP订单录入，如果是开纸质发票的话，这样可以避免合单的情况下需要开多次发票。

拆合单

什么情况下需要拆单？

• 同一订单需由不同仓库发货（仓库维度的判断需放在第一位）
• 同一订单中的商品不可同时打包，如钻石（高价值商品）就不可与食品一起打包，或者公司层面基于物流成本考虑需要将不同的商品发不同的快递（比较重的不易损坏的发物流，轻的易损坏的发快递）
• 用户主动放弃购买订单中的部分商品，即订单部分商品发生退款
• 订单缺货的情况下，用户允许部分商品先发货
• 其他特殊情况（需根据公司具体业务而定）

什么情况下需要合单？

为了节约公司快递成本，将同一渠道同一客户所提交的同一收货地址分配在同一仓库的未发货订单进行合并

订单拆合单的本质是什么？

订单拆合单的本质是不同订单的明细自由组合，且是建立在一定规则基础上的自由组合，因此订单拆合的次数可以是不限的。组合过程中需始终记录原始渠道明细单号（即渠道子订单号，上文例子中的001001和001002），这样的好处是可以溯源，如果用户针对某个明细商品发生退款，我们可以准确地在ERP商品中标记出来，后续财务针对部分商品收款时（财务是以渠道订单为基础做的收款），也可以明确地知道是哪些ERP商品收款了。

订单拆合单需注意什么？

• 订单拆合过程中要对商品的总优惠及实付进行重新分摊或求和
• 如果拆出来的订单取消了，需取消其对库存的占用
• 如果原有订单有发生缺货，需同时更新其对应的缺货信息（取消旧的缺货信息，以拆合后的订单判断是否缺货）
• 订单需要重新分仓、分配快递
• 订单备注、开票需求不能因为拆合单丢失
• 订单审核前拆合单，需重新触发生成新的拦截记录；订单审核后拆合单，无需重新生成新的拦截记录。

拆合单后系统UI层面需注意什么？

• 展示当前订单的拆合单状态
• 展示当前订单的拆合原订单，方便溯源

订单退款

订单从支付完成到最终发货的过程中，用户可能突然不想要了，申请退款，这时需要对申请退款的订单作处理。

如何处理订单退款？

直觉上而言，如果用户申请退款，我们需要锁定OMS订单和WMS出库单，订单退款成功则取消相应的OMS订单和WMS出库单，订单退款被商户拒绝或用户取消退款则解锁OMS订单和WMS出库单继续流转。

但是细想这样处理对OMS订单而言是没有问题的，但对WMS是不利的，为什么呢？考虑下现实场景和真实数据，订单从翻译至ERP到最终从仓库发货，退款的订单量还是很大的，而且在这大批量的退款中99%商家都会同意用户的退款申请给用户退款的，这样一来如果锁住仓库的出库单，仓库就会有一堆未出库但已拣货的打包盒，里面装了要给用户发货的商品，等到出库单解锁时，需要仓库从这一堆打包盒里面找出解锁出库单对应的打包盒进行出库操作，可想而知有多影响仓库效率，放在双11这种时候更不敢想象。

因此理想的操作是：

如果订单发生退款可以锁定OMS订单，但取消对应的出库单；

若全部商品退款成功，可以取消OMS订单；

若部分商品退款成功，可以自动拆单；

若订单退款被商户拒绝或用户取消退款，则可以重新生成出库单，让仓库当成新的拣货任务进行拣货，这样可以提升仓库的拣货效率。

订单审核

订单审核是确认当前ERP订单可以下发给仓库（WMS）的确认操作。

订单自动审核：

ERP订单产生且预分仓成功后，会经过系统的层层筛选判断，这些判断汇集一下就两大点：有无满足的拦截条件和消费者/客服备注能否系统自动处理，如果订单流转顺利未被拦截且其中的备注能被系统完全识别处理，则可以自动审核，下发至仓库。

人工审核：

系统无法审核的，均交由人工处理。

ERP订单关键信息说明

以上是结合目前所在公司真实业务思考所得，跟真实业务有偏差（真实业务因为各种原因某些方面虽不合理，但不致使影响使用，就没硬照着可能正确的方向修正），如果各位同学看了觉得有可以优化的地方，可以及时交流。

作者：青柠，微信公众号：一只进化中的产品汪（pm_move_forward），欢迎交流。

本文由 @青柠 原创发布于人人都是产品经理。未经许可，禁止转载。

题图来自Unsplash，基于CC0协议