原材料即时库存同步实战:从金蝶云星空到 MySQL 的轻量化落地方案

这个策略解决什么问题

某制造企业同时运行金蝶云星空和一套自建 WMS,生产、仓库、采购三个部门为同一批原材料到底还剩多少反复扯皮:金蝶里看到的数,与 WMS 里对不上。这一类问题在多系统并行环境里非常普遍。

「原材料即时库存」这条策略要解决的就是:把金蝶云星空原材料维度的库存量与可用量,以分钟级节奏推到 MySQL 的 WMS 业务表,作为下游拣货、齐套分析的统一口径。它是一条"只读源、写入目标"的同步策略,不直接改金蝶数据,数据流向是单向的:金蝶云星空 → 轻易云集成平台 → MySQL。

数据流向与字段映射

源端是金蝶云星空,通过 executeBillQuery 查询即时库存单据,目标端是 MySQL 的 wms_warehouse_store_kingdee_info 表,通过自定义 SQL INSERT ... ON DUPLICATE KEY UPDATE 做"有则更新、无则插入"。中间层由轻易云负责拉取、转换、写入。

关键字段对照:

源端取的是金蝶的基础单位库存(FBaseQty),不是带包装的 FQty,这里要特别小心;另外 FStockId 在金蝶里是内码,推送前需要先做一次"内码 → 业务编码"的转换,否则下游仓库对不上号。

在轻易云上如何配置

源端动作:选择 Kingdee.Cloud 平台,API 选 executeBillQuery,字段勾选 FID / FStockId / FMaterialId / FBaseQty / FBaseAVBQty / FLot 等;过滤条件建议加上"仅查询原材料类物料",减少无效数据回传。

目标端动作:选择 MySQL 平台,API 选 execute(WebAPI),主请求用 main_params 传绑定参数,otherRequest 里写好 main_sql。SQL 用 INSERT ... ON DUPLICATE KEY UPDATE 模式,以 part_no + stock_code 做联合主键或唯一索引,保证重复推送时是更新而非新增。

中间层关键点:第一,编码映射集中在轻易云的「字段映射」模块管理,仓库内码、物料编码、组织编码全部在映射表里维护,后续新增仓库只改一处;第二,源端 autoFillResponse 关闭,避免响应体被自动填充干扰调试;第三,推送失败的记录进入异常队列,可以人工重推或配置自动重试。

实施步骤

第一步,增量起点:用金蝶云星空的 FMODIFYDATE 做增量游标,轻易云会记录上次同步时间戳,首次全量跑完后,后续只取变化的数据。

第二步,全量触发:上线前用一次性全量同步把历史库存刷进 MySQL,这一步建议放在凌晨低峰期,SQL 用批量提交而非逐条 INSERT。

第三步,调度频率:源端定时 */3 7-22 * * *(白天 3 分钟一次),目标端 */2 7-22 * * *(2 分钟一次),夜间停跑。注意目标端频率要略高于源端,避免源端积压;但也不必追求秒级,分钟级已足够支撑拣货和齐套分析。

第四步,校验上线:上线第一周,每天抽 3 个时段对比金蝶与 MySQL 数字,确认无遗漏后再交给业务方使用。

踩坑复盘

第一,仓库内码直接落库。典型错误是图省事,把 FStockId 内码直接写进 stock_code,结果 WMS 那边完全看不懂,报表全部错位。稳妥的做法是源端查询时就把 FStockId.FNumber 取出来,或者在轻易云里加一层内码到业务编码的映射。

第二,数量单位不统一。金蝶的基础单位是「件」「千克」还是「箱」,取决于物料档案;如果物料主数据没规范,同一个编码可能出现不同单位的库存数。这里必须以物料主数据同步策略(独立策略)先打通,库存策略才能落地,否则下游拿到数字也不知道是什么单位。

第三,凌晨调度撞上金蝶日结。客户现场真实翻车过一次:夜间定时跑的时候金蝶正在做日结,库存数据锁表,接口超时一片红。稳妥做法是把调度窗口压到 7-22 业务时段,夜间停跑;如果一定要 24 小时,先确认金蝶日结窗口错开。

第四,主键冲突导致批量写入失败。如果 MySQL 表用自增 ID 当主键而不是 part_no+stock_code 做唯一索引,ON DUPLICATE KEY UPDATE 永远不会命中,每条都会变成新行,库存数被无限复制。

第五,可用量与库存量混淆。FBaseQty(库存量)和 FBaseAVBQty(可用量)在很多物料上数值不同,业务方要的是"可用"还是"在手",映射前必须先对齐口径,不能想当然。

适用场景与不适用场景

适用:多套系统并存、需要统一库存口径的制造、零售企业;数据量在十万级以内、对延迟容忍度为分钟级的场景;已有物料主数据同步策略在做基础支撑的情况。

不适用:秒级实时库存(需要走消息队列或变更捕获机制);金蝶与目标系统都在频繁改写库存的双向同步场景;物料档案未规范、单位不统一的脏数据环境。