yanhui/cangku
1
0
Fork 0
forked from lunanting/cangku
Code Pull Requests Activity
197 Commits 7 Branches 0 Tags
Commit Graph

10 Commits

Author SHA1 Message Date
134
66e0ddf709 fix: 用箱仓库存补齐滞后的配件库存 2026-09-23 15:42:46 +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
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
be52bdd0b5 feat(配件库存监控/MKH-BOM): 两页面新增「同步最新数据」按钮 
需求：配件库存监控、MKH-BOM 资料两个页面各加一个同步按钮，任何时候点击都能
立即拉取最新数据，不必等凌晨 00:00 的定时刷新。

后端：
- mkhBomService 新增 clearMkhBomCache()：清空本页全部服务端缓存
  （businessBom / officialBomIndex / officialBomDetail / productBom /
  mkhProduct / replenishIndex / workOrderIndex / pendingOrderIndex /
  componentStock / componentLocation），返回 syncedAt + 各缓存清除条目数。
- modularStockMonitorService 新增 syncModularStock()：本页无进程内缓存
  （每次请求直连副本库），同步动作 = 重新解析并返回最新监控日，前端据此重拉列表。
- 新增接口 POST /api/mkh-bom/sync、POST /api/modular-stock-monitor/sync。

前端：
- api/mkhBom.js 新增 syncMkhBom；api/modularStockMonitor.js 新增 syncModularStock。
- 两个页面工具栏各加「同步最新数据」主按钮（SyncOutlined，带 loading 态），
  点击 → 调后端 sync → 成功后重新拉列表（MKH-BOM 页同时清空展开明细缓存
  detailCache，避免看到旧的配件明细）→ 提示「已同步最新数据」；
  失败时展示后端返回的错误信息。

口径说明（重要）：
- 两页数据来自副本库 JSReportReplica，由上游聚水潭同步；应用层无法触发上游拉取。
  本按钮的作用是「清服务端缓存 + 直连副本库重取最新」，保证看到的不是
  2~15 分钟前的缓存结果，而不是重新跑一遍上游同步。
- 后端已内置的 dailyRefresh（cron 0 0 * * *，Asia/Shanghai）刷的是
  summary_daily_* / summary_monthly_* 汇总表，不覆盖这两页数据源，
  与本按钮既不重复也不冲突，可并存。

验证：
- 后端 4 个改动文件 node --check 全部通过。
- 前端 4 个改动文件（含 2 个 jsx）用 @babel/parser 解析全部通过。
- 实测：syncModularStock 返回 monitorDate=2026-09-16；
  clearMkhBomCache 返回 syncedAt 与各缓存清除条目数。
- 单测 mkhBomService.test.js 40/40 通过，无回归。
- 前端 lint/build 未运行：frontend/node_modules 仍是之前被中断 npm ci 破坏的
  坏目录（frontend/node_modules_broken_0917/，未纳入提交）。
  合并前需在本机 npm ci 恢复后，打开两个页面确认按钮渲染与点击效果。
- 后端改动需重启服务后才生效。
 2026-09-17 18:14:57 +08:00
yanhui
bc8c46d5be 配件库存监控：未配置MKH 不进任何缺货/预警 
业务确认（2026-09-17）：未配置MKH 的配件不属于模块化体系，预警列一律显示「正常」，
既不报缺货（实时库存<=0）也不报预警（可用天数<=7）。

实现：
- 新增 buildWarningOrderSql() 统一表达式（0缺货/1预警/2正常），未配置MKH(cfg.configured=0) 直接判 2。
- 列表映射 mapRow 改用 SQL 算好的 warningOrder 推导 warningLevel（删除重复 normalizeWarningLevel，
  避免前后端各算一份导致排序与显示不一致）。
- 汇总计数 buildSummary.outOfStockCount / lowStockDaysCount 改用统一表达式，不再计入未配置MKH。
- 筛选 buildFilters：按预警等级筛选、onlyWarning=1（仅看缺货/预警）均排除未配置MKH。

实测（接口直跑，目标仓 794 SKU）：
- 未配置MKH 95 个全部判「正常」（其中 55 个库存=0、58 个可用天数<=7，原会预警）。
- summary.outOfStockCount=13 / lowStockDaysCount=3，与已配置MKH 页面分布一致。
- onlyWarning=1 返回 16 条，0 条未配置MKH。
 2026-09-17 16:41:25 +08:00
yanhui
0bb7c5905d fix(模块化库存监控): 已配置MKH 改从聚水潭 SKU 级 BOM 维护(jst_skuBomItem)判定 
业务反馈上一版「已配置MKH」数量不对(仅 29 个)，原因是用了
jst_comboProductItem 组合装引用口径，漏掉了真正以 MKH 成品为父项的 BOM 配件。

修正：
- 数据源由 jst_comboProductItem 改为 rpt.jst_skuBomItem(聚水潭 SKU 级 BOM 明细，
  含配件商品编码 map_outer_sku_id)。
- 判定口径：目标仓商品编码出现在 jst_skuBomItem.map_outer_sku_id，且父项
  sku_id 以 'MKH' 开头(即被某 MKH 模块化成品 BOM 引用为配件) → 已配置MKH。
- 实测目标仓 794 个 SKU 中 699 个命中(map_outer_sku_id 匹配、父项 MKH 过滤)，
  95 个未配置，合计 794，与接口返回 summary 一致。
- 同步前端状态列 tooltip 与页脚口径说明。
- 移除对「产品资料系统数据库商品档案」「jst_comboProductItem 组合装」两套旧口径的依赖。

注：pm_bomBaseInfo(聚水潭 BOM 维护) 的配件行无 SKU 编码列(仅中文品名/位号)，
其组件 SKU 编码实际落在 jst_skuBomItem.map_outer_sku_id，故采用后者。
 2026-09-17 16:20:17 +08:00
yanhui
e6ea1246f9 配件库存监控：已配置MKH改为"被MKH模块化成品引用"判定 
- backend/src/services/modularStockMonitorService.js
  - 「已配置MKH」判定口径切回 jst_comboProductItem 组合装引用：
    该 SKU 出现在 jst_comboProductItem.src_sku_id 且 combine_sku_id 以 'MKH' 开头
    即视为被 MKH 模块化成品（组合装/成品档案）引用为配件。
  - 移除产品资料系统数据库覆盖清单逻辑（resolveProductCoverage / productCoveredCsv），
    产品资料库仅保留作图片来源。
  - 实测目标仓 794 SKU 中 29 个命中（原产品资料库口径 661 已废弃）。
- frontend/src/pages/ModularStockMonitor/index.jsx
  - 状态列 tooltip 文案同步为「是否被 MKH 模块化成品作为配件引用」。

注：本改动会令已配置MKH数量从 661 降至 29（数据使然，非 bug）。
 2026-09-17 16:01:20 +08:00
yanhui
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
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
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