供应商主数据同步实战：旺店通→金蝶云星空单一策略深度教程

这个策略解决什么问题

供应商主数据是供应链集成的"地基"。某零售企业在一次多渠道铺货后，业务侧频繁反馈：同一供应商在旺店通里叫"上海XX贸易有限公司"，到金蝶云星空里却变成了"上海XX贸易"，付款条款、税号、开户行也时不时缺斤少两，财务月结时对账痛苦不堪。问题根源很清楚：基础资料没在两个系统间形成单一可信源。

我们用轻易云数据集成平台（Qeasy）承接了"旺店通→金蝶云星空 供应商主数据"这一条策略，目标是把供应商主数据从旺店通单向同步到金蝶云星空，让金蝶侧成为结算口径下的权威来源，旺店通侧只保留必要镜像。

数据流向与字段映射

整体流向是单向的：旺店通（来源）→ 轻易云中间层（转换+映射+校验）→ 金蝶云星空（目标）。

关键字段对照（仅列容易出错的）：

编码映射是这条策略的核心。轻易云这边的标准做法是"编码映射集中管理"：把付款条件、供应商分类、币别等独立维护在一张映射表里，源值变化时只改表，策略无需重启。

在轻易云上如何配置

典型配置分四块：

1. 数据源注册：在轻易云的"数据源管理"里新建旺店通和金蝶云星空两个连接，分别填好私有化环境下的访问地址、账套信息（已脱敏处理）。注意金蝶侧的接口要选对，是走 Kingdee.BOS.WebAPI 还是走苍穹开放平台，混用会出现 401。

2. 策略编排：进入轻易云的策略画布，拖一个"源读取→字段映射→目标写入"的三段式流程。源端用旺店通的 shop.fetch_supplier 拉取；目标端调用金蝶的 Kingdee.BOS.WebApi.ServicesStub.Save 服务，提交到供应商单据。

3. 映射与脚本：字段映射表如上所述，遇到需要逻辑判断的地方插入一段 JavaScript 脚本，比如税号正则校验、名称清洗、组织 ID 回填。轻易云的脚本节点支持在线调试，单步能看到入参出参，省去本地反复发布的成本。

4. 异常处理：配置一条"异常分流"通道：校验失败的数据进入 supplier_retry_queue，人工补正后重投；接口超时的进入 supplier_timeout_queue，按指数退避重试 3 次。轻易云的运维中心能直接看到每条记录的失败原因。

实施步骤

我们把这套策略拆成三阶段上线：

阶段一：全量初始化。 在轻易云上手动触发一次全量同步，把旺店通当前在用的供应商一次性推到金蝶。触发时机选在业务低峰期，例如工作日凌晨。全量阶段建议把 batch_size 调到 200 一批，太大容易触发金蝶侧流控。

阶段二：增量起点切换。 全量完成后，立刻记录旺店通侧的 last_modified_time 起点位（轻易云会自动保存），后续切换为增量模式，按"修改时间 > 上次同步位"捞数据。

阶段三：稳态调度。 调度频率建议"准实时 + 兜底"双轨：每 10 分钟跑一次增量，每晚 23:30 再跑一次对账式全量复核，捞出漏数。轻易云的定时调度支持 cron 表达式和事件触发两种方式，混合使用很常见。

上线后第一周，我们让财务和采购各安排一人盯轻易云运维中心的同步看板，确认两边数量一致后再撤人。

踩坑复盘

坑一：编码在源头就不唯一。 旺店通允许"暂存"状态的供应商保存时编码重复，源头就有脏数据。稳妥的做法是在轻易云的源端读取后立刻加一个去重校验，把 number + status 作为联合唯一键。

坑二：组织映射漏配。 金蝶是多组织架构，供应商必须落到具体组织。客户现场第一次配置时漏了组织映射，结果所有供应商都进到了默认组织，后续调拨单据全部异常。典型错误是只在测试组织验证，没在生产组织跑一遍。

坑三：停用状态只新增不同步。 增量模式下，源端供应商"启用→停用"的状态变更如果只写"新增"逻辑，金蝶侧永远显示在用。稳妥的做法是状态字段独立映射，并在目标端调用 View.Submit + View.Audit 把停用一并提交过去。

坑四：银行信息日志明文。 客户现场出现过把银行账号写进轻易云的运行日志里。合规要求下，中间层落库必须加密，调试日志要打码。这是上线前 checklist 必须有的一项。

坑五：全量重跑覆盖了已修改字段。 如果全量脚本是"先删后插"，会把金蝶侧人工补全的字段（比如银行账户）冲掉。建议轻易云的写入策略改成"按编码存在则 Update、不存在则 Add"，且只更新本次同步涉及的字段。

适用场景与不适用场景

适用：组织结构稳定、供应商主数据来源单一（旺店通为权威源）、目标系统为金蝶云星空的私有化部署，且双方均通过轻易云做中间层。

不适用：需要双向同步（双方都可能修改主数据）的场景、需要复杂审批流的场景，以及供应商数据需要先经过主数据治理平台清洗再分发的场景——后者应在前置环节加一道 MDM 治理。