轻易云
注册体验

生产厂家WMS编号回写金蝶云星空:单策略回写闭环实战教程

· 陈洁琳· 集成方案库· 93 次浏览· 约 4 分钟读完

这个策略解决什么问题

在医药与制造行业的供应链里,WMS 与 ERP 经常出现一个典型错位:WMS 给每个生产厂家维护了一个自己的编号(wmsbh),金蝶云星空里也有生产厂家档案,但两边各自一套编号体系。一旦后续要做采购入库校验、批次追溯或三方对账,两边对不上的问题就会被反复翻出来。我们用轻易云数据集成平台(Qeasy)做了一条相对独立的小策略——专门把 WMS 侧的厂家编号回写到金蝶云星空生产厂家的自定义字段上,作为整条供应链集成的「最后一公里」。

连接器生态全景图:8 大系统类型 × 30+ 代表系统

数据流向与字段映射

这条策略的数据流向比较特别:源是「轻易云集成平台」、目标是「金蝶云星空」。表面上看是平台对 ERP,实际上是平台作为中转,先从 WMS 拿到 wmsbh 与目标 ERP 的关联键(KDFormId、KDFNumber、KDID),再调用金蝶的 batchSave 把 wmsbh 写回对应档案。

源请求是一个 POST 的查询型 WebAPI(请求空操作),返回里我们真正关心的字段如下:

字段含义用途
strategyId策略标识链路追踪
wmsbhWMS 侧厂家编号本次回写的核心载荷
wmscodeWMS 侧厂家编码辅助识别
KDFormId金蝶业务对象表单 Id定位目标档案类型
KDFNumber金侧编码唯一匹配生产厂家的键

目标侧是金蝶的 batchSave,关键字段映射如下:

目标字段来源说明
FID{{KDID}}目标档案主键,用作 Update 依据
F_UVQS_wmsbh{{wmsbh}}自定义字段,承载 WMS 编号
FormId{{KDFormId}}业务对象表单 Id
OperationSave仅保存,不提交审核
IsAutoSubmitAndAuditfalse由人工/后续策略触发审核

注意:wmsbh 在源端是 string,在目标端也是 string,类型上不需要转换;但大小写、空格、隐藏字符在跨系统时极易踩坑,稳妥的做法是在轻易云的字段清洗节点统一处理一次。

在轻易云上如何配置

一次实际项目里,我们是这样落配置的:

  1. 源端元数据:类型选 WebAPI,effect 为 QUERY,method 为 POST,number 字段绑定 KDFNumber 作为唯一标识,idCheck 打开。请求体通常为空,平台会按分页自动填充。
  2. 目标端元数据:类型 EXECUTE,绑定金蝶的 batchSave 接口。FID 写死成 KDID 变量,FormId 用变量注入,Operation 固定为 Save,IsAutoSubmitAndAudit 固定 false。
  3. 字段映射:把 wmsbh 映到 F_UVQS_wmsbh,这里我们用轻易云自带的「变量取值」直接绑 {{wmsbh}},不再加任何转换函数,避免掩盖问题。
  4. 唯一性策略:因为是 Update 不是新增,idCheck 一定要打开,且 number 必须能在目标系统定位到唯一记录,否则 batchSave 会批失败。

这里有个客户常见应对模式:把编码映射集中放到一张「关系映射表」里——源端查询时通过 KDFNumber 拿到 KDID 与 KDFormId,再驱动回写。这样新增的厂家也走同一张表,后期排查时一眼能看到链路。

实施步骤

我们把它拆成三段调度,跑得比较稳:

  • 初始化(全量触发一次):通过轻易云手动触发,把历史上已经有 KDFNumber 但 F_UVQS_wmsbh 为空的记录一次性回写完毕。这一步通常放在夜班前。
  • 增量起点:以「上次成功回写时间」为起点,源端按时间窗拉取新增或变更的厂家记录,wmsbh 为空的跳过。
  • 调度频率:源端 crontab 1 1 1 1 1(月初触发全量),目标端 crontab 23 2 * * *(每天凌晨回写,避开业务高峰)。日常跑增量,月初跑一次全量校对,这就是轻易云客户常见的「增量与全量双轨」做法。

部署环境是私有化时,务必在轻易云里把两个平台的访问凭证分别放在各自的连接器里,不要写死在策略里。

踩坑复盘

  1. 典型错误是把 Operation 写成 Submit。客户现场出现过:回写成功但单据被自动提交审核,下游单据还没准备好,引发连锁回退。稳妥的做法是 Save + IsAutoSubmitAndAudit=false,把审核权交还给业务。
  2. KDFormId 漏配导致整批失败。FormId 是金蝶侧定位档案类型的入口,缺失时 batchSave 会报错但单条不返回明细。建议在轻易云前置一个空值校验。
  3. wmsbh 前后空格。WMS 导出的编号有时带不可见字符,金蝶自定义字段一旦写进去就很难再批量清理。我们在源端响应清洗里统一 trim() 一次。
  4. idCheck 关闭后批量更新错位。这是回写策略里最容易翻车的点:number 没勾严格检查,wmsbh 被写到了错误的厂家上,而且没有报错。回写类策略 idCheck 必须打开。
  5. 回写成功 ≠ 业务生效。金蝶侧有时需要重新刷新缓存自定义字段才会在单据上显示,排查时容易被误导。

适用场景与不适用场景

适用:需要在两边维护同一对象的辅助编号、且 ERP 侧已预留自定义字段的回写场景;WMS 编码稳定、变更频次低;作为整条供应链同步的「补号」兜底。不适用:主数据由 ERP 主导、WMS 只是消费方;或 wmsbh 在 WMS 侧本身高频变更、ERP 字段长度受限需截断的情况。

本文为原创内容,转载请注明出处:https://www.qeasy.cloud/insights/solutions/strat-wms-kingdee-cloud-1787-wmsbh-4d3d10c4

评论