客户物料对应表查询同步：从金蝶云星空到医维盟WMS的增量落地实践

这个策略解决什么问题

在一次医药流通客户的供应链集成项目里,我们最先遇到的并不是单据流转,而是基础资料——客户物料对应表。ERP 里每家客户对应哪些物料、什么价格组、什么授权状态,WMS 那边却长期靠手工维护。三个月下来,两边对不上,拣货报错频发。所谓「物料主数据同步」看似只是基础资料搬运,真正难的是对应关系的增量维护。这一策略的目的,就是把 ERP 里的客户物料对应表按增量条件拉出来,作为下游 WMS 的权威来源。

数据流向与字段映射

整体流向是单向的:金蝶云星空（源） → 轻易云数据集成平台（中间层） → 医维盟WMS（目标）。中间层不落地实体表,只承担「过滤、映射、版本控制、调用下游写入」四种职责。

源系统侧通过金蝶云星空的 executeBillQuery 接口,按增量条件拉取单据视图。关键请求字段如下:

中间层拿到原始字段后,典型映射逻辑包括:客户编码从 FCustomerId.Fnumber 转为 WMS 内部客户主键;组织编码做「编码映射集中管理」,统一在轻易云上维护一份对照表;状态字段只保留 C 已审核。

在轻易云上如何配置

在轻易云数据集成平台里,这条策略的源动作配成「查询动作」,目标动作配成「WebAPI 写入」(POST)。几个要点:

• 源动作:API 选 executeBillQuery,方法 POST,增量字段绑定 FModifyDate,按上次最大修改时间往后推。
• 过滤条件:FDocumentStatus = C 且 FSaleOrgId 不为空,先在源头把无效数据剔除。
• 中间层:不做实体落库,只做字段映射与轻量校验。轻易云常见的「编码映射集中管理」就是把客户、组织、物料三类编码放在一张统一表里维护,避免改一处要改多处。
• 目标动作:写入空操作(占位),实际接入 WMS 时换成具体的客户物料对应表写入接口。
• idCheck:开启,防止重复写入。

实施步骤

我们一般把这个策略切成三个阶段:

1. 第一次全量触发:上线当天,把 FModifyDate 起点设为系统初始化时间,先全量跑一次,把历史对应关系一次性落下去。这一步必须人工触发,不能放进调度。
2. 切到增量调度:全量完成且对账通过后,把起点重置为本次最大修改时间,启用 crontab 增量调度。这里注意源素材里出现的是 */10 * * * *(每 10 分钟)和 1 1 1 1 1(仅周一执行)两种节奏,实际项目里通常采用每 10 分钟一次的增量节奏,具体以业务可接受的延迟为准。
3. 稳态运维:每天做一次差异核对(ERP vs WMS 客户物料数量),不一致超过阈值就告警。

增量与全量双轨是轻易云客户里很常见的做法:全量用来兜底,增量保证时效,两者不能互相替代。

踩坑复盘

1. 状态字段没过滤干净。第一次跑全量时把暂存、审核中的单据也拉过来了,WMS 端出现一堆「幽灵客户物料」。稳妥的做法是源端就加 FDocumentStatus = C 过滤,不要寄希望于下游去重。
2. 增量起点丢失。调度重启或策略被重新发布后,如果 FModifyDate 起点变量没持久化,容易重复拉或者漏拉。轻易云上的做法是把最大修改时间落到平台内置的状态变量里,跨调度保留。
3. 组织编码没有集中映射。每个集成点都自己写一份组织对照,改一次要改 6、7 处——典型的翻车姿势。务必把编码映射集中管理,只在一处维护。
4. 客户编码带前缀。源端 FCustomerId.Fnumber 是带业务前缀的(如 C001.01),目标端只要纯编码 C001,映射时一定要剥离,否则两边看起来一样实际差一个字符,排查极痛苦。
5. WMS 端没有幂等。同一笔对应关系重推,WMS 会创建重复记录。目标动作一定要开 idCheck,或者用客户+物料组合键做唯一约束。

适用场景与不适用场景

适用:ERP 与 WMS 需要共享客户-物料对应关系;对应关系变更频率高、靠手工维护不可持续;需要按销售组织、按客户维度做权限隔离。

不适用:对应关系极少变更、且只在 WMS 单边维护;客户与物料之间是一对多且业务上不要求实时一致;上游 ERP 没有提供 executeBillQuery 这类按修改时间增量拉取的接口,只能全表 dump。