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

55 Commits

This Branch
This Branch
All Branches
Author SHA1 Message Date
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
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
a928135a63 Merge pull request 'fix: 兼容生产服务器旧版 Git' (#15) 
Avoid unsupported git -C and branch --show-current commands in the production build script.
 2026-09-17 11:56:10 +08:00
lunanting
5302b22fc1 fix: 兼容生产服务器旧版Git 2026-09-17 11:55:37 +08:00
lunanting
fd89eb64d2 Merge pull request 'build: 使用兼容生产环境的前端构建流程' (#14) 
Use standard Vite and an isolated Node.js 22 production build script verified against the deployed SHA.
 2026-09-17 11:54:50 +08:00
lunanting
31a4b0aebb build: 使用兼容生产环境的前端构建流程 2026-09-17 11:54:03 +08:00
lunanting
611165dded Merge pull request 'docs: 修正生产部署运行时命令' (#13) 
Use commands compatible with the production Git and build the frontend under Node.js 22.
 2026-09-17 11:46:14 +08:00
lunanting
e1c2ad1ea6 docs: 修正生产部署运行时命令 2026-09-17 11:45:37 +08:00
lunanting
2b096ed2e2 Merge pull request 'fix: 从模块化成品列表排除配件档案' (#12) 
Only designated warehouse SKU records that are official BOM parents appear as modular finished products.
 2026-09-17 11:43:38 +08:00
lunanting
986174076f fix: 仅展示正式BOM父项商品 2026-09-17 11:42:50 +08:00
lunanting
ecfd97787d Merge pull request 'fix: 配件仓位仅使用箱及仓位库存表' (#11) 
Use rpt.jst_packInventoryInfo as the sole BOM location source and document explicit owner merge authorization.
 2026-09-17 11:15:47 +08:00
lunanting
80028665c5 docs: allow explicit owner merge authorization 2026-09-17 11:14:46 +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
6c0097753f Merge pull request 'fix: show MKH component warehouse locations' (#10) from codex/fix-bom-location-0917 into main 2026-09-17 09:52:44 +08:00
lunanting
006737e4ae fix: show MKH component warehouse locations 2026-09-17 09:39:25 +08:00
lunanting
50202557d9 Merge pull request 'fix: restrict MKH products and use official BOM tables' (#9) from codex/bom-warehouse-filter-0916 into main 2026-09-16 21:03:57 +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
lunanting
4aed4d543d Merge pull request 'fix: 从包装库存读取 BOM 配件仓位' (#8) from codex/bom-pack-location-0916 into main 2026-09-16 21:00:01 +08:00
lunanting
8e5d427b3a fix: read MKH details from official BOM tables 2026-09-16 20:56:26 +08:00
lunanting
3bf7b9f208 fix: restrict MKH BOM list to designated warehouse 2026-09-16 18:02:28 +08:00
lunanting
65d009dcdc fix: read BOM locations from pack inventory 2026-09-16 17:52:49 +08:00
lunanting
3fe0e55ad6 Merge pull request 'fix: show MKH BOM details in drill-down' (#7) from codex/fix-mkh-bom-drilldown into main 2026-09-16 16:58:54 +08:00
lunanting
3ccba5f460 fix: show MKH BOM details in drill-down 2026-09-16 14:57:05 +08:00
yanhui
4c2ebef988 Merge pull request 'feat: 启用运营分析模块，新增模块化库存监控与 MKH-BOM 资料' (#6) from yanhui/codex/yanhui-operation-modules-001 into main 
经项目负责人 yanhui 授权合并（2026-09-16）。

基线 main: 8448f7a0e849ac04c7f572bb3fb1fa89765c0945
待合并提交: 445347e664a555cdc8bc2a0a7c488f111db2039e

验证：前端 lint 通过 / test 16-16 通过 / vite build 通过；
后端语法检查 149 文件通过、node --test 38-39 通过
（唯一失败 resilientSecretStore.test.js 为 Windows 文件权限语义差异，不涉及本次改动）。
 2026-09-16 13:49:35 +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
lunanting
8448f7a0e8 Merge pull request 'feat: support product information PostgreSQL config' (#5) from codex/add-product-information-postgres into main 2026-09-12 21:34:32 +08:00
lunanting
4b1e004b3c feat: support product information PostgreSQL config 2026-09-12 21:34:07 +08:00
lunanting
d726dfd4cb Merge pull request 'docs: require database load and index validation' (#4) from codex/database-index-guidelines into main 2026-09-12 19:49:57 +08:00
lunanting
3c1895a9e2 docs: require database load and index validation 2026-09-12 19:48:57 +08:00
lunanting
490c68f7d7 Merge pull request #3: remove commerce monitoring feature suites 
Validated frontend, backend, remote-access and dashboard route checks.
 2026-09-12 18:51:35 +08:00
lunanting
d9ebbba61e refactor: remove commerce monitoring feature suites 2026-09-12 18:49:37 +08:00
lunanting
36948c98ca refactor: remove store and operations feature suites 2026-09-12 17:50:26 +08:00
lunanting
1d87c3f94c docs: define safe production deployment workflow 2026-09-12 17:38:11 +08:00
lunanting
4f78a5b512 security: run managed Redis unprivileged 2026-09-12 17:33:26 +08:00
lunanting
e1772917ea fix: persist provisioned Redis ACL users 2026-09-12 17:29:24 +08:00
lunanting
4f48a20670 fix: avoid Redis INFO in restricted clients 2026-09-12 17:26:23 +08:00
lunanting
c4f14b0cdf fix: label Redis certificate mount for SELinux 2026-09-12 17:21:05 +08:00
lunanting
8c448bcd74 feat: provision managed Redis during enrollment 2026-09-12 17:13:59 +08:00
lunanting
86ab958911 security: restrict bootstrap state permissions 2026-09-12 16:58:00 +08:00
lunanting
3229c2a1c3 fix: use backend liveness health check 2026-09-12 16:55:48 +08:00
lunanting
a85acabde5 ops: add isolated production deployment 2026-09-12 16:53:18 +08:00
lunanting
088a24c3a9 fix: route bootstrap HTTPS through port 8443 2026-09-12 16:11:05 +08:00
lunanting
5689671312 fix: use DNS validation for managed TLS certificate 2026-09-12 16:08:57 +08:00