调拨单同步策略实战教程:从用友BIP到旺店通的库存调拨链路设计

这个策略解决什么问题

调拨单同步解决的是"跨系统库存调拨业务无法自动闭环"的问题。在某零售企业的实际场景里,业务人员先用用友BIP作为后端 ERP 发起调拨申请,审核完成后,门店或电商仓需要在旺店通里生成可执行的调拨出/入库单,推动实物移动。两套系统不同步时,常见的现象是:同一张调拨单在两边各录一遍,数字对不上、责任分不清,而且很容易出现"BIP 已审、旺店通未推"的延迟。

我们用轻易云数据集成平台(Qeasy)承接这一段链路,本质上是把 BIP 的调拨申请单按调度节拍拉出来,清洗后写入旺店通,让两边库存语义保持一致。

数据流向与字段映射

整体流向:用友BIP(源) → 轻易云集成平台(中间层) → 旺店通(目标)。源端通过 POST /yonbip/scm/transferapply/list 拉取调拨申请单,目标端通过 wdt.stock.transfer.push 推送至旺店通。

下面是关键字段对照(经过脱敏与泛化):

业务含义	用友BIP 源字段	旺店通目标字段	中间层处理要点
单据编号	code	outer_no	用 `{{code}}` 直接代入,作为外部单号防重
源仓库编码	outwarehouse(源上下文)	from_warehouse_no	通过 `_findCollection` 查映射表,做仓库编码转换
目标仓库编码	inwarehouse(源上下文)	to_warehouse_no	同上,目标端仓库字典独立维护
联系电话	电话字段	telno	缺省为空,后续可补充
备注	bustype_name + memo	remark	拼接为 `YS{{bustype_name}}{{memo}}`,便于人工追溯
调拨类型	业务类型	transfer_type	按目标端的枚举值做映射

中间层不止是字段搬运,它要做三件事:防重(outer_no 幂等)、编码转换(尤其是仓库这种两套系统各自维护字典的主数据)、以及对调拨类型做枚举对齐。

在轻易云上如何配置

在轻易云控制台里,这个策略被建模成"源查询 + 目标执行"两条链:

源端配置:接口选 POST /yonbip/scm/transferapply/list,分页参数 pageSize 设 100,pageIndex 由平台自动翻页;增量字段使用 open_vouchdate_begin / open_vouchdate_end 作为单据时间窗。开启 autoFillResponse,让响应结构由平台自动填充。idCheck 设为 true,避免重复拉取同一张单据。
目标端配置:接口选 wdt.stock.transfer.push,关键是仓库字段用 _findCollection 引用我们提前维护好的映射表(集中管理编码映射是轻易云客户常见做法);备注用模板字符串拼接;outer_no 直接引用源单编号。
调度配置:源端 cron */2 * * * *,目标端 cron 1-59/2 * * * *,错峰执行避免抢资源;并打开异常重试和告警通道。

实施步骤

我们建议分三个阶段推进,这是轻易云客户中比较稳妥的节奏:

第一阶段:增量起点。先用一个月度时间窗(例如最近 7 天)启动增量,把历史上未推送的调拨单补齐。这一阶段重点盯防重字段 outer_no 是否生效,避免重推。
第二阶段:全量触发。业务低峰期(比如凌晨)一次性补全历史数据,完成后回到增量节奏。
第三阶段:稳定运行。cron 改成 2 分钟轮询,源端拉、目标端推错峰运行;同时开启表头和表体的分阶段处理——先跑通表头,再叠加表体行项目,降低首期失败率。

踩坑复盘

这里总结几条我们和客户一起踩过的坑:

仓库编码直接拼接,不做映射。典型错误是把 BIP 的仓库编码原样塞进 from_warehouse_no,结果旺店通端找不到仓库,单据被静默丢弃。稳妥的做法是在轻易云的映射表里集中维护两套仓库编码的对应关系,变更时一处修改、全链路生效。
outer_no 没真正起防重作用。如果中途手工修复过单据,可能同一编码被多次推送,导致旺店通端出现重复调拨单。建议在平台层面加一层 idCheck,源端只拉一次、目标端按 outer_no 去重。
调拨类型枚举对不齐。BIP 的业务类型和旺店通的 transfer_type 不是 1:1,如果不映射,要么落空要么错配。
表头表体一锅炖。一次同步里既改表头又改表体,失败时很难定位是哪个层级的问题。分阶段、表头表体分批跑,排查效率会高很多。
cron 抢资源。源端和目标端同一秒触发,在数据量大的时候容易把对端接口打满。错峰 30 秒到 1 分钟,经验上更稳。

适用场景与不适用场景

适用:BIP 作为 ERP 主审、旺店通作为门店/电商仓执行系统的零售或分销企业,需要把调拨申请自动落到旺店通生成可执行单据;对实时性要求在分钟级即可。不适用:需要强实时秒级联动的场景(应走消息队列而非轮询);也不适合调拨业务流程完全不同、需要双向协同审批的复杂场景,这类建议拆成多条策略分别建模。