本文报告了OMS观念以及相关处事和成果（包罗：信息下发、信息上传、 订单分发协同单号生成与拉、拆单发票处事、状态更新与模板、流水、库存），与各人分享！

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还会举办一些业务处理惩罚。