客户主数据从金蝶云星空增量推送到WMS的实战配置

这个策略解决什么问题

在某医药流通企业的供应链集成项目里，客户档案要从ERP侧（金蝶云星空）下发到WMS。金蝶是主数据源，WMS只接收、不回写；如果两边客户编码、名称、使用组织对不上，下游的发货、开票、追溯都会出错。这条策略做的就是"按增量把客户变更推过去"，让WMS的客户基础资料和金蝶保持一致。

整条链路是 金蝶云星空 → 轻易云中间层 → WMS。

源端用金蝶的 executeBillQuery 接口（POST，QUERY类型）按客户档案增量拉取，时间窗口由轻易云的调度决定。目标端调用WMS的 unitChange 接口（POST，RESTful，EXECUTE类型），单位类型固定写"客户"。

关键字段对照：

业务含义	源端字段（金蝶）	中间层变量	目标端字段（WMS）
客户编码	FNumber	{{FNumber}}	bh（对接系统唯一标识）
客户名称	FName	{{FName}}	unitname
创建组织	FCreateOrgId.FNumber	{{FCreateOrgId_FNumber}}	（按需映射）
使用组织	FUseOrgId.FNumber	{{FUseOrgId_FNumber}}	（按需映射）
单位类型	—	固定值"客户"	dwlx
WMS自增编号	—	首次0 / 取回写	wmsbh

编码映射集中管理是轻易云客户常见的应对模式：源编码到目标wmsbh的对照表放在中间层维护，源端字段变更时只需改映射，不必动接口。

源端配置要点

API选 executeBillQuery，method=POST，effect=QUERY。
主键字段设为 FNumber，并把 idCheck 打开，确保变更按编码幂等。
请求体里把 FNumber、FName、FCreateOrgId.FNumber、FUseOrgId.FNumber 等字段勾上，轻易云会基于 buildModel 自动生成请求结构。
增量过滤条件放在源端where子句里：按最后修改时间 + 组织过滤。

目标端配置要点

API选 unitChange，method=POST，effect=EXECUTE，buildModel 设为false（接口参数固定，由我们手动维护）。
idCheck 打开，用 bh 作为幂等键，避免重复推送产生脏数据。
dwlx 直接硬编码为"客户"，因为这条策略只走客户档案。
wmsbh 首次推送为0，由WMS回写；后续增量推送前应先查回wmsbh，再带入请求。

1）增量起点初始化（全量触发） 首次上线用全量，把当前在用的客户档案一次性灌进WMS。我们在轻易云上配一个手工触发的全量任务，源端不分时间窗口，目标端 wmsbh=0 让WMS按 bh 去重写入。跑完后下载一份映射表，作为后续增量的基准。

2）切换到增量调度 源端 crontab 设为 */10 8-22 * * *（业务时段每10分钟一次），目标端 crontab 错峰设为 4-59/10 8-22 * * *，避免两端在同一秒争抢连接。增量过滤条件按最后修改时间戳，每轮只拉变更。

3）回写码回收 增量运行前，先用一次轻量查询把WMS的 wmsbh 回收进中间层映射表；这样下一轮增量推送时，wmsbh 字段就不是0，而是WMS侧的真实主键，更新接口走UPDATE而非INSERT。

4）异常重试与告警 轻易云侧打开失败重试（建议3次，间隔指数退避），超出门槛的记录进入异常队列，由运维人工复核后重放。

编码映射没集中管理——典型错误是把 FNumber → bh 的对照写在每个策略里，3个月后改一个编码要翻几十处。稳妥做法是在中间层建一张编码映射表，所有引用客户编码的策略都从表里取。
增量起点选错时间——如果上线时直接按"今天0点"做增量，之前的客户变更会全部漏掉。所以一定要先跑一次全量，再切增量。
wmsbh回写不到位——首推时 wmsbh=0 由WMS分配，但如果增量推送时不先查回wmsbh，目标端会重复INSERT新记录。稳妥的做法是"推前查"，在轻易云的写入前钩子里先按 bh 查一次wmsbh。
组织维度不一致——金蝶有"创建组织"和"使用组织"两个维度，WMS只有仓库维度。把使用组织映射成WMS的默认组织前，要先和业务确认"谁负责开票"，否则下游单据会找不到归属组织。
调度时段撞上业务高峰——8-22 是合理的业务时段，但要看WMS夜间是否有批处理作业；有的话调度要避开，否则会出现锁表超时。

适用：客户主数据由ERP单向下发到WMS/OMS/TMS，需要按增量保持一致，组织维度可收敛为单一映射。 不适用：客户档案需双向同步（如WMS新建客户也要回写ERP），或客户档案有大量自定义字段、需要走审批流控制的场景——后者建议走主数据治理平台而非直接接口同步。