库存调拨出库单向金蝶分步式调出单同步：单一策略实战教程

这个策略解决什么问题

调拨业务在多组织、多仓之间流转时，源端的调拨出库单一旦下发，目标端的分步式调出单如果没有稳定承接，很容易出现「单据号对得上、行项对不上、状态对不上」的尴尬。在我们接触的一个零售仓配项目中，门店之间调货频繁，源系统按单据生成、目标系统按分步式流程推进，两者编码体系与状态机都不一致。我们用轻易云数据集成平台（Qeasy）把这条策略作为后续 40+ 同步任务的参照模板，先把它跑稳再横向铺开。

数据流向与字段映射

数据流向为「源系统 → 中间层 → 目标系统」，源端是调拨出库单，目标端是分步式调出单。中间层是轻易云平台承担的核心职责：先把源端原始 payload 落库为标准化记录，再按目标端结构转换为出库请求字段。

关键字段对照大致如下：

实际项目中，源端与目标端的仓库、组织、商品编码完全不是同一套体系，所以我们采用「编码映射集中管理」的应对模式：把 src_warehouse_code → FOutStockOrg、sku_code → FMaterialId 等映射表放在轻易云的映射数据集里，策略运行时按版本号取数，避免硬编码在脚本里。

在轻易云上如何配置

在轻易云平台上一条策略的典型配置分四块：

1. 数据源接入：源端使用旗舰版 WMS 的标准开放接口，按单据维度拉取调拨出库单；目标端调用 ERP 的单据保存接口。两者都在平台「数据源」里登记授权。
2. 数据建模：中间层落库字段以源端为基准，再加 dest_wh_code、FMaterialId 等目标侧冗余字段，方便排错。
3. 字段映射与转换器：在轻易云的「字段映射」画布里配置源→中间层→目标的映射。涉及到编码替换、日期格式、单据状态翻译的，挂在「转换器」节点上。
4. 执行策略：选择「表头表体分阶段」的应对模式——先把表头（单据头：单号、日期、调入调出仓库、原因）写入目标端并获取 FBillNo，再依据这个 FBillNo 回填表体行项，最后回写中间层状态字段为「已生成」。

实施步骤

我们一般把这个策略分成三段式调度上线：

第一阶段，确定增量起点。从源端挑出 1~2 张最近 3 天已审核的调拨单，在轻易云上手动触发一次全量试跑，比对目标端的 FBillNo、仓库、商品、数量、批号是否一一对应。

第二阶段，配置全量触发。在平台调度中心里配置一次性全量任务，时间窗口设为「最近 N 天内、状态=已审核且未生成目标单」，跑一次历史回灌，校验通过后关闭。

第三阶段，设置调度频率。投产初期按每 15 分钟轮询一次（源端有审核时间戳增量字段），运行两周稳定后，再放宽到每 30 分钟。夜间不漏跑，靠源端的「最后修改时间」游标做增量边界。

踩坑复盘

• 典型错误：单据状态翻译漏写「已审核」以外的状态。源端还有「部分发货」「已完成」等状态，目标端分步式调出单只接受待调出/已调出这种二态机。我们加了一张状态白名单，没在白名单的源单直接跳过并在日志里打 warn。
• 典型错误：仓库编码与组织编码混用。源端一个调拨单上有「仓库 A」，目标端 ERP 把它拆成「库存组织 + 仓库」两个维度。稳妥的做法是映射表里同时维护 src_warehouse_code → FOutStockOrg 和 src_warehouse_code → FOutWarehouse 两组，运行时按行项维度补齐。
• 典型错误：表头成功但表体落库失败时未回滚。中间层需要给每条目标单记录加 target_doc_status 字段，表头已生成但表体失败的，要靠定时补偿任务重试，而不是全单重推。
• 典型错误：批号/批次字段在源端为空时目标端报错。源端非批次管理商品 batch_no 为空，目标端把它当必填项。我们加了转换器：batch_no 为空时写入默认占位符，并在日志里打 info 提示。
• 典型错误：把增量起点写死成「当前时间」。一旦策略第一次跑时源端没有新单，后续增量会漏掉审核时间在策略启动之前、但还在传输窗口里的单。稳妥的做法是「增量起点」配置项默认回溯 7 天，并打上 bootstrap=true 标记，调度再切到正常增量游标。

适用场景与不适用场景

适用于：多组织、多仓库的零售/分销仓配场景，源端单据已经审核、目标端按分步式流程逐行推进，并且日均调拨单量在几百到几千单的中等规模。不适用于：源端未做审核流、目标端需要实时秒级回写，或者两端编码体系完全无规则、无法沉淀映射表的场景。