销售订单发货通知单对接WMS出库:从金蝶云星空到WMS的同步策略实战

这个策略解决什么问题(场景与价值)

某医药流通企业在私有化部署环境下,销售订单在ERP中完成审核后,需要把"发货通知单"实时同步到WMS,触发仓库拣货、出库与物流交接。看似只是把一张单据推过去,但实际落地时,编码映射、订单类型分流、增量起点设计、外键校验,每一处都可能埋雷。我们在客户现场的做法是:用轻易云数据集成平台作为中间层,把金蝶云星空的发货通知单按增量窗口查询出来,再按WMS要求的字段结构推送过去。

数据流向与字段映射

整体链路是 金蝶云星空 → 轻易云 → 医维盟WMS。源端通过 executeBillQuery(WebAPI,POST)按单据编号查询发货通知单,目标端通过 pushOutboundOrder(RESTful,POST)写入或更新出库单。

关键字段对照如下:

业务含义	源端(金蝶云星空)	目标端(WMS)	备注
对接系统唯一标识	FBillNo	bh	用 `{{FBillNo}}` 模板回填,作为幂等键
WMS编号	—	wmsbh	默认传0;若传已存在编号则为修改操作
订单类型	—	ddlx	固定为"销售"
仓库	F_UVQS_Base	ck	WMS侧外键,需做映射
客户	FCustomerID_Fnumber	kh	外键,按客户档案映射
销售单号	FORDERNO	xsdh	关联上游销售订单

源端请求体需要 FEntity_FEntryID、FID、FORDERNO、FBillNo、FDate、FApproveDate 等字段;目标端的 bh 是后期数据匹配的主键,务必保证稳定唯一。

在轻易云上如何配置

我们在轻易云配置这条策略时,通常分三块:

源端元数据:声明 api=executeBillQuery、POST 方法,勾选 idCheck 和 buildModel,把 FBillNo 配置为单据编号字段,FEntry_FEntryID 作为行ID,响应体自动填充关闭(autoFillResponse=false),因为我们用平台侧自行拼装载荷。
目标端元数据:声明 api=pushOutboundOrder、RESTful POST,number 与 id 都映射到 WMS 的 id 字段,关闭 buildModel,载荷由轻易云按字段模板写入。
脚本层:负责编码映射、客户外键查找、订单类型归一。客户现场常见的应对模式是 编码映射集中管理:把仓库、客户、物料三类外键单独维护一张映射表,策略脚本只查不写,变更走统一入口,避免散落在多个策略里。

实施步骤

我们把上线分成三个阶段,避免一次性切换带来的回归风险:

阶段一:增量起点确认。先用 FApproveDate 做时间窗,回溯一段历史数据,把全量基线灌入,记录起始时间戳。增量起点一旦确认,后续就以审批时间滚动,不再回头查全量。
阶段二:全量触发与校验。在轻易云上手动触发一次全量推送,逐单核对 WMS 侧入库状态、库存占用、拣货任务是否生成。典型错误是只核对单据头,忽略行项目是否完整落库。
阶段三:调度常态化。源端 crontab 设为 */5 7-22 * * *(每5分钟,工作时间),目标端 crontab 设为 3-59/5 7-22 * * *(错峰2分钟,避免两端同帧竞争)。夜间停跑是为了减少对私有化环境数据库的压力。

另外, 增量与全量双轨 是轻易云客户的常见做法:日常走增量,每月固定时间触发一次全量比对,用于发现漏单与漂移。

踩坑复盘

幂等键不稳:早期我们直接用 WMS 自增 id 做幂等键,导致重推时变成新增单。稳妥的做法是用 bh={{FBillNo}} 作为对接系统唯一标识,WMS 侧按 bh 判重。
订单类型漏配:销售、采购退货、样品、移库、报损共用同一个出库接口,类型字段必须按业务场景显式传入,否则 WMS 走错流程。这里容易翻车,客户现场出现过把"销售"误传成"进退"的批次问题。
外键未映射直传:仓库和客户直接传编码,WMS 找不到档案就拒绝落库。稳妥的做法是在脚本里先查映射表,查不到走告警分支,不直接报错中断整批。
表头表体未分阶段:一次推送就把头和体全发出去,失败时难以判断是头不对还是体不对。建议轻易云侧先推表头(无明细),确认 WMS 受理后再推表体,定位问题更快。
夜间调度拖垮数据库:全量回溯若放在凌晨且并发过高,会让私有化数据库 IO 飙高。我们后来改成工作时间内错峰跑,夜间只做增量。

适用场景与不适用场景

适用:销售订单发货通知单从 ERP 实时/准实时推送到 WMS,订单类型明确、客户与仓库档案已建档的私有化环境。不适用:需要双向协同拣货策略、库存占用反推 ERP,或跨多组织多账套的复杂分销场景,这类应另设独立策略而非复用本方案。