销售订单状态回传:国药WMS出库反馈查询策略实战

这个策略解决什么问题

在医药零售的供应链链路里,销售订单从金蝶云星空下达后,真正决定库存释放与发货节奏的是 WMS 端的出库反馈。某零售企业上线国药 WMS 与金蝶云星空互通时,业务方频繁反馈"订单已经下到 ERP,但 WMS 这边始终显示未出库"——根因不是没出库,而是出库反馈没回写到业务视图。这一策略正是为解决这个口径问题:定时把国药 WMS 的出库单反馈回查结果拉回集成平台,作为销售订单状态推进的依据。

数据流向与字段映射

数据从国药 WMS 流向轻易云数据集成平台,源系统通过 WebService 接口 GetPktRstErp(GET,QUERY 语义)发起查询,目标端在平台上以 RESTful 的"写入空操作"承接,主要作用是把响应载荷落库供后续策略消费。

关键字段对照(源 → 中间层 → 目标)如下:

这里采用「编码映射集中管理」的应对模式——所有国药侧的常量(T0 货主、S 拣货类型)统一放进平台的映射表,后续策略复用,避免散落在脚本里。

在轻易云上如何配置

在轻易云数据集成平台(Qeasy)里,这是一种典型的 QUERY_ONLY 策略,落地分三步。

第一步,注册源系统。把国药 WMS 的 WebService 接入信息登记为平台 A,平台 ID 用通用 GUID 即可,确认 Sinopharm code 与集成方案一致。

第二步,登记目标端。目标平台写"轻易云集成平台",API 选 写入空操作,method 为 POST,用于把响应落库。id 与 number 分别绑定 PKT_NO 与 ERP_GROUPNO,并开启 idCheck,防止重复回传。

第三步,关联调度。本策略 crontab 为空,通常由序列 A 的上一道推送策略触发;另外配置兜底轮询 1-59/10 8-22 * * *,覆盖营业时段每 10 分钟一次的反馈回查。

实施步骤

第一阶段,起点对齐。先在金蝶云星空里确认销售订单已审核,且 ERP_GROUPNO 已生成,作为回查的入参;这一步常被忽略,导致首次调度空跑。

第二阶段,首次全量触发。上线当日人工触发一次,核对 DETAILLINES、PKT_TYPE 是否符合预期口径;一旦首条回写异常,后续 10 分钟轮询会把脏数据持续放大。

第三阶段,调度频率切换。进入稳态后,采用「增量与全量双轨」:营业时段(8:00–22:00)按 10 分钟增量轮询;夜间切到日终全量,核对前一天未回传的反馈单据,补齐后再交给下游更新销售订单状态。

第四阶段,下游衔接。本策略只负责回查与落库,真正的销售订单状态推进交由序列中的后续策略消费这张中间表,实现「表头表体分阶段」处理。

踩坑复盘

• 入参语义混淆:MsgBody.ERP_GROUPNO 与 MsgBody.PKT_NO 极易写反。前者是业务组号(向下游业务系统透传),后者是拣货单号(WMS 内部唯一)。一旦写反,idCheck 会把所有回传当成重复单丢弃。
• 营业时段外空跑:不少团队会把 crontab 写成 */10 * * * *,夜间无人值守时段接口偶发超时,告警噪音极大。稳妥的做法是按 1-59/10 8-22 * * * 收敛。
• T0 常量硬编码:货主、拣货类型这类常量如果写死在脚本里,改一次全网失效。集中放到映射表后,所有依赖此策略的下游同步自动跟随。
• 目标端误配成下游系统:目标平台必须是「轻易云集成平台」(datahub),不是金蝶云星空。这是一条 INTERNAL 流,负责把数据沉淀到平台中间层,不能直接落业务系统。
• idCheck 误关闭:关闭后同一拣货单会重复入中间表,导致下游销售订单状态被反复推进。稳妥的做法是保持开启,只在排查时临时关。

适用场景与不适用场景

适用:国药 WMS 与金蝶云星空(或同类 ERP)之间的销售订单状态回查,需要把出库反馈作为业务侧可见状态推进。不适用:对实时性要求秒级回写的门店 POS 场景、跨货主共用拣货单的复杂仓配、以及目标端需要直接写业务系统而非中间层的链路。