金蝶物料分组对接MES物料分类：单一策略同步方案实战教程
这个策略解决什么问题
物料主数据从金蝶云星空推到 MES,看似简单,但分类层级没建立好,后面物料同步就会大面积报错——因为物料接口要求传入 classifyNo、parentClassifyNo,而这些值要先去物料分类里查。一次实际项目中,客户就是因为分类漏推,导致物料同步整批失败,排查花了两天。本策略就是用来先把"树形分类骨架"铺好,为后续物料同步铺路。
数据流向与字段映射
数据从金蝶云星空流向四化智造 MES。源端调用 executeBillQuery 拉取 AMB_MaterialGroup 表,无过滤条件全量拉取,经轻易云数据集成平台(Qeasy)中间层做转换,再 POST 到 MES 的 /api/createMaterialClassify。
| 目标字段 | 源字段/规则 | 映射类型 | 说明 |
|---|---|---|---|
| companyCode | 固定常量 | CONSTANT | 公司代码 |
| classifyNo | FID | DIRECT | 物料分类流水,取金蝶分组内码 |
| parentClassifyNo | _function case when '{{FPARENTID}}'='0' then '' else '{{FPARENTID}}' end | TRANSFORM | 根节点传空,非根节点传上级 FID |
| classifyName | FNAME | DIRECT | 分类名称透传 |
| classifyCode | FNUMBER | DIRECT | 分类代码透传 |
主键设计上,业务主键用 FNUMBER,幂等主键用 {{FID}}-{{FNUMBER}} 复合键,开启 idCheck 保证重复执行不脏数据。
在轻易云上如何配置
在 Qeasy 平台新建一个策略,源平台选金蝶云星空,目标平台选四化智造 MES(API),同步模式选 QUERY → EXECUTE。源端分页参数 Limit、StartRow 用平台变量 {{PAGINATION_PAGE_SIZE}}、{{PAGINATION_START_ROW}},TopRowCount 设为 0(不返回总行数,降低响应体大小)。目标端公司代码写常量。parentClassifyNo 这个字段不要直接映射,改用 _function 表达式处理根节点——这是这份配置最关键的一处。
轻易云客户常见的应对模式之一,是把编码映射集中管理在中间层,本策略里没用 _findCollection,因为物料分组本身就是被依赖方,没有上游可查;但形态上保持"所有映射规则都集中在策略里",后续如果 MES 分类编码规则变了,改这一处即可。
实施步骤
按"分类先行、物料在后"的顺序,分三个阶段:
- 全量初始化:第一次上线,把金蝶全部物料分组一次性推过去,完成后到 MES 里肉眼核对分类树结构。
- 调度上线:crontab 设为
* 7-22 * * *,覆盖业务时段即可,深夜留给 MES 自身做索引重建。 - 下游衔接:确认物料分类稳定后,再开启"金蝶物料对接 MES"策略,并在该策略里把 classifyNo、parentClassifyNo 的查询指向本策略同步的结果。
增量与全量双轨也是轻易云客户常见做法——本策略当前配置的是无 FilterString 全量拉取,适合分类量级小(几百到几千条)的场景;如果未来分组量级膨胀,可以改成按 FModifyDate 增量。
踩坑复盘
- 根节点 FPARENTID 写死成 '0' 的字符串:这里容易翻车。MES 接口要求第一层父类传空字符串,而不是 '0'。一定要用 _function 做条件分支,不能图省事直接传 FPARENTID。
- idCheck 没开:典型的错误是忘了勾主键校验,导致整点重跑时把同一个分类又 POST 一次,虽然 MES 端有去重,但日志里全是 200,排查时反而看不到真正的失败。
- 顺序颠倒:物料同步先于分类同步启动,导致物料写入时找不到分类,大批报错。稳妥的做法是分类策略先单独跑两天,确认 MES 侧分类树完整,再开物料。
- TopRowCount 误设为 1:会让源端响应体多带一个总行数字段,在某些金蝶版本里反而触发分页逻辑异常,保持 0 最安全。
- 私有化环境里 companyCode 常量写错:上线前一定先在 MES 侧查一下示例值,跟金蝶账套的实际公司对应起来,不要照搬测试环境的常量。
适用场景与不适用场景
适用:物料分类量级在几千条以内、金蝶分组结构稳定、需为下游物料同步铺路的私有化部署场景。不适用:分组频繁变动且要求分钟级同步的高频场景,以及需要双系统双向同步分类的复杂架构——后者建议另起冲突解决策略,而不是在本策略里加逆向同步。