订单管理在电商供应链中扮演着核心角色。OMS系统负责接收订单信息、协调库存、分配仓储资源、确定交付时间，就像一条纽带，把用户需求和仓库履约连在一起。接下来，从单据在系统中的流转过程，来拆解订单管理的设计思路。



在OMS的完整链路中，有三种关键单据，分别对应订单处理的不同阶段。

销售订单是用户下单时产生的第一个单据，记录了交易的所有信息。包括用户层面的用户ID、等级、收货地址；商品层面的商品编号和购买数量；价格层面的单价、总价及优惠信息；还有下单时间、活动ID、用户备注等等。销售订单是整个流程的起点，之后的所有操作都围绕它展开。

包裹单是OMS把销售订单发给WMS（仓储管理系统）时生成的单据，两者呈多对多关系——一个销售订单可能拆成多个包裹，一个包裹也可能合并多个销售订单。包裹单的核心字段和銷售订单有明显差异：商品ID对应后台商品编码，发货信息包含仓库、物流公司和单号，包装信息涉及包材类型、重量和体积。包裹单是仓储履约的直接执行依据。

出库申请单由WMS在出库环节生成，是仓库实际配货的核心凭证。相比包裹单，它增加了库位信息、商品批次等用于库存精细管理的字段。这一环节与WMS深度耦合，属于仓储管理的范畴，这里就不展开说了。

从销售订单到最终出库，OMS需要完成一系列复杂的处理，其中最核心的四个环节是：拦截、合单、拆单、审单。

拦截的作用是在订单进入正式处理流程前先把它截下来。这通常发生在特定业务场景下：商品属性限制是最典型的情况，比如国家重大会议期间，某些地区不能发粉末或液体类商品；或者针对特定用户、活动的风控拦截。订单被拦截后，解决相应问题就能自动释放，恢复正常流程。

合单本质上是把符合条件的多个销售订单合并成一个包裹。电商场景中，同一用户、同一店铺、同一收货地址的订单天然具备合并条件。合单的核心目的在于降本增效——减少包裹数量意味着降低仓储操作成本、物流费用和包材消耗。近年兴起的社区团购模式就充分体现了合单逻辑：团长下的订单需要把多个团员的商品合并后统一配送。

拆单和合单看似矛盾，但解决的是不同问题。当出现以下情况时，订单必须被拆分：用户在不同仓库有商品库存；商品体积较大需要原箱发货，比如纸尿裤按箱计算；礼品盒或指定商品需要单独包装以保护品相；订单总量超过仓库最大包材容量。拆单过程同时伴随着仓库分配和物流资源的确定，是订单履约路径确定的关键节点。

审单是对包裹单的确认环节。人工审单时可以添加备注信息，审核通过后推送至WMS创建出库申请单。对于符合规则的订单，系统也可以配置自动审单，提升处理效率。



在实际运行中，异常情况不可避免：仓库库存不足、收货地无物流覆盖、快递单号获取失败、商品信息转换异常等。这些情况需要人工介入处理，OMS通常会提供异常订单的专门处理入口。

理解单据的状态流转，是把握订单全生命周期的关键。



销售订单依次经历待付款（用户提交订单但未支付）、待发货（支付完成后）、已发货（仓库完成出库）这几个核心状态。逆向链路中还包括取消和售后等状态。

包裹单的状态流为：待审核（包裹单初始创建）、待处理（人工审核通过，系统执行拆合单后）、未发货（仓库接收订单但未出库）、已发货（仓库完成发货）。



出库申请单的状态相对简洁：待出库（创建初始状态）、出库中（分配库存或创建波次后）、已完成（实际出库完成）。

各单据之间状态相互关联，形成一条从用户下单到仓库履约的完整链路。

不同业务场景下，合单规则、拆单策略和审单流程的具体实现会有差异，但核心思路是一致的——在用户体验和运营效率之间寻找最优平衡。