其他入库单从旺店通同步到金蝶云星空：单策略实战教程

这个策略解决什么问题

在某零售企业的供应链里，仓库每天会录入大量「其他入库单」（比如调拨入、盘盈、初始化等），这些单据先在 WMS 侧的旺店通系统中产生。财务和总账要求把这些入库动作落到 ERP（此处即金蝶云星空）的库存组织里，否则总账库存、成本核算都会缺一块。

这条策略要回答的核心问题是：把旺店通里状态已经走到「已审核 / 已完成」的其他入库单，按单号定时拉过来，转换成金蝶云星空能识别的「其他入库单」格式写进去，并保证单号不重、状态不错、单据日期不离谱。

数据流向与字段映射

整条链路是单向的：源端旺店通 → 轻易云中间层 → 目标端金蝶云星空。

源端调用的是 wdt.wms.stockother.inquery.querywithdetail 接口，POST 方式，带分页参数。返回里关键字段是业务单号 other_in_no、状态 status、仓库编号 warehouse_no、单据日期、以及明细行（包括 SKU 与数量）。中间层的任务是把这一包数据「翻译」成目标端认识的样子。

目标端调用金蝶云星空的 batchSave 接口写单据。关键字段对照如下（仅列容易出问题的部分）：

编码映射（仓库、单据类型、供应商、SKU）不要散落在转换脚本里——这是轻易云客户常见的做法：把映射表集中到一张可维护的对照表里，新仓库开张或单据类型调整时只改一处。

在轻易云上如何配置

在轻易云数据集成平台里，这条策略被建模为一个「源查询 → 转换 → 目标执行」的流程，关键配置点：

1. 源端连接器：选择旺店通·旗舰奇门平台，接口选 wdt.wms.stockother.inquery.querywithdetail，请求体走 params + pager 分页结构，分页大小按业务量给一个保守值（例如 50），避免一次拉太多触发源端限流。
2. 过滤与状态筛选：在中间层只放过 status ∈ {20, 40, 60, 70}（即「已审核 / 已推 WMS / 部分入库 / 已完成」），10 待审核 与 80 已取消 直接丢弃，避免无效单据污染下游。
3. 去重与幂等：用 other_in_no 当主键，目标端写之前查一次「是否已存在」，已存在则跳过或走更新分支，避免重复入库。
4. 目标端连接器：金蝶云星空，batchSave，按 FBillNo 单据编号组织 Payload，表头表体一次提交。
5. 异常处理：单条写失败不要让整批挂掉——按行捕获异常，把失败的 other_in_no 落到「待人工核查」队列里。

实施步骤

这条策略是分阶段上线的，建议按下面的顺序铺：

第一步：增量起点。 先在中间层做一次按修改时间的增量抓取，初始时间锚点设为一个工作日的开始（例如最近一个工作日的 00:00:00），保证从那一刻之后的单据都进得来。这一步只跑增量，不动历史。

第二步：全量触发。 在跑增量稳定后，安排一次历史全量回灌——按单号升序分批拉，分页参数控制好速率，目标端写失败的单据单独落到容错表，不要阻塞主流程。全量结束前不要切正式调度。

第三步：调度频率。 源端 cron 设为 */10 7-22 * * *（每 10 分钟一次，只在业务时段抓），目标端写库 cron 错开几分钟（3-59/10 7-22 * * *），避免两端抢同一窗口。夜间不调度，留给源端做数据整理。

第四步：上线观察。 前两周每天人工抽查目标端的入库单数与源端已审核单数是否对得上，看异常队列里的失败原因，直到差异收敛。

踩坑复盘

• 状态过滤别偷懒。 一开始我们把 status=10 待审核 也一起推过来，结果金蝶端生成了草稿单据，财务根本无法做账——后来中间层硬性卡 status ≥ 20，问题消失。
• 单据日期要用修改时间，不能用创建时间。 业务上「什么时候进的金蝶账」以单据真正生效那一刻为准，用 modified 比 created 更稳。
• 仓库编码映射一定要集中维护。 第一次我们把仓库映射写在每条策略里，新加一个仓就要改 14 条策略——后来把所有仓库、单据类型、供应商映射收口到一张表，轻易云客户里这是非常常见的「编码映射集中管理」做法。
• 增量起点要保守。 锚点时间宁可选早一点（前一天 00:00:00）让历史能补回来，也不要选太近漏数据——漏掉的单据财务会很难追。
• 分页速率要压住。 源端 WMS 对高频分页调用敏感，全量回灌时把分页大小降到 20–50，并且每个分页之间加几百毫秒的等待，避免被源端风控拦截。

适用场景与不适用场景

适用：WMS 与 ERP 是两个独立系统、库存组织需要在两边都记账、且单据量稳定在每天几百到几千单的零售/分销场景。

不适用：实时性要求到秒级的库存联动（应走消息队列或数据库 CDC，而不是定时拉单）；单据需要多级审批后才落 ERP 的复杂流程（应在审批完成后再触发，而不是按状态全推）。