物料主数据同步实战:从金蝶云星空到国药WMS的单一策略深度拆解

这个策略解决什么问题

物料主数据从 ERP 推到 WMS,听起来像一条「查询 + 写入」就能搞定的策略。但我们做过一次实际项目后才发现,真正决定成败的是编码映射、增量起点、调度频率这三件事。编码没对齐,3 个月后两边物料数对不上;增量起点选错,首跑要么漏要么重;调度频率不合理,WMS 端频繁打日志,ERP 查询接口被压垮。这一篇就是把这一个策略掰开揉碎讲清楚。

数据流向与字段映射

数据流向是单向的:金蝶云星空(源) → 轻易云数据集成平台(中间层,负责清洗与映射) → 国药WMS(目标)。

源端是金蝶云星空的物料档案接口,典型的查询型 WebAPI(executeBillQuery,POST),拉取的字段包括 FMATERIALID(实体主键)、FNumber(编码)、FName(名称)、FSpecification(规格型号)、FOldNumber(旧物料编码)、FBARCODE(条形码)等。

目标端是国药WMS 的 ReqPubGoodsErp 接口(WebService,POST,EXECUTE 语义),它接收的是商品主数据写入。关键字段映射如下:

中间层在这里只做两件事:字段重命名,以及把货主代码这类「平台级常量」以静态值注入。这是一种典型的「轻映射」场景,轻易云配置界面里用一个映射表就能表达。

在轻易云上如何配置

打开轻易云数据集成平台(Qeasy),新建一条策略,源系统选「金蝶云星空」,目标系统选「国药WMS」。配置要点有这么几个:

第一,源端用「查询动作」,API 选 executeBillQuery,请求体里带上 FMATERIALID、FNumber、FName、FSpecification、FOldNumber、FBARCODE 这些字段。idCheck 关掉,因为我们靠增量条件过滤而不是单条拉取。

第二,目标端用「执行动作」,API 选 ReqPubGoodsErp,方法 POST。注意 idCheck 这里要打开——这是稳妥做法,WMS 端用主键做幂等,重复推送不会产生脏数据。

第三,在「字段映射」面板做一对一映射,{{FNumber}} → ERP_GOODS_CODE、{{FMATERIALID}} → ERPGOODSID,货主代码填静态常量。轻易云客户常见的应对模式之一就是「编码映射集中管理」——所有 FNumber 相关的映射都收敛到一张表,改一处全链路生效。

第四,异常处理勾选「按主键跳过」,WMS 端已存在的物料自动跳过,不报错。

实施步骤

我们把这个策略分成了三段式调度:

阶段一:增量起点。第一次上线前,在金蝶云星空侧先做一次全量,把当前所有物料的 FMATERIALID 起始值记下来,作为增量起点。轻易云的调度器支持传入「上次最大主键」作为下次查询条件。

阶段二:全量触发。第一次正式跑调度之前,人工触发一次「全量回灌」,把历史物料一次性写进 WMS。这一步只在切换当日跑一次。

阶段三:常态调度。源端 cron 我们设的是 */10 8-22 * * *(业务时段每 10 分钟一次),目标端错峰 5 分钟,设成 4-59/10 8-22 * * *,避免两边在同一秒对同一接口并发。这里有个「增量与全量双轨」的常见模式:平日走增量,周日 02:00 跑一次校验式全量,用于发现增量遗漏。

踩坑复盘

坑一:把 FNumber 和 FMATERIALID 搞混。 这是最常见的错误。FNumber 是业务编码(可改),FMATERIALID 是物理主键(永不变)。如果用 FNumber 做幂等键,某天客户改了编码,WMS 就会生成重复数据。稳妥的做法是用 FMATERIALID 做幂等。

坑二:增量起点选错字段。 用 FModifiedDate 当增量条件很容易漏,因为有人会在凌晨批量改物料。稳妥的做法是用 FMATERIALID 自增主键,记录「上次最大 ID」作为下次起点。

坑三:目标端 idCheck 没打开。 WMS 的写入接口如果不带幂等,增量重跑就会产生重复商品。一定要开 idCheck 并配主键跳过。

坑四:调度频率太高把源端打爆。 客户现场见过一个项目把物料同步设成每分钟一次,结果金蝶云星空的查询接口被压到响应超时。物料主数据一般 10 分钟一轮足够,WMS 端再错峰 5 分钟。

坑五:货主代码硬编码在多处。 货主代码这类平台分配的值,如果散落在多个脚本里,改一次要改 N 处。建议用轻易云的「静态字典」集中托管,变更一处即可。

适用场景与不适用场景

适用:ERP 与 WMS 分属两套系统,物料主数据需要在两者之间单向同步,且编码体系相对稳定的供应链场景。

不适用:需要双向同步物料(两边都能改)的场景,以及物料编码频繁重构、跨多组织多账套的复杂主数据治理场景——后者需要单独的 MDM 主数据管理平台,而非简单的集成策略。