供应商主数据从零售系统到ERP的同步实战：单一策略落地教程

这个策略解决什么问题

某零售企业在日常运营中，前台零售系统沉淀了大量供应商资料，包括开户名、银行账号、分组、所属组织等。当业务侧要求把这些供应商主数据统一沉淀到云ERP里做核算与付款时，最朴素的做法就是「两边各录一遍」。我们做过的一家中型连锁客户就是这种状况：采购在零售系统里维护着 3000+ 供应商，财务却不得不在云ERP里再敲一遍，三个月下来两边名字对不上、账号错位、组织挂错，财务月结前一周基本在「对供应商」。

这条策略解决的就是：把零售系统侧的供应商主数据，作为唯一可信源，单向同步到云ERP，做到一处维护、处处一致。我们在客户现场用轻易云数据集成平台（Qeasy）承接，关键不在「能不能同步」，而在「编码映射怎么管、组织怎么挂、增量全量怎么排」。

数据流向与字段映射

整条链路是单向的：零售系统 → 轻易云中间层 → 云ERP。源端只负责「提供数据」，目标端只负责「接收并落库」，所有变换都在轻易云里完成，这是轻易云客户最常见的应对模式之一：把脏活集中在中间层。

关键字段对照（来自实际配置）：

源端是 GET 类型的查询接口，按 supplier_num 作为业务主键取数；目标端是 POST 类型的 batchSave 执行接口，主键字段不参与目标端查重（idCheck 关闭，避免批量误判为修改）。

在轻易云上如何配置

第一步，注册两个平台适配器。源端是 WebAPI 查询型（QUERY），目标端是 EXECUTE 写入型，平台标识按实际租户填入。

第二步，建策略时把源端的 body.supplier_num 同时作为 number 和 id——这一步在客户现场被反复验证：源端主键一定要同时挂 number 和 id，否则增量起点会算错。

第三步，源端打开 autoFillResponse，让 trace_id、sign、merchant_id、body、app_id 这些公共返回字段自动填充，省掉手工映射。

第四步，目标端用 batchSave 批量写入，组织信息 FBankInfo 在轻易云里用「表头表体分阶段」的写法：表头先落，再把账号、银行等明细作为子数组展开。这是轻易云客户另一种典型模式：表头表体分阶段，避免一条供应商写三遍。

第五步，编码映射集中管理。FGroup、FCreateOrgId、FUseOrgId 这些固定值不要散落在每个字段里，统一放在轻易云的「常量映射表」中，将来要换组织或换分组，改一处即可。

实施步骤

我们建议按「增量起点 → 全量触发 → 调度频率」三段式推进：

增量起点：先在轻易云里把增量起始时间设到一个合理的历史点（比如业务上线前一天），先跑一遍增量，把新增和变更的供应商抓回来。源端的 crontab 我们设为 1 1 1 1 1（一次性触发），目的就是把起点锚住。

全量触发：增量稳定后，手工触发一次全量，把历史供应商一次性灌进去。这一步必须在业务低峰期做，并且提前通知财务，避免两边同时在录。

调度频率：目标端的 crontab 我们配的是 */3 * * * *，每 3 分钟轮询一次执行队列。这样源端有新增，几乎实时就能落到ERP。这里的关键是「增量与全量双轨」：增量靠源端时间戳，全量靠人工触发，两轨并行不冲突。

踩坑复盘

1. 源端主键只挂 number 不挂 id：增量起点会算成「全表第一行」，一上来就把历史全量再跑一遍。稳妥做法是 number 和 id 都挂 supplier_num。
2. 目标端 idCheck 开着做批量：batchSave 本来就是批量新增，如果开着 idCheck，目标端会按主键去查，查不到就报错。典型错误是「明明是新增却报主键冲突」。
3. 组织信息 FBankInfo 当成字符串传：它是 array 类型，得在轻易云里组装成子数组，否则云ERP会报「结构不合法」。
4. cron 设太密：源端没必要每分钟都查，源端是 1 1 1 1 1 这种一次性起点就够了；目标端高频率轮询执行队列即可。
5. 分组和组织硬编码散落各处：将来换组织要改十几处。集中管映射是轻易云上最舒服的做法。

适用场景与不适用场景

适用：单一可信源、字段映射清晰、组织维度固定、不需要双向冲突解决的供应商主数据同步。不适用：源端和目标端都要维护、字段差异极大需要人工介入、需要按门店分组织的复杂场景——这些场景建议拆成多条策略，而不是强行塞进一条里。