这个策略解决什么问题
物料主数据是 ERP 与 MES 的「共用字典」。在一次实际项目中，某制造企业把金蝶云星空作为物料主数据的唯一来源,要求所有新增、修改的物料按小时推到 MES。一旦两边编码或分类对不上,车间领料、BOM 绑定、库存扣减都会出问题。我们用轻易云数据集成平台(Qeasy)承接,把这套「物料同步」做成一条独立的策略,做到源端改了,目标端一小时内可见。
数据流向与字段映射
数据流向非常直接:金蝶云星空(BD_MATERIAL)→ 轻易云中间层 → 四化智造 MES(/api/createMaterialInfo) 。源端通过 executeBillQuery 拉取物料,中间层做字段映射与过滤,目标端按 idCheck=true 校验后写入。
关键字段对照如下:
| 目标字段 | 源字段 / 规则 | 映射类型 | 说明 |
|---|---|---|---|
| materialUuid | FMasterId | DIRECT | 金蝶物料主键作为 MES 物料流水 |
| partNo | FNumber | DIRECT | 物料编码 |
| gradeName | FName | DIRECT | 物料名称 |
| spec | FSpecification | DIRECT | 规格型号 |
| classifyNo | FMaterialGroup | DIRECT | 物料分类流水,依赖物料分组先同步 |
| parentClassifyNo | FMaterialGroup | DIRECT | 最父级分类,通常与 classifyNo 同值 |
| unitUuid | FBaseUnitId | DIRECT | 计量单位流水 |
| purchaseUnitUuid | FBaseUnitId | DIRECT | 采购单位流水,与计量单位一致 |
| erpClassifyCode | FCategoryID.FNumber | DIRECT | 存货类别编码透传 |
| companyCode | 固定常量 | CONSTANT | 公司代码 |
值得注意的几处:classifyNo 与 parentClassifyNo 都直接取 FMaterialGroup------这里有个隐含依赖,物料分类方案必须先跑完。quality、brand、picNo 等字段当前都用空常量占位,后续可按需扩展。
在轻易云上如何配置
在轻易云上,这条策略的典型配置包含四个要点:
- 源端设置 :平台选 Kingdee.Cloud,API 用
executeBillQuery,表单BD_MATERIAL,分页Limit=2000、TopRowCount=0不返回总行数以减少开销。 - 过滤条件 :源端 WHERE 子句固定为
FUseOrgId.fnumber='100' AND FModifyDate>='{``{LAST_SYNC_TIME}}' AND FMaterialGroup.FNumber!='virtual'。三段条件缺一不可:限定组织、增量时间戳、排除虚拟物料。 - 目标端设置 :平台选四化智造 MES,API 路径
/api/createMaterialInfo,idCheck=true,materialUuid + partNo作为去重键。 - 编码映射集中管理 :本方案未启用
_findCollection/_mongoQuery,所有目标字段都是 DIRECT 或 CONSTANT。如果未来 MES 单位流水格式与金蝶不一致,可在轻易云的「编码映射」里加一张单位映射表,而不是散落在策略里------这是轻易云客户常见的应对模式之一。
实施步骤
实际落地建议分三步走:
第一步:增量起点初始化 。第一次上线前,先在金蝶端按 FModifyDate>='某个起点时间' 做一次冷启动,把历史物料一次性补齐。轻易云的 LAST_SYNC_TIME 会自动记录每次执行的最大修改时间,后续按它继续追增量。
第二步:全量触发 。客户现场我们一般建议在凌晨低峰期手动跑一次全量校验,确认两边数字对得上。轻易云支持手动触发的「全量重跑」,跑完后会自动写回 LAST_SYNC_TIME。
第三步:调度频率 。源端给的是 crontab: * 7-22 * * *,即每天 7:00 到 22:00 每整点一次。物料主数据变更不会秒级发生,整点调度足够覆盖;若业务方需要更快,可压到 30 分钟一次,但一般不建议低于 15 分钟,容易打满源端 API 配额。
另外一条关键依赖:物料分类策略要先于本策略执行 。因为 classifyNo 直接拿 FMaterialGroup 作为分类流水,如果分类还没推过去,物料就会引用到不存在的分类流水。
踩坑复盘
- 物料分组没先同步,直接跑物料策略。典型错误是「两个策略一起上线」。稳妥的做法是分阶段上线:先跑物料分组,观察一周无异常,再开放物料同步。
- 忘了排除虚拟物料 。素材里特意写了
FMaterialGroup.FNumber!='virtual',但客户现场有同事拷贝策略时漏掉这一行,导致 MES 里多了一堆虚拟物料,后续清理很麻烦。 - 修改时间字段理解错 。金蝶的
FModifyDate是「最后修改时间」,如果用户反审核-修改-再审核,这个时间会更新。如果业务方要求「审核后才同步」,应该改用FAuditDate,这是另一个常见踩点。 - 分页参数
TopRowCount=0容易被误改成1或100,改成非零值会让源端多返回一次全量计数,大表场景下显著拖慢首屏。保持0是正确选择。 - 公司代码用错常量 。
companyCode在素材里给了固定常量值,实际项目里这个值往往每个组织不同,而且客户改组织后会要求更新。建议把它从常量改成「按当前用户组织动态取」,不要硬编码。