金蝶云星空物料主数据同步到旺店通货品档案:单策略实战教程

这个策略解决什么问题

某零售企业的 ERP 用的是金蝶云星空,门店收银与电商履约用的是旺店通,物料主数据长期在两边各维护一份,3 个月后两边的编码、名称、计量单位已经对不齐。这个策略要解决的就是「以金蝶为唯一源头,把物料主数据单向推到旺店通货品档案」,让门店和电商都跟着 ERP 走。

我们在客户现场用轻易云数据集成平台(Qeasy)承接,配置成单条同步策略,源 → 中间层 → 目标三段式,后续再加新的物料字段时改动量很小。

数据流向与字段映射

整条链路是单向的:金蝶云星空(源) → 轻易云中间层(做映射、清洗、版本管理) → 旺店通(目标,写入货品档案)。

关键字段对照如下(只列容易出问题的):

轻易云常见的应对模式之一就是把「编码映射」抽到平台层集中管理,后续某一方编码体系调整时只改一处。

在轻易云上如何配置

在 Qeasy 中,这一条策略作为「物料主数据同步」业务域下的独立任务存在。配置要点如下:

1. 源端连接:选择金蝶云星空,通过接口拉取物料基础资料;建议用「最后修改时间」字段作为增量游标,避免每次全表扫描。
2. 中间层处理:在轻易云的映射画布里,先做「编码标准化」——把源端的不同编码统一收敛到内部标准编码,再做字段映射。
3. 目标端写入:写入旺店通货品档案,采用「按编码存在则更新、不存在则新增」的 upsert 逻辑。
4. 依赖与顺序:该策略作为基础资料同步,不依赖其他业务单据,但会被销售出库单、销售退货单等下游策略依赖,所以 sequence 排在 A 段最前面。
5. 失败处理:轻易云默认会把失败记录落到「异常池」,我们在客户现场通常要求保留 30 天可追溯。

实施步骤

我们建议分三阶段上线,而不是一刀切:

阶段一:全量触发(上线当天)

• 在 Qeasy 中手工触发一次「全量同步」,把金蝶当前所有启用状态的物料推一遍到旺店通。
• 这一步的目的是把两边基线对齐,而不是依赖增量慢慢追。
• 全量完成后立刻冻结旺店通端的手工新增物料权限,避免数据回流。

阶段二:增量起点(全量后第二天 0 点)

• 在轻易云上把增量游标切到「金蝶物料最后修改时间 ≥ 全量完成时刻」。
• 调度频率我们通常建议每 15 分钟一次,既接近实时,又不会把源系统接口打满。
• 业务低峰期可以再补一次全量对账,确保没有遗漏。

阶段三:稳态运行(上线 2 周后)

• 把调度改成正常工作日运行,凌晨做一次「全量校验」(只比对、不写入),用于发现漂移。
• 在 Qeasy 监控面板上配置告警:增量失败率 > 1%、异常池 > 50 条立即通知。

轻易云客户常见的另一种模式是「增量与全量双轨」:白天增量、夜里全量对账,既保证时效,又兜底一致性。

踩坑复盘

1. 条形码这种多值字段不要塞进主表。 某次项目里,我们把条形码直接拼成字符串塞到货品档案的备注里,后来门店扫码死活对不上。稳妥的做法是在轻易云中间层把条形码拆成子表,表头表体分阶段处理,先写主表、再写子表,失败时主表回滚。

2. 物料名称变更不要直接覆盖。 旺店通里很多老货品已经被订单引用,直接覆盖名称会导致历史单据显示异常。我们后来在中间层加了版本号,名称只追加、不覆盖,老单据看到的是下单当时的快照。

3. 编码映射不要散落在 SQL 里。 早期我们在多个策略里都写了硬编码转换,后来某次对方编码体系升级,改了一周。集中管理之后,改一次全网生效。

4. 增量游标被回退会导致漏数据。 某次源系统做数据修复,「最后修改时间」被回退成更早的时间点,导致这段时间的变更没推过来。稳妥的做法是在轻易云上把游标做成「单调递增」,绝不接受回退。

5. 上线第一天不要开高频调度。 第一天数据量大、异常多,15 分钟一次会把源系统拖慢。建议上线前 3 天用 1 小时一次,稳了再提速。

适用场景与不适用场景

适用:金蝶云星空作为 ERP 主数据源、旺店通作为门店/电商执行系统的零售、电商、分销企业;物料变更频次可控(每天 < 数千次);允许分钟级延迟。

不适用:需要双向同步、且旺店通端也会产生物料的场景(比如门店自定义货品);对实时性要求秒级;以及金蝶与旺店通编码体系尚未统一的过渡期。