供应商 WMS 编号回写金蝶云星空:单策略实战教程
这个策略解决什么问题
在 WMS 与 ERP 共存的医药供应链场景里,供应商主数据往往先在 WMS 落地,ERP 端只保留财务核算口径。两边一旦断开,WMS 现场扫码收货时只能「认自己人」,财务与质量追溯时却查不到仓库侧的真实编号,跨系统对账就成了糊涂账。
我们这次给某医药流通企业做集成时,核心矛盾就是:WMS 侧的供应商编码已经稳定运行,但金蝶云星空里没有对应字段保存它,导致质检回传与入库单据无法反查。本策略的目的只有一个——把 WMS 侧的供应商编号,稳定地回写到金蝶云星空供应商档案的自定义字段上,让两边的主数据「同源、可对、可追」。
数据流向与字段映射
整体流向是单向回写:源端是轻易云集成平台侧的查询接口(用于拿到金蝶云星空里现有供应商的 KDID 与 WMS 编号),目标端是金蝶云星空的 batchSave 执行接口。中间不落地第三方业务表,只做轻量映射与回写。
关键字段对照如下:
| 层级 | 字段标识 | 含义 | 来源/去向 |
|---|---|---|---|
| 源端(查询) | KDFNumber | 金蝶云星空供应商编码 | 入参,用于查询 |
| 源端(查询) | wmsbh | WMS 侧供应商编号 | 返回结果,作为回写值 |
| 目标端(回写) | FSupplierId | 金蝶云星空供应商内码 | 写入,定位档案 |
| 目标端(回写) | F_UVQS_wmsbh | WMS 编号自定义字段 | 写入,落账 WMS 编号 |
| 目标端(回写) | FormId | 业务对象表单标识 | 固定传供应商档案 |
| 目标端(回写) | Operation | 执行操作 | 固定 Save |
| 目标端(回写) | IsAutoSubmitAndAudit | 是否提交并审核 | 建议先 false,人工复核后再审 |
注意源端是一个「请求空操作」的 QUERY 类型 WebAPI,本质上是借助轻易云作为中转,把金蝶云星空里的供应商档案抽出来,挑出已经有 WMS 编号映射关系的目标记录,再批量回写一次。
在轻易云上如何配置
我们用轻易云数据集成平台(Qeasy)来承接这一策略,典型的配置分三块。
源端元数据 metadata:选 WebAPI + POST + QUERY,id 字段设为 wmsbh,开启 idCheck,请求与响应体先留空(autoFillResponse: true),让平台自动从目标端反推可用字段。
目标端元数据 metadata:选 EXECUTE + POST,api 填 batchSave,这是金蝶云星空标准的批量保存接口。number 与 id 都设为 id,因为我们要按供应商内码定位记录。请求体里只暴露三个业务字段:FSupplierId、F_UVQS_wmsbh、表单与操作控制项;IsAutoSubmitAndAudit 默认 false,这是稳妥做法。
调度策略:策略源端 crontab 设为 1 1 1 1 1(每周一执行一次轻量探测),目标端 crontab 设为 23 2 * * *(每天凌晨 2:23 触发回写)。一次实际项目中我们把目标端改成「变更触发 + 兜底日批」双轨,既不丢数据,也不会在白天交易时段冲撞金蝶云星空。
实施步骤
第一阶段,确认增量起点。金蝶云星空里已有供应商档案,首次回写必须基于「已存在」做增量匹配,而不是全量覆盖。我们通常的做法是先用源端查询接口把现有供应商清单拉出来,只在 F_UVQS_wmsbh 为空或与 WMS 编号不一致的记录上做回写,这就是「增量起点」。
第二阶段,触发全量回写。在确认自定义字段 F_UVQS_wmsbh 已经按业务规范建好以后,人工触发一次全量,把历史供应商档案补齐。这里稳妥的做法是先关掉 IsAutoSubmitAndAudit,全量跑完核对无误再开审核。
第三阶段,稳定调度。日常运行以目标端 23 2 * * * 为节拍,凌晨低峰期执行。源端 1 1 1 1 1 充当周级探测,用于发现编号漂移或新增未映射记录。一旦源端探测命中,目标端在下一次调度里自动补齐。
编码映射我们集中在轻易云的「映射管理」里维护,不在金蝶云星空侧散落硬编码,这是客户现场最常见的应对模式之一。表头表体方面,因为本策略只动供应商档案表头,没有表体行项目,所以无须分阶段;但若后续扩展到物料主数据,务必把表头与表体拆成两条策略。
踩坑复盘
第一,自定义字段没建就回写。某项目上我们急着上线,结果 F_UVQS_wmsbh 在金蝶云星空还没启用,所有 batchSave 调用全部失败。稳妥的做法是上线前用一次空跑验证字段存在性。
第二,IsAutoSubmitAndAudit 默认 true。一旦回写后自动审核,任何编号错误都会被锁死在已审核状态,清理成本很高。这里容易翻车,默认务必 false。
第三,编码映射散落在脚本里。早期我们把映射逻辑写在每条策略的脚本里,后来新增一个业务域就要改十几处。后来统一抽到轻易云的「映射管理」,改一处全局生效,这是增量与全量双轨之外的第三个关键习惯。
第四,源端查询接口超时。源端 QUERY 拉供应商全量时,数据量大就会超时。我们后来把源端拆成「按编码区间分页」,既不超时也方便断点续传。
第五,时区与调度错位。私有化环境下服务器时区未必统一,23 2 * * * 在不同时区解释不同。我们统一在轻易云侧锁定时区,避免凌晨调度漂到交易时段。
适用场景与不适用场景
本策略适合:WMS 与 ERP 共存、供应商主数据由 WMS 先建档、ERP 需要可追溯 WMS 编号的医药/零售/制造场景。不适合:WMS 编号本身频繁变更、需要双向同步、或涉及供应商资质证照批量维护的场景——这些场景应当另起策略,避免与本回写策略耦合。