乘风好去,漫空万里,直下看山河。 全文合计3300字,估计阅览时刻: 8 分钟 导语 OMS即订单办理中心,是零售电商体系的中心,跟着中台概念的炽热,许多电商公司都开端投入资源开端…
乘风好去,漫空万里,直下看山河。
全文合计3300字,估计阅览时刻: 8 分钟
导语
OMS即订单办理中心,是零售电商体系的中心,跟着中台概念的炽热,许多电商公司都开端投入资源开端建立各种中台体系,几天前和朋友沟通,他们公司建立一个新的中台项目,项目上线后会替代现在的OMS及一些相关体系。
自己前公司好像也在风风火火的搞中台,但中台是什么?建立完结后处理了什么问题?能带来多少效益?上了中台是否真的能快速呼应事务需求呢?
由于对中台了解的不多,现在也答复不了,这些只能渐渐去学习,所以也只能聊聊我对根底的一些体系、模块的了解,之前总结过拆单、订单状况、退换货等,这些都好像都可以归归于OMS,本篇接着说下我了解的OMS。
OMS与中台

上图是我在网上找一家做OMS产品的体系介绍,这儿的订单中心归于事务中台。

上图是依据一位朋友发给我的中台规划,做了些简化;订单办理也是事务中台的一部分。
OMS

这个图是依据自己了解的内容简略画的一个图,OMS主要是接受各种事务单据「入库与出库」快速的与上下流体系进行信息的传递与处理,订单是其最中心的数据,也是数量最大、功率要求最高的部分。
在上图中,第一层归于内部相关体系,如产品体系、收购办理、前端购物流程发生的出售订单、售后建议的退货订单、以及领用等事务单据,这个咱们可以称之为「上游体系」或ERP,当然OMS也应归于ERP体系的一部分。
OMS主要是针对订单的处理,履单包含上游体系的快速流通,但真实的出产应该是仓储内作业,所以OMS是与WMS体系交互最为严密,与WMS体系的信息传递是经过仓储体系的API接口完结的,API接口与WMS可以称之为「下流体系」。
OMS就是一个中心体系服务的组成,在横向上,它又会与财政进销存体系进行数据的传递,所以它是被许多体系围住中中心的,称其为订单中心的确不为过。
相关服务与功用
信息下发
OMS不只担任出售订单的下发与上传,也包含收购订单及返厂单数据的传输,一同包含根底的产品信息。
在上一篇介绍WMS收货与入库流程时提到过,产品收货是WMS的初始作业,收货入库后才干发出产品库存。
WMS在运用前首先要进行数据初始化,即产品信息、品类和供货商等根底信息,一同要进行库存初始化,此外需求在WMS体系中进行库区、货位等信息创立与保护。
假如库内需求依据原材料进行加工出产,则需求在产品体系中进行装备,如父子产品装备、加工品质料装备,这些都会以BOM单方法提早下发到WMS体系中。
供货商信息是在供货商办理模块进行创立,它包含供货商ID、编号、称号及状况,WMS收货时是要获取此部分信息,进行数据校验,此外,在上下流体系中都有供货商库存,且要进行供货商产品本钱的核算与核算。
在WMS体系中有产品批次数据,批次编码可以依据相关规矩进行创立,以确保一品多商时可以进行产品的区别。
这儿的单据是指事务创立收购单、返厂单,也包含用户的出售订单、退换货订单。
收购单、返厂单在SCM体系中创立完结后需求经过OMS同步到库房,以便供货商到货后WMS体系中可以依据现已收集的收购单进行数据验证与核算,一同在此前供货商预定送货请求时也可以进行收货组织。
出售订单经过付出、拆单后要下发到WMS,库房接纳后可以开端处理,拣货、打包、发货单。
单据的下发一般分为头和行数据,产品数据则依据下发的单据信息,在WMS体系中依据BOM进行验证处理。
这些都是经过API接口完结的,咱们本来的体系每次的数据下发与上传都会保存报文信息,以便出现问题进行检查、剖析并处理。
所以在OMS体系与WMS等体系进行数据同步时,接口下发或回传的XML信息一定要保存完好。
信息上传
来而不往非礼也,数据有去就应该有回,这儿的OMS体系中信息上传是指接纳WMS体系回传的数据和相关状况,一同在接纳完数据和状况后OMS还会进行一些事务处理。
以收购单为例,当库房完结入库后,会将实践的入库数量回传,此刻OMS体系需求依据回传数据进行入库单的生成,并更新上游体系的库存,一同还要进行本钱的核算及入库流水的生成,由于数据流通到一个节点需求核算,体系一般都是经过MQ来完成异步处理的。
同信息下发相同,回传的信息明细需求保存,有些还需求进行解析并保存在联系数据库中,便于核算查询、展现。
订单分发协同
在信息下发与上传时都会使用到规矩与战略,跟着事务的迸发,单量增加也非常快,所以OMS体系中还应该进行一些规矩装备,以便数据快速流通,加速体系的呼应速度,给用户更好的表现。
一同有许多状况有些是仓储内部的,有些是事务体系的,在订单处理时要进行一些设置,需求有挑选的屏蔽和转化。
单号生成与拉、拆单
这几个服务咱们都比较了解,单号生制品就是依赖于界说好的规矩生成不能重复的单号,供给给前端购物流程或后台事务体系调用。
一同,单号的规矩也会与分库分表服务相相关,所以单号的规矩非常重要,它有必要满意单量的迸发增加,不能重复,可以经过单号进行不同维度的订单数据保存与查询。
发票服务
现在纸质发票越来越少了,电子发票的开票信息不需求同步到WMS体系了,可是开票金额的核算必不可少,且需求同步到电子发票税务渠道。
关于售后的一些补开、退换货触及的重开等也需求经过发票服务进行核算,这些尽管与财政相关很大,可是与OMS体系密不可分,所以应该是OMS的一部分。
订单状况是依据履单的流程不断改变的,有在上游体系的改变,有在WMS体系内的更新,订单的全程盯梢就是依据状况的流通进行的核算与剖析,事务部分会依据订单的生命周期来进行改善。
只需与用户有关,那么就要重视用户体会,不能漏发或多发,也不能乱发,要设置好相关的规矩。
流水
我在这儿将出入库流水划分在OMS体系中,由于接纳一切的仓储作业数据,只需有出入库那么就触及到库存的增或减。
可是在WMS供给的API接口或回来的数据中或许不会区别单据类型,需求上游体系进行重新处理。
这个几年前在与LSCM「仓储对接渠道」进行库存核对时就需求到这样的问题,WMS尽管有单据类型,可是经过LSCM后就只有出与入两种大类型,详细的信息都需求依据XML报文解析后,由上游体系进行重新处理。
流水也是SCM与财政体系交互的根底,财政依据出入库流程、库存进行财政本钱的核算、相关报表生成等。
所以假如你在担任OMS,需求留意这一块,WMS有些是以调整单方法进行的,单据需求上游进行生成。
库存
在零售电商体系中库存一般分为三部分,内部ERP、WMS和财政,其间联系曾经曾说过,先有WMS,ERP依据出入库单据由OMS进行增或减,财政则依据OMS的出入库流水进行再次核算生成。
所以对账是有必要的,WMS和ERP是实时作业的,库存是实时改变的,会有时刻性的差异,财政是依据流水生成的可以有精确的期末库存。
触摸过几个WMS体系都是经过快照方法备份期末库存的,这个假如WMS体系中没有,需求进行开发,只需有一笔笔的数据就可以推算出期末库存。
总结
OMS名词咱们都知道,可是在不同的公司OMS的功用不同,包括的事务也不同,只需依据事务较为合理的进行规划,满意事务的改变就行了,至于它是不是订单中台不用过多计较了。
事务驱动技能发展,在设计时要使用范畴模型,这是最近看书了解到的,事务、技能、数据、范畴,终究该怎么去做,需求不断的去参照成功企业的使用事例结合实践场景去实践。
有朋友说,我写的东西不装X,其实是想写巨大上的,可是文采和储藏有限,只能写点根底的自娱自乐,找点事干:)。