构建商家电商平台OMS订单管理系统，打造全渠道零售电商系统核心！

目前国内高端的电商/新零售OMS市场，还没有特别完整的解决方案提供商，相当于大家都是站在同一起跑线之上。杭州爱聚科技有限公司（以下简称爱聚科技）成立于2012年4月（公司早在2013年、2014和2015年获得阿里系高管、阿里系资本及界石/万得资本的投资），基于国内最早的电商SaaS云ERP电商宝ERP基础研发而成。创始创始团队均来自阿里云及淘宝技术专家，技术实力扎实，从业经验丰富，2010年初爱聚科技OMS中台正式发布，并且立即获得蟹太太、九阳电器、阅邻、博洋家纺、收钱吧、米莱妆园等诸多品牌商家的青睐。通过口碑传播的方式进入市场且仅一年时间就已经和数十家品牌企业建立了合作关系。爱聚科技定位自己是一家业务主导型的软件服务商，致力于通过爱聚OMS中台、电商宝ERP、电商宝SCRM、一起播小程序帮助企业构建一个稳定灵活的中台系统从而实现全渠道打通运营的战略部署。爱聚科技秉承一对一的服务理念，目前已经在杭州、广州、武汉、长沙和青岛分别建立了分公司或办事处。

OMS即：订单管理中心，是零售电商系统的核心。

随着中台概念的火热，很多电商公司都开始投入资源开始搭建各种中台系统。

几天前和朋友交流，他们公司成立一个新的中台项目，项目上线后会取代现在的OMS及一些相关系统。

本人前公司似乎也在风风火火的搞中台，但中台是什么?搭建完成后解决了什么问题?能带来多少效益?上了中台是否真的能快速响应业务需求呢？

由于对中台了解的不多，现在也回答不了，这些只能慢慢去学习，所以也只能聊聊我对基础的一些系统、模块的理解。

之前总结过拆单、订单状态、退换货等，这些都似乎都可以归属于OMS,本篇接着说下我理解的OMS。

一、OMS与中台

1. OMS

OMS主要是承接各种业务单据「入库与出库」快速的与上下游系统进行信息的传递与处理，订单是其最核心的数据，也是数量最大、效率要求最高的部分。

在上图中，第一层属于内部相关系统，如商品系统、采购管理、前端购物流程产生的销售订单、售后发起的退货订单、以及领用等业务单据——这个我们可以称之为「上游系统」或ERP；当然OMS也应属于ERP系统的一部分。

OMS主要是针对订单的处理，履单包括上游系统的快速流转；但真正的生产应该是仓储内作业。所以OMS是与WMS系统交互最为紧密，与WMS系统的信息传递是通过仓储系统的API接口完成的，API接口与WMS可以称之为「下游系统」。

OMS就是一个中间系统服务的组成，在横向上，它又会与财务进销存系统进行数据的传递，所以它是被很多系统包围中中间的，称其为订单中心确实不为过。

2. 中台

上图是我在网上看到的一家做OMS产品的系统架构介绍，这里的订单中心属于业务中台。

上图是根据一位朋友发给我的中台规划，做了些简化；订单管理也是业务中台的一部分。

二、相关服务与功能

1. 信息下发

商品信息

OMS不仅负责销售订单的下发与上传，也包括采购订单及返厂单数据的传输，同时包括基础的商品信息。

商品收货是WMS的初始工作，收货入库后才能产生商品库存。

WMS在使用前首先要进行数据初始化，即：商品信息、品类和供应商等基础信息，同时要进行库存初始化，此外需要在WMS系统中进行库区、货位等信息创建与维护。

如果库内需要根据原材料进行加工生产，则需要在商品系统中进行配置，如父子商品配置、加工品原料配置，这些都会以BOM单方式提前下发到WMS系统中。

供应商信息

供应商信息是在供应商管理模块进行创建，它包括供应商ID、编号、名称及状态，WMS收货时是要获取此部分信息，进行数据校验。

此外，在上下游系统中都有供应商库存，且要进行供应商商品成本的计算与统计。

在WMS系统中有商品批次数据，批次编码可以根据相关规则进行创建，以保证一品多商时可以进行商品的区分。

单据

这里的单据是指业务创建采购单、返厂单，也包括用户的销售订单、退换货订单。

采购单、返厂单在SCM系统中创建完成后需要通过OMS同步到仓库，以便供应商到货后WMS系统中可以根据已经采集的采购单进行数据验证与统计；同时在此前供应商预约送货申请时也能够进行收货安排。

销售订单经过支付、拆单后要下发到WMS，仓库接收后可以开始处理，拣货、打包、发货单。

单据的下发一般分为头和行数据，商品数据则根据下发的单据信息，在WMS系统中根据BOM进行验证处理。

这些都是通过API接口完成的，我们原来的系统每次的数据下发与上传都会保存报文信息，以便出现问题进行查看、分析并解决。

所以在OMS系统与WMS等系统进行数据同步时，接口下发或回传的XML信息一定要保存完整。

2. 信息上传

来而不往非礼也，数据有去就应该有回。

这里的OMS系统中信息上传是指接收WMS系统回传的数据和相关状态，同时在接收完数据和状态后OMS还会进行一些业务处理。

以采购单为例，当仓库完成入库后，会将实际的入库数量回传；此时OMS系统需要根据回传数据进行入库单的生成，并更新上游系统的库存；同时还要进行成本的计算及入库流水的生成，由于数据流转到一个节点需要计算，系统一般都是通过MQ来实现异步处理的。

同信息下发一样，回传的信息明细需要保留，有些还需要进行解析并保存在关系数据库中，便于统计查询、展示。

3. 订单分发协同

在信息下发与上传时都会应用到规则与策略。

随着业务的爆发，单量增长也非常快，所以OMS系统中还应该进行一些规则配置，以便数据快速流转，加快系统的响应速度，给用户更好的体现。

同时有很多状态有些是仓储内部的，有些是业务系统的，在订单处理时要进行一些设置，需要有选择的屏蔽和转换。

4. 单号生成与拉、拆单

这几个服务大家都比较熟悉，单号生成品就是依赖于定义好的规则生成不能重复的单号，提供给前端购物流程或后台业务系统调用。

同时，单号的规则也会与分库分表服务相关联，所以单号的规则非常重要，它必须满足单量的爆发增长，不能重复，可以通过单号进行不同维度的订单数据保存与查询。

拉单就将前端用户产生的单据拉取到后端生产库，这是销售订单数据的来源，拆单可以查看以前总结的《OMS|订单拆单》,这里不重复描述了。

5. 发票服务

现在纸质发票越来越少了，电子发票的开票信息不需要同步到WMS系统了，但是开票金额的计算必不可少，且需要同步到电子发票税务平台。

对于售后的一些补开、退换货涉及的重开等也需要经过发票服务进行计算——这些虽然与财务关联很大，但是与OMS系统密不可分，所以应该是OMS的一部分。

6. 状态更新与模板

订单状态是根据履单的流程不断变化的，有在上游系统的变化，有在WMS系统内的更新。订单的全程跟踪便是根据状态的流转进行的统计与分析，业务部分会根据订单的生命周期来进行改进。状态变更时不仅涉及其他业务流程的逻辑处理，同时也需要进行消息通知，如短信、邮件或微信。

在零售电商系统的基础服务层中会有对应的网关与SP进行对接，但是与用户的交互要注意文案与格式，所以模板配置需要提前设置好，以便OMS进行调用。

只要与用户有关，那么就要注重用户体验，不能漏发或多发，也不能乱发，要设置好相关的规则。

7. 流水

我在这里将出入库流水划分在OMS系统中，因为接收所有的仓储作业数据，只要有出入库那么就涉及到库存的增或减；但是在WMS提供的API接口或返回的数据中可能不会区分单据类型，需要上游系统进行重新处理。这个几年前在与LSCM「仓储对接平台」进行库存核对时就需要到这样的问题。

WMS虽然有单据类型，但是经过LSCM后就只有出与入两种大类型，具体的信息都需要根据XML报文解析后，由上游系统进行重新处理。

流水也是SCM与财务系统交互的基础，财务根据出入库流程、库存进行财务成本的计算、相关报表生成等。

所以如果你在负责OMS，需要注意这一块，WMS有些是以调整单方式进行的，单据需要上游进行生成。

8. 库存

在零售电商系统中库存一般分为三部分，内部ERP、WMS和财务。其间关系以前曾说过，先有WMS，ERP根据出入库单据由OMS进行增或减，财务则根据OMS的出入库流水进行再次计算生成。

所以对账是必须的，WMS和ERP是实时作业的，库存是实时变化的，会有时间性的差异，财务是根据流水生成的可以有准确的期末库存。

接触过几个WMS系统都是通过快照方式备份期末库存的，这个如果WMS系统中没有，需要进行开发，只要有一笔笔的数据就能够推算出期末库存。

但是当SKU数量和单据量非常非常大时，计算就需要时间，在系统设计上就要进行分仓、分品类等进行分布式计算，当然我这里只是提出；在实际生产系统中最多遇到过一天几十万单，几十万个SKU的场景，与京东等平台这种设计肯定满足不了，有兴趣的同学可以去考虑，可以私信交流。

三、总结

OMS名词我们都知道，但是在不同的公司OMS的功能不同，涵盖的业务也不同；只要根据业务较为合理的进行规划，满足业务的变化就行了，至于它是不是订单中台不必过多计较了。

业务驱动技术发展，在设计时要应用领域模型，这是最近看书了解到的，业务、技术、数据、领域，究竟该如何去做，需要不断的去参照成功企业的应用案例结合实际场景去实践。

有朋友说我写的东西不装X，其实是想写高大上的，但是文采和储备有限，只能写点基础的自娱自乐，找点事干。

最后，感谢您的阅读！

作者：倔强的大萝卜 感谢分享！