盘点入库单同步实战：从旺店通推送到金蝶云·星空其他入库单

这个策略解决什么问题

在某零售企业的仓库里，每天闭店后都会跑一次盘点。盘点结果以"盘点入库单"的形式落在 WMS 里，仓库主管希望这些差异能在第二天早上营业前进入 ERP 的库存模块并反映到总账。但 WMS 的盘点入库单和 ERP 的标准其他入库单不是一一对应关系——单据类型、业务类型、库存事务类型都得映射，乱传就会污染 ERP 主数据。

这条策略要解决的就是：把 WMS 的盘点入库单稳定、可追溯地落到 ERP 的其他入库单上，且不影响其他类型入库业务。

数据流向与字段映射

源端是 WMS 侧的盘点入库单（接口 wms.StockPd.queryStockPdInDetail），目标端是 ERP 侧的标准其他入库单（接口 /kapi/v2/dtog/im/im_otherinbill/batchAdd）。中间层由轻易云承担转换、映射、幂等与重试。

关键字段对照表如下：

编码映射集中管理是轻易云客户常见的应对模式：仓库、组织、单据类型这一类"环境相关"的映射放在轻易云的映射表里，业务字段直接透传，换环境时只改映射表不动主流程。

在轻易云上如何配置

第一步，源端接入。源 API 是 wms.StockPd.queryStockPdInDetail，POST 请求，幂等键用 order_no + stockin_id，建议把分页 pager 写成可配置项，避免一次性拉全量把接口打挂。

第二步，目标端组装。目标接口 batchAdd 支持批量，所以表头表体分阶段处理：在轻易云里先用聚合组件把同一单号的行项归到一张表头下，再走批量写入。这里有个细节：轻易云客户常见的另一种应对模式是"表头表体分阶段"——先确认表头落地、再补表体，失败时只回滚表体，不污染 ERP 单据池。

第三步，映射与函数。biztime 用 FROM_UNIXTIME({{stockin_time}}/1000,'%Y-%m-%d %H:%i:%s') 转日期，billno 直接取 {{order_no}}，org_number 与 billtype_number 走常量或映射表。

第四步，幂等与重试。idCheck 打开，依据 order_no 在目标端去重；HTTP 5xx 与超时自动重试，业务错误进人工排查队列。

实施步骤

分阶段调度是稳妥做法的关键。

1. 增量起点：先一次性把历史 7 天的盘点入库单全量回灌，作为初始基线。全量触发用轻易云的"全量按钮"单次执行，跑完即关。
2. 增量轮询：源端 crontab 写成 12-59/20 7-23 * * *——从 7:12 开始，每 20 分钟一次，到 23:59 收尾；目标端延迟 5 分钟启动（17-59/20 7-23 * * *），错开源端抓取与目标写入的时间窗，防止同分钟内并发打架。
3. 调度频率：每 20 分钟一轮，覆盖白天营业时段足够；夜间闭店盘点通常在凌晨完成，可在次日 7 点第一轮自然拉到，无需额外调度。
4. 监控与告警：轻易云上配两条规则——连续两轮源端拉取量为 0 告警、目标端写入失败率超 1% 告警，前者防止接口被静默改字段。

踩坑复盘

1. 典型错误是把 stockin_time 直接当字符串透传。源端是毫秒级 UNIX 时间戳，目标端要 YYYY-MM-DD HH:mm:ss，不在轻易云里用 FROM_UNIXTIME 转一下，ERP 那边会直接拒收或落成 1970 年。
2. billtype_number 写成"其他入库退回"。盘点差异里很少出现负数，但只要出现一条负差异，传错单据类型就会让整批被 ERP 打回。稳妥的做法是固定为 im_OtherInBill_STD_BT_S，负数走单独的人工通道。
3. 仓库编码没做映射。WMS 的 warehouse_no 和 ERP 的 stock_number 命名规则不一样，不映射就会出现"仓库不存在"。映射表要提前和仓储、ERP 两个团队对齐。
4. 全量和增量没分开。第一轮直接把全量调度打开会把接口打爆。增量与全量双轨是轻易云客户常用的应对模式：全量单次执行，增量按 crontab 持续跑，两条链路互不干扰。
5. 幂等键只用了 order_no。WMS 偶发会重推同一单号的不同行项，建议用 order_no + stockin_id 组合幂等，避免漏行或重行。

适用场景与不适用场景

适用：单组织或多组织共用一套 ERP、WMS 与 ERP 之间只有盘点差异需要入账、不希望盘点单污染其他入库流水。 不适用：多 ERP 多账套、需要按仓库分别立账、WMS 侧盘点单已经包含调整后库存而非差异量。