B端OMS系统设计：产品结构与流程

本文主要描述B端OMS模块的功能设计、流程设计与上下级模块交互等。

本文章描述我个人对B端OMS模块的功能设计、流程设计与上下级模块交互等。

因笔者一直从事的是电商相关行业，顾名思义，我定位的上级就是各个电商平台，第三方等、下级类似于各个商家。

订单大体产品结构

看过很多笔者的文档，对于订单的组成概念大体都相同，大体可分为：

1. 订单主表信息

订单标识号，订单状态，寄件人信息，收件人信息等。

2. 订单明细表信息

商品信息，订单价格属性等。

3. 支付信息

支付方式,支付时间,支付单号,支付金额等。

4. 与下级模块交互时可能会需要的字段

这块根据各个产品制定，有些是属于行业专属类似于3c类目的sn码，食品生鲜类目的保质期等；

1. 发票信息：消费者需开通发票，联通开票系统时需存储的信息
2. 标识类内容：例如来自于消费者的留言信息，来自于商家前端客服人员的备注信息，订单旗帜，标签等
3. 承运方信息：例如某东下单时消费者可选择京配或京尊达等承运方式，也可商家指定承运方给到订单信息，用于后续与wms,tms系统交互使用
4. 操作日志：check环节，涉及商家自主操作的环节，日志都是必不可少的，后续追诉问题时会用到
5. 重量：如预估重量，方便后续对接自动化设备或物流智选环节

流程

描述完了订单结构，描述一下大体流程：

流程图简要概括，红色区域偏业务，可拓展性也强，竞品优势体现也更明显，下面描述下各个业务模块的功能点及场景。

最顶端来源于上游接口，如电商平台，第三方仓储，线下订单等，订单数据拿到后做字段转换，通俗理解就是讲上游api中给的字段信息替换成我们自己的字段保存至我们业务表，在保存的过程中我提到了两点：

1. 赠品规则

智能配赠品，绝大多数平台会有平台级的赠品规则，比如某宝聚划算或上款界面都可设置比如前100购买次数会获赠一个商品，金额满500会获赠一个商品等等，由于平台规则等原因商家很多个性化营销活动都在线下完成，会通过配置一定的策略在订单下载时自动判断，满足规则后自动添加赠品至订单。

赠品规则的触发条件需提供入口给到商家配置，如下单触发，付款触发等，赠品规则通常情况下需要的维度。

1. sku级别
2. spu级别
3. 买家账号，收货人，收货人联系方式，收货地址级别等
4. 订单商品数量，订单金额（包含应付，已付）
5. 供分销(供分销管理，订单可支持多级供销推送及发货回传)
6. 发货仓(多级仓库管理，多地协同作业)

2. 筛选规则

筛选规则的实用性会更加丰富，商家特殊单筛选（刷单）恶意买家筛选，平台抽检订单筛选，或者更实用一点的——”新疆的订单需要发ems””这几天上海进博会，不能发货”…

满足特定条件的订单需用特定的方式操作，配合规则的实现就是筛选出地址为新疆的订单并自动配快递为ems，筛选出地址为上海的订单自动转为异常管理，同样筛选规则的考虑维度和赠品规则类似再附加上来自消费者的一些标识信息如买家留言等。

简述了订单模块的两个规则类设置，针对不同的业务场景不同的行业，也会衍生出不同的规则，同时也需要考虑的就是多种规则的执行顺序，即优先级问题。

订单被”规则”后，流入OMS系统中，这部分也就是B端用户对订单的操作，我们大体可以对订单类型做这样的概括：

• 待付款
• 待发货
• 异常
• 已发货

代付款状态 比较好理解，消费者下单后，或已经产生单据或在购物车中，但并未付款。

待发货状态 即消费者已付款订单，即可以发货状态。

异常状态管理 在我看来相对重要，这个环节也是根据不同系统的业务来决定的，多种异常分类管理及多种异常处理方式，与接口交互类的异常，如消费者付款后又修改了订单收货地址，系统内信息修改前拉入异常管理，修改后转入发货流程，异常精细管理，方便操作端。

订单单据创建后，正式流入发货阶段前，其实商家可以对订单进行很多操作，如订单信息修改，订单成本估算，订单预估发货时间及预计到达时间等，这部分根据各自公司的客户群体做差异化，融入行业特点，便利商家操作，提高竞聘优势。

单据信息确认后，可以推至WMS端进入发货流程，这个时候需要审单流程介入，审单通俗来说就是确认订单是否可以发货，确认来自消费者的诉求 订单上是否已经实现，确认发货地址信息是否正确等，确认无误审核，预售业务介入。

当前的各大销售平台都会推出预售活动，提前锁定消费者，使消费者有一种“提前有意向后尾款会优惠”的想法，类似预售活动会影响到订单判断库存的逻辑，决定是否预留库存给到预售订单和如何预留，也是预留库存业务的核心，这里就不再赘述，有兴趣交流的同学我们也可以再继续深入交流这个业务。审核的最后也就是判断库存，判断发货仓，判断供销商等环节。确认后，成功推至WMS端，走进发货流程。

单据进入WMS环节后OMS就完结了吗？

不是的，不管订单在哪个环节，来自于消费者的需求都是有可能的，OMS需关联至WMS端的订单，实现后端同步前段修改，前端订单信息发生了改变，后端需同步拉回，同步修改。

单据发货后，可能会产生售后，售后环节我也放在了OMS侧，售后操作流程大体如下：

消费者申请售后，商家同意，销售者寄出退回包裹并在平台端填写退回单号，商家仓库人员收到退回包裹后check货物，无误后确认收货状态，同步至OMS端并同步至平台端，平台退款给消费者，这样子的一个环节。

售后单据类型大体为仅退款业务，退货退款，换货，补发四种类型，如某宝支持发货前消费者申请仅退款，发货后消费者申请退款退款不支持仅退款，某猫支持消费者申请换货等、漏发等由于商家端的问题则会用补发补偿消费者。

对于收货方式，不同的产品也会有不同的操作，可优化的点也会体现出来，这里也就不再赘述了。

因为当前工作就是这个行业,很多细节文章里中不便拿出来分享了，关于OMS后续的操作端，例如WMS，TMS，MRP，CRM等环节有兴趣的同学也可评论或一起来交流学习，平时有整理出一整套企业erp组成的prd文档及脑图等材料，有需要同学也可评论。

 

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

题图来自Unsplash，基于CC0协议