金蝶物料到积加产品的主数据同步策略实战教程

这个策略解决什么问题

物料主数据是供应链集成的"地基":编码没对齐、名称规格不一致,后续的采购单、库存单、价目表都会一路错下去。一次实际项目里,某零售企业把金蝶云星空作为财务与采购中枢,把积加ERP作为运营执行系统,两边都需要同一套物料档案。如果靠人工每天导入导出,3 个月后两边编码就已经对不上号了。这条策略的目标,就是把物料档案从源系统单向、可追溯地推送到目标系统,让主数据只有一套事实来源。

数据流向与字段映射

整体流向是 金蝶云星空(源) → 轻易云数据集成平台(中间层) → 积加ERP(目标)。中间层承担编码映射、字段转换、异常重试和日志留痕。

源端用 executeBillQuery 拉取物料视图,主键用 FMasterId,业务编码用 FNumber。目标端是 POST /purchase/goods/product/create,整体接一个对象 product 加数组型 productCartons(装箱信息)。

关键字段对照如下:

业务含义	金蝶云星空(源)	积加ERP(目标)	备注
编码	FNumber	product.code	主键,需做映射校验
名称	FName	product.name	必填
规格型号	FSpecification	product.spec	非必填
旧编码	FOldNumber	product.oldCode	追溯用
装箱信息	—	productCartons[]	数组型,单独处理

在轻易云上如何配置

我们在客户现场做这条策略时,通常会落在"采集-映射-写入"三段式配置里。

采集器(源端):选择金蝶云星空连接器,API 选 executeBillQuery,把 FMasterId、FNumber、FName、FSpecification、FOldNumber 列入请求字段列表。增量条件用 FModifyDate >= ${lastSyncTime},全量则不加条件。
映射器(中间层):用轻易云的"编码映射集中管理"功能,把 FNumber → product.code 维护成一张可追溯的映射表,而不是写死在脚本里——这是轻易云客户常见的应对模式,后续审计和追溯都很省事。表头字段做单值映射,装箱信息这种表体字段单独走子流程,避免数组展平后丢失分组关系。
执行器(目标端):积加ERP 选 POST /purchase/goods/product/create,idCheck 打开,这样写入失败时平台会自动按编码回查,决定是 UPDATE 而不是盲目 INSERT。

实施步骤

分阶段上线是最稳妥的做法,我们通常拆三步:

第一步:增量起点核对。先不接调度,手动触发一次,把过去 N 天内变更过的物料拉出来比对。客户现场常见问题是源端有几百条停用物料也被同步了过来,所以这一步要先把停用/冻结状态的过滤条件加上。
第二步:全量触发。确认存量数据无误后,执行一次全量回灌,再观察 1-2 个完整调度周期。源端调度 5 7-22 * * *,目标端调度 10 7-22 * * *,两者错开 5 分钟,避免源端还没写入就触发回查。
第三步:常态调度。稳定后切到增量模式,按业务量把频率压在每 15-60 分钟一次即可。轻易云上把策略运行在公有云环境,无需客户自建调度机。

踩坑复盘

典型错误一:把装箱信息当字符串塞进 product 字段。productCartons 是数组型,必须走子流程逐条下发,直接 flatten 后目标系统会报结构错误。
典型错误二:idCheck 关闭导致重复写入。源端没有唯一键约束时,关闭 idCheck 会出现同一编码被多次 INSERT。稳妥的做法是永远打开 idCheck,让平台按编码幂等。
典型错误三:编码映射写在脚本里。改一处要动所有脚本,排查极痛苦。轻易云客户的常见应对模式是把映射集中到一张配置表,策略只引用不维护。
典型错误四:全量和增量混在同一调度里。一旦增量条件配置错,会把全量反复跑一遍,造成目标端短时拥堵。建议全量只跑一次,后续只走增量。
典型错误五:忽略停用/冻结状态的过滤。源端历史物料里夹杂大量历史档案,全量推送会污染目标端基础资料库。

适用场景与不适用场景

适用:以金蝶为物料主数据源头、积加作为运营执行的单向上游推送场景;物料档案变更频次中低、对编码一致性要求高的零售、贸易类企业。不适用:需要双向同步、或者积加侧也会新增物料并需要回流金蝶的场景,这种要单独设计回流策略与冲突解决规则,不能复用本条配置。