从0到1搭建OMS订单管理系统

OMS（订单管理系统）是电商供应链最重要的环节之一，整个业务链条大致为：买家从电商平台下单--OMS（订单）--WMS（仓储）--TMS（运配）--买家，OMS主要起到承上启下的作用，上接电商平台，对其进行订单的管理（还有一些内部订单的管理，后面说），下接仓储，安排订单的出入库，最终将商品送到买家手中。对了，还有一些资金流需要与ERP交互，这是企业内部的需求。

       有人可能会问，我大电商平台有对应的后台，为什么要用OMS？以下为个人观点：1、电商平台的后台主要是对订单销量、退货退款单量进行统计、管理商品的上下架、店铺的装饰、平台的活动等，可以说是支撑平台运营的基本功能；而OMS更多的是为企业提供更多具体的，包括企业内部的订单管理及个性化的服务，如：采购订单、调拨订单、黄牛订单的管理等等；2、一般来说，买家在电商平台下的订单并不是直接就下发给仓库发货的，而是需要进行订单的管控，可以看下京东或当当下单流程，都有一步是审核，OMS可以做这方面；3、如果某个店铺有多个仓库，但是商家应该安排哪个仓库发货呢？比如我有北京和上海两个仓库，如果买家的收货地址是北京，那发货的仓库就需要是北京仓，这个就需要在OMS中进行发货优先级的配置了……其实还有很多其他的原因，总的来说只要平台的开放API支持，OMS基本可以替代电商后台。

       OMS的用户角色包括：客服、售后专员、发票专员、仓库管理员、商品专员、结算专员、物流专员等等，主要看此OMS实现了哪些功能，因为它本身可以做很多的拓展。

       介绍下此次OMS的背景，目的是做一个2B的平台，包含了从供应商--服务商--零售商--门店--消费者的交易关系，可以说是B2B2B2B2C，我有点晕……这里的重点是零售商，他们是我们此次设计主要要进行销售和管理的对象，也就是零售商怎么通过OMS要货，给自己的实体门店，门店再进行销售。

       从0到1一定要做好优先级排序，然后要看时间，没时间做的，砍砍砍！本次做的OMS资源极少，从接需求到上线，只有1个月时间（5月，而且包含两个假期……），而要做的内容包括用户注册登录、权限管理等各种基础架构的搭建，还有多层级的交易关系设计，以及考虑到未来与WMS对接的设计，工作量可想而知，所以第一版时把所有需要对接的功能全部改成了导入的方式，比如创建商品、订单发货、订单签收等。

       接下来各个击破：用户注册登录、权限管理、审批流、订单与单据（重中之重）、库存管理、售后管理、发票管理

       1、用户注册登录

       其实这个大家并不陌生，这个是创建用户信息的过程，正常2C的注册流程直接通过电话或邮箱注册即可完成，但是2B涉及到审核资质的问题，所以在注册时需要相关负责人进行审核，审核通过后此账号才能登录。

       这里当时就遇到一个问题，是注册申请后就创建用户信息，但是此时用户信息无效（即不可登录系统），还是审核通过后才创建用户信息，且用户信息有效？

       本来我想的是第一种，但是当初在需求评审时并没有说清楚，而且我自己当时也没细想，开发大牛在做开发设计时直接按后者设计的，直到后来具体开发时有些地方跟我当初的设计有冲突才发现问题，因为时间紧，也就直接改的我的设计方案。

       直到现在我仍觉得第一种方式更好些，但是第二种方式也并非不妥。

       2、权限管理

       这个绝对是搭建任何后台产品都需要的最重点功能，没有之一！

       以前我只知道用户--角色--权限关系，后来才知道有个名词叫：RBAC模型。因为后台产品的角色特别多，比如我上面收到的客服、仓库管理员之类的，每种角色的人看到的功能是不一样的。所以要把每个功能（页面、按钮）挂到对应的角色身上，再把角色分配给用户。比如我有一个账户是zhenghuig，我是一个客服，那么就给我分配“客服”这个角色，我就只能看到需要我操作的功能了。

       刚才说的是功能角色，还有一个是数据角色。比如此OMS中有供应商、服务商、零售商、门店，4个主体，这些主体有层级关系，看到的数据范围不一样，比如零售商可以看零售商自己和门店的数据，但是门店不能看零售商的数据。数据角色就是在角色身上挂上不同地域或者主体的数据权限，你是我的下级，我能看你的，但你不能看我的。

       功能角色权限是必需的，而数据角色权限是非必需的。我当时就陷入了深深的纠结当中。如果不用数据角色，那么在给用户授权时，分配完功能角色后，就需要选择可以查看的数据范围；如果用数据角色，在给用户分配完功能角色后，再给用户分配数据角色就行了。

       用数据角色坏处是，每次在创建用户前，都要事先定义好数据角色，不然就没办法给他分配相应的权限，所以前期就需要定义好数据角色，或者每次在创建不同角色的新用户后都要再创建数据角色，过程类似于：创建用户--创建数据角色--授权--分配功能角色--分配数据角色。而不用数据角色的过程类似于：创建用户--授权--分配功能角色--选择数据范围。

       很明显后面这个过程更简洁，但是如果用户量大了，那就每次创建一个用户都需要重复勾选数据范围，即使角色相同。而且要修改某一类角色人的数据范围时，需要修改每个相关账号的数据范围，而有了数据角色这个过程就变得很简单了。所以设不设计数据角色需要权衡。

       3、审批流

       审批流程主要是针对需要审批的工作单（各类申请单），最简单的审批流程只需一个人或者一个角色审批，状态分为：待审批、审批通过、审批不通过。如果一个工作单需要多个不同角色审批，简单的做法就是“写死”，比如门店的要货申请，需要零售商、服务商、供应商，3个主体对应的角色审批，那么“写死”的做法就是这个流程固定，走到哪个审批步骤以后都是这个审批步骤，不可修改审批流程的先后步骤和审批角色，要改就要改程序。而如果要灵活的话，就需要整个审批流可配置，这是一个比较麻烦的过程，要设计灵活。

       这个OMS第一版并没有做复杂的审批流，之前在做其他的项目时倒是设计过，可以定义某个流程需要几步审批，每步审批人的角色，这样就相对灵活而且开发不太复杂。也有做成图形的，一个流程图加各种控件，通过拖拽完全自定义流程，太麻烦。

       4、订单与单据

       订单主要包括：对消费者的销售订单、企业内部或公司间的采购订单、从一个仓库或库存地到另一个地方的调拨订单、退换货订单；

       单据说的是物流单，为了处理库存而存在，有商品和数量，但没有金额。单据主要就分为两类：出库单、入库单，这两类可以和不同的订单进行组合。

       为什么OMS要设计物流单？因为要对接WMS（仓储管理系统）。OMS里的每种订单都要设计对应的下发WMS的单据，比如：我在电商平台下了一个订单，这个销售订单就要进入OMS，审核通过后把发货信息下发给WMS，这时就要在此销售订单的基础上系统自动创建一个销售出库单，把这个单据信息给到WMS，WMS根据收到的出库单信息安排发货，发货完成后会操作此出库单，把信息给回到OMS，通知OMS发货成功，这时OMS就要扣减对应的库存。

       既然是这样，为什么不直接把销售订单下发给WMS，而要设计订单--单据的两层结构？这种情况确实好像不需要做两层，但是有些时候需要一个订单对应两个单据，比如调拨订单（1个调拨出库单和1个调拨入库单）、换货订单（1个换货入库单和1个换货出库单），如果这时还是用一个订单，这个订单的单据类型就会一会儿入库，一会儿出库，逻辑上不清晰，对历史查库存变动记录也会有影响。

       这么多单据每一个都单独查会比较麻烦，所以一般会统一设计一个凭证表，用来记录所有出入库各个类型单据的商品数量变动。

       5、库存管理

       库存一般分为采购在途库存、实物库存、销售在途库存（在途就是在路上，是虚拟库存）。库存跟上面的单据息息相关，也就是库存的增减都是以单据过账（WMS通知OMS出入库完成）为依据。

       1）采购的过程中（OMS给WMS下发采购入库单），库存为采购在途，当库房收货后，WMS通知OMS采购入库完成，OMS中将减少采购在途库存并增加对应的实物库存（相当于库存的转移）。

       2）销售订单下发后（OMS给WMS下发销售出库单），WMS安排发货，发货完成WMS通知OMS销售出库完成，OMS中将减少实物库存并增加销售在途库存。

       3）当买家签收订单后，TMS会将物流信息回传给OMS，OMS扣减销售在途库存。

       这就是整个正向流程，商品所有权变动引起的库存变动情况。

       逆向的比较复杂，涉及签收前退货和签收后退货两种，暂略过……

       6、售后管理

       售后主要涉及到3部分：退货、退款、换货。当当都支持换货了，天猫到现在还不支持换货，不知道怎么搞的。最简单的换货方式是同品换货，而异品换货一般都涉及内部审批流，还是挺麻烦的。

       既然天猫不支持换货，那么OMS还是支持吧，当然这也要看重要和紧急度，此次OMS第一版并没有做售后管理部分。

       做退货时，退货订单要注意设计参考订单，也就是能找到原销售单的订单行，因为这涉及到后续退款、开红票的金额等。

       7、发票管理

       发票一般会分为2C、2B两种，就是给消费者开的发票和企业间采购开的发票（一般称为进项发票或销项发票，这两个词是相对的，我的销项是你的进项，你的进项是我的销项）。而每种发票又都会涉及退货时开冲红发票。

       2C发票一般是随货物一同寄出，当然也有电子发票，这就需要OMS和WMS之间进行协调，定义好发票的类型，才知道给消费者时开何种发票（一般分为纸质普通发票、电子普通发票、纸质专用发票、电子专用发票）。

       消费者退货后，服务商一般按一定周期汇总退货数据给到供应商，由供应商开冲红发票，反冲之前的进项发票。

       还有很多其他的模块，比如商品管理、上下架管理、对账管理、黄牛单管理。。。

       这次能顺利开展工作，真的很靠有技术大牛带，很多我只是提个想法，他就知道怎么做了，很省心。但是问题也出来了，就是在跟踪项目进度过程中，开发团队有些排斥，我又不好说，没办法我只能安排了每日站会，虽然跟大牛的关系很好，但是我想他也不会鸟我的站会，但我还是要做给其他人看。很多东西我还没玩转，在具体表结构设计上的一些对应关系还需要继续学习。

       写在最后，2B产品在设计过程中更注重每个功能模块之间的衔接，也就是信息流如何形成闭环，在考虑某个模块的改动时，要多考虑是否对其他功能模块或者系统造成影响。大家都说2B产品重逻辑轻体验，其实并不是不想重体验，只是除了体验还有更重要的事要做。不管是什么产品，重要的都是解决用户需求，体验不过是锦上添花，而产品本身的特性才是雪中送炭！