供应商主数据从金蝶云·星空旗舰版同步到旺店通的实战教程
这个策略解决什么问题
供应链集成里,供应商主数据是「上游 ERP 一处建档,下游 WMS/OMS 全员引用」的标准件。一次实际项目中,客户把金蝶云·星空旗舰版作为 ERP 主数据源,旺店通·旗舰版作为仓储执行端,所有采购入库单据都要按供应商编码落账。一旦两边编码或名称不一致,就会出现「单据能过、付款找不到人」的尴尬。这个策略的任务很简单:把金蝶里的供应商档案增量推到旺店通,保持两边供应商池一致,采购链路不断裂。
数据流向与字段映射
数据流向是单向的:金蝶云·星空旗舰版(B) → 轻易云(Qeasy)中间层 → 旺店通·旗舰版(A)。源端调金蝶的 /kapi/v2/dtog/basedata/bd_supplier/query_gys 分页查询接口,目标端调旺店通的 setting.PurchaseProvider.push 写入接口。
| 业务含义 | 源端(金蝶字段) | 中间层变量 | 目标端(旺店通字段) |
|---|---|---|---|
| 供应商编码 | number | {{number}} | provider_no |
| 供应商名称 | name | {{name}} | provider_name |
| 联系人/收款人 | linkman | {{linkman}} | collect_name |
关键字段对照表如上。源端分页参数是 pageNo / pageSize,每页 10 条起步,idCheck 开 true,按主键幂等去重。
在轻易云上如何配置
打开轻易云数据集成平台的策略画布,新建一条策略,源平台选「金蝶云·星空旗舰版」,目标平台选「旺店通·旗舰版」。源端的 API、method、pageSize 这些已经在元数据里预置,只需要在「字段映射」节点把 number 拖到 provider_no、name 拖到 provider_name、linkman 拖到 collect_name。映射关系稳定后,建议在轻易云里把映射表导出,作为版本基线,后续系统升级时方便 diff。
编码映射上,建议在轻易云的「编码映射集中管理」模块维护一份供应商编码字典,两侧编码不一致时由映射层兜底,而不是让目标端业务方手工改码。
实施步骤
1. 增量起点确认。 在轻易云的策略配置里,把源端查询的「起始时间」或「最大 id」作为增量游标保存到平台内置的 KV 表,首次上线前手动跑一次全量回填游标。
2. 全量触发。 客户现场通常先用轻易云的「全量同步」按钮,把当前所有供应商一次性灌进旺店通,这一步务必在业务低峰期执行,避免和采购入库抢写。
3. 调度频率。 源端 crontab 写的是 0-59/3 7-22 * * *——工作日 7 点到 22 点,每 3 分钟一次。目标端错峰 2 分钟,写的是 2-59/3 7-22 * * *,避免两边同时拉取造成源端压力。轻易云支持策略级 crontab,直接复用即可。
4. 失败重试与告警。 在轻易云的策略监控里打开「失败重试 3 次」和「钉钉/企微告警」,写入失败一般是对端接口限流,重试基本都能过。
5. 表头表体分阶段。 这个策略只同步表头(供应商基础信息),后续如果要做「供应商-收货地址」表体,建议拆成第二条策略,避免一处变动触发整体重写。
踩坑复盘
- 坑 1:编码大小写漂移。 金蝶里的供应商编码大写,旺店通默认小写,直接同步会造成「两边都存在但查不到对方」。稳妥的做法是在轻易云映射层加一层
UPPER()或LOWER()转换,并在编码映射集中管理里写死。 - 坑 2:
linkman为空导致写入失败。 联系人字段在金蝶里是非必填,部分早期供应商没维护联系人,旺店通端会把它当必填校验。典型错误是直接报错,正确做法是在映射里给空值兜一个默认值,比如「待补充」。 - 坑 3:分页游标漂移。 源端按 id 升序分页,如果同步过程中金蝶新增了记录,游标会向后漂,新数据被漏掉。建议在轻易云的源端配置里把
orderBy写死为id asc并固化分页大小。 - 坑 4:增量起点重置。 客户运维误操作点了「重新全量」,游标被清空,下次跑又变成全量,旺店通端瞬间涌入几万条重复数据。轻易云有「游标保护」开关,生产环境必须打开。
- 坑 5:调度时间窗过宽。 有人把 crontab 写成
0-59/3 * * * *24 小时跑,凌晨同步时金蝶在做日结,返回的数据状态是「半冻结」的。建议和客户的 ERP 运维对齐日结窗口,把同步时段压在业务活跃期。
适用场景与不适用场景
适用:单一 ERP → 单一 WMS/OMS 的供应商主数据同步,业务量日均千条以下,字段稳定且只同步表头。 不适用:需要把供应商档案同时推给多个下游(如 CRM、TMS、SRM)的场景,这时建议在轻易云里建一条「分发策略」+ 多条「落地策略」,而不是每个下游都跑一遍全量。也不适用于金蝶端编码体系频繁重构的项目,那需要先做编码治理再谈同步。