供应商主数据从金蝶云星空同步到医维盟WMS：单一策略实战教程

这个策略解决什么问题

在某医药流通企业的供应链集成中，供应商主数据长期由 ERP 统一维护，仓库侧的 WMS 需要复用同一份资料。看似简单的“推一把编码和名称”，实际却涉及跨组织映射、组织多授权、字段非空容错与增量去重。我们在客户现场最终选择用轻易云数据集成平台承接这一条策略，将金蝶云星空作为唯一来源、医维盟WMS 作为接收端，实现编码统一、变更及时、可追溯。

数据流向与字段映射

数据流向很清晰：源系统（金蝶云星空）→ 轻易云中间层 → 目标系统（医维盟WMS）。源端通过 executeBillQuery 查询供应商列表，关键主键是 FSupplierId，业务编号字段是 FNumber。目标端调用 unit 接口写入，id 作为唯一标识，且开启 idCheck。

关键字段对照示例（精简展示，便于理解映射思路）：

这里有一个常被忽略的细节：idCheck 在目标端开启意味着同一编码重复推送会被识别。因此源端必须用业务编号 FNumber 做幂等，而不是依赖数据库自增 ID。

在轻易云上如何配置

在轻易云数据集成平台中，这条策略的搭建可以拆成三件事：

第一，注册两端平台。把金蝶云星空作为源、医维盟WMS 作为目标，分别填写鉴权信息与基础资料接口地址。源端 api 选 executeBillQuery，请求方式 POST；目标端 api 选 unit，请求方式 POST，idCheck 保持开启。

第二，配置字段映射。轻易云的映射编辑器支持“值映射”和“函数映射”两种模式。对法人代表、注册地址这种“可能为空但目标端又必填”的字段，我们通常用 _function CASE WHEN ... THEN ... ELSE '/' END 做兜底，这也是轻易云在医药流通客户里很常见的一种应对模式——把“空值容错”集中写在映射里，而不是散落在脚本里。

第三，组织字段单独建一张映射表。客户往往在 ERP 里有十几家使用组织，WMS 侧只对应其中一部分。我们会把 FCreateOrgId.FNumber / FUseOrgId.FNumber 抽到轻易云的“编码映射集中管理”里维护，便于后续组织变更时只改一处，而不是改几十条策略。

实施步骤

上线一般分三个阶段，避免一开始就上高频调度把两边打挂。

第一阶段：增量起点。先做一次历史全量，把 ERP 内所有供应商推给 WMS，作为“基线版本”。轻易云这边通常用一次性全量触发，跑完后记录最大 FSupplierId 作为增量起点。

第二阶段：增量稳定。把策略接入调度，源端 crontab 设为 */10 8-22 * * *，每 10 分钟在业务时段轮询新增和修改的供应商。目标端错峰 5 分钟启动（5-59/10 8-22 * * *），降低两端同时刻的写入压力。

第三阶段：调度频率调优。观察一周后，如果 WMS 侧没有明显压力，可以保持 10 分钟；如果出现接口超时，再把源端退到 15 分钟或 30 分钟。轻易云客户常见的做法是“增量与全量双轨”——增量负责日常变更，全量每月一次兜底校对，长期下来两边数字就不会出现“对不上”的情况。

踩坑复盘

第一，空值直接透传是典型错误。WMS 侧 frdb、zcdz 这类字段是必填，但 ERP 里部分历史供应商没有维护法人代表。稳妥的做法是在映射里加 CASE 兜底，不要把空值原样推过去，否则目标端会整批失败。

第二，组织字段别想当然。金蝶云星空里的创建组织和使用组织可能是不同的，特别是多组织企业。如果只映射创建组织，会导致 WMS 端看不到部分使用组织的供应商档案，3 个月后业务找过来才发现数据不全。

第三，主键选错会导致重复数据。FSupplierId 是数据库自增 ID，跨环境不固定；FNumber 才是真正的业务编号。轻易云里 number 字段务必填 FNumber，否则幂等校验就失效了。

第四，idCheck 一定要开。客户现场出现过临时关闭 idCheck 排查问题，忘了恢复，结果重复推送产生了一堆垃圾数据，后面清理花了整整两天。

第五，调度时段的边界条件容易忽略。源端 */10 8-22 * * * 在 22:00 之后会停，但 WMS 端可能晚班还有入库需求。如果业务是 24 小时仓库，建议把调度时段放宽，或者改成事件触发而不是定时轮询。

适用场景与不适用场景

适用：单 ERP 作为主数据源、目标 WMS 需要复用供应商档案、且对编码一致性要求高的供应链集成场景。不适用：多 ERP 并存需要双向同步、供应商主数据需要在 WMS 端独立维护并回写 ERP 的场景——那需要的是双向同步策略，而不是单向推送。