视频号小店（现已迁移到微信小店）的供货商代发模式是一种独特的履约形态：商家的订单需要分配给代发者（供货商/云仓）执行发货动作。当商家使用ERP/OMS系统、供货商使用WMS系统时，订单信息需要跨越两个独立的第三方服务边界。微信小店官方为此提供了基于奇门协议的标准化对接指南，其核心设计思路值得深入剖析。

一、代发模式要解决的三个工程问题

官方对接指南开宗明义地指出了代发模式面临的三个核心问题：WMS拿到发货单后，如何知道这批货对应平台上的哪张代发单、哪些商品；一张发货单聚合了多张代发单，或一张代发单拆成多个包裹时，发货结果如何正确分组回传；取号与发货动作由ERP还是WMS执行，如何显式约定。这三个问题分别对应身份映射、结果分组和职责划分，是代发模式集成中必须逐一解决的工程难题。

二、奇门协议中的关键映射规则

代发单的唯一标识为ds_order_id，供货商以supplier_appid标识，平台商品以product_id+sku_id标识。ERP向WMS推单时，使用奇门发货单创建接口taobao.qimen.deliveryorder.create，平台来源编码需设置为WXXD以标识微信小店。代发单的核心信息（ds_order_id、平台商品ID、SKU ID、商品数量）通过extendProps自定义拓展字段进行传递。

这里有一个极易被忽视但后果严重的规则：“微信小店商品件数”与“本地货品拣货件数”是两个不同维度。一个平台SKU可能对应多个本地货品（组合装），一个本地货品也可能被多个平台SKU共用。回传发货结果时必须使用平台维度的商品与件数，不能直接使用拣货件数。开发者在系统设计之初就应在WMS侧建立平台SKU与本地货品的映射关系表，否则发货回传环节必然出现商品数量错位。

三、取号与发货动作的职责显式约定

指南明确指出，“取号与发货动作由ERP还是WMS执行，需要显式约定”。这一设计决策直接影响系统的接口调用链路和职责边界。ERP取号模式将物流接口的调用集中在ERP侧，适合多仓库、多供货商的复杂调度场景；WMS取号模式将链路缩短至仓库作业现场，适合单一仓库的高效履约。两种模式没有绝对优劣，关键在于在对接协议中明确约定并写入接口契约，避免双方各自实现导致重复取号或发货信息冲突。

四、链路分段与异常分支的处理

代发模式的完整链路中，“推送代发单”和“拣货打包”发生在ERP与WMS之间，而“建立关联”“分配代发单”“取电子面单”“发货回传”“修改物流”“售后换货”需调用平台接口。其中“修改物流”和“售后换货”是按需触发的分支，不是每单必经环节。开发者在设计状态机时，应将主链路和分支链路分别建模：主链路保证每单必然经过的节点状态准确流转，分支链路则通过事件触发的方式按需介入，避免将分支逻辑耦合进主流程导致状态机膨胀。

点三深耕全渠道数据对接领域十余年，已全面适配代发模式下的ERP-WMS协同架构。如有对接电商平台的需求，可咨询点三客服免费获取接口文档。