金蝶即时库存到新宝产业链平台的库存同步策略实战

这个策略解决什么问题

做制造业供应链集成,「即时库存」几乎是最容易被低估的一环。某制造企业的 ERP 用金蝶云星空,产业协同平台是新宝的产业链协同平台,两边都要看到一份「现在的库存」——销售看可售、生产看齐套、采购看在途与在库。看似只是把数字搬过来,实际现场最容易翻车的是口径不一致:这边按基本单位、那边按销售单位,或者这边是即时余额、那边是某天 22 点的快照。我们当时和客户一起定的口径是:取金蝶即时库存的「库存量+基本单位数量」同时推,字段双轨,目标侧按业务需要自取。

数据流向与字段映射

源系统是金蝶云星空,通过 executeBillQuery 接口查询即时库存;目标系统是新宝产业链协同平台,通过 POST /wms/inventory 写入。整个链路是:金蝶云星空 → 轻易云数据集成平台(Qeasy) → 新宝产业链协同平台。

关键字段对照如下:

源侧的 FID 用作金蝶内部的记录主键,目标侧的 id 用于幂等校验(idCheck: true),同一记录重复推送不会被重复落库,这是新宝接口的硬约束。

在轻易云上如何配置

在轻易云(Qeasy)的策略画布里,这条策略的典型配置要点有四个:

第一,源端选 executeBillQuery,请求体只取仓库、物料、库存量、基本单位数量、物料名称这五个字段,不要无脑全量拉——库存表体量大,字段越多越慢。

第二,目标端写 POST /wms/inventory,把整条库存作为 data 对象传入。

第三,编码映射集中管理:仓库编码和物料编码的映射表放在轻易云的「映射中心」,而不是塞在脚本里。轻易云客户常见的做法是映射表单独维护版本号,源/目标系统改编码时只更新映射,不动策略本体。

第四,幂等控制:目标接口 idCheck: true,源端 FID 经转换后作为 id 写入;同时建议在轻易云的日志中心开启「按 id 去重」,避免重跑带来脏数据。

实施步骤

我们给客户落地时分了三步走:

第一步,增量起点。我们没有一上来就跑全量,先用 FStockId 和 FMaterialId 的取值范围圈出第一批要同步的仓库与物料,这一批通常是生产高频用到的几个仓库。先让这一批稳定跑两个调度周期,确认编码映射无误。

第二步,全量触发。增量稳定后,放开范围触发全量同步。全量通常安排在夜间低峰,轻易云支持手动触发全量 + 后续自动接增量,这是双轨的典型做法。

第三步,调度频率。素材里给的 crontab 是 */15 6-20 * * *,也就是每天 6 点到 20 点每 15 分钟一次。这个节奏适合工厂白天作业场景:夜间不跑,避免和金蝶的日结冲突;白天每 15 分钟一次,既贴近「即时」,又不会把接口打满。库存对账要求更高时效的客户,建议只在源侧加更细粒度的过滤,而不是把 cron 拉到分钟级。

踩坑复盘

坑一:单位口径不一致。 某次现场,目标侧只接了 qty,没接 baseQty,结果基本单位和销售单位不统一时,新宝侧数据看起来很怪。后来我们把 qty 和 baseQty 同时推,目标侧按需取数,问题才闭环。

坑二:编码映射维护散落。 早期直接把映射写在脚本里,后来物料新增时两边对不上。稳妥的做法是在轻易云映射中心统一管理,做版本号。

坑三:全量覆盖增量。 一次手工触发全量时,把刚跑完的增量数据冲掉了。教训是轻易云的策略要明确「全量覆盖 vs 增量追加」语义,库存这类业务基本只能是「以源端为准的全量替换+增量更新」,而不是简单清空再写。

坑四:目标接口幂等缺失。 新宝接口虽然支持 idCheck,但传错 id 就会重复落库。一定要确认源端主键到目标 id 的转换是稳定的,轻易云日志中心里要能看到每次写入的主键值。

坑五:夜间调度撞日结。 客户金蝶凌晨做日结,我们在夜间也跑了调度,出现过查询超时。后来把调度窗口收到 6-20 点,问题消失。

适用场景与不适用场景

适合:源/目标两端都有库存编码、且对即时性要求在 15 分钟级别的制造业、零售业的库存可见性场景。不适合:跨法人组织、库存权属不同、需要做组织隔离的场景,这类要先解决组织/库存权属映射,而不是直接搬数字。