|
|
75a8795723
|
配件库存监控：表头"SKU编码"改为"商品编码"
- frontend/src/pages/ModularStockMonitor/index.jsx
- 表格列头 "SKU编码" → "商品编码"
- MKH 配置状态 tooltip 文案同步调整
- 搜索框 placeholder "SKU 编码 / 名称" → "商品编码 / 名称"
- backend/src/services/modularStockMonitorService.js
- 文件头注释同步更新（仅文案，无逻辑改动）
关于"从 BOM 维护匹配已配置 MKH 成品编码"：
已探测 rpt.pm_bomBaseInfo 与目标仓 SKU 的编码体系完全脱钩
（sku_id/i_id/name 均 0 命中），若直接切换数据源会导致已配置数
从 661 归零。经用户确认，本次保留现有产品资料库判定口径，
仅做表头文案变更。
|
2026-09-17 15:44:30 +08:00 |
|
|
|
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 |
|
|
|
445347e664
|
feat: 启用运营分析模块，新增模块化库存监控与 MKH-BOM 资料
本次将此前被列入退役名单的运营分析相关模块恢复为可用，并新增「模块化库存监控」
一级菜单及其两个子页面。
主要变更：
1. 恢复启用：商品监控、激励看板、营销活动、推广模块、商品分析
- retiredFeatures 移出对应退役名单与清表语句，改为正常保留
- 补齐后端路由、前端页面与 API 封装、侧边栏配置、桌面客户端能力项
- 同步更新 retiredFeatures / retiredRoutes / retiredNavigation / desktopSessionService 测试
2. 新增「模块化库存监控」一级菜单
- 配件库存监控：仅取「简尚-崔桥工厂半成品包装项目仓」SKU 的实时库存、
当日入库/出库、近 7 日日均发货量、库存可用天数与预警（库存可用天数 ≤ 7 预警）
- MKH-BOM资料：按商品编码展示配件明细、数量、仓位、库存，支持 A4 纵向打印
3. 新增产品资料系统数据库（PostgreSQL）连接模块：读取系统库 database_configs 中
name = product_information_database 的配置，凭据只从配置读取，不落代码
4. 新增系统设置页配置项：商品标签配置、部门商品标签配置、部门SKU负责人配置
5. 旧 /api/dashboard 接口迁移至 /api/productAnalysis，仪表盘预览页改用新接口，
相应移除 dashboard 路由模块及其测试
6. 修复 retiredRoutes 测试在 Windows 下挂起超时的问题：该测试用
parent.filename.endsWith('/api/planningUpload.js') 判断是否注入 mock，
而 Windows 的 filename 为反斜杠路径，导致判断恒为 false、mock 全部失效、
真实模块去连中央系统库而挂起（Linux CI 正常）。改为平台无关的路径匹配。
7. .gitignore 忽略本地验证产物（outputs/、.git-status.txt）
验证：
- 前端：lint / test（16 项）/ build（含 planning entry 校验）全部通过
- 后端：语法检查 149 个文件通过；测试 38/39 通过
- 已知未通过项：resilientSecretStore.test.js 断言密钥备份文件权限为 0o600，
Windows 下 chmod 无法表达该权限（实际为 0o666），属既有的平台相关失败，
与本次改动无关，本次未修改该文件
- 说明：本机 frontend/ 下存在未纳入版本库的旧依赖备份目录 node_modules_old_*，
会污染 ESLint 扫描（十余万条第三方报错），故 lint 步骤以
--ignore-pattern node_modules_old_*/** 排除后执行，其余步骤与仓库 check 一致
未提交内容：本地验证截图 outputs/ 与 .git-status.txt 已被 .gitignore 排除。
|
2026-09-15 16:53:12 +08:00 |
|
