原材料即时库存校验实战：MySQL 到金蝶云星空的库存量双向核对方案

这个策略解决什么问题

在离散制造与原材料密集型企业里，WMS/MES 一侧的库存可用量与 ERP 财务账的库存量长期存在差额，是供应链对账的老大难。一次实际项目中，某制造企业每月对账要花 3 个人日，差异追溯往往卡在「物料编码映射」「仓库主键」「批次口径」三个地方。本策略聚焦原材料即时库存的高频校验，目标是把日级手工对账压缩到分钟级自动核对。

数据流向与字段映射

数据链路是「金蝶云星空 → 轻易云 → MySQL」的回写式校验：先把 ERP 实时库存拉出来，再落库到中间库的 wms_warehouse_store_info 表，供 MES 端做差异比对。

业务含义	源字段（金蝶云星空）	目标字段（MySQL）	处理要点
物料编码	FMaterialId.FNumber	`part_no`	编码映射集中维护
仓库	FStockId	`company_code`	按仓映射独立字段
库存量	FBaseQty	`kingdee_stock`	数值直接回写
可用量	FBaseAVBQty	（对照字段）	用于差异告警
批次	FLot	（对照字段）	启用时进入映射表

关键点：idCheck=false 表示金蝶侧不按主键强校验，靠物料+仓库+批次的组合键来定位记录。

在轻易云上如何配置

在轻易云数据集成平台里，这条策略配两条元数据：

源（金蝶云星空）：API 选 executeBillQuery，方法 POST，number=FMaterialId_FNumber，id=FID。典型做法是把它当作一个数据源视图，每次按增量时间窗拉取变化。
目标（MySQL）：API 选 execute，方法 POST，otherRequest.main_sql 是一段带命名绑定的更新语句：

sql

update wms_warehouse_store_info
set kingdee_stock=:stock_numb
where part_no=:part_no and company_code=:company_code

main_params 用对象绑定 :part_no、:stock_numb、:company_code 三个变量。idCheck=true 表示更新必须有命中行，否则报错进入重试队列，这是稳稳地兜底的关键。

实施步骤

首次全量初始化：停掉增量调度，用一次性脚本把金蝶当前所有仓库-物料的 FBaseQty 全量刷到 MySQL。建议先在一个测试账套里跑通，再切换到生产账套。
增量起点确定：金蝶没有原生的「库存增量时间戳」时，我们推荐两种方案：
- 引入中间表 kd_inventory_changelog，由触发器或调度写最后更新时间；
- 用 FBaseQty 当日的 Hash 摘要对比，差异才同步。
调度频率：源端 crontab=5,15,25,35,45,55 7-22 * * *，目标端错开 3 分钟 8,18,28,38,48,58 7-22 * * *。两端错峰避免「回写未落库又被覆盖」的竞态。
告警与重跑：轻易云的策略级重试 + 失败邮件告警，是客户现场最常用的兜底。建议给库存这类关键链路配「失败 3 次告警 + 人工确认后再补跑」。

踩坑复盘

编码映射分散在 SQL 里：典型错误是 part_no 写在 main_sql 里硬编码，结果新增一个仓库就要改 SQL。稳妥做法是用轻易云的「编码映射」做集中维护，新仓库只需在映射表加一行。
idCheck=true 被误关：不少客户第一次配置时关掉了 idCheck，导致目标 SQL 静默更新 0 行，差异越来越大。库存类策略务必保持开启。
源端拉全表不加分页：金蝶 executeBillQuery 不分页就是灾难——某客户单次拉了 80 万行，轻易云内存吃紧。建议加 Top 参数，按仓库分批拉。
时区与日期口径：金蝶的库存时点和 MySQL 的更新时间戳如果混用 UTC 和本地时间，会出现「明明没变却一直同步」的现象。建议两端统一用本地时区，并在 SQL 里加 update_time=NOW()。
调度错峰一定要做：源端与目标端同分钟触发会导致数据回写延迟到下一周期才被发现，错峰 3 分钟是最简单有效的做法。

适用场景与不适用场景

适用于原材料、半成品、委外加工件的库存与可用量高频核对，私有化部署、ERP 与 MES/WMS 不同账套的场景；不适用于需要「事务级强一致」的库存业务（建议走接口直连或分布式事务），也不适用于实时性要求 < 1 分钟的超高频场景，本方案 10 分钟粒度已经是稳妥上限。