WMS已发货状态反写金蝶云星空：单策略实战教程

这个策略解决什么问题

WMS 完成销售出库发货后，ERP 端的销售出库单并不会自动感知，财务、客服、计划看到的还是「未发货」。本策略把 WMS 已发货事实回写到金蝶云星空的销售出库单表头，让 ERP 与 WMS 的发货状态对齐，是销售订单闭环中关键的一环。

数据流向与字段映射

数据流向：MySQL（WMS 视图 v_delivered_order）→ 轻易云数据集成平台 → 金蝶云星空（业务对象 SAL_OUTSTOCK）。本策略属于主表级反写，不涉及出库分录。

关键字段对照表：

源端 SQL 已经做了业务类型过滤：outType in ('1','2','9','12')，并按 realTime >= :realTime 增量拉取，避免无关出库类型与历史数据混入。

在轻易云上如何配置

1. 源端（MySQL）：平台选 MySQL，API 选 select（POST 自定义 SQL）。otherRequest 填主 SQL，request 用 :realTime、:limit、:offset 三个参数承接调度参数。number 与 id 都设为 outOrderNo，开启 idCheck 用于幂等。
2. 目标端（金蝶云星空）：平台选 Kingdee.Cloud，API 选 batchSave。request 四个字段按上表配置，value 用 {{字段名}} 透传，发货状态直接写常量 "1"。
3. otherRequest（控制参数，必填）：FormId=SAL_OUTSTOCK、Operation=BatchSave、NeedUpDateFields=F_DPs_FHstate,F_WMS_OrderNo、IsDeleteEntry=false、IsUserModelInit=true、IsAutoSubmitAndAudit=false。这几个参数决定「只更新、不删分录、不网控、不自动审核」，是部分更新能跑通的关键。
4. 编码映射集中管理：把 userDef1 → FID 这层映射放在轻易云的映射配置里，不要在脚本里散写，方便后续销售订单全量同步策略复用同一套对照关系。

实施步骤

1. 增量起点设置：源端调度 1-59/10 * * * *（每 10 分钟），首次全量时把 :realTime 设为历史最小时间戳跑一遍历史回写，之后切换为按 realTime 滚动增量。
2. 目标端错峰：目标端调度 3-59/15 * * * *（每 15 分钟），比源端晚 2 分钟起步并拉大间隔，避免源端还在写、目标端就来更新造成的脏读。
3. 触发与频率：源端按 realTime 增量、目标端按批号触发；运行稳定后维持 10/15 分钟双轨。
4. 上线三步走：先在测试账套验证 → 再用沙盒生产数据压一遍 → 最后切到正式账套正式跑，保留回滚开关。

踩坑复盘

1. NeedUpDateFields 漏配：典型错误是只传了 request 的业务字段，忘了在 otherRequest 里指定 NeedUpDateFields，结果金蝶按全字段校验，把分录冲掉。这里的稳妥做法是：表头表体分阶段，凡是「只改几个字段」的反写场景，必须显式列更新字段。
2. IsUserModelInit=true 被忽略：如果忘开这个，网控环境下 batchSave 会失败，单据看起来「没动」。
3. userDef1 没回填：销售出库单第一次从金蝶同步到 WMS 时，必须把 FID 写进 WMS 的 userDef1；否则反写时找不到主键，只能按 FBillNo 模糊匹配，错单概率陡增。
4. outType 过滤条件漏配：不写 outType in ('1','2','9','12')，调拨、其他业务类型的出库单也会被回写，引发业务方投诉。
5. 同分钟并发更新：源端 10 分钟、目标端 15 分钟如果同分对齐，可能在并发窗口里把同一条单据更新两次。错峰 2 分钟起步是最简单的避坑办法。

适用场景与不适用场景

适用：WMS→ERP 的状态/标记类反写、出库单表头发货标记、发货单号回写、需要保留原分录的部分更新。 不适用：含明细数量、金额变化的反写（必须走新增或全量更新流程）、跨组织的复杂审批流、需要触发金蝶工作流的场景（此时建议走 submit + audit 而不是 batchSave）。