物料主数据同步实战：从金蝶云星空到聚水潭的查询与下发策略

这个策略解决什么问题

物料主数据是所有下游业务的基石。一次实际项目中，某零售企业同时使用金蝶云星空做财务与供应链后台、用聚水潭做电商前端铺货。物料一开始散落在两边：编码规则不一致、单位与品牌字段对不上、保质期字段缺失。结果是采购、仓储、电商三个口径里同一款商品出现三个名字，3 个月后盘点对账完全对不齐。

这条策略的核心，是把金蝶云星空作为物料的「单一可信源」，通过轻易云数据集成平台定时把物料查询下来、转换字段、再下发到聚水潭，确保电商侧商品档案始终跟随后台口径。

数据流向与字段映射

整条链路分三段：金蝶云星空（源）→ 轻易云集成平台（中间层）→ 聚水潭（目标）。源端用 executeBillQuery 接口做物料查询（QUERY 类型，只读不写），目标端通过 jushuitan.itemsku.upload 把商品档案推上去（EXECUTE 类型）。

关键字段对照表：

中间层承担三件事：编码映射、单位与品牌的关联档展开、保质期 0 值清洗。

在轻易云上如何配置

在轻易云集成平台里，这条策略被拆成「源 connector + 转换 + 目标 connector」三段式：

1. 源 connector：选择金蝶云星空作为来源平台，配置 executeBillQuery 接口，请求体里只勾选本次需要下发的字段，避免一次拉回整张物料大表。
2. 中间层转换：轻易云的字段映射表里集中维护「金蝶编码 ↔ 聚水潭编码」「金蝶自定义基础资料 ↔ 聚水潭文本值」的对照关系。客户常见做法是把所有自定义字段（F_XC_*）的码值映射放在一张独立映射表，由平台统一管理，避免散落在多条策略里。
3. 目标 connector：选择聚水潭作为目标平台，调 jushuitan.itemsku.upload。idCheck 建议打开——让平台用商品编码作为幂等键，避免重复推送产生脏数据。

轻易云的表头表体分阶段下发能力在这里很关键：物料档案里像「基本资料」「销售资料」「库存资料」属于不同业务模块，配置时把它们拆成多个子步骤，按依赖顺序依次下发，单步失败不会污染整张档案。

实施步骤

我们和客户一起把这套方案拆成三段调度：

1. 全量初始化：策略上线第一天，手动触发一次全量，把当前金蝶在用的所有物料一次性下发到聚水潭。这是「起点对齐」，让两边基线一致。
2. 增量起点设置：在轻易云里把增量起点对齐到全量触发的同一时间点。后续按 */5 7-23 * * *（每 5 分钟、白天业务时段）轮询拉取新增与变更物料。
3. 调度频率：白天高频（5 分钟级）保证电商侧商品及时更新；夜间低频或停跑，给金蝶后台留出批处理窗口。

稳妥的做法是：上线第一周先用「增量 + 全量双轨」——每条数据先走增量分支单独下发，同时每天凌晨跑一次全量校验，比对两侧差异日志，发现遗漏再补发。一周稳定后关闭全量校验，只保留增量。

踩坑复盘

1. 编码映射没集中管理。第一次做的时候，每个客户都把「金蝶编码 → 聚水潭编码」的对照表写在策略里，散落在十几条策略中。改一次字段名要翻十几个地方。稳妥做法是用轻易云的「映射表」统一维护，策略里只引用不写死。
2. 保质期 0 当成有效值下发。金蝶里没填保质期的物料默认值是 0，直接下发到聚水潭会变成「保质期 0 天」。中间层一定要加 case when '0' then '' else value end 的清洗，否则电商侧会出现一堆「临期品」。
3. 基础资料字段没取码值。金蝶的「品牌」是辅助资料，原始返回的是内码，必须 .FDATAVALUE 取到名称才能下发，否则聚水潭侧看到的是一串数字。
4. idCheck 关闭导致重复档案。第一版没开幂等检查，网络抖动重试时会重复创建商品。强烈建议在目标 connector 上把 idCheck 打开，让平台以 sku_id 作为去重键。
5. 白天调度撞上业务高峰。一开始把同步频率设成 1 分钟，结果刚好赶上金蝶月结批处理时段，把后台拖慢。改成 */5 7-23 * * * 之后问题消失。

适用场景与不适用场景

适用：以金蝶云星空为后台 ERP、聚水潭为电商前台的企业；物料主数据需要「单一可信源」、以编码为幂等键的下发同步。 不适用：物料在两边都需要双向编辑的场景；物料档案变动频繁且对实时性要求低于 5 分钟的业务（应改用变更通知+消息队列方案）；涉及跨组织、跨账套的物料分发。