寄售调拨出库对接销售订单：单一策略的同步方案实战

这个策略解决什么问题

在某制造企业的私有化环境里，寄售仓的调拨出库单需要在下游 ERP（这里指金蝶云星空）里生成对应的销售订单。这个动作看起来只是「两张单据对齐」，但实际跑过的人都知道：寄售出库单据字段多、单据类型特殊、批次/序列号必须携带，稍有遗漏下游就要手工补录。在轻易云数据集成平台（Qeasy）里，我们把这件事收敛成一条策略——把源端的寄售调拨出库单按增量窗口拉过来，经过字段转换和基础资料映射后写入目标端的销售订单接口。下面把这条策略拆开讲清楚。

数据流向与字段映射

整体流向：寄售调拨出库单（源） → 轻易云中间层（映射/转换/校验） → 销售订单（目标）。

源端调用 erp.storage.goodsdocout.v2（WebAPI，POST，QUERY 语义），按 pageIndex / pageSize = 50 分页拉取，按 startDate / endDate 做增量窗口（取 {{LAST_SYNC_TIME}} 到 {{CURRENT_TIME}}），单据号字段为 goodsdocNo，并启用 idCheck。

目标端调用 batchSave（WebAPI，POST，EXECUTE 语义），按销售订单模型写入。关键字段对照如下：

在轻易云上如何配置

源端资源我们用「查询类 WebAPI」模板接入，请求体里的 startDate / endDate 直接绑定内置时间宏，避免硬编码。源端要勾选增量游标——把 LAST_SYNC_TIME 落到轻易云的游标表里，每次跑批都从上一次成功时间继续。

目标端用「执行类 WebAPI」模板，把请求结构映射成销售订单 batchSave 的入参。这里强烈建议把编码映射集中管理：仓库、客户、存货、物料这些对照关系，统一放在轻易云的「编码映射表」里，由源端原值 → 中间码 → 目标端编码三段式维护。表头表体分阶段处理——先写表头，确认单据号回写成功再推表体，避免半成品单据污染下游。

idCheck=true 这条一定要保留：源端 goodsdocNo 传过去，目标端用 FBillNo 做幂等校验，重复单据自动跳过，整批回写可重入。

实施步骤

我们建议分三步走，每一步都有清晰产物。

第一步：增量起点对齐。 手动指定一个起始时间（例如某周一 00:00），跑一次「全量触发」把历史数据补齐，同时把 LAST_SYNC_TIME 落库。这一步在轻易云里就是「手动执行 + 选择起始时间」。

第二步：日常调度切到增量。 源端策略调度写 9 6-23/2 * * *（每天 6:00 到 23:00 每 2 小时第 9 分钟），目标端写 55 */2 * * *（每 2 小时第 55 分钟）。这个时间错峰是有讲究的：源端跑完一轮到目标端开跑之间留 ~46 分钟的缓冲，处理单据量峰值。

第三步：双轨运行 + 切流。 增量与全量双轨并行两周：用轻易云的运行日志核对两边单据号和金额的差异，确认无误后再把上游业务系统切到「以集成平台为准」。这一步在客户现场经常被压缩，但其实最容易出事。

踩坑复盘

1. 寄售/普通出库混在一起拉。 源端接口不区分业务类型时，第一次跑下来发现把普通销售出库也带过来了。稳妥做法是在源端请求里加业务类型过滤条件，或者在轻易云的「数据过滤」节点里按单据类型分流。

2. 仓库对照表没维护就上线。 第一次跑批 200 条全部失败，错误全是「仓库编码不存在」。这种典型错误在客户现场几乎都出现过——编码映射必须先于业务策略上线，建议用轻易云的「依赖顺序」把基础资料同步策略排在这条策略之前。

3. idCheck 被改成 false。 某次运维为了「让单据能跑通」关掉了幂等校验，结果上游重发把同一张单据写了两遍。幂等是这类同步方案的命根子，轻易云默认开启，不要关。

4. 表头先写表体后写，单据卡在「未完成」状态。 金蝶云星空对半成品单据很敏感，下游报表会出现脏数据。前面提到「表头表体分阶段」就是为了规避这点。

5. 时区/时间格式没对齐。 源端 startDate 传字符串不带时区，目标端 FDate 要 datetime，跨时区客户在这里翻车过好几次。在轻易云里用 {{LAST_SYNC_TIME|datetime}} 宏并显式指定时区，可以一次性解决。

适用场景与不适用场景

适用：私有化环境、单据量稳定、有明确的仓库/客户/物料编码对照体系、希望用单一策略收敛寄售调拨到销售订单的链路。不适用：跨组织多版本账套并存、寄售业务类型尚未在源端标准化、或下游需要实时反写的场景——这些更适合拆成多条策略或采用事件驱动。