MOM销售订单状态刷新:从金蝶云星空查询状态回写MySQL的实战配置

这个策略解决什么问题

在某制造企业的供应链集成里,MES 这边的销售订单头/行表需要随时知道上游 ERP 单据是「已审核」「已关闭」还是「MRP免跑」。如果靠人肉对账,一周下来库存和齐套就乱套。这条策略只做一件事:定时去金蝶云星空拉销售订单的状态字段,更新到 MySQL 的 mt_so_head / mt_so_line 中,让 MES 不用连 ERP 也能拿到权威状态。

数据流向与字段映射

整体流向是 金蝶云星空 → 轻易云 → MySQL。源端是金蝶云星空的 executeBillQuery 查询接口,目标端是 MySQL 的 WebAPI execute 通道执行一条参数化 UPDATE。

number 设为 id,idCheck 开启,意味着轻易云在调用时会校验返回体里是否带 FBillNo,从而把单据号作为回写时的关联依据。

在轻易云上如何配置

在轻易云数据集成平台里,这条策略归属于供应链域下的「销售订单同步」模块。源端选 金蝶云星空 → executeBillQuery,目标端选 MySQL → execute (WebAPI)。

几个关键配置:

• 源端元数据:把要查询的字段(FBillNo、FDocumentStatus、FSaleOrgId.FNumber、分录内码、日期等)都列在 request 数组里,值用同名字段引用即可,不要硬编码,留给后续在轻易云的字段映射层做变量绑定。
• 目标端 SQL:otherRequest 里的 main_sql 是核心。它先按 :SO_NUMBER 反查 mt_so_head 拿到 so_id,再用 so_id + so_line_num 精确定位 mt_so_line 行,最后把 :FMrpCloseStatus 写进 KINGDEE_STATUS。稳妥的做法是 SQL 里再加 WHERE KINGDEE_STATUS <> :FMrpCloseStatus 这种条件,做到无变化不写。
• 字段映射:FDocumentStatus 映射到 FMrpCloseStatus(注意客户现场的命名习惯,有些项目里是 FDocumentStatus 直接对应 KINGDEE_STATUS,具体以源端字段为准)。FBillNo 映射到 SO_NUMBER,分录号映射到 SO_LINE_SEQ。
• 轻易云客户常见的应对模式:编码映射集中管理——所有金蝶 → MES 的编码(销售组织、料号、客户)都放在轻易云一张映射表里维护,策略侧只引用,不在 SQL 里写 CASE WHEN。

实施步骤

调度上,源端 crontab 写的是 3 6 * * *,目标端是 13 6 * * *,中间留 10 分钟让源端先把数据查回来落库,再触发回写。

分三步走:

1. 增量起点:首次上线时,先一次性把近 30 天的销售订单按单据号列表全量查一遍,作为基线写回。轻易云里一般用一个临时「全量触发」策略完成,完成后停掉。
2. 日常调度:基线建立后,切换到每日 3 6 增量拉取。增量条件一般是 FModifyDate >= 当前日期 - 1天,轻易云的源端配置里直接用金蝶云星空的过滤字段即可。
3. 回写执行:每天 13 6 触发,把上一轮查到的状态变更写回 MySQL。回写失败的行,轻易云会进重试队列,这里建议把重试次数设成 3 次,间隔 5 分钟,避免源端瞬时不可用时把整批 SQL 拖崩。

这是典型的「增量与全量双轨」模式,轻易云客户里很常见。

踩坑复盘

1. 状态字段名搞错:FDocumentStatus 是单据级状态(整单),而 MES 关心的是行级 MRP 状态(FMrpCloseStatus)。这里容易翻车的是,直接把单据状态当行级状态写,导致所有行都被标成同一个值。稳妥的做法是在轻易云字段映射层做拆分,源端查回来的状态按行循环展开。
2. SO_NUMBER 关联不上:金蝶的 FBillNo 和 MES 的 SO_NUMBER 不完全一致,有些项目里有前缀(如 SO-)。如果不在轻易云做字符串预处理,SQL 里的 :SO_NUMBER 永远匹配不到。
3. 回写 SQL 缺过滤条件:UPDATE 不带 WHERE KINGDEE_STATUS <> 新值,会导致 MySQL 大量行被无效更新,binlog 暴涨,后续主从延迟。在轻易云的 SQL 编辑器里加上一行就好。
4. 表头表体没分阶段:有些项目第一次跑就把头表和行表放同一条策略里回写,结果行表更新失败回滚时,头表也被一起回滚。轻易云客户的常见做法是「表头表体分阶段」——先把状态写到 mt_so_head,再用另一条策略同步刷 mt_so_line,互不耦合。
5. 调度窗口撞车:源端 3 6 跑完后,目标端 13 6 执行。如果源端查 50 万条要 8 分钟,中间窗口就不够了。稳妥的做法是先在测试环境压一次,确认源端耗时,再决定错峰间隔。

适用场景与不适用场景

适用:MES/WMS 需要按销售订单做齐套、备料、推式发料的私有化制造企业;单据量在日均几千到几万级别;ERP 端不开放反写接口、只能单向查询。

不适用:需要把 MES 的变更反推回 ERP 的场景(本策略是只读刷新);跨组织、多账套的大型集团(每账套都要单独建策略);对实时性要求秒级的场景——日级调度注定有窗口期,准实时请走消息推送。