lunanting/cangku
1
0
Fork 1
Code Issues Pull Requests 2 Actions Packages Projects Releases Wiki Activity
194 Commits 63 Branches 0 Tags
Commit Graph

61 Commits

Author SHA1 Message Date
yanhui
893f4d6aca feat: 新增「仓储中心24小时发货时效」侧栏（11 个主仓 · 12:00/16:00 双轮核验） 
需求（yanhui 2026-10-20）：在 MKH-BOM 列表左侧加一栏「仓储中心24小时发货时效」，
下列 11 个主仓（横林二仓、横林三仓、横林二仓品牌仓、崔桥工厂仓、崔桥工厂品牌仓、
崔桥工厂半成品仓、新苏北仓、睢宁仓、山东青岗集仓、山东品牌仓、河南洛宁仓），
从系统库存抓取已发货/未发货订单，按订单创建时间判定发货是否及时：
· 每天 12:00 核验「当天创建时间 7:00 之前」的订单是否已完成发货
· 每天 16:00 核验「当天创建时间 16:00 之前」的订单是否已完成发货

已确认的三条设计决策：
1. 子仓归属 → 连子仓一起算（京东云仓/自营仓/运营C专用仓/唯品仓等并入主仓）
2. 崔桥工厂半成品仓 → 系统无同名仓，先留空占位（不映射到配件仓 15718196）
3. 展示结构 → 只显示超时未发

实现要点
- 仓库归属用「关键词最长匹配」（不写死 wms_co_id），新增子仓只要名字含主仓关键词
  就自动归入，缓存 1h。实测 28 个子仓全部正确归入 11 个主仓，132 个代发仓零误并。
- 12:00 之前**不做核验**：resolveActiveRound 返回 null，服务层直接返回 notStarted，
  既不查订单表（接口 165ms）也不回填昨天的数据。前端显示「未到核验时间」+
  「12:00 开始首轮核验（核验当日 07:00 前创建的订单）」，11 个仓结构保留、数字显示「—」。
- 订单取数：两张表店铺互斥（jst_Orders = 京东/拼多多/抖音/得物/唯品会，
  jst_qmcust_orderlist = 天猫/淘宝/1688），并行分开查 + Node 侧按 o_id 去重合并，
  用 Promise.allSettled 保证单表失败时另一表数据仍可用（detailDegraded 标记）。
- 三态判定 pending / shippedLate / onTime：send_date 与出库表 io_date 取先到的发货痕迹，
  避免上游 send_date 回写滞后导致「已发的被判成没发」。
- 状态过滤：排除 Cancelled / Merged / **Split**（拆单父单永不发货，不排除会捞出一年前
  1.3 万条历史单），Question 仍计入待发。
- freshness 字段如实报告出库表最新 io_date，前端「发货数据可能滞后」告警，
  不拿一份可能滞后的数据去考核仓库。

排除的两次错误优化（均在代码注释里留了实测数据与复测脚本路径）
1. 用 created 替代 order_date 做窗口过滤（快 10 倍）—— 已证伪：2581 行里完全相等的只有 4 行，
   差 >1h 的 412 行，198 行跨日；典型形态 order_date=10-18 23:58 而 created=10-19 04:00:08
   （上游凌晨 4 点批量补录，created 是灌库时间不是下单时间）。业务口径是「订单创建时间」，
   只有 order_date 正确。
2. 「UNION ALL 一条 SQL 慢 5~8 倍」—— 被后续实测推翻（46.3s vs 并行 48.2s，基本持平）。

验证
- 新增 backend/test/warehouseShipTimeliness.test.js，10 条用例全绿，覆盖：
  最长匹配不误并、子仓命名、山东/河南高频前缀不误并、占位仓、12:00 前返回 null、
  12:00 轮窗口 00:00~07:00、16:00 轮窗口 00:00~16:00、状态排除表、三态分桶互斥、
  跨表重复 o_id 去重、round.windowEnd 必须带出（否则前端渲染成「核验 前」）。
- check-syntax 185 文件通过；全量 node --test 415 项 / 413 过 / 2 fail，
  两条失败均为已知环境因素（负缓存带 TTL 因 .env 有 CLOUD_DB_* 短路；
  resilientSecretStore 的 Windows 权限断言，基线恒失败）。
- 真渲染验收（组件级沙盒 + 真实接口数据）：两态均 0 控制台错误；
  已核验态 358 单超时未发、8 个仓有数字、点仓切换选中/再点取消均正常；
  多分辨率验证 1920/1600 侧栏 208px、1440/1366 收窄 176px、列表始终竖向。
 2026-10-20 11:23:08 +08:00
yanhui
c9715c0e5b fix: MKH-BOM 成品库存按仓白名单多仓求和（并入横林二仓品牌仓） 
## 问题

业务反馈「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 本提交即恢复单仓口径，无数据迁移、无状态残留。
 2026-10-17 09:34:55 +08:00
youruo
62cac712db fix: 动销分析多来源销量先按 仓库+商品 汇总再 join 
4 个销量来源 union all 后各分支各自 GROUP BY，同一个 仓库+商品 命中多个
分支时外层层 LEFT JOIN 没有二次聚合，一个仓位行被拆成多行、每行只带某一
个分支的销量（实测 SJ038411 同时出现 sales=0 与 sales=44 两行）。

新增 shipAgg CTE：按 仓库+商品 对各来源求和成一行，再与仓位行 join。
 SalesQty/分摊销量/日销/等级随之统一。
 2026-10-14 13:57:14 +08:00
youruo
2bdc4b5713 fix: 动销分析销量补齐组合装子件与全民客户(B2B)渠道 
线上订单里组合装以 ZH-子件A-N-子件B-M 拼接编码存在，按 sku_id 精确
匹配永远查不到子件销量；全民客户(jst_qmcust_orderlist)渠道此前完全
未纳入。两处缺失导致大量 SKU(尤其组合装子件)窗口销量被算成 0。

销量 ship CTE 拆为 4 个 UNION ALL 分支：
1) jst_Orders 普通行(sku_type<>combine)
2) jst_Orders 组合装行 JOIN jst_comboProductItem 展开为子件x数量
3) jst_qmcust_orderlist 普通行(排除拆单父单 Split/Question)
4) qmcust 组合装行同样展开
均按 send_date 窗口，仓库过滤不变。等级/日销/分摊销量随数据源自动重算。
 2026-10-14 11:05:13 +08:00
134
fa0e604bf8 fix: 排除拣选位报表中的箱记录 2026-10-12 14:31:45 +08:00
youruo
99fa402092 feat: 拣选库位动销分析固定只统计拣选位，移除仓位类型切换 
- 取数固定只取拣选位：bin CTE 直接过滤 bin_group 为空（更早过滤，存货位不再进入后续 CTE）
  移除可变的 binType IN 过滤与 resolveBinTypes，binType 字段恒为拣选
- 接口 payload 的 binTypes / binTypeOptions 固定为 ['拣选']；缓存键不再含类型
- 列表与导出移除「类型」列（全为拣选，冗余）；页面移除类型多选器、底部文案改为「统计范围：仅拣选位」
- 口径说明补充统计范围；Tooltip 同步

验证（基准日 2026-10-08、30 天）：
- 列表 11871 行 / 6821 个去重商品 / 库存 499141 / 去重商品销量 96847，明细类型集合仅为 ['拣选']
- 导出 11871 行，表头无「类型」列；分摊销量合计 96847 = 去重商品销量合计 96847（差异 -0.0017 浮点舍入）
- 旧参数 binType=存货 被忽略（仍返回拣选且命中同一缓存）；7 / 60 天窗口与单仓过滤均正常
- 单测 9/9 通过；后端语法检查 182 文件通过；前端 eslint 无报错、vite build 成功
 2026-10-08 13:09:49 +08:00
youruo
88a39975d3 feat: 动销等级改为按商品日销统计，列表与导出统一到仓位×商品粒度 
- 取数统一为 fetchPickingBinSkuRows：一行 = 一个「仓位 × 商品编码」，列表与导出共用
  商品日销 = 商品窗口整档销量 ÷ 天数（不做仓位分摊）；同一商品占几个仓位都是同一等级
  另输出分摊销量 = 商品销量 ÷ 占用同类型仓位数，供按行求和
- 列表页同步拆到商品粒度：新增商品编码列，去掉 SKU数列，搜索支持商品编码
- 汇总卡片主数值改为去重商品数，另显示明细行数；销量按去重商品口径统计
- 导出新增「分摊销量」「商品日销」列，表头口径标注更明确
- 性能：仓位类型选满时不拼 IN 过滤（避免参数嗅探走坏计划），全类型查询由超时降到约 30 秒

验证（基准日 2026-10-08、30 天、拣选位）：
- 明细 11871 行 / 去重商品 6821 个 / 库存合计 499141（与旧口径一致）
- 跨多仓位的 2028 个商品，销量与等级不一致 0 个
- 导出行求和：分摊销量合计 96847 = 去重商品销量合计 96847（差异 -0.0017，浮点舍入）
- 单测 9/9 通过；语法检查 182 文件通过；前端 eslint 无报错、vite build 成功
 2026-10-08 10:58:17 +08:00
youruo
31f184edd0 feat: 拣选库位动销分析导出增加商品编码，按仓位×商品编码拆行 
- 新增 fetchPickingBinSkuRows：仓位 × 商品编码 粒度明细
  库存数量 = 该商品在此仓位的实际库存；销量 = 商品销量 ÷ 其占用同类仓位数（贡献）
- 导出列：仓库 / 仓位 / 类型 / 商品编码 / 库存数量 / SKU数 / 销量 / 日销 / 动销等级 / 统计天数 / 统计基准日
- SKU数、动销等级仍为仓位粒度（同一仓位多行重复），列表页口径不变（仍用 bin 级聚合）
- 同一次取数比对：7055 个仓位，列表与导出库存/销量 0 处差异，库存合计一致 497721
- 单测 11 条通过
 2026-10-08 09:35:26 +08:00
youruo
817cc74a40 feat: 拣选库位动销分析默认按近 30 天销量划分等级 
- 默认统计窗口 15 天 -> 30 天（后端 PICKING_BIN_DEFAULT_DAYS 与前端常量同步）
- 可切换窗口补充近 60 天（7 / 15 / 30 / 60）
- 等级阈值不变：爆款≥20 / 热卖 10-20 / 平销 3-10 / 滞销-1 1-3 / 滞销-2 (0,1) / 销售=0
- 单测断言同步更新；实测 30 天窗口：7091 个拣选库位，日销=销量÷30
 2026-10-07 17:41:17 +08:00
youruo
70550b5499 feat: 新增二级页面「拣选库位动销分析」（大货库存监控） 
- 后端：pickingBinSalesAnalysis 配置/服务/路由，仓位库存取 rpt.jst_packInventoryInfo
  （bin_group 空值=拣选位、存货=存货位），销量按「SKU 占用同类仓位数平均分摊」，
  恒等式「全部库位销量之和 = 有库位 SKU 销量之和」差异为 0
- 动销等级（近 N 天日销，默认 15）：爆款>=20、热卖款 10-20、平销款 3-10、
  滞销款-1 1-3、滞销款-2 (0,1)、销售=0
- 前端：大货库存监控下新增二级菜单 + 页面（等级卡片、仓库/类型/天数/仓位筛选、
  分页表格、xlsx 导出），路由/菜单/页面权限四处注册
- 测试：后端 8 项单测通过；前端 lint/test/build 通过
 2026-10-07 16:59:39 +08:00
yanhui
a93691f5d8 fix: MKH-BOM 配件库存增加箱表兜底，修正「配件有货却判配件不足」 
根因
- 配件监控页取实时库存是三级兜底（inventoryInfo → 同仓箱表 packInventoryInfo
  → 监控快照 jsStock），而 MKH-BOM 的 loadComponentStock **只查 jst_inventoryInfo**，
  一级来源到底就结束。
- 上游 jst_inventoryInfo 存在滞后：2026-09-30 该行停在 09-28 14:51 的值 0，
  而 jst_packInventoryInfo 当日 10:30 已记 bin=ZT-30 qty=200。
- 结果：同一个仓（15718196）、同一个配件，配件监控页显示 200（判「正常」），
  MKH-BOM 判「配件不足」、可组装数 0。
  案例 MKHDNZ0409260600849 的配件 DNZ040947N1440V01（瓶颈唯一）。

改动
- backend/src/services/mkhBomService.js
  · loadComponentStock()：一条语句同时取两张表（UNION ALL + src 标记），
    库存表有正库存以它为准；为 0 / 缺行时用同仓 jst_packInventoryInfo 的
    bin 非空行合计兜底。**只补 0、不覆盖正库存**，与配件监控页
    buildRealtimeStockSql 同口径；查询失败仍整体 degraded（不做判定）。
  · 文件头 ⑪：修正「不能用 jst_packInventoryInfo 当配件库存 —— 与 MKH 配件
    零交集」这条结论 —— 它是 09-17 的表状态（当时该表 bin 全空），
    09-18 上游整表重建后已失效。
  · 文件头 ⑤：同理修正该表的关联列与数据现状结论。PR #22 的提交信息声称
    已更新 ⑤，但实际 diff 未改，此处补齐（该表 wms_co_id 关联、目标仓
    727/794 命中、配件仓 743 个 SKU 有箱记录）。
- backend/test/mkhBomService.test.js
  · 新增 3 个用例：箱表兜底生效且不覆盖正库存 / SQL 形状防腐化（两张表 +
    bin 非空 + 限定仓）/ 查询失败仍降级不做判定。
    对照组已验证：在修复前的实现上前两个用例失败（expected 200、actual 0）。

影响与验证
- 仅影响 MKH-BOM 的「配件不足」标记与可组装数；不改预警级别、排序与预警总数。
- 同一数据快照下的新旧口径对照（监控日 2026-09-29）：
  配件不足 26 → 24（2 行翻盘）、预警总数 29、缺货 23 两边一致，
  0 行反向变化、0 处其他字段变化、0 处级别变化。
- 真库实测：DNZ040947N1440V01 0 → 200、DNZ040959N1440V01 0 → 200；
  库存表本就有正数的对照配件（60 / 87）未被箱表覆盖。
- 负载（SET STATISTICS IO，300 编码一个分片）：jst_inventoryInfo 4543 逻辑读 +
  jst_packInventoryInfo 947 逻辑读，物理读 0、Worktable 0；实测中位耗时
  215ms → 391ms（+176ms/分片，配件全集 784 个约 3 个分片，占冷查 61s 的 1% 以内，
  且结果按编码缓存 10 分钟）。
  说明：SHOWPLAN 权限被拒（账号无该权限），改用 STATISTICS IO + 实测耗时 + 数据量
  作为执行计划等价证据。
- 数据量边界：配件仓 jst_inventoryInfo 837 行、jst_packInventoryInfo 1163 行
  （bin 非空 1024 行）。
- 后端：check-syntax 179 文件通过；node --test 393 项 392 通过
  （唯一失败为既有环境问题 resilientSecretStore 权限断言，与本改动无关）。
 2026-09-30 17:43:30 +08:00
youruo
2745cf18ff feat: 库存动销分析「销售=0」导出按仓位拆行，库存数量按实际仓位统计 
上一版把同一 SKU 的多个仓位用「、」拼在一格里，库存数量仍是 SKU 总量，
无法直接按仓位盘点。现改为每个仓位独立一行：

- bin CTE 改为按 (wms_co_id, sku_id, LTRIM(RTRIM(bin))) 分组，
  SUM(qty) 得到仓位级库存（各仓位行之和 = SKU 总库存，实测 240=60+69+35+76）
- 导出行 = graded（SKU 级「销售=0」判定）LEFT JOIN 仓位级明细：
  有仓位数据的 SKU 按仓位展开多行、库存数量取该仓位实际 qty（qty=0 的仓位行剔除）；
  仓位表未覆盖的 SKU 保留一行（仓位为空、库存取总库存），不丢数据
- 排序：仓库 → SKU 总库存倒序 → SKU → 仓位名称，同一 SKU 的各行保持相邻
- 前端按钮提示同步更新拆行与兜底规则说明

验证：后端 syntax 通过、单测 9/9（全量 389/390，唯一失败为既有 Windows 环境项）；
前端 eslint/build 通过；
本地实测：单仓（睢宁 196 行，原 128 SKU 行）样例 SKU 正确拆为 4 行且合计 240；
全仓导出 6798 行（原 3650），有仓位行 6529、仓位为空兜底行 269，覆盖 26 仓
 2026-09-28 09:55:45 +08:00
youruo
fc280bfe27 feat: 库存动销分析「销售=0」导出增加系统仓位列 
仓位用于定位滞销库存的实际存放位置，便于盘点与挪位处理。
数据源为 rpt.jst_packInventoryInfo.bin（jst_sku.bin 全部为空、库存表无仓位字段，
这是业务库唯一可得的系统仓位）：
- 按 (wms_co_id, sku_id) 聚合，LTRIM 去空格后 DISTINCT，STRING_AGG 按名称排序用「、」连接
- 排除无仓位（bin 为空）与零库存（qty=0）的行，避免无效仓位干扰
- LEFT JOIN 且按「仓库+SKU」双条件匹配，避免跨仓错配
- 导出列顺序：仓库 | SKU编码 | SKU名称 | 系统仓位 | 库存数量 | 销量 | 统计天数 | 统计基准日
- 前端按钮提示同步说明多仓位拼接规则与留空含义

验证：后端 syntax 通过、单测 9/9（全量 389/390，唯一失败为既有 Windows 权限环境项）；
前端 eslint/build/测试均通过；
本地实测导出 3650 行，系统仓位列就位，3381 行有仓位（92.6%，未覆盖的 7.4% 为
仓位表仅含 13 个仓库所致），销量列全为 0，最长仓位串 600 字符（Excel 上限内）；
浏览器实测点击下载，文件名与列结构正确
 2026-09-28 09:34:55 +08:00
youruo
2c8ed86c26 feat: 库存动销分析「销售=0」档支持导出 SKU 明细 
- 后端新增 GET /api/stock-sales-analysis/zero-sales-export：
  复用与页面完全一致的分档口径（同一段 gradeCase 表达式 + 「有库存或有销量」过滤），
  输出仓库/SKU编码/SKU名称/库存数量/销量/统计天数/统计基准日的 SKU 级明细；
  支持.days 统计窗口、wmsCoId 逗号分隔过滤（仅允许仓库清单内的 ID，防任意拼参）、
  format=xlsx|csv，复用通用导出服务 exportWorkbook
- services 新增 fetchZeroSaleSkuRows：SKU 级「销售=0」查询，LEFT JOIN rpt.jst_sku 取名称，
  按仓库+库存倒序排列
- 前端工具栏新增「导出销售=0」按钮：跟随当前统计天数与仓库筛选，
  文件名含业务日期与仓库范围，失败时解出错误体给出可读提示
- 测试补充 3 条：防呆抛错、空参短路、SQL 口径与参数传递断言

验证：后端 syntax 通过、单测 8/8（全量 389 条仅既有 Windows 环境项失败）；
前端 eslint/build/test 21/21 通过；
本地实测：全仓导出 3641 行、26 仓、销量列全为 0；
单仓（崔桥半成品包装 694 行）与页面「销售=0」SKU 数一致；
浏览器实测点击下载真实文件名「库存动销分析-销售0明细-20260926.xlsx」
 2026-09-27 17:47:45 +08:00
youruo
f20bd3a487 feat: 侧边栏新增二级「库存动销分析」页面 
按《仓库库存动销分析.xlsx》：
- 一级菜单「大货库存监控」下新增二级「库存动销分析」（路由 /planning/operation/stock-sales-analysis）
- 表头与表格结构按需求表：仓库 | 动销等级 | SKU数量 | SKU占比 | 库存数量 | 库存占比 | 销量，
  每仓 6 个动销等级（爆款/热卖款/平销款/滞销款-1/滞销款-2/销售=0）+ 1 行汇总，仓库列跨行合并
- 分档口径：日销 = 统计窗口内已发货件数 ÷ 窗口天数（7/14/30 天可选，默认 30），
  库存取 rpt.jst_inventoryInfo 实时库存，销量取 jst_Orders×jst_OrderItem 按 send_date
  （排除 Delete/Cancelled，与每日进销存发货口径一致），只统计有库存或有销量的 SKU
- 后端 /api/stock-sales-analysis：单条 SQL 一次覆盖全部仓库×等级，5 分钟缓存 + refresh=1 强制重算；
  返回逐仓 + 全仓合计、占比、无数据仓数量
- 前端页面：统计天数/仓库筛选、口径说明弹窗、合计行高亮、无数据仓计数提示
- 页面权限：前后端 sidebarPages 注册 pageKey=stock_sales_analysis，默认 planning 角色可见

验证：后端 syntax + 单测 5/5；前端 eslint、build、npm test 21/21；
本地接口 30 天窗口实测 27 仓（崔桥汇总 2080 SKU / 90822 件 / 54076 件销量），
占比逐仓闭合为 100%；浏览器实测侧边栏入口、表头、197 行渲染与截图均正常
 2026-09-27 16:29:58 +08:00
youruo
117d59c9f0 fix: 每日进销存截图按业务日期归档并补充幂等/执行记录测试 
定时任务在凌晨 01:00 推送的是「昨日」数据，但截图对象键原先直接取执行时刻的北京日期，
导致归档目录与通知里的业务日期不一致（daily-inventory/2026-09-26/... 装的是 09-25 的数据）。
现改为由定时任务显式传入业务日期，目录与文件名统一用业务日期、时间仍用执行时刻：
  daily-inventory/2026-09-25/daily-inventory-20260925-010000.png

另补充验收要求 8 的测试：
  · buildScreenshotNames 归档命名（含业务日期与执行日期不同的场景）
  · markNotified / hasNotified 幂等：同业务日同用户只成功一次，跨日期互不影响
  · appendRunRecord 保留执行时间、截图地址、通知对象与失败原因
 2026-09-27 14:53:05 +08:00
youruo
0e77a70c33 feat: 每日进销存支持导入聚水潭官方进销存校正数据 
业务库只能还原 4/12 个流水列且口径与聚水潭不一致（采购按单据日期、销售按订单发货日期，
jst_salesOutboundInfo.qty 全为 0），调拨/盘点/加工/其它出入库无单据表，故以官方导出为准：

- 新增本地表 daily_inventory_official（biz_date + warehouse 存期初/12 流水列/期末）
- 新增解析与导入服务：xlsx 解析、仓库 ID 映射、「期初+流水=期末」恒等式校验
- GET /api/daily-inventory 支持 ?date= 指定业务日，官方值优先、缺失回退推算并返回来源标记
- 新增 POST /api/daily-inventory/official-import（xlsx 上传/JSON）与 GET /official 查询
- 导入后回写本地库存快照（官方期初→上一日期末、官方期末→当日期末），使推算也对齐
- 前端：业务日切换、官方/推算来源标记、导入弹窗、口径说明同步更新
- 仓库清单补入「简尚-横林三仓主仓」（聚水潭导出中存在）
- 命令行导入：npm run inventory:import-official -- <日期> <xlsx>
 2026-09-27 14:16:06 +08:00
youruo
c47a25b002 fix: 期初兜底弃用 pm_stockMonitor，全部改用实时库存扣流水回推 
口径校准（对照聚水潭进销存导出 09-23 期初基准）：
  崔桥工厂仓 基准 92388 / pm 路径 114286 / 回推 ≈89650
  横林二仓   基准 63780 / pm 路径  1197  / 回推 ≈64029
  山东青岗集 基准 88377 / pm 路径  67339 / 回推 ≈88210
  河南洛宁   基准 83305 / pm 路径  76992 / 回推 ≈82473

pm_stockMonitor.jsStock 只覆盖纳入监控范围的 SKU 子集（横林二仓实测
1197 vs 全仓 63780），系统性偏低，不能充当全仓结存；「实时库存扣
流水回推」与基准偏差 0.3%~2.7%（来自缺失的 8 类单据），显著更准。
 2026-09-27 10:09:19 +08:00
youruo
952c57a84a fix: 修复流水取数漏传 cloudDb 导致流水列静默为空 
路由调用 fetchFlows(wmsCoIds, from) 少了第一个参数 cloudDb，
导致形参错位（cloudDb=数组、wmsCoIds=日期、fromText=undefined），
函数静默返回空 Map 且无任何报错。补传参数，并为 fetchFlows 增加
防呆校验：首参非数据库实例时立即抛 TypeError。补 1 项回归测试。
 2026-09-27 10:03:24 +08:00
youruo
c358aff781 feat: 每日进销存补充流水与期初数据，修复合计行 NaN 
数据补充（全部来自数据库，无人工填数）：
- 流水列接入 4/12：采购进仓（jst_purchase×Item，po_date，Confirmed/Finished）、
  采购退货（jst_purchaseout×Item，io_date）、销售出仓（jst_Orders×OrderItem，send_date，
  与周转率发货口径一致）、销售退货（jst_returnAndRefund×Item，as_date，实收 r_qty）。
  其余 8 列业务库确无单据表（已核实全库表清单），保持「—」待 DBA 建表
- 期初快照缺失时自动兜底：优先用 rpt.pm_stockMonitor（报表库 01:00 跑批 T-1 库存，
  按 dbWarehouse 聚合 jsStock，精确）；监控表没有的虚拟仓（运营专用/京东仓）用
  实时库存扣自期初时刻以来的带符号流水回推（近似），推导结果补写快照逐日滚动

缺陷修复：
- 合计行仓库名显示 NaN：isTotal 渲染分支拦截了所有列，'合计' 被强转数字；
  现仓库名原样显示，无数据来源的流水列合计也显示「—」而非误导性 0
- 合计行：某列全部仓库均无数据时合计置空，避免 0 误读

新增 4 项单元测试（流水符号约定、参数展开、期初双路径推导）。
 2026-09-27 09:54:59 +08:00
youruo
f205cb9322 fix: 截图服务改用系统库专用服务账号身份 
页面启动会调用 /api/auth/verify，该接口要求令牌 sub 必须是系统库 users 表中真实且 active
的用户。原实现签发的是一个不存在于用户表的合成身份，verify 返回 401，前端清除令牌并跳转
登录页，截图因此永远拿不到数据（等待数据行 3 分钟超时）。

改为在系统库维护一个仅供服务端使用的专用账号：
  · 账号不存在时按 role=admin、status=active、auth_source=service 创建
  · 密码哈希为随机值且无人知晓，账号无法通过密码登录
  · 已存在时复用 id，并仅对 auth_source=service 的本服务账号补齐管理员与启用状态
  · 令牌 sub 使用该账号 id，15 分钟过期，仍只注入 localStorage
  · 账号 id 进程内缓存，删除该行即可回收权限

新增 2 项单元测试：账号创建/复用与令牌 sub 校验。
 2026-09-27 09:24:39 +08:00
youruo
3bfc48b8b3 Merge branch 'codex/daily-inventory-snapshot-0924' into codex/daily-inventory-notify-0924 
冲突文件：backend/src/index.js
处理理由：采用已解决好与他人 PR #40/#41 冲突的分支 A 版本，再补回本分支的通知接口
require、/api/daily-inventory-notification 路由注册与调度器启动，双方行为均保留。
 2026-09-26 12:18:11 +08:00
134
345214daed fix: force live refresh on MKH sync 2026-09-24 14:49:08 +08:00
134
ea312d9070 fix: force fresh MKH operational data 2026-09-24 13:30:09 +08:00
youruo
3af6bd9ef2 Merge branch 'codex/daily-inventory-snapshot-0924' into codex/daily-inventory-notify-0924 2026-09-24 12:00:26 +08:00
youruo
c4ea12e9ba fix: 修正截图站点地址与通知正文链接，生产镜像补充 Chromium 与中文字体 
- 截图默认站点改为生产主站 ck.yydd.ai（原默认值指向无关域名）
- 通知正文补充「页面地址」，便于在通知中心直接打开
- 服务身份增加 daily_inventory 页面权限声明
- Dockerfile 安装 Chromium 与 fonts-noto-cjk，否则容器内无法截图且中文显示为方块
 2026-09-24 11:59:36 +08:00
youruo
56fba389e4 feat: 每日进销存增加定时截图通知 
设置（仅管理员）
- 可配置是否启用、通知时间（默认 01:00 Asia/Shanghai）、多名通知用户
- 收件人在后端规范化：去空、去重、限长限量，配置持久化到 system_config
- 接口不返回通知中心密钥与对象存储密钥，只给是否已配置与脱敏预览

定时任务
- 单实例锁（MySQL GET_LOCK），按配置时间触发，命中后 30 分钟内失败最多补跑 3 次
- 服务端签发 15 分钟短时效 JWT 作为专用身份，令牌只写入浏览器 localStorage
- 等数据真正渲染完成（有数据行、无加载中、无错误提示）才截图，展开滚动容器后整页截图
- 对象键形如 daily-inventory/2026-09-25/daily-inventory-20260925-010000.png
- 截图上传成功后才逐用户发通知，单人失败不影响他人；正式推送按「业务日期+收件人」幂等
- 立即测试走同一链路但幂等键带随机数，不影响次日正式推送
- 每次执行记录时间、截图地址、通知对象、成功状态与失败原因

测试
- 覆盖收件人去重、通知时间校验、幂等键、业务日期与对象键、重试退避（17 项）
 2026-09-24 11:22:51 +08:00
134
4227d9001e fix: reconcile MKH received stock and work orders 2026-09-24 09:19:21 +08:00
134
b8e60a19d2 fix: MKH刷新改用实时订单库存口径 2026-09-23 11:12:08 +08:00
yanhui
97a93766e8 Merge pull request 'fix: MKH-BOM 配件仓位仓名改用 wms_co_id 关联，修正误显示「常州简尚家居有限公司」' (#22) from codex/mkh-pack-warehouse-join-0919 into main 2026-09-22 23:58:40 +08:00
yanhui
f4303c0aed Merge pull request 'fix: 隧道断线自愈 + 修复配置负缓存永久固化（根治「隧道一断即整栈不可用 / 必须重启后端」）' (#21) from codex/tunnel-selfheal-config-cache-0922 into main 2026-09-22 23:58:24 +08:00
yanhui
a58fc7d67b Merge pull request 'fix: MKH-BOM 修复在途旧查询回写缓存，导致「同步最新数据」点完仍是旧数据' (#20) from codex/mkh-cache-stale-write-fix-0922 into main 2026-09-22 23:58:04 +08:00
yanhui
38fa3f2127 fix: 隧道断线自愈 + 修复配置负缓存永久固化 
远端 RST 会把隧道反复踢掉（09-20 实测当天断 5 次，每次存活 15~25 分钟）。原先的
实现把「一次网络抖动」放大成「整个开发栈不可用」，根因有两处，本次一并修掉。

1) scripts/start-remote.mjs —— 隧道断了却拉着应用陪葬

   隧道进程 exit 时直接 stopChildren()，把后端和前端一起杀掉，于是每一次 RST 都
   升级成一次「网站打不开」，还得靠外部守护清残留、整树重启才能恢复。

   改为「退避重连隧道本身，后端/前端进程不受影响」——这正是 autossh 的语义
   （autossh 只负责重启 ssh，从不牵连被它服务的应用）。建立失败走 1s→30s 指数
   退避，建立成功即重置退避。

   顺带补齐保活参数：TCPKeepAlive=yes、ConnectTimeout=10，探活间隔 30s → 15s，
   以便更快发现已被对端 RST 的死连接。

2) backend/src/config/cloudDatabase.js —— 配置负缓存被永久固化

   系统库读取失败时把「空候选」写进缓存，而入口判断是
   `if (cachedCloudConfigCandidates)` —— [] 在 JS 里是 truthy，于是这次失败被
   永久固化：之后永不重试，直接抛「业务数据库尚未配置」500，隧道恢复了也没用，
   必须重启后端。

   改为「带 TTL 的负缓存」（默认 30s，可用 CLOUD_DB_CONFIG_NEGATIVE_TTL_MS 调整）：
   入口用 `!== null` 判断，失败态到期自动重新解析，使隧道恢复后无需人工干预。
   缓存清理收敛到 invalidateCloudConfigCache() 单点，避免日后只清数组、忘了清
   TTL 时间戳而退化回「永不过期」。同时让「测试连接」入口显式失效，保证用户改完
   配置点测试能立即看到真实结果。

   顺带把请求超时默认值 600000ms → 60000ms：10 分钟 × maxAttempts=2 最坏挂
   20 分钟，用户体感就是「卡死」；冷查实测 16~42s，60s 仍有充足余量。

验证：
- 新增 backend/test/cloudDatabaseConfigCache.test.js，锁定负缓存三段语义
  （TTL 内不重复解析 / 到期必须重试 / 上游恢复后自动复原且成功态不被 TTL 淘汰）；
  test/remote-access.test.mjs 补隧道保活参数、退避曲线，以及「自愈循环不得调用
  stopChildren」的防腐化断言。
- 两处均做对照组实验：去掉保护后测试如实报错（负缓存 → 报 TTL 到期未重试；
  隧道 → 把 stopChildren 加回去即被用例抓住），证明用例真能拦住回归。
- 后端全量 340 项 / 339 通过，唯一失败为 resilientSecretStore 的 Windows 权限
  断言（环境固有，与本次无关）；check-syntax 通过。
- 本地实测：kill 掉隧道进程后 1 秒内自动重建（PID 36268 → 15816），后端进程
  PID 未变（29580）、/health 仍返回 200。
 2026-09-22 19:32:40 +08:00
yanhui
add148192d fix: MKH-BOM 修复在途旧查询回写缓存，导致「同步最新数据」点完仍是旧数据 
问题：点「同步最新数据」后，页面在 2~10 分钟内仍显示旧数据，用户表现为「像在用缓存」。

根因：本页 10 个进程内缓存都是「先挂 pending → await 结果 → 无条件写回」的写法。
若某个查询 in-flight 期间用户点了同步（clearMkhBomCache 清空全部缓存），那个**发起于
清缓存之前**的查询读到的仍是旧快照，返回时会无条件把旧值写回缓存，覆盖掉清缓存后新
请求填入的新值 —— 谁后完成谁生效。并发越高（多人同时使用、或先点刷新再点同步）越容
易撞上，且清缓存反而把旧数据「钉」在缓存里 2~10 分钟（各缓存 TTL），表现为按钮失灵。

修法：引入缓存代际 cacheEpoch。
- clearMkhBomCache() 先自增代际，再清各缓存；
- 每个查询发起时记下当时的代际，写回缓存前比对：代际对不上说明中途被清过缓存，
  本次结果只返回给发起它的那个请求，不写缓存。
覆盖 7 个变量型缓存（officialBomIndex / businessBom / productBom / mkhProduct /
workOrderIndex / orderIndex / replenishIndex）与 3 个按 key 的 Map 缓存
（officialBomDetail / componentLocation / componentStock）。
POST /api/mkh-bom/sync 响应新增 cacheEpoch 字段，便于线上核对清缓存是否生效。

验证：
- 新增 2 个用例：① 复现竞态——对照组（去掉写回保护）报 expected 1 / actual 9，正是
  「点同步后拿到旧值」；加保护后通过。② 同代际内缓存照常命中的回归保护。
- 后端全量 node --test test/*.test.js：340 用例 / 339 通过，唯一失败为环境固有的
  resilientSecretStore Windows 权限断言（与基线一致）。
- 本地端到端：预热 24.3s → 缓存 58ms；sync 返回 cacheEpoch=1；冷查 8.5s 确实重查；
  再查 37ms 缓存重新生效；数据指纹前后一致。
 2026-09-22 18:39:09 +08:00
yanhui
5e029f831f fix: MKH-BOM 库存增加箱表兜底，修复「当日入库当天显示库存为 0」 
现象：MKHDNZ0409260700491 当天已入库、实物有货，但页面上「现有库存」一直是 0；
点「同步最新数据」也不变。

根因：页面唯一的库存源 rpt.jst_inventoryInfo 是「有变化才写 updateTime」的同步表，
品牌仓尤其稀疏。该 SKU 在 inventoryInfo 里只有主仓 14138566 的一行 qty=0，
品牌仓连行都没有；而小时级的箱表 rpt.jst_packInventoryInfo 里，
品牌仓 bin='P-1' / qty=4 / createTime 当天 15:19 —— 当日入库的货只有箱表看得见。
页面取不到实时值 → 回退 09-18 监控快照 jsStock=0 → 显示 0。
「同步最新数据」按钮只清服务端缓存，不触发上游同步，所以点多少次都是 0。

改法（只补 0，不覆盖有效值）：
  ① inventoryInfo 品牌仓 qty > 0        → 用它（stockSource='realtime'，旧口径不变）
  ② 否则箱表品牌仓 bin 非空行合计 > 0    → 用它（stockSource='pack'）
  ③ 否则 inventoryInfo 有品牌仓行(qty≤0) → 用 0
  ④ 否则回退监控快照 jsStock             → stockSource='monitor'

为什么不拿箱表当主源：两表都 > 0 且不等的 28 个成品里 25 个是 inventoryInfo 更大
（箱表只记已装箱的货，散货不计），拿它当主源会系统性低估库存、误报缺货。
另外必须过滤 bin 为空的行——那是装箱记录不是库存（品牌仓合计 21 件）。

影响面（实测）：品牌仓 4,408 个成品里只有 3 个走箱表兜底
（MKHDNZ0409260601548=5 / MKHDNZ0409260700059=4 / MKHDNZ0409260700491=4，
同一箱 115870495000001201、货位 P-1、均为当天新建行），
预警列表 27 → 24 条（缺货 21 → 18），少的正是这 3 条「入库当天被误判缺货」。

前端：「现有库存」列 tooltip 增加 pack 来源说明（当天入库、实时库存表尚未同步）。

验证：check-syntax 151 文件通过；node --test 339/340（唯一失败是既有的
resilientSecretStore Windows 权限断言）；mkhBomService.test.js 47/47；
HTTP 实测该 SKU stock=4 / stockSource=pack，点「同步最新数据」后仍正确。

遗留（需业务/上游跟进）：inventoryInfo 当天 06:41 后就没再更新过
（09-17 / 09-18 都是全天逐小时更新），疑似上游同步任务异常；
箱表兜底只解决「当日入库看不见」，存量库存仍依赖该表恢复。
 2026-09-19 18:11:38 +08:00
yanhui
0e0fcbb378 fix: MKH-BOM 日销兜底增加出库校验，标了「已发货」但无实际出库的单不计销量 
业务口径：标了「已发货」但没有实际出库的 SKU，不需要出现缺货预警。
即在 ⑦-a 的金额/标签判据之上，再以出库表为准判定「有没有真出货」。

已发货分支计入销量需同时满足（待发货分支不变）：
  1. 非样品/测试店铺（⑦-a）
  2. 非异常单：pay_amount <= 0.01 或 labels 含「特殊单」（⑦-a）
  3. 出库表能查到该 o_id：rpt.jst_salesOutboundInfo / rpt.jst_qmcust_salesoutbound

两个必须豁免的情形（否则会大面积误杀真实单）：
  · 拆分单（status='Split'）：出库记录挂在子单上，父单必然查不到。
    实测窗口内 40 张 Split 单 100% 无出库记录；不豁免会误杀
    「京东-HX旗舰店104 09-19 实付 1194.14 元」这类真实单
  · 今天发货的单：当天出库尚未同步完（09-19 全天出库表仅 1 行，09-18 有 14,690 行）。
    豁免只到「昨天」为止——09-18 的 18 张无出库 Sent 单 100% 是特殊单，
    且出库表 09-18 数据完整，豁免 09-18 会放过刷单
  豁免只免「出库校验」，金额/标签判据照样生效。

真实数据验收（近 15 天窗口，1,086 张已发货 MKH 单）：
  · 出库表命中 889 张 → 197 张无出库 = 40 张拆分单 + 157 张 Sent
  · 157 张里 131 张是 ≤0.01 元或「特殊单」（即 ⑦-a 已排除的刷单），
    唯一 1 张正常金额的是 09-05 的 388 元单（标签「发货后取消/发货后售后/风控订单」）
  · 兜底生效 SKU = 12 个（与只按金额/标签判据一致），兜底日销最大值 = 0.2
  · 10 个异常单 SKU 在预警列表中零出现；总预警 27 条（缺货 21 + 仅预警 6）

性能：1086 个订单号分 2 块并行 UNION 查询，冷缓存约 0.4~1.4s；
      整窗口拉全量 DISTINCT o_id 实测要 8s，故不采用。

降级策略：出库数据取不到时整体跳过出库校验（退化成只按金额/标签判据）并标 degraded。
漏杀只是多报一条预警，错杀会让真实缺货彻底隐身。

注意：jst_salesOutboundInfo.qty 全表 1,119,606 行恒为 0，只能判「有没有出库行」，
不能用 SUM(qty)（永远得 0）。

验证：check-syntax 151 文件通过；node --test 338/339（唯一失败是既有的
resilientSecretStore Windows 权限断言，与本改动无关）；mkhBomService.test.js 45/45。
 2026-09-19 17:53:16 +08:00
yanhui
da08b03dcb fix: MKH-BOM 配件仓位仓名改用 wms_co_id 关联，修正误显示「常州简尚家居有限公司」 
根因
- rpt.jst_packInventoryInfo.wh_id **不是** rpt.jst_warehouseInfo.Id：
  全表只有 6 个取值（1/2/3/4/6/7），90% 的行都是 wh_id=1，
  按 `w.Id = p.wh_id` 关联后，727 个配件的仓位仓名被统一显示成「常州简尚家居有限公司」。
- 该表的仓 id 列是自带的 `wms_co_id`：
  09-19 实测 30,236 行 **0 NULL**、14 个仓取值，按 `w.wms_co_id = p.wms_co_id`
  关联即得到正确仓名「简尚-崔桥工厂半成品包装项目仓」。
- 旧结论「该表 wms_co_id 全表 NULL，必须用 wh_id」只对 09-17 的表状态成立
  （当时 85,152 行、只有 3 个箱、bin 全空、与 MKH 配件零交集）；
  该表由上游**小时级增量刷新**（业务确认 09-19），09-18 重建后 wms_co_id 已全部有值。

改动
- backend/src/services/mkhBomService.js
  · loadComponentLocations() 的 JOIN 与 GROUP BY：p.wh_id → p.wms_co_id
  · 文件头 ⑤ 与 formatPackLocation() 注释更新为正确关联列，并记录该表的小时级
    增量刷新特性（行级 updateTime 只反映「有变化的行」，不能当表的更新频率；
    行数/箱数/命中数会随上游变化，不要写死）。
- backend/src/services/modularStockMonitorService.js
  · 补注：该页只取 bin、不 join 仓名，不受此关联列问题影响；命中数会随上游变化。
- backend/test/mkhBomService.test.js
  · 仓位格式化用例的 fixture 改回真实仓名，避免继续固化错误仓名。

影响与验证
- 仅影响 MKH-BOM 页「配件仓位」列与导出配件明细的仓名文本；
  A4 打印预览本就会去掉仓名前缀（stripWarehousePrefix），不受影响。
- 配件监控页不 join 仓名，无影响。
- 实测：修正后 15 个真实配件编码输出「简尚-崔桥工厂半成品包装项目仓 · BCP01-01-1」。
- 后端：check-syntax 151 文件通过；node --test 337/338 通过
  （唯一失败为既有环境问题 resilientSecretStore 权限断言，与本改动无关）。
 2026-09-19 17:08:00 +08:00
yanhui
dff2422b34 fix: MKH-BOM 日销兜底排除 0.01 元特殊单，修复「没发过货却有日销」 
背景
- 业务反馈 MKHDNZ0410260700005 从没发过货，页面却显示日销 0.6 并报缺货。
- 根因是上一版日销兜底（⑦-a）只看 send_date，把「0.01 元特殊单」当成了真实销售：
  · 拼多多-亿家达书房家具官方旗舰店在 2026-09-18 10:35–10:36 **一分钟内**批量生成
    18 张 MKH 订单，实付合计仅 0.18 元、免额合计 16,344 元（单张：实付 0.01 元、
    商品额 908.01、免额 908 全额免），备注统一为 SSDD，标签含「特殊单」「转x00005」；
    同批还有 18 张商品码为占位码 1.X00005 的 0.01 元订单。
  · 这批单 status=Sent、有物流单号，但 **rpt.jst_salesOutboundInfo 里查不到对应出库记录**
    （同店同时段其他订单有 6,467 行出库）—— 即系统标了「已发货」，货并没有真出。
  · 后果：把 10 个 SKU 的日销从 0 抬到 0.6~1.8（共 162 件），凭空产出缺货预警。

改动
- loadOrderIndex 的**已发货分支**增加异常单过滤：命中任一即不计入日销
  · pay_amount <= 0.01（0.01 元全免单）
  · labels 含「特殊单」
- 查询补充取出 o.pay_amount / o.labels（两张订单表均有这两列，已确认）。
- 金额取不到（null / 空串 / 非数字）时**不排除** —— 宁可少排也别误杀，取不到就退化成旧口径。
- ⚠️ **不使用 free_amount > 0 作为判据**：正常订单普遍带折扣免额（窗口内实测 569/1086 行
  free_amount > 0），按它筛会把实付 356 / 458 / 1338 元的正常单一并误杀（第一版即踩此坑）。
- 本次只作用于「已发货」分支，待发货（⑩）口径未改动。

验证
- 语法检查：151 文件通过。
- 后端测试：338 项 337 通过。唯一失败为 resilientSecretStore 权限断言（期望 0o600、
  Windows 实际 0o666），平台固有，与本改动无关。mkhBomService 单测 44/44。
- 新增回归断言：实付 0.01 / 0 元及字符串金额判为异常单；标签含「特殊单」判为异常单；
  **有免额的正常单不得被排除**；金额缺省/为 null/非数字时不排除。
- 订单索引用例补充：0.01 元单与「特殊单」标签行不进入 shippedBySku，而带折扣免额的
  正常单照常计入（shippedBySku.size 由 1 调整为 2）。
- 真实数据端到端（业务库实时，窗口 15 天）：
  · 应排除的 10 个异常单 SKU（MKHDNZ0410260700001/0002/0004/0005/0007/0008/0009/
    0010/0011/0012）**全部已排除**；
  · 应保留的 12 个真实单 SKU **全部保留**（含本问题之外的 MKHDNZ0409260601548 等）；
  · 兜底生效 SKU 由 **22 → 12**；兜底日销最大值由 **1.8000 → 0.2000**
    （0.2 来自 MKHDNZ0409260700483 的 3 件真实发货，属正常）。

风险与回退
- 只影响「快照日销 ≤ 0 且近 15 天有发货」的商品；快照 > 0 的商品行为完全不变。
- 实付 ≤ 0.01 元的订单在任何业务口径下都不构成正常销售，排除不会误伤真实需求。
- 回退：本提交可整体 revert，无表结构变更、无数据迁移。
- 遗留（未在本次改动内）：待发货（⑩）分支同样可能被 0.01 元单驱动，
  是否一并排除需业务确认；「售后 / 补发」类订单是否计入亦有待定夺。
 2026-09-19 14:49:39 +08:00
yanhui
3e64702f12 fix: MKH-BOM 新增日销订单表兜底，修复上游快照漏算导致「库存 0 却不报缺货」 
背景
- 业务反馈 MKHDNZ0409260601548 近 15 天实发 2 件、库存 0，页面既不报缺货也不进任何预警。
- 根因是双重盲区：
  ① 上游 rpt.pm_stockMonitor.fifteenAvgSale 漏算 —— 快照 09-18 下，窗口内有真实发货的
     178 个 MKH 成品编码里有 24 个被记成 0；其中 16 个订单全部来自样品专用店铺（上游同样
     不计样品单，属合理口径），剩 8 个是真实店铺（天猫/京东/拼多多）。该列是**保留两位
     小数的日均**（最小非零 0.07 = 1 件 ÷ 15 天），无法用四舍五入解释。
  ② 快照日销 = 0 且待发货订单 = 0 时，判定直接落到「无销量」分支、hasWarning=false，
     彻底排除在预警之外 —— 库存为 0 也救不回来。

改动
- 日销兜底（服务文件头新增 ⑦-a）：**快照日销 ≤ 0 且近 15 天有真实发货**时，日销改用
  订单表实算值 = 已发货件数 ÷ 15；快照 > 0 一律以上游为准，不覆盖，避免两套口径打架。
  · 排除样品/测试专用店铺（shop_name 含「样品」「测试」），与上游口径对齐
  · 窗口 = 含今天在内的 15 个自然日，与分母同口径
  · 结果透出 dailySaleSource('snapshot'|'orders') / snapshotDailySale / recentShippedQty
- 取数：loadPendingOrderIndex 重构为 loadOrderIndex，一条查询同时覆盖「待发货
  （send_date IS NULL）」与「近 15 天已发货（send_date 在窗口内）」。实测合并后总耗时
  约 1.25s ≈ 单查待发货，而拆成两条独立查询要在现有开销之上再加一次全表扫描
  （首轮冷执行计划下 qmcust 单表可劣化到 20s+）。
- PENDING_ORDER_TABLES 更名 ORDER_TABLES：两张表的口径没变，只是不再仅服务待发货。
- 前端：日销来自兜底时加虚线下划 + 悬停说明，业务拿该数字与源系统 fifteenAvgSale
  对照时不会被误判为数据错误。

验证
- 语法检查：151 文件通过。
- 后端测试：338 项 337 通过。唯一失败为 resilientSecretStore 的权限断言（期望 0o600、
  Windows 实际 0o666），平台固有，与本改动无关。
- 新增回归测试：兜底生效 / 快照非零不覆盖 / 无发货不兜底 / 与订单驱动的优先级 /
  订单源降级时退化成旧口径；订单索引测试补充「已发货同编码跨表累加」与「样品、测试店排除」断言。
- 真实数据端到端（本地接口 /api/mkh-bom/list，4,223 个成品）：
  · MKHDNZ0409260601548：日销 0 → 0.1333（source=orders），不再隐身
  · 日销 > 0 的商品 177 → 198；有效预警（缺货 + 预警）18 → 28
  · 21 个等级变化**全部是「无销量 → 缺货/正常/已排产」**，没有任何既有预警被降级
  · 其中 10 个新缺货均为「库存 0 + 近 15 天真实发货 9~27 件」的真盲区
  · 样品店排除按整行生效：实测某编码窗口内 5 件（含样品店 1 件）→ 索引记为 4 件
- 前端 eslint 通过、vite build 通过。

风险与回退
- 只影响「快照日销 = 0」的商品，快照 > 0 的商品行为完全不变。
- 订单源不可用时兜底自动失效，退化成旧口径（不会误报）。
- 回退：本提交可整体 revert，无表结构变更、无数据迁移。
 2026-09-19 13:24:15 +08:00
yanhui
f156b90dbb fix: MKH-BOM 待发货订单合并两张渠道表，修复天猫/淘宝订单漏报 
问题
  MKHDNZ0409260700059、MKHDNZ0409260601228 等成品明明有待发货订单，
  补货预警却显示 0 单、判为「不预警」，业务反馈到系统。

根因
  业务库的订单按渠道拆成**互不重叠的两张表**，而 loadPendingOrderIndex()
  只读了 rpt.jst_Orders（京东/京喜/拼多多/抖音/得物/唯品会），
  天猫 / 淘宝 / 1688 / 阿里巴巴渠道的待发货需求**全部被漏掉**。

实测（2026-09-19，近 30 天窗口）
  - 两表店铺名交集 0（jst_Orders 398 店 vs qmcust 78 店），so_id 交集 5 条，
    o_id 交集 **0 条** —— 合并无重复计件风险；
  - jst_Orders 里 `shop_name LIKE '%天猫%'` = **0 行**
    （不是命名差异：同一品牌在不同平台是不同店铺名，按品牌名反查会误判）；
  - MKH 成品待发货：仅 jst_Orders = 36 编码 / 50 件  →
    合并后 = **40 编码 / 56 件**，补回 4 个编码：
    MKHDNZ0409260700059 / MKHDNZ0409260601228 /
    MKHDNZ0409260601530 / MKHDNZ0409260700498。

修复
  - PENDING_ORDER_TABLE → PENDING_ORDER_TABLES（两张表，新增 qmcust 源）；
  - Promise.allSettled 并行读取，按 o_id 去重后合并（去重为防御性逻辑）；
  - 部分源失败时**保留成功源的数据**并透出 degraded=true，用短 TTL 尽快重试，
    不再像原先那样单源失败就整表降级为空索引（那会静默漏报全部需求）；
  - 口径范围：**渠道全并**（2026-09-19 业务确认），含 1688 / 阿里巴巴 /
    分销导单专用店铺。

测试
  - 新增 2 个回归测试：两张表都读到 + 跨表同 o_id 只计一次 + 组合装不计入；
    单源失败时 degraded=true 且成功源数据保留。
  - 后端 337 项：336 通过，1 项失败为 Windows 平台固有差异
    （resilientSecretStore 断言 0o600，Windows 实际 0o666），与本改动无关。
  - 语法检查 151 文件通过。
 2026-09-19 12:25:43 +08:00
yanhui
b7aca2343b feat(配件库存监控/MKH-BOM): 新增「采购在途」数量列与在途明细弹窗，补货预警改按结余库存判定 
配件库存监控：
- 列表「实时库存」后新增「采购在途数量」列，口径 SUM(MAX(0, jst_purchaseItem.qty - inQty))
- 顶部「实时库存合计」后新增可点击「采购在途」卡片，弹窗展示在途明细
  （商品编码/商品名称/采购数量/已入库/在途数量/计划到货日期/采购单号），支持关键词、排序、分页
- 新增后端接口 GET /api/modular-stock-monitor/purchase-in-transit
- 筛选器品类改直查 jst_sku 主表，避免新增 OUTER APPLY 拖慢筛选
- 采购在途列仅取数展示，不参与 ORDER BY / 聚合（规避 MSSQL 对 OUTER APPLY 列的灾难性执行计划）

MKH-BOM 补货预警：
- 日销驱动与已排产分支改用「结余库存 = 现有库存 - 待发货件数」判定可用天数与预警等级
- 建议补货量按 ceil(3 天日销 + 待发货件数 - 现有库存) 计算
- 新增 scope=work-order 范围筛选；列表新增「结余库存」列
- 打印模板剥离公司名前缀，打印字号调大

测试：mkhBomService 单测新增结余库存缓冲/紧张用例与回归用例
 2026-09-18 17:44:01 +08:00
yanhui
8ba052649d feat: 补货预警-日销为0有代发订单时按库存÷代发件数算可用天数预警 
- ⑩订单驱动分支改为：可用天数 = 现有库存 ÷ 代发(待发货)订单件数
  · 可用天数 = 0（无库存）→ 缺货
  · 0 < 可用天数 < 3 天 → 预警（建议补到 3 天缓冲：3×代发件数−现有库存）
  · 可用天数 ≥ 3 天 → 库存充足，不预警（阈值语义与日销分支一致）
- buildReplenishMetrics 订单驱动分支不再把 stockDays 记 null，统一如实记录
- 同步前端「可用天数」列/导出/数据口径说明文案（不再显示「按订单」）
- 更新 mkhBomService.test.js 对应用例，单测 40/40 通过
 2026-09-17 15:04:50 +08:00
yanhui
3e02c3e393 feat: 日销口径由近 7 天改为近 15 天（MKH 补货预警 + 模块化库存监控） 
业务要求「近7日日销」改「近30天日销」。实测业务库与产品资料库均无 30 天日销，
已实现的最长周期是 pm_stockMonitor.fifteenAvgSale（15 天），经与业务确认改用 15 天。

为什么没有 30 天（2026-09-17 实测，避免重复排查）：
- rpt.pm_stockMonitor 只有 threeAvgSale(3天)/sevenAvgSale(7天)/fifteenAvgSale(15天)，
  且整表只保留 1 天快照（2026-09-16），攒不出 30 天历史
- rpt.dws_sn_sales_full_info_di（stat_date+skuid+goods_count，新鲜到 09-15）
  里 MKH 商品 0 个；目标仓 794 个 SKU 命中也是 0
- rpt.dws_order_sales_cost_detail_di 停在 2025-04（历史归档）
- rpt.jst_salesOutboundInfo 只有出库单头，无 SKU 明细；业务库无出库明细表
- rpt.op_BarcodeSalePrice30dDaily 名字带 30d，但只有 salePrice 没有销量

改动：
- backend/src/services/mkhBomService.js
  · SALE_WINDOW_DAYS 7 → 15，新增 DAILY_SALE_COLUMN='fifteenAvgSale'，
    监控快照 SQL 按该常量插值取数（以后改口径只改常量）
  · buildReplenishMetrics 入参 sevenAvgSale → avgSale（语义与周期解耦）
  · 文件头 ⑦ 补「为什么是 15 天」的完整排查结论；⑦ / ⑩ / ⑪ 实测数字按新口径更新
- backend/src/services/modularStockMonitorService.js
  · 取数列与 API 字段名 sevenAvgSale/avgShip7d → fifteenAvgSale/avgShip15d
    （字段名同步改，避免名不副实）
- frontend/src/pages/MkhBomData/index.jsx
  · 列头与口径说明「近7日」→「近15天」；动态文案兜底 7 → 15
- frontend/src/pages/ModularStockMonitor/index.jsx
  · 列头「近7日日均发货量」→「近15天日均发货量」，dataIndex 同步改
  · 口径说明补充：可用天数仍沿用 jsUseDays（源系统口径），与日销并非同一时间窗

影响（同一份 09-16 快照，7 天 vs 15 天）：
  有销商品  114 → 170   周期拉长，更多商品进得了「有销」集合
  补货预警   25 → 19    反而变少：15 天日销普遍低于 7 天（近期销量走低），
                         可用天数 = 库存 ÷ 日销 随之变大，跌破 3 天的变少
  缺货        9 → 10
  已排产     11 → 13
  订单驱动   14 → 8     更多商品自己有日销，不再需要靠订单兜底
  配件不足   10 → 12
「预警变少」是口径变化的正常结果，不是 bug。

验证：
- 后端语法检查 151 个文件通过
- mkhBomService + mkhReplenishAlertJob 单测 52/52 通过
- 后端全量 334 tests / 333 pass（唯一失败是 resilientSecretStore 的
  Windows 文件权限断言，与本改动无关的环境固有问题）
- 接口实测：total 4223 / warningCount 19 / outOfStockCount 10 /
  saleWindowDays 15 / componentShortageCount 12
 2026-09-17 14:06:50 +08:00
yanhui
06952d8a04 Merge remote-tracking branch 'origin/main' into codex/mkh-alert-export-0917 
origin/main 已前进 11 个提交（PR #11~#15），其中 #11「配件仓位只取箱及仓位库存表」
与 #12「从模块化成品列表排除配件档案」改动了与本分支相同的三个文件。

冲突处理（3 个文件，逐处保留双方意图，未使用 ours/theirs 批量取舍）：
- backend/src/services/mkhBomService.js（4 处）：取本分支侧。本分支的 ⑤~⑪ 注释与
  loadComponentLocations 是 origin/main 那段的超集，且双方都已删除
  buildInventoryWarehouseMap 回退链，语义一致；同时并入 origin/main 收紧后的
  MKH_WHERE（必须是 jst_skuBomItem 正式父项）与文件头 ① 的新口径说明。
- backend/test/mkhBomService.test.js（1 处）：hunk 边界冲突，双方各缺一个 `});`。
  origin/main 新增的「无箱记录不回退仓库」测试按语义插在仓位测试之后，
  再接本分支新增的测试，两处闭合各自补回。
- frontend/src/pages/MkhBomData/index.jsx（2 处）：合并双方文案。数据口径采用
  origin/main 的表述（正式 BOM 父项、仓位只取 rpt.jst_packInventoryInfo），
  并保留本分支的补货预警 / 待发货订单 / 在途加工单 / 配件不足四段说明。

顺带校正 mkhBomService.js 注释中因成品口径收紧而过期的数字
（成品总数 4408 → 见 ①，预警数 26 → 25），仅改注释，不动逻辑。

合并后重新验证：后端语法检查 151 个文件通过；mkhBomService + mkhReplenishAlertJob
单测 52/52 通过；接口实测 total 4223 / warningCount 25 / componentShortageCount 10。
 2026-09-17 13:52:40 +08:00
yanhui
f69d26796e feat: MKH-BOM 补货预警支持待发订单驱动与配件不足标记 
补货预警在原有「销量 + 库存」口径之外增加两条判定，均不改变已上线行为：

1. 待发订单驱动
   - MKH 成品条码历史无销售量、但存在未发货订单时，同样进入补货预警。
   - 建议补货量按「未发货件数 − 现有库存」计算，无订单时不参与该口径。
   - 列表新增待发货订单列，展示件数、单数与最早下单时间。

2. 配件不足
   - 对判定为缺货或预警的商品，按 BOM 计算可组装数：
     可组装数 = 各配件 ⌊(现有库存 − 未完成加工单占用) ÷ 单台用量⌋ 取最小值。
   - 可组装数为 0 时标记「配件不足，无法补货」并保留在清单中，
     建议补货量显示「—」，同时给出短板配件及其库存。
   - 配件库存只认「简尚-崔桥工厂半成品包装项目仓」的现有库存，
     按业务确认不计采购在途。
   - 配件库存查询失败时降级为空索引并标记 componentStockDegraded，
     不写入缓存，避免把瞬时故障固化为错误数据。

导出与通知文案同步：导出新增「配件不足」列、补货量按同一口径输出；
缺货通知在配件不足时插入短板配件提示并把建议补货量显示为「—」。

验证：backend 相关单测全部通过（新增 9 例）；语法检查通过；
前端 eslint 零错误且 vite build 通过；接口实测与页面渲染结果见 PR。
 2026-09-17 12:18:32 +08:00
lunanting
3a87d8ecba fix: use pack inventory for BOM locations 2026-09-17 10:26:54 +08:00
yanhui
897bbd2afd Merge remote-tracking branch 'origin/main' into codex/mkh-alert-export-0917 
远端 6c00977（PR #10 "show MKH component warehouse locations"）与本地的
通知推送 / 导出 / 在途加工单改动改到了同一批文件，手工合并如下：

配件的仓位与库存统一到 loadComponentLocationData()，列表展开、单品明细、
导出配件明细三处共用（新增 loadComponentLocations 作为兼容入口）：

- 仓位四级兜底链：真货位 bin_group/bin → 箱号 pack_id → 库存正数量仓库
  （未分箱）→ jst_sku.other_3 商品档案仓（暂无箱号）
- 库存与仓位一次查询同时产出，两条查询都成功才写缓存（TTL 10 分钟）
- 修正远端版本的仓库关联列：仓名必须用 jst_warehouseInfo.Id = p.wh_id；
  jst_packInventoryInfo.wms_co_id 全表 NULL，用它关联 85,152 行全部取不到仓名。
  （库存表相反，必须用 w.wms_co_id = i.wms_co_id）
- 前端口径说明同时保留补货预警/在途加工单与新仓位口径
 2026-09-17 10:06:26 +08:00
yanhui
fe831c32fd feat: MKH-BOM 补货预警排除在途加工单、缺货通知推送、导出功能 
- 补货预警：接入加工单(链接服务器 bi_processing_work_orders)，有未完成加工单则不预警，新增在途加工量列
- 新增每日 09:00 缺货/预警通知推送（cron + 统一通知中心 + 幂等键）
- 新增导出：商品清单 / 配件明细，XLSX / CSV，按当前筛选条件全量
- 配件仓位：新增 loadComponentLocations 批量加载器（导出/列表展开共用）
 2026-09-17 10:01:13 +08:00
lunanting
006737e4ae fix: show MKH component warehouse locations 2026-09-17 09:39:25 +08:00
lunanting
1c72df7f36 Merge remote-tracking branch 'origin/main' into codex/bom-warehouse-filter-0916 
# Conflicts:
#	backend/src/services/mkhBomService.js
 2026-09-16 21:02:07 +08:00