现如今电商行业发展势头很猛，订单管理这件事变得越来越重要。一个好用的订单管理系统，直接关系到用户买得顺不满意、仓库能不能省成本、物流送得快不快。

说得直白点，订单管理系统就是连接买家需求和仓库发货的桥梁。它一方面要接收商城那边过来的订单，另一方面得和库存系统保持同步，根据商品在哪儿、订单急不急来智能分配库存、确定发货时间。整套系统能不能跑顺溜，关键就在于能不能把订单从生成到出库的每个环节都管明白。



这篇文章会从单据类型、流转逻辑、状态变化三个角度，带你看透订单管理系统的设计门道。

一、核心单据类型

订单在OMS里转来转去，本质上就是不同单据之间来回倒腾。把这三种单据搞清楚了，整个流程就明白了一大半。

销售订单是用户在商城一下单就生成的最早那版单据，相当于订单的“原始档案”。它把交易的方方面面都记了下来：用户这头的ID、等级、收货地址；商品这头的商品ID和数量；价格这头的单价、总价、优惠金额；另外像活动ID、下单时间、买家备注这些也都会关联进去。

包裹单是OMS要把订单发给WMS之前，经过一通业务处理后生成的中间单据。为什么需要这么一层转换呢？因为一个销售订单可能会对应好几个包裹单——举个例子，用户在同一家店买了好几样东西，可能因为仓库不在一处或者包装限制，得分开寄。包裹单里的字段就更偏实际操作了，比如后台商品ID、从哪个仓库发、用的哪家物流、运单号是多少、包装材料啥规格、商品多重多大等。

出库申请单是WMS收到包裹单、审核通过后，用来指挥仓库具体怎么出库的单据。相比前面两种，它更关注仓库内部怎么执行，比如商品放在哪个库位、是哪一批次的等等。



二、单据流转的关键逻辑

从销售订单到最终出库，OMS得跑好几个流程。其中最核心的四个环节是：拦截、合单、拆单、审单。

拦截就是在订单正式开跑之前，先设些规矩把它拦下来。常见的情况有：某些地方发不了货（比方说特定时段某些省份不收粉末或液体类商品）、发现异常用户、活动期间需要控单等等。被拦下来的订单等条件解除了可以自动恢复，也可以让人工去处理。

合单的思路是把能合并的订单凑成一个包裹，这样仓库和物流都能省点钱。常见的合并规则是：同一个用户、同一家店、同一个收货地址。近年来社区团购火起来了，就是个很好的例子——一个团长下好几个团员的订单，到最后其实会合并成团长那边的一个包裹来配送。

拆单呢，则是反过来。有些订单天然就不适合合并，这时候系统就会把它拆开处理。常见的情况包括：用户买的商品分布在不同仓库；商品必须按原箱规格发（像纸尿裤四提装一箱，就算用户买了八提，也得拆成两个包裹）；礼品盒得单独包防止压坏；订单太大超出仓库包装能力等等。拆单的同时，仓库怎么分配、选哪家物流、运单号怎么生成这些问题也就一起解决了。

审单就是让人再复核一遍。包裹单在进WMS之前，通常需要审核确认。审核时可以加上必要的备注，审完系统会自动把包裹单推给WMS生成出库申请。当然，如果订单符合自动审单的条件，也可以全程自动跑，不用人介入。

实际操作中，异常情况免不了。库存不够、物流到不了、运单号拿不到、商品信息同步出问题这些，都需要人工来擦屁股。

三、单据状态流转

搞清楚了单据状态怎么变，订单处理的全貌也就清楚了。

销售订单的状态按顺序是这样的：待付款（订单提交了但还没给钱）→待发货（钱已到账）→已发货（仓库发出去了）。另外还有取消、售后这些反向的状态。



包裹单的流转是：待审核（刚创建出来，系统一般会自动通过）→待处理（审核完后执行拆合单逻辑，等仓库确认）→未发货（仓库收到了但还没发）→已发货（仓库完成发货）。

出库申请单的状态相对简单：待出库（刚创建）、出库中（库存已分配或波次已创建，等着正式出库）、已完成（整个流程走完了）。

写在最后

订单管理系统设计来设计去，核心就是要在用户体验和运营成本之间找到平衡点。拦截规则设得合理，业务风险就能控住；合单拆单做得精准，既能省物流成本又不会耽误用户收货；状态流转设计完善了，运营分析也有据可依。把这三个维度的门道搞明白，做订单管理系统心里就有底了。