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

115 Commits

This Branch
This Branch
All Branches
Author SHA1 Message Date
134
30f5df2206 fix: auto refresh MKH live data 2026-09-24 13:15:53 +08:00
lunanting
52b74aafe9 Merge pull request #31: 修正 MKH 已入库库存与加工在途 
保留任务提交历史；验证 346 项后端测试通过。
 2026-09-24 09:20:30 +08:00
134
4227d9001e fix: reconcile MKH received stock and work orders 2026-09-24 09:19:21 +08:00
youruo
db2362307d Merge pull request 'feat: 新增每日进销存（大货库存监控）' (#30) from codex/daily-inventory-0923 into main 2026-09-24 08:01:48 +08:00
youruo
e4b6bbcf31 feat: 新增每日进销存（大货库存监控） 2026-09-23 17:41:03 +08:00
youruo
eaa8489600 feat: 新增每日进销存（大货库存监控） 2026-09-23 17:41:02 +08:00
youruo
b57fc1ad5b feat: 新增每日进销存（大货库存监控） 2026-09-23 17:41:01 +08:00
youruo
cd936f5e92 feat: 新增每日进销存（大货库存监控） 2026-09-23 17:41:00 +08:00
youruo
9e2f26b1c9 feat: 新增每日进销存（大货库存监控） 2026-09-23 17:40:58 +08:00
youruo
39c7933d2d feat: 新增每日进销存（大货库存监控） 2026-09-23 17:40:57 +08:00
youruo
2bd5dce3d7 feat: 新增每日进销存（大货库存监控） 2026-09-23 17:40:56 +08:00
youruo
9fd0bcaf4b feat: 新增每日进销存（大货库存监控） 2026-09-23 17:40:55 +08:00
youruo
9a77d15448 feat: 新增每日进销存（大货库存监控） 2026-09-23 17:40:54 +08:00
youruo
fce269828f feat: 新增每日进销存（大货库存监控） 2026-09-23 17:40:53 +08:00
youruo
a90c2fd4f0 feat: 新增每日进销存（大货库存监控） 2026-09-23 17:40:52 +08:00
youruo
e579f73560 feat: 新增每日进销存（大货库存监控） 2026-09-23 17:40:51 +08:00
youruo
570666f772 feat: 新增每日进销存（大货库存监控） 2026-09-23 17:40:50 +08:00
youruo
fb1b433f94 feat: 新增每日进销存（大货库存监控） 2026-09-23 17:40:22 +08:00
youruo
23e576d26e feat: 新增每日进销存（大货库存监控） 2026-09-23 17:37:48 +08:00
youruo
d3f36d5359 feat: 新增每日进销存（大货库存监控） 2026-09-23 17:37:47 +08:00
youruo
819cd08de2 feat: 新增每日进销存（大货库存监控） 2026-09-23 17:37:45 +08:00
youruo
855586d5de feat: 新增每日进销存（大货库存监控） 2026-09-23 17:37:44 +08:00
youruo
8655433e39 feat: 新增每日进销存（大货库存监控） 2026-09-23 17:37:42 +08:00
youruo
f6b755aac4 feat: 新增每日进销存（大货库存监控） 2026-09-23 17:37:41 +08:00
youruo
700d7ae96d feat: 新增每日进销存（大货库存监控） 2026-09-23 17:37:40 +08:00
youruo
37c1adf4f2 feat: 新增每日进销存（大货库存监控） 2026-09-23 17:37:39 +08:00
youruo
d52151d7dc Merge pull request 'refactor: 移除大货库存监控功能（26 仓）' (#29) from codex/remove-large-stock-monitor-0923 into main 2026-09-23 16:12:50 +08:00
lunanting
592c52f891 refactor: 移除大货库存监控功能（26 仓） 
应用户要求下线该功能组，侧边栏不再显示「大货库存监控」及 26 个仓库二级菜单。

移除内容：
- 前端页面 LargeStockMonitor、18 列定义、API 封装与样式
- 路由 /planning/large-stock-monitor/:warehouseSlug 与权限点 large_stock_monitor
- 侧边栏菜单组 stock-monitor-large 与 SIDEBAR_ROUTE_MAP 26 条映射
- 后端 /api/large-stock-monitor 路由挂载、largeStockMonitor.js、
  largeStockMonitorConfig.js、largeStockMonitorFlow.js 及端到端校验脚本

验证：
- 全仓无 largeStockMonitor 残留引用；后端 346 用例 345 通过
  （1 项失败为 resilientSecretStore.test.js，Windows 权限语义基线既有失败）
- 前端 lint + 测试 + 构建通过，产物中 LargeStockMonitor chunk 已消失
- 运行时验证：/api/large-stock-monitor/* 返回 404，页面与登录不受影响
 2026-09-23 16:07:04 +08:00
lunanting
d4e6c6e4a2 Merge pull request 'fix: 配件库存用最新箱仓数据补齐' (#28) from codex/component-pack-stock-fallback-0923 into main 2026-09-23 15:43:53 +08:00
134
66e0ddf709 fix: 用箱仓库存补齐滞后的配件库存 2026-09-23 15:42:46 +08:00
youruo
2e52e4a393 Merge pull request 'feat: 新增大货库存监控（26 仓）' (#27) from codex/large-stock-monitor-0923 into main 2026-09-23 14:01:44 +08:00
lunanting
2bc949099b feat: 新增大货库存监控（26 仓） 
按「库存监控」表格在侧边栏增加一级/二级菜单与共用页面
（路由 /planning/large-stock-monitor/:warehouseSlug）。

后端：
- 新增 largeStockMonitorConfig.js：26 仓配置，含 wms_co_id / 快照仓名 / routeKey / slug 映射
- 新增 largeStockMonitor.js：config / overview / sku-list 三个接口
- 新增 largeStockMonitorFlow.js：采购进仓、采购退货、销售出仓、销售退货四类单据流水取数
- 新增 verify-large-stock-monitor.js：26 仓端到端校验脚本
- index.js：挂载 /api/large-stock-monitor 路由

口径说明：
- 库存周转天数 = 月度发货总件数 / 月度日均库存件数 × 100%，下沉到 SQL CASE WHEN 计算
- 四级分级（滞销预警/慢流/呆滞/僵尸）按库龄 + 周转率双维度判定
- 期末数量取聚水潭实际库存 jst_inventoryInfo（按 wms_co_id 单仓），
  不用 pm_stockMonitor.jsStock —— 后者 warehouse 是「归属仓」口径，
  会把已调拨到外仓的货仍计在本仓名下（崔桥工厂仓因此虚高约 2.2 万）
- 截止时刻统一为快照日次日 01:00（跑批时点），库龄/分级均以此为基准，不再用 GETDATE()

前端：
- 新增 LargeStockMonitor 页面、18 列定义、API 封装与样式
- 路由与侧边栏：26 条二级菜单 + 权限点

冲突处理：
- 主仓库已下线 /api/dashboard（backend/src/api/dashboard.js 被移除），
  相应删除 dashboardRoutes 的 require 与挂载，避免后端启动时 require 失败崩溃
- 保留主仓库新增的「模块化库存监控」菜单组及其子项
 2026-09-23 13:42:58 +08:00
lunanting
254d1dd9f9 Merge pull request 'docs: 明确前端冒烟检查的预期鉴权响应' (#26) from codex/deploy-doc-frontend-smoke-0923 into main 2026-09-23 11:54:13 +08:00
134
181ea0237d docs: 修正文档排版 2026-09-23 11:52:32 +08:00
134
783bb5182b docs: 明确登录页预期鉴权响应 2026-09-23 11:52:07 +08:00
lunanting
ac44a00a49 Merge pull request 'docs: 补充前端骨架屏部署验收规范' (#25) from codex/deploy-doc-frontend-smoke-0923 into main 2026-09-23 11:45:04 +08:00
134
b3b38d4aa2 docs: 增加前端部署运行时验收规则 2026-09-23 11:43:29 +08:00
lunanting
5034cc5782 Merge pull request 'fix: 根治前端循环分块导致的永久骨架屏' (#24) from codex/web-bootstrap-fix-0923 into main 2026-09-23 11:36:49 +08:00
134
d32494ca12 fix: 消除前端循环分块导致的骨架屏 2026-09-23 11:35:47 +08:00
lunanting
6b0bf59e74 Merge pull request 'fix: MKH 刷新实时读取订单库存并阻止旧请求覆盖' (#23) from codex/mkh-sync-freshness-0923 into main 2026-09-23 11:18:13 +08:00
134
b8e60a19d2 fix: MKH刷新改用实时订单库存口径 2026-09-23 11:12:08 +08:00
134
fa91b9242c fix: 根治MKH同步后旧请求覆盖最新数据 2026-09-23 11:05:28 +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
bbabda5016 Merge pull request 'fix: MKH-BOM 预警与库存口径修复：日销以出库为准 + 库存增加箱表兜底' (#19) 2026-09-22 23:14:37 +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