lunanting/cangku
1
0
Fork 1
Code Issues Pull Requests 3 Actions Packages Projects Releases Wiki Activity
61 Commits 76 Branches 0 Tags
Commit Graph

22 Commits

Author SHA1 Message Date
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
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
3ccba5f460 fix: show MKH BOM details in drill-down 2026-09-16 14:57:05 +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
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
088a24c3a9 fix: route bootstrap HTTPS through port 8443 2026-09-12 16:11:05 +08:00
lunanting
3239d6a558 feat: bootstrap local instances from central system database 2026-09-12 16:06:01 +08:00
lunanting
f182ec962a Allow PDD production startup without optional image-search integrations 2026-09-12 11:56:50 +08:00
lunanting
ec8949cfbf Initial public PDD edition without market, Claw, skills or platform switching 2026-09-12 11:51:44 +08:00