供应商主数据从金蝶云星空同步到旺店通：基于轻易云的实战方案

这个策略解决什么问题

供应商主数据是供应链系统的"底座"——采购订单、收货单、付款单都要依赖它。一旦两边档案不一致，下游单据就会出现"找不到供应商"或挂错组织的问题。我们在一次零售企业的项目里就遇到过：金蝶云星空里已经停用了某个供应商，旺店通侧却还在持续推单，导致采购入库单据悬挂、月底对账反复返工。这个策略的核心价值，就是把金蝶云星空作为供应商主数据的唯一可信源（Single Source of Truth），通过轻易云数据集成平台定时把变更同步到旺店通，让两边档案长期保持一致。

数据流向与字段映射

整体流向是单向的：金蝶云星空（源端）→ 轻易云中间层 → 旺店通·旗舰奇门（目标端）。

源端调用金蝶云星空的 executeBillQuery 查询接口，过滤出供应商档案（FSupplierId 为业务主键，FNumber 为编码）。中间层拿到数据后做编码映射与字段转换，最后调用旺店通的 wdt.setting.purchaseprovider.push 接口写入。

关键字段对照表：

在轻易云里，编码映射建议集中放到一张映射表里维护，避免散落在脚本各处；这是轻易云客户最常见的应对模式之一。

在轻易云上如何配置

源端配置：选择金蝶云星空适配器，API 选 executeBillQuery，方法 POST，勾选 idCheck（按 FSupplierId 幂等去重）。请求体里把 FSupplierId、FNumber、FName、创建组织、使用组织这些字段都勾选出来。

目标端配置：选择旺店通·旗舰奇门适配器，API 选 wdt.setting.purchaseprovider.push。把 provider_no 映射到 {{FNumber}}，provider_name 映射到 {{FName}}。联系人、座机、手机、传真这些字段在金蝶侧的字段如果本次没勾选，先留空字符串，后续在轻易云里再加。

调度配置：源端用 */10 7-22 * * *，每 10 分钟拉一次；目标端用 8-59/10 7-22 * * *，错开 8 分钟执行，避免源还没拉完目标就调用。

实施步骤

第一步是确认增量起点。在轻易云的源端配置里设置"上次同步时间"游标，只拉取该时间之后变更的供应商。第一次上线时建议把时间设到一个明确的业务节点之前，确保存量数据能被覆盖。

第二步是触发一次全量。把游标清空跑一次全量，把当前所有供应商同步过去。轻易云客户的常见做法是"增量与全量双轨"：平时增量跑，一旦怀疑数据漂移，立刻触发全量兜底。

第三步是建立调度节奏。源端每 10 分钟查一次，目标端错开 8 分钟。建议只在 7:00–22:00 这个业务时段跑，凌晨留给对账和补偿。

第四步是上线后校验。前三天每天抽 5 条人工核对两边档案，重点看编码、组织、停用标志是否一致。

踩坑复盘

坑一：组织字段被忽略。金蝶是支持多组织的，供应商在不同组织下编号可能不同。如果只同步了 FNumber 没带组织，旺店通侧就会出现"同名不同组织"的供应商串数据。稳妥做法是组织作为辅助键一起写入映射表。

坑二：源头是停用状态没过滤。金蝶里供应商被禁用/冻结后，旺店通侧应该同步停用，否则下游还在下单。典型错误是源端 query 没加状态过滤，把禁用档案也推过去。建议在源端过滤条件里加 FForbidStatus = 'A'。

坑三：联系人字段为空导致接口报错。旺店通 purchaseprovider.push 对部分非必填字段的格式有校验，比如传 null 会失败。这里容易翻车的点是轻易云默认会把空值转成 null 而不是空串。稳妥的做法是在目标端映射前加一个空值兜底脚本，把 null 转成 ""。

坑四：增量起点设错导致漏数据。第一次上线时如果游标时间设到了今天凌晨，那么今天上午在金蝶里新建的供应商就同步不过去——因为它们可能是在游标时间之后才变更的。稳妥做法是把游标时间往前推 1–2 小时，覆盖时钟误差。

坑五：编码在金蝶侧被修改后两边对不上。供应商编码理论上不该改，但实际业务里偶尔会发生。轻易云平台默认按 id 幂等，如果金蝶改了 FNumber 但 FSupplierId 不变，旺店通就会"按 id 找到老编码、更新名称、编码还是老的"。建议在目标端加一个脚本，检测编码不一致时主动告警，而不是默默静默更新。

适用场景与不适用场景

适用：金蝶云星空是供应商主数据唯一来源、旺店通是下游业务系统，需要单向把供应商档案同步下去；供应商数量在几千到几万级、需要定时而非实时同步。

不适用：双向同步（比如两边都要维护供应商）、需要实时秒级响应（应改用事件触发而非轮询）、供应商档案字段在两边差异巨大需要复杂转换的场景（建议先做数据治理再集成）。