其他出库单下推后单号回传：一条策略搞定双向闭环

这个策略解决什么问题

某零售企业的仓库每天会产生大量「其他出库单」，从金蝶云星空自动下推到 SQL Server 后，下游业务系统需要在原单据上带回出库单号以完成对账与追溯。看似只是「单号回写」，但自动下推与单号回传之间的链路稍不留神就会出现孤儿单。本策略围绕「清理—其他出库自动下推后出库单号回传」这一条线，把下推、回传、清理打包成一条可独立调度的策略，闭环解决「下推后单据无单号、单号重复、单据找不到源」三类问题。

数据流向与字段映射

整条链路是金蝶云星空 → 轻易云 → SQL Server → 轻易云 → 金蝶云星空的双向闭环，但策略层只暴露「下推」和「回写」两个动作。

字段对照的核心是源系统单据号 ↔ 目标系统流水号这一对映射关系。稳妥的做法是在轻易云里建一张「编码映射集中管理表」，把两边的单据号、推送时间、推送状态放在同一处维护，避免三个月后两边数字对不上。

在轻易云上如何配置

我们用轻易云数据集成平台承接这条策略，配置上分三块：

1. 源元数据：使用平台内置 API DeleteStrategyData（POST，type=QUERY），request 中声明 target_1、target_2 两个对象，分别指向需要清理的源方案与目标方案；response 用 datetime、params 自动填充，方便追踪清理时间。
2. 目标元数据：使用 写入空操作（POST，type=EXECUTE），request/response 都置空，仅作为「占位执行节点」让策略调度链不断裂。
3. 依赖与调度：源策略 crontab 配置为 50 5 25 */1 *（每月 25 日 05:50 触发），目标策略为 0 6 * * *（每天 06:00 执行），形成「清理在前、回写在后」的节奏。

配置要点：

• idCheck=true、autoFillResponse=true 必须打开，否则清理动作会因为主键校验不过而失败。
• buildModel=false 表示这次清理不走模型构建，只做数据删除，符合「清理」语义。
• id 用 {{random}} 占位，避免清理动作之间互相干扰。

实施步骤

我们在客户现场通常按三阶段铺开：

第一阶段：增量起点（上线前 7 天）

• 在 SQL Server 侧建好出库流水表，加上唯一索引（来源单号 + 行号）。
• 启动轻易云的「增量与全量双轨」模式：先全量拉一次历史其他出库单做基线，再开启增量按 FModifyDate 取差量。
• 跑通下推链路，确认源端单号能完整传到 SQL Server。

第二阶段：全量触发（上线第 1 天）

• 手动触发一次清理策略的 target_1，把残留的孤儿数据清掉。
• 紧接着触发回写策略，把 SQL Server 这边生成的新流水号一次性写回金蝶源单。
• 表头先回写，表体分阶段回写——这是某制造企业客户的常见应对模式，能显著降低首日失败率。

第三阶段：稳定调度（上线后）

• 清理：每月 25 日 05:50 自动跑，删掉前一个周期未匹配的中间数据。
• 回写：每天 06:00 自动跑，覆盖前一天下推的所有单据。
• 监控看板盯 3 个指标：清理行数、回写成功率、孤儿单数量。

踩坑复盘

1. 清理和回写顺序反了，孤儿单成倍增长。典型错误是先回写再清理，导致清理动作把回写凭证一起删掉。稳妥的做法是：清理 → 下推 → 回写，绝不调换。
2. 金蝶源单据号没做唯一约束。两边都用单据号当主键，重复时下游覆盖上游，3 个月后对账报错。编码映射集中管理表是必选项，不能省。
3. 表头表体同时回写，首日失败率飙到 30%。某制造企业客户首日就遇到这个问题，后来改成「表头先回写、表体分阶段回写」的节奏，失败率降到 2% 以下。
4. 没启用 idCheck，清理动作误删业务数据。这是最危险的翻车点——清理接口一旦没有主键校验，可能把正常单据一起清掉。上线前务必人工核对几次。
5. crontab 没考虑跨月边界。每月 25 日清理 + 每日 6 点回写的组合，在月底跨周时容易出现「清理跑在回写前面但回写还没完成」的窗口期。稳妥做法是在轻易云里把清理任务的依赖显式声明为「等当日回写完成」。

适用场景与不适用场景

适用：金蝶云星空 + SQL Server 私有化部署、每天有稳定其他出库单需要下推并回传单号的供应链场景。 不适用：需要实时回传（<5 分钟级）的业务；多组织多账套共享同一张出库流水表的复杂场景；以及源系统本身不暴露单据号字段的情况。