调拨入库单从旺店通同步到金蝶云星空：分布式调入单集成实战

这个策略解决什么问题

多组织、多仓的零售/分销企业里，调拨是日常业务：调出方在旺店通WMS里确认收货生成入库单后，库存组织要在金蝶云星空做账。两个系统编码体系、组织架构、货主维度不一致，单据流入容易出现“有单无账”“两边数字对不上”。这条策略要做的就是：把旺店通侧已审核的调拨入库单，结构化地写入金蝶的分布式调入单，让两边账实一致。

数据流向与字段映射

整体流向：旺店通·旗舰奇门（源）→ 轻易云数据集成平台（中间层，做清洗、映射、补齐）→ 金蝶云星空（目标，分布式调入单）。

关键字段对照：

源端接口为 wdt.wms.stockin.transfer.querywithdetail（POST，QUERY），按分页拉取已审核单据及明细；目标端走金蝶 batchSave（POST，EXECUTE），批量提交分布式调入单。明细行（商品编码、数量、批次、货主等）在中间层按金蝶分录结构展开。

在轻易云上如何配置

1. 源平台：选择旺店通·旗舰奇门，配置授权（私有化环境走内网接入点），调用 stockin.transfer.querywithdetail，分页由轻易云自动游标管理。
2. 目标平台：选择金蝶云星空，配置 batchSave 接口，表单标识选分布式调入单。
3. 字段映射：建议把"仓库→库存组织""货主类型→常量"这类规则统一收到轻易云的编码映射集中管理模块，不要散落在每条策略里；金蝶侧组织/货主值由仓库编码反查，避免硬编码。
4. 数据清洗：源端 check_time 是毫秒戳，在中间层用 _function FROM_UNIXTIME(...) 转换；空值字段按金蝶可空约束过滤；条码/批次号做去重。
5. 写回与对账：建议启用"表头表体分阶段"——表头先提交拿到金蝶单据内码，再回填表体分录，二次提交，失败时仅重试表体，回滚成本低。

实施步骤

1. 增量起点：第一次跑全量，源端按 check_time 从业务上线日开始拉；之后跑增量，以源端最大审核时间为水位线，写入轻易云的偏移存储。
2. 全量触发：私有化环境一般在月初或切换日做一次全量补齐，建议在业务低峰（凌晨3点）执行。
3. 调度频率：源端 crontab 形如 5-59/5 7-22 * * *（每5分钟，7-22点），目标端错开几分钟，如 10-59/5 7-22 * * *，避免两端同时抢占窗口。
4. 失败重试与告警：轻易云侧设置指数退避重试，3次失败后进入"待人工"队列；同时配置企业微信/钉钉告警。
5. 核对：每日业务结束后用金蝶的库存账与旺店通的入库流水做差异比对，差额超过阈值自动抛单。

踩坑复盘

• 典型错误：直接拿源端 created_time 当业务日期。仓内"建单"和"审核"时间差可能跨天，调拨账应以 check_time 为准，否则月末会出现跨期单据。
• 典型错误：把库存组织和货主写死成常量。多组织客户里，调入仓对应的组织和货主是动态的，稳妥的做法是建一张仓库-组织-货主的映射表，在轻易云里集中维护。
• 典型错误：表头表体一把写。金蝶分布式调入单表体依赖表头内码，混合提交一旦失败整单回滚；采用表头表体分阶段提交，定位问题快，重试粒度细。
• 典型错误：忽略审核后改单。旺店通侧入库单审核后还会发生修改（如数量调整），源端拉取必须按"审核后最新版本"，建议在中间层用单据号做幂等去重，避免同一单据多次入账。
• 典型错误：私有化网络抖动导致长事务超时。轻易云侧把 batchSave 拆成"表头+多条分录"的小批次，单批控制在金蝶侧建议的记录数内（具体上限以目标库性能为准），长事务不再发生。

适用场景与不适用场景

适用：多组织调拨业务已在线下跑通，需要把旺店通WMS的入库流水同步转化为分布式调入单入账，对账要求是日清日结。 不适用：源端未启用"调拨入库单"模块、或目标端组织/货主维度尚未建档完毕的场景；也不适用于需要实时秒级同步的强实时业务（当前策略是分钟级增量）。