fix: MKH-BOM 成品库存按仓白名单多仓求和（并入横林二仓品牌仓） #67
Loading…
x
Reference in New Issue
Block a user
No description provided.
Delete Branch "codex/mkh-brand-warehouse-multi-1017"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
fix: MKH-BOM 成品库存按仓白名单多仓求和（并入横林二仓品牌仓）
问题
业务反馈「MKHDNZ0409260600788 库存在横林二仓品牌仓，重新加了一个品牌仓库存，
需要同步这个仓库库存」。
根因：商品档案
jst_sku.other_3记录的是归属仓，不是实物所在仓。该批 MKH 成品的归属仓仍是「简尚-崔桥工厂品牌仓」(15870495)，但实物已被整批搬到
2026-10-13 新建的「简尚-横林二仓品牌仓」(16132681)。归属仓库存为 0、新仓有货，
而 ⑦-d 的库存取数只查
wms_co_id = 15870495单仓 → 这批成品库存全被算成 0。实测影响（2026-10-17）：
other_3全为崔桥品牌仓），合计 525 件改动
backend/src/services/mkhBomService.jsBRAND_WMS_CO_IDS = [15870495, 16132681]成品库存仓白名单（BRAND_WMS_CO_ID保留给仓库名文案与监控快照过滤）
jst_inventoryInfo/jst_packInventoryInfo两条取数改为wms_co_id IN (白名单)+SUM(qty)+GROUP BY sku_id，按 SKU 多仓求和ORDER BY updateTime DESC（单仓去重）在多仓下只会留一个仓，必须换成 SUM + GROUP BY —— 本次同时修掉这个隐患
并入会让「配件不足」漏判
backend/test/mkhBomService.test.js验证
check-syntax.js：182 文件通过node --test：405 tests / 404 pass / 1 fail（唯一失败为
resilientSecretStoreWindows 权限断言，环境固有，与本改动无关）报错精确指向旧 SQL（
wms_co_id = @brandWmsCoId ... ORDER BY updateTime DESC），证明测试非空过差异 58 个，全部是新值 > 旧值，反向 0 个、来源标记变化 0 个，
合计补回 525 件（= 新仓总量，完全吻合）
total 4347（不变）/warning 30 → 23/outOfStock 21 → 16，与逐 SKU 分析结论一致（消除 5 个误报缺货 + 2 个误报预警）STATISTICS IO两边均为jst_inventoryInfo scan 1 / logical reads 4683（不增加 IO）；实测 355ms vs 旧 356~914ms，无退化
风险与回退
已在代码注释与文件头 ⑦-e 写明。
## 问题 业务反馈「MKHDNZ0409260600788 库存在横林二仓品牌仓，重新加了一个品牌仓库存， 需要同步这个仓库库存」。 根因：商品档案 `jst_sku.other_3` 记录的是**归属仓**，不是**实物所在仓**。 该批 MKH 成品的归属仓仍是「简尚-崔桥工厂品牌仓」(15870495)，但实物已被整批搬到 2026-10-13 新建的「简尚-横林二仓品牌仓」(16132681)。归属仓库存为 0、新仓有货， 而 ⑦-d 的库存取数只查 `wms_co_id = 15870495` 单仓 → 这批成品库存全被算成 0。 实测影响（2026-10-17）： - 新仓 58 个 SKU **全是 MKH 成品**（`other_3` 全为崔桥品牌仓），合计 **525 件** - 页面 49 个 SKU 库存值错误，其中 **5 个误报「缺货」、2 个误报「预警」** ## 改动 `backend/src/services/mkhBomService.js` - 新增 `BRAND_WMS_CO_IDS = [15870495, 16132681]` 成品库存仓白名单（`BRAND_WMS_CO_ID` 保留给仓库名文案与监控快照过滤） - `jst_inventoryInfo` / `jst_packInventoryInfo` 两条取数改为 `wms_co_id IN (白名单)` + `SUM(qty)` + `GROUP BY sku_id`，**按 SKU 多仓求和** - ⚠️ 原 `ORDER BY updateTime DESC`（单仓去重）在多仓下只会留一个仓， 必须换成 SUM + GROUP BY —— 本次同时修掉这个隐患 - 配件库存**不动**：新仓一个配件都没有，横林三仓/沭阳仓虽有 MKH 配件但归属别的项目， 并入会让「配件不足」漏判 `backend/test/mkhBomService.test.js` - 新增 ⑦-e 多仓求和测试（锁 SQL 白名单 + SUM/GROUP BY，并断言求和结果） - 新增白名单常量测试（防止后续误删横林二仓 ID） ## 验证 - `check-syntax.js`：182 文件通过 - `node --test`：**405 tests / 404 pass / 1 fail** （唯一失败为 `resilientSecretStore` Windows 权限断言，环境固有，与本改动无关） - **对照组实验**：stash 回修复前源码跑新测试 → 2 条**全部失败**， 报错精确指向旧 SQL（`wms_co_id = @brandWmsCoId ... ORDER BY updateTime DESC`），证明测试非空过 - **同一数据快照双口径 diff**（生产库实测）：参与比对 385 个 SKU， 差异 58 个，**全部是新值 > 旧值，反向 0 个、来源标记变化 0 个**， 合计补回 525 件（= 新仓总量，完全吻合） - **新代码在生产容器实跑**：`total 4347`（不变）/ **`warning 30 → 23`** / **`outOfStock 21 → 16`**，与逐 SKU 分析结论一致（消除 5 个误报缺货 + 2 个误报预警） - **性能**：`STATISTICS IO` 两边均为 `jst_inventoryInfo scan 1 / logical reads 4683`（不增加 IO）； 实测 355ms vs 旧 356~914ms，**无退化** ## 风险与回退 - 风险：白名单常量是硬编码，后续上游再新增同类「成品发货仓-真实库存」仓时需追加 ID。 已在代码注释与文件头 ⑦-e 写明。 - 回退：单文件改动，revert 本提交即恢复单仓口径，无数据迁移、无状态残留。