这个策略解决什么问题
WMS 完成销售出库发货后，ERP 端的销售出库单并不会自动感知，财务、客服、计划看到的还是「未发货」。本策略把 WMS 已发货事实回写到金蝶云星空的销售出库单表头，让 ERP 与 WMS 的发货状态对齐，是销售订单闭环中关键的一环。
数据流向与字段映射
数据流向 ：MySQL（WMS 视图 v_delivered_order）→ 轻易云数据集成平台 → 金蝶云星空（业务对象 SAL_OUTSTOCK）。本策略属于主表级反写，不涉及出库分录。
关键字段对照表：
| 源字段（MySQL） | 目标字段（金蝶云星空） | 映射类型 | 转换规则 | 业务说明 |
|---|---|---|---|---|
| userDef1 | FID | DIRECT | 直接取值 {``{userDef1}} |
WMS 侧存储的金蝶主键，定位目标单据 |
| outOrderNo | FBillNo | DIRECT | 直接取值 {``{outOrderNo}} |
出库单号，辅助追溯 |
| --- | F_DPs_FHstate | CONSTANT | 固定常量 "1" |
发货状态：1 表示已发货 |
| outTaskNo | F_WMS_OrderNo | DIRECT | 直接取值 {``{outTaskNo}} |
WMS 发货任务单号，便于追到 WMS 执行记录 |
源端 SQL 已经做了业务类型过滤：outType in ('1','2','9','12')，并按 realTime >= :realTime 增量拉取，避免无关出库类型与历史数据混入。
在轻易云上如何配置
- 源端（MySQL） ：平台选 MySQL，API 选
select（POST 自定义 SQL）。otherRequest填主 SQL，request用:realTime、:limit、:offset三个参数承接调度参数。number与id都设为outOrderNo，开启idCheck用于幂等。 - 目标端（金蝶云星空） ：平台选 Kingdee.Cloud，API 选
batchSave。request四个字段按上表配置，value用{``{字段名}}透传，发货状态直接写常量"1"。 otherRequest（控制参数，必填） ：FormId=SAL_OUTSTOCK、Operation=BatchSave、NeedUpDateFields=F_DPs_FHstate,F_WMS_OrderNo、IsDeleteEntry=false、IsUserModelInit=true、IsAutoSubmitAndAudit=false。这几个参数决定「只更新、不删分录、不网控、不自动审核」，是部分更新能跑通的关键。- 编码映射集中管理 ：把
userDef1 → FID这层映射放在轻易云的映射配置里，不要在脚本里散写，方便后续销售订单全量同步策略复用同一套对照关系。
实施步骤
- 增量起点设置 ：源端调度
1-59/10 * * * *（每 10 分钟），首次全量时把:realTime设为历史最小时间戳跑一遍历史回写，之后切换为按realTime滚动增量。 - 目标端错峰 ：目标端调度
3-59/15 * * * *（每 15 分钟），比源端晚 2 分钟起步并拉大间隔，避免源端还在写、目标端就来更新造成的脏读。 - 触发与频率 ：源端按
realTime增量、目标端按批号触发；运行稳定后维持 10/15 分钟双轨。 - 上线三步走：先在测试账套验证 → 再用沙盒生产数据压一遍 → 最后切到正式账套正式跑，保留回滚开关。
踩坑复盘
NeedUpDateFields漏配 ：典型错误是只传了request的业务字段，忘了在otherRequest里指定NeedUpDateFields，结果金蝶按全字段校验，把分录冲掉。这里的稳妥做法是：表头表体分阶段，凡是「只改几个字段」的反写场景，必须显式列更新字段。IsUserModelInit=true被忽略 ：如果忘开这个，网控环境下batchSave会失败，单据看起来「没动」。userDef1没回填 ：销售出库单第一次从金蝶同步到 WMS 时，必须把FID写进 WMS 的userDef1；否则反写时找不到主键，只能按FBillNo模糊匹配，错单概率陡增。outType过滤条件漏配 ：不写outType in ('1','2','9','12')，调拨、其他业务类型的出库单也会被回写，引发业务方投诉。- 同分钟并发更新：源端 10 分钟、目标端 15 分钟如果同分对齐，可能在并发窗口里把同一条单据更新两次。错峰 2 分钟起步是最简单的避坑办法。
适用场景与不适用场景
适用 ：WMS→ERP 的状态/标记类反写、出库单表头发货标记、发货单号回写、需要保留原分录的部分更新。
不适用 ：含明细数量、金额变化的反写（必须走新增或全量更新流程）、跨组织的复杂审批流、需要触发金蝶工作流的场景（此时建议走 submit + audit 而不是 batchSave）。