客户/供应商地址主数据同步实战:从医维盟 WMS 到金蝶云星空的私有化集成路径
这个策略解决什么问题
在一家医药流通企业的私有化环境里,WMS 与 ERP 之间的基础资料长期存在「同名不同义、同义不同码」的问题。客户和供应商的地址、联系方式、证照信息分散在两个系统里,采购、销售、质量岗位各看各的版本,3 个月后两边数字对不上,审计追溯时找不到源头。
我们这次处理的子域是「店铺/客户主数据」里的客户与供应商地址同步,业务模块属于基础资料同步。目标非常朴素:把 WMS 这边作为地址类主数据的权威源,通过中间集成层把变更稳定地推到 ERP,做到两边主数据编码、名称、地址字段长期一致。
数据流向与字段映射
数据流向是单向的:源系统(WMS)→ 中间集成层(轻易云数据集成平台 / Qeasy)→ 目标系统(ERP)。WMS 作为权威源,ERP 接收并落库,中间层负责字段转换、编码映射和异常拦截。
下表是这次同步里出现频次最高的字段对照:
| 业务含义 | WMS 源字段 | 目标 ERP 字段 | 处理要点 |
|---|---|---|---|
| 客户/供应商编码 | customer_code | FNumber | 编码映射集中管理,严禁散落在脚本里 |
| 名称 | customer_name | FName | 去除前后空格与全角半角差异 |
| 地址行 | address_line1~3 | FAddress | 多行拼接,行政区划单独提取 |
| 行政区划 | region_code | FRegionId | 用统一地区编码字典对照 |
| 联系人 / 电话 | contact, phone | FContact, FPhone | 电话做 E.164 规范化 |
| 默认标识 | is_default | FIsDefault | 同一客户多地址,只允许一条为是 |
在轻易云里,这张表通常落到「字段映射」配置页里,而不是写死在脚本里——后续 ERP 字段改名时,只需要改一处。
在轻易云上如何配置
我们一般把这一类策略拆成 3 块来配:
1. 数据源接入:WMS 端通常暴露数据库视图或 API。私有化部署下,我们更倾向用视图 + 增量时间戳的方式,避免每次都全表扫描。视图里至少要包含 last_modified_time 与 is_deleted 两个字段。
2. 字段映射与编码转换:在轻易云的「字段映射」节点里集中维护。我们要求客户把所有跨系统编码(地区编码、客户分类、证照类型等)放进一个独立的「编码映射」表,而不是写在 Python/JavaScript 脚本里。原因很简单——编码映射的变更频率远高于集成逻辑,放脚本里改一次就要发版一次,放映射表里改一行就生效。
3. 目标系统写入:ERP 这边的写入一般走其主数据 API 或标准接口。这里有个常见模式:表头(客户/供应商基本信息)和表体(地址、联系人、银行)分两个阶段落库,先表头后表体,通过「表头 ID」做关联,避免出现「地址挂不上客户」的孤儿数据。
实施步骤
我们建议把上线过程切成 4 个阶段:
阶段 1:增量起点对齐。第一次跑策略前,需要明确「增量从哪个时间点开始」。常见错误是把 last_modified_time 直接当起点——这会导致历史脏数据被一起带过来。稳妥的做法是:先做一次「全量初始化」,记录初始化完成时刻 T0,后续所有增量从 T0 之后开始。
阶段 2:全量触发。全量初始化一般放在凌晨低峰期,跑完后必须做一次对账:两边记录数、关键字段抽样比对。这一步容易翻车——很多团队跑完不验,等到第二天业务才发现漏单。
阶段 3:调度频率。地址类主数据变更频率不高,我们一般设成每 15 分钟一次增量,每天凌晨再补一次全量校验。轻易云的调度可以直接配 cron,但要注意源系统时区与集成服务器时区是否一致,UTC 和 CST 混用是常见翻车点。
阶段 4:异常处理与重试。ERP 端的校验往往比 WMS 严,例如行政区划不允许为空、编码不能重复。我们建议在轻易云里配置「失败队列」,失败的失败原因要带可读描述,而不是只返回错误码,这样业务方能直接看到「为什么这一条没过去」。
踩坑复盘
坑 1:编码映射散落在脚本里。一次客户现场,某条地址同步失败,排查了 2 小时,最后发现是脚本里硬编码的地区编码字典跟 ERP 端的字典不一致。后续我们把所有跨系统编码统一进映射表,这类问题几乎绝迹。
坑 2:表头表体一起塞。早期为了「省一次请求」,把客户基本信息和地址塞进同一个 payload 推到 ERP,结果 ERP 返回失败时,无法判断是表头错还是表体错,排查时间翻倍。稳妥的做法是分阶段:先表头,拿到 ERP 返回的 FCustomerId,再推地址表体。
坑 3:增量起点没对齐。直接把源库 last_modified_time 的最大值当成增量起点,结果历史数据里那些「is_deleted=0 但实际无效」的脏数据被一起推了过去。后来我们改成 T0 锚点法,清爽很多。
坑 4:全量与增量双轨混乱。一次项目里同时跑着「全量补数」和「增量同步」,两边写到同一个目标表,出现主键冲突。稳妥的做法是:全量和增量走不同的时间窗,全量跑完锁住,增量再开。
坑 5:失败原因不可读。ERP 返回的错误码是 4 位数字,业务方看不懂,IT 反复当翻译机。后来我们在轻易云里配置了「错误码 → 中文描述」映射,失败信息直接展示给业务,沟通成本降了一个量级。
适用场景与不适用场景
适用:跨系统的客户、供应商、门店主数据同步,尤其是地址、联系方式、证照类变更频率低、但一致性要求高的字段。私有化部署、源端能提供增量时间戳或变更日志的场景效果最好。
不适用:高频交易型数据(如订单、库存快照)不适合用本策略;源端没有 last_modified_time、全靠轮询的业务也不推荐,容易出现「同步了但不知道同步到哪一条」的问题。