金蝶仓库主数据增量更新同步至MES：基于审核日期的增量修正实战方案

这个策略解决什么问题

某制造企业把仓库主数据放在金蝶云星空,MES 现场需要拿到同一份仓库信息。仓库一旦改名、改编码或调整使用组织,MES 这边如果不跟上,后续的出入库、盘点、调拨全都会出错。本策略不是"首次建档",而是把金蝶里已经存在、后续发生修改的记录,定位更新到 MES,本质是一个按审核日期增量、定位主键幂等更新的修正链路。

数据流向与字段映射

流向:金蝶云星空(源,executeBillQuery / BD_STOCK)→ 轻易云数据集成平台(中间层,做过滤、映射、调度)→ 四化智造MES(目标,/api/updateWarehouse)。

中间层负责:按 FAuditDate 拉增量、把源字段塞进目标字段、把 FStockId 作为定位键透传。

关键字段对照

源端 FGroup(仓库分组)、FUseOrgId(使用组织)、FIsOpenLocation(是否启用仓位)在当前 MES 接口中没有对位字段,因此未映射——这是后续扩展点,不是当前策略的事。

在轻易云上如何配置

我们用轻易云(Qeasy)来做这件事,整条链路围绕"源 QUERY → 中间层 → 目标 EXECUTE"三段式搭建。

源端配置要点

• 数据源选金蝶云星空,API 选 executeBillQuery,业务对象 BD_STOCK,请求方式 POST。
• 把 FStockId / FNumber / FName / FGroup / FUseOrgId / FIsOpenLocation 全部声明为返回字段,即便当前不映射,也建议先取回来——后续加映射不用改源端。
• 增量过滤条件 FAuditDate>='{{LAST_SYNC_TIME|dateTime}}',轻易云会自动用上一次同步成功的截止时间作为起点。
• idCheck 设为 false,因为我们不在源端做 ID 去重,留给中间层。

目标端配置要点

• 数据源选四化智造 MES,API 选 /api/updateWarehouse,请求方式 POST。
• idCheck 设为 true——这是定位更新的关键,MES 侧以 warehouseUuid 找到已存在的仓库记录再 UPDATE,而不是 INSERT,天然幂等。
• request[0].value 写常量(公司编码),其余三个字段都用 {{源字段}} 直接插值。
• number 与 id 都置 0,因为定位靠的是 body 里的 warehouseUuid,不是 URL 路径。

调度与触发

• crontab 配 * 7-22 * * *,覆盖白天作业时段,夜间留给全量校核或维护窗口。
• 在轻易云的策略详情里,把"上一次同步时间"字段勾上,平台会自动持久化 LAST_SYNC_TIME,断点续跑不需要手工改。

实施步骤

把项目拆成三段推进,这是我们现场用得最多、也最稳的一种节奏。

第一步,定增量起点。首次上线前,先和客户确认"以哪个时间点为基准"——一般取历史上最近一次手工同步的时间,或上线当天 0 点。轻易云策略里把这个时间作为初始 LAST_SYNC_TIME,后续由平台自动滚动。

第二步,跑全量触发。第一次执行时不带时间过滤,或者用管理后台的"补跑"功能强制拉一批历史数据,目的是让 MES 里所有现存仓库都被建过档案,之后才能进入"修改"模式。如果跳过这一步直接开增量,MES 端没有对应记录,update 会变成 404 或空更新。

第三步,进入增量调度。每天 7:00–22:00 整点触发,每次只取审核日期 >= 上次同步时间的仓库。注意:审核日期 ≠ 修改日期,客户现场踩过这个坑——基础资料在金蝶里改了但还没审核,这一轮不会进来,需要和业务方约定"改完即审"。

分阶段策略(客户现场常见做法):表头基础资料先按整点跑增量,把链路打通、告警配齐;后期如果有表体(比如仓位、库位),再单独建策略,避免一次失败把整条链路拖垮。这就是表头表体分阶段。

踩坑复盘

1. 增量起点没设计好,3 个月后两边对不上。典型错误是"上次同步时间"字段没勾或勾错位置,平台拿不到截止时间,导致每次都从最早数据开始拉。稳妥做法:上线前在轻易云策略里手动设一次 LAST_SYNC_TIME,并在监控里加一条"单次同步条数>阈值则告警"的规则。

2. 审核日期 vs 修改日期混用。金蝶里基础资料改了没审核,FAuditDate 不会动,这一条记录就漏推了。我们后来要求客户业务方改一条规则:仓库信息调整后必须当天审核,否则次日 MES 看不出来。

3. 目标端 idCheck 设成 false。这一条最容易翻车——平台按 INSERT 处理,金蝶改一次就 MES 多一条,几周后数据就翻倍了。仓库修改场景,idCheck 必须为 true。

4. 未映射字段当不存在处理。FGroup、FIsOpenLocation 当前 MES 接口没接,但客户半年后会要求"分组也带过来"。所以源端字段先全部取回,不要图省事只取当前要用的那几个,后期扩展不用动源端,只在中间层加映射。

5. 多组织场景误用常量 companyCode。本策略用固定常量表示 MES 租户/组织,只在单组织下成立。客户一旦多组织,必须把 companyCode 改成基于 FUseOrgId.FNumber 的 COLLECTION 映射或 TRANSFORM 表达式,不能照搬常量。

适用场景与不适用场景

适用:金蝶云星空与 MES 同组织、仓库编码稳定、修改频率不高(每日个位数到几十条)的场景,以及已有建档策略在做增量修正。

不适用:首次建档(走 create 策略)、跨组织多租户(常量无法满足)、需要同步仓库分组或仓位明细(本策略未覆盖表体,需另建方案)。