OMS订单系统：智能拆单规则引擎设计
引子：一个被拆成5单的订单 “用户下单买了3件商品，为什么最后拆成了5个包裹？客户投诉说运费太贵了！” 这是2023年春节后，客服经理的第一通投诉电话。我打开OMS系统查看： 订单详情： 商品A：2件（北京仓有1件，上海仓有3件） 商品B：1件（深圳仓有货） 商品C：1件（北京仓有货） 系统拆单结果： 北京仓发货：商品A × 1 上海仓发货：商品A × 1（本应2件） 上海仓发货：商品A × 0（空单！） 深圳仓发货：商品B × 1 北京仓发货：商品C × 1 问题分析： 拆单逻辑错误：商品A应该合并发货 产生空单：浪费系统资源 运费激增：5个包裹 vs 最优2个包裹 客户体验差：收货5次，退货率上升 这个案例暴露了硬编码拆单逻辑的致命缺陷。经过2个月的重构，我们实现了： 拆单准确率：65% → 98% 平均拆单数：2.8单 → 1.5单 人工干预率：15% → 3% 拆单耗时：500ms → 80ms 这篇文章，就是那次规则引擎重构的完整技术总结。 业务场景：为什么需要拆单 常见拆单场景 场景1：跨仓发货 订单包含： - 商品A：北京仓 - 商品B：上海仓 拆单结果： - 子订单1：北京仓发商品A - 子订单2：上海仓发商品B 场景2：部分有货 订单包含：商品A × 3件 库存情况： - 北京仓：2件 - 上海仓：1件 拆单结果： - 子订单1：北京仓发2件 - 子订单2：上海仓发1件 场景3：物流限制 订单总重：35kg（单票限重30kg） 拆单结果： - 子订单1：20kg - 子订单2：15kg 场景4：营销活动 订单包含： - 商品A：参加满减活动 - 商品B：不参加活动 拆单结果： - 子订单1：商品A（享受满减） - 子订单2：商品B（正常发货） 拆单规则的复杂性 多维度规则冲突 示例场景： ...