销售物流单号回写金蝶其他出库单：基于轻易云的闭环同步实战

这个策略解决什么问题

在供应链集成里，最容易被低估的反而是「物流回写」这一步。一次实际项目中，某零售企业先把金蝶线下其他出库单推到吉客云销售单，仓库发货后才在吉客云 WMS 拿到快递公司和快递单号；如果这些信息回不到金蝶，财务对账、平台对账都会卡壳。

本策略解决的就是这个闭环尾巴：吉客云 WMS 发货完成后，把物流承运商、运单号、平台单号回写至金蝶云星空已经存在的其他出库单表头。它不创建新单据，也不改分录行，只更新物流相关字段，是典型的「窄而稳」的同步策略。

数据流向与字段映射

整体流向是「吉客云·奇门 → 轻易云中间件 → 金蝶云星空」。源端通过 jackyun.tradenotsensitiveinfos.list.get 拉取增量交易数据，目标端通过 batchSave（FormId: STK_MisDelivery，Operation: BatchSave）按 FID 精准更新已有单据。

关键字段对照如下（源 → 目标）：

这里最关键的一行是 sellerMemo → FID：金蝶→吉客云同步时，金蝶的 FBillNo 被写入吉客云的 sellerMemo；回写时通过 _mongoQuery 在中间层 MongoDB 查到 content.FBillNo 等于 {{sellerMemo}} 的记录，取出 content.FID，从而精准定位要更新的那张金蝶单据。

在轻易云上如何配置

在轻易云数据集成平台里配置这条策略，核心要点有三：

1. 源端采集器：选用「吉客云·奇门」连接器，API 选 jackyun.tradenotsensitiveinfos.list.get，按 startModified / endModified 走增量，时间窗口用 {{LAST_SYNC_TIME|datetime}} 到 {{CURRENT_TIME|datetime}} 自动衔接。tradeTypeList 覆盖多种交易类型，isDelete=0 排除已删除订单。
2. 中间层联查：在目标端字段「FID」上配置 TRANSFORM 表达式，调用 _mongoQuery 联查上游方案的中间表，根据 sellerMemo 反查 FID。这是轻易云客户常用的「编码映射集中管理」模式——把跨策略的关联键统一沉淀在 MongoDB 镜像表里，避免在每条策略里硬编码。
3. 目标端执行器：选用「金蝶云星空」连接器，API 用 batchSave，NeedUpDateFields 显式声明只更新 FID, F_Platform_order_number, F_EXPRESS_COMPANY, F_Express_tracking_number, F_Platform_order_number2 等表头字段；IsAutoSubmitAndAudit=false，IsDeleteEntry=false，保留人工审核与分录完整性。

实施步骤

按分阶段调度落地，比较稳妥：

• 阶段一 · 增量起点：先用 startModified 给一个明确起点（例如前一天 0 点），手动触发一次全量回灌，确认 sellerMemo 与 FBillNo 能正确互查。这一步是「冷启动」，必须人工验证。
• 阶段二 · 全量触发：金蝶已存在的其他出库单如果过去几个月都没物流信息，建议在低峰期跑一次全量，确保历史单据也有 logisticName / mainPostid。轻易云平台支持按时间窗批量回溯。
• 阶段三 · 调度频率：源端和调度都设为「每 7 分钟、7-22 点」，源端用 1-59/7 7-22 * * *，目标端错开 2 分钟用 3-59/7 7-22 * * *，避免两端抢同一窗口。夜间停摆，早上自然衔接 {{LAST_SYNC_TIME}}，这是增量与全量双轨的常见做法。
• 阶段四 · 监控与重跑：在轻易云上对每条记录打日志，重点看 _mongoQuery 命中数与 batchSave 返回码；命中为 0 通常意味着关联键没写上，需要回查上游策略。

踩坑复盘

1. 关联键没写上，回写全线失败：金蝶→吉客云那条策略如果忘了把 FBillNo 写进 sellerMemo，本策略 _mongoQuery 永远查不到 FID，表现为「单据没回写」。稳妥的做法是把关联键写入做成上游策略的强制映射节点，并加单元测试。
2. 把整张单据当新建处理：典型错误是误用 save 而不是 batchSave + NeedUpDateFields，导致分录被重建甚至单据重复。这里务必采用「表头表体分阶段」——本策略只更表头，IsDeleteEntry=false，分录完全不动。
3. 接口结构不完整被金蝶拒收：金蝶 batchSave 严格要求请求体带 FEntity，即便我们不更新分录，也必须把 goodsDetail 整数组作为 FEntity 传过去，否则接口会报结构错误。
4. 调度窗口与营业时间错位：设成 24 小时轮询看似保险，但凌晨吉客云 WMS 不发货，会产生大量空跑；设成 7-22 点既贴合实际业务，也减少无意义调用。
5. NeedUpDateFields 漏配：不显式声明更新字段时，金蝶可能默认更新整个 model，把无关字段清空。建议在轻易云上把允许更新的字段做成白名单，每次策略改动时核对一遍。

适用场景与不适用场景

适用：金蝶与吉客云已经打通基础单据、需要把 WMS 发货后的物流信息回写到金蝶表头的线下销售链路；以及任何「跨系统只更新表头、不动分录」的窄更新场景。

不适用：需要新增金蝶其他出库单的场景（应走「金蝶-其他出库单→吉客云-销售单」那条正向策略）；以及源端没有 sellerMemo、无法建立反向关联键的系统组合。