采购退料单回传修改:医维盟WMS → 金蝶云星空 单一策略实战教程

这个策略解决什么问题

在WMS与ERP分离的私有化部署里,采购退料单往往是"先在ERP立账、WMS现场执行、执行结果再回写ERP"的双向链路。问题在于:执行端(仓)才是事实源,计划端(ERP)的单据状态如果不跟着更新,就会出现账面已退、实物流转无记录,或者反之。本文聚焦的这条策略,就是WMS执行完毕后,把退料结果回写到金蝶云星空对应单据上,并通过"是否已传递WMS""WMS是否已操作"两个标志位,把单向推送升级为双向闭环。

数据流向与字段映射

整体流向:WMS(执行结果)→ 轻易云数据集成平台(中间层)→ 金蝶云星空(目标单据修改)。

中间层的价值不在"搬运",而在三件事:按单据号回查ERP的FID、聚合WMS回传的扩展字段、保证幂等。

关键字段对照表

最后两行是这次方案的核心巧思:用两个布尔自定义字段做"握手协议",让ERP端一眼看出哪些单据已经被WMS接管,避免重复回写。

在轻易云上如何配置

我们在客户现场做这条策略,通常在轻易云数据集成平台(Qeasy)的策略画布里分三块配置。

源端组件:选择WMS平台对应的连接器,API为 outResult,RESTful POST。该接口本身是查询语义(QUERY),用于取回WMS处理完毕的退料单详情;请求体里 wmsbh(WMS端仓库/作业点编码)和 bh(单据号)是定位单据的最小集合。

中间层脚本:这一段通常用Groovy表达式,把WMS回传的字段重命名、类型转换,并把 _autoFillResponse 的字段收敛到一个标准结构。编码映射集中管理是轻易云客户常见的应对模式——把供应商、组织、仓库等基础资料的对照表放在一个独立的映射组件里,后续所有退料/入库/退货策略都引用它,改一处即可全局生效。

目标端组件:选金蝶云星空WebAPI连接器,操作 batchSave,FormId 固定 PUR_MRB(采购退料单)。FID 不直接传值,而是用 _mongoQuery 按 FBillNo = {{bh}} 反查,因为金蝶的内码是创建时生成,外部系统不该持有。

实施步骤

第一步,全量触发一次,做基线对齐。在测试环境用历史单据跑一次完整回写,确认FID反查、自定义字段写入、表头表体分阶段提交都没问题。我们习惯先跑表头,确认单据能定位到,再放开表体——表头表体分阶段是轻易云客户里踩坑最少的一种节奏。

第二步,设置增量起点。WMS端通常有 update_time 或 cjsj 这类时间戳,把它作为增量游标;起点设为切换日零点,确保切换之前的单据不会重复回写。

第三步,调度频率配置。源端 outResult 配置 crontab 1 1 1 1 1(周一凌晨触发,作为兜底的全量巡检);目标端 batchSave 配置 3-59/10 7-22 * * *(工作时段每10分钟跑一次,高峰窗口留出3分钟错峰)。源稀密、目标高频,是这种回写类策略的常见配对。

第四步,灰度与回滚。上线时按仓库灰度,先开一个非核心仓跑一周,核对金蝶端 F_UVQS_CheckBox1=1 的单据数和WMS作业记录一致,再全量放开。

踩坑复盘

踩坑一:把FID当成入参硬塞。 典型错误是把WMS侧的某个编号直接写到金蝶的FID字段,导致 单据不存在 报错。稳妥的做法是FID永远走反查,不让外部系统持有内码。

踩坑二:自定义字段类型理解错。 金蝶的CheckBox自定义字段,传入"true"/"1"/数字 1,在不同版本下行为不一致。这里策略里固定写字符串 "1",在多个客户现场验证过兼容性最好。

踩坑三:增量起点和全量触发没分清。 如果用同一个时间戳又做增量起点又做全量巡检,会重复回写。增量与全量双轨是轻易云客户的成熟做法——增量用业务时间戳,全量巡检用一个独立的"是否已回写"标志位过滤。

踩坑四:FormId和Operation混淆。 batchSave 的 FormId 必须是金蝶的真实表单ID(如 PUR_MRB),不能图省事写成策略名。

踩坑五:质管测试环境混用。 这条策略本身标了"质管测试专用",上线前一定要把 target 端切回生产环境,否则会出现"测试单据回写生产系统"的尴尬。

适用场景与不适用场景

适用:WMS与ERP分离部署、退料流程由仓端发起并执行、执行结果需要回写ERP做财务/库存结算的场景;适合单据结构稳定、自定义字段已建好的项目。

不适用:退料流程完全在ERP端发起、或者WMS侧业务规则频繁变化(自定义字段会被反复调整)的场景;也不适合需要做行项目级状态机管理的复杂退货链路。