VMI调拨入库对接采购订单：从吉客云到金蝶云星空的单策略集成实战

这个策略解决什么问题

VMI（供应商管理库存）模式下，调拨入库单据需要在源系统与目标系统之间对齐：源系统记录实物的调拨与入库，目标系统则希望以采购订单的形式承载这笔业务，以便后续走收货、发票、付款链路。我们在客户现场常见的需求是：把源系统中的 VMI 调拨入库单，按时间窗口增量取出，落到目标系统的采购订单上，单据状态自动下推。看似一个简单的同步策略，但跨系统编码、组织、供应商档案没对齐时，3 个月后两边账对不上是常态。

数据流向与字段映射

整体流向：源 ERP（吉客云）→ 轻易云中间层 → 目标 ERP（金蝶云星空）。源端按入库单号与创建时间增量分页拉取，目标端以 batchSave 接口写入采购订单头与明细。

关键字段对照如下：

供应商与采购组织这两列是典型翻车点：源端的"仓库编码"在目标端要解释成"供应商档案"，中间层必须做一次语义转换。

在轻易云上如何配置

源端采用 QUERY 类型的 WebAPI（POST），分页参数 pageIndex / pageSize 固定，时间窗口用 {{LAST_SYNC_TIME|datetime}} 与 {{CURRENT_TIME|datetime}} 拼接，单号 goodsDocNo 作为幂等键写入中间层。idCheck=true 保证重复拉取不会重复入库。

目标端采用 EXECUTE 类型的 WebAPI（POST），调用 batchSave，把头字段与明细 FPOOrderEntry 一次性塞进去。我们一般建议客户把编码映射（仓库→供应商、组织映射、单据类型映射）放在轻易云的集中映射表里维护，不要写死在脚本里——上线后业务调整时只改一处。

实施步骤

分三阶段推进，避免一上来就跑全量把目标系统压垮：

1. 增量起点对齐：第一次执行前，把 LAST_SYNC_TIME 设定为业务约定的历史截止时间，先跑一次冷启动，确认源端能拉到数据、目标端能写入。
2. 全量补数：冷启动成功后，切换到全量模式补齐历史单据；这一阶段重点观察目标端的写入性能与组织/供应商校验失败的报错。
3. 稳态调度：源端调度设为 9 6-23/2 * * *（6 点到 23 点每 2 小时第 9 分钟触发），目标端调度设为 55 */2 * * *（每 2 小时第 55 分钟触发）。两端错峰运行，中间层留出缓冲窗口处理异常单据。

踩坑复盘

• 典型错误一：把源端仓库编码直接当目标端供应商写入。 源端是物流概念，目标端是业务概念，必须在中间层做语义转换。稳妥做法是在轻易云的映射表中显式维护对应关系，并加一条"找不到映射则写入异常队列"的兜底分支。
• 典型错误二：时间窗口按本地时区传，跨时区漏单。 源端 startDate / endDate 务必明确时区，建议两端统一在轻易云里以同一时区落库。
• 典型错误三：明细里数量、单价、单位混在同一个 JSON 节点里没拆分。 目标端 FPOOrderEntry 要求结构化字段，源端返回的是嵌套数组，写入前要在中间层展开并校验非空。
• 典型错误四：自动下推 Fisautopush=true 全程开着，调试期的脏数据也被下推。 建议上线初期先关闭自动下推，确认无误后再打开。
• 典型错误五：源端分页用 pageSize=50，但目标端 batchSave 单次上限更小。 稳妥的做法是表头表体分阶段，先写表头拿到返回的 FBillNo，再回填明细并写入，轻易云的编排器能很自然地承接这种分阶段流程。

适用场景与不适用场景

适用：源端有规范的 VMI 调拨入库单据、目标端希望以采购订单承载、两边都有清晰的主数据档案。不适用：源端单据状态极不稳定需要复杂判定、目标端必须做审批流才能落单、或者跨法人主体需要先做组织隔离再同步的场景——这些更适合拆成多个策略组合，而非单一同步策略。