50000+企业的共同选择
点三全渠道全链路ERP
400 8080 092
编辑:原创 时间:2026-10-14 16:46:37
微信小商店的供货商代发模式是一种独特的电商履约形态——商家的订单需要分配给代发者(供货商/云仓)执行发货动作。当商家使用ERP/OMS系统、供货商/云仓使用WMS系统时,涉及横跨不同第三方服务之间的信息传输。微信小商店官方为此提供了基于奇门协议的标准化对接指南,用于解决代发模式下的三个核心问题:WMS拿到发货单后如何知道对应平台上的哪张代发单;一张发货单聚合了多张代发单或多张代发单拆成多个包裹时,发货结果如何正确分组回传;取号与发货动作由ERP还是WMS执行,如何显式约定。本文将深入解析这套协同架构的技术要点。
一、角色定义与核心概念
在代发模式的对接架构中,涉及两个核心角色。上游ISV/ERP是向WMS推送发货单的一方,下游ISV/WMS是接收发货单并实际执行拣货发货的一方。关键业务对象包括:代发单(唯一标识为ds_order_id)、供货商ID(以supplier_appid标识)、微信小商店商品(以product_id+sku_id标识)。
开发者需要特别注意一个关键区分:“微信小商店商品件数”与“本地货品拣货件数”是两个不同维度。一个平台SKU可能对应多个本地货品(组合装),一个本地货品也可能被多个平台SKU共用。回传发货结果时必须使用平台维度的商品与件数,不能直接使用拣货件数。这一规则在对接初期极易出错,开发者需要在WMS系统中建立平台SKU与本地货品的映射关系表。
二、代发模式的完整链路
代发模式的完整链路分为八个步骤,其中“建立关联”“分配代发单”“取电子面单”“发货回传”“修改物流”“售后换货”需调用平台接口,“推送代发单”“拣货打包”发生在ERP与WMS之间。
流程的起点是商家在微信小商店平台创建代发单并将其分配给指定的供货商。随后,ERP系统通过奇门协议将代发单信息推送到下游WMS系统。WMS系统接收到代发单后,执行拣货和打包操作。在发货环节,系统需要调用平台接口获取电子面单,并将发货信息(包括物流单号和平台维度的商品明细)回传到微信小商店平台。
对于一张发货单聚合了多张代发单的情况,WMS系统需要在回传时按照平台要求的格式进行正确分组。同样,当一张代发单拆成多个包裹时,每个包裹的物流信息和商品明细需要独立回传,确保平台侧能够正确追踪每一个包裹的履约状态。
三、取号与发货动作的角色约定
取号与发货动作由ERP还是WMS执行,需要在系统设计之初就显式约定。这一决策直接影响系统的职责划分和接口调用链路。如果由ERP执行取号,则WMS只需负责拣货打包并将包裹信息回传给ERP,由ERP统一调用微信小商店的电子面单接口和发货接口。如果由WMS执行取号,则WMS需要直接对接微信小商店的物流相关接口。
两种模式各有优劣:ERP取号模式的优势在于统一管理和集中调度,适合多仓库、多供货商的复杂场景;WMS取号模式的优势在于链路更短、响应更快,适合单一仓库的高效履约场景。开发者应根据商家的实际业务模式进行选择。
四、奇门协议与数据安全保障
代发模式下,ERP与WMS之间的数据传输通过奇门协议完成。奇门协议是阿里巴巴生态中用于系统间安全通信的标准协议,支持加密传输和数据校验。微信小s店在供货商代发模式中同样采用了这一协议,确保订单数据在跨系统流转过程中的安全性。
开发者需要在ERP和WMS两侧分别实现奇门协议的对接能力。在数据安全方面,涉及消费者敏感信息的字段应进行脱敏处理,仅在必要环节获取明文。发货回传时,应使用平台要求的密文格式传递收件人信息。
点三深耕全渠道数据对接领域十余年,已全面适配ERP-WMS协同架构。点三电商开放平台内置了代发单分配、奇门协议通信、发货回传分组等核心能力,帮助数千家供货商和云仓实现与电商平台的高效协同。如有对接电商平台的需求,可咨询点三客服免费获取接口文档。
最新文章