直接结论。 拆单应使客户原订单、供货方执行单、金额与售后记录仍能互相追溯。把一张单复制成几张子单只是开始，真正要核对的是责任、状态和异常。商猫云链提供订单拆分与履约协同方案；具体拆分条件及适用版本按项目确认。
拆分依据与参与方
先区分三种看似相近的“拆”：按供货方划分，目的是明确经营和履约责任；按仓库划分，可能只是安排不同出库点；按支付主体划分，则牵涉收款与机构账户。一个项目可能同时涉及这些关系，但不能把它们压成一个子单字段。评审时应画出客户、平台、自营仓、联营商与支付机构，标注每笔商品由谁销售、谁发货、谁承担售后。
金额与明细如何保留
用一笔完全虚拟的订单说明记录关系：客户购买自营商品 400 元、供货方甲商品 350 元、供货方乙商品 250 元，商品金额合计 1,000 元。系统保留原订单和明细，并为执行方形成对应任务。此例不含优惠、运费和税费，也不代表资金已拆分。若存在优惠与运费，就要另定分摊规则，确保客户应付总额、各执行单分配额及调整记录可以核对；不能悄悄把差额塞到某一方。
履约状态与售后关联
状态不能只求整齐。甲已经发货、乙缺货时，客户整单不应被简单标作“全部完成”或“全部取消”。需要分别记录各执行方任务，并按项目规则汇总给客户。若甲的一件商品退货，售后应找到原明细、履约方和对应支付/结算记录。退货实物、退款申请、机构执行和结算调整可能发生在不同时间，不能在订单页面减掉一个金额就视为全部完成。
验收与项目范围
一组最低限度的验收样例包括：正常多供货方订单、其中一方缺货、部分发货、局部退货、原订单与子单金额及数量核对。每个样例说明触发条件、参与方、预期状态、实际结果与证据。项目验收应记录每个样例的实际结果与证据。
最后把项目差异落到书面范围。现有产品能直接处理的规则列为已有覆盖；特殊分配依据、平台商家接口、优惠承担或售后回写要求列为配置、集成或定制。由此确定工作包和验收标准，避免把“支持拆单”理解为任意经营关系都可以直接启用。