118 Commits

Author SHA1 Message Date
146f98e9ee Merge pull request 'fix: 页面刷新强制更新 MKH 运营数据' (#35) from codex/mkh-fresh-refresh-0924 into main
页面刷新强制更新 MKH 运营数据 (#35)
2026-09-24 13:31:06 +08:00
134
ea312d9070 fix: force fresh MKH operational data 2026-09-24 13:30:09 +08:00
1afa99a783 Merge pull request 'fix: MKH 页面自动刷新实时数据' (#34) from codex/mkh-auto-refresh-0924 into main
修复 MKH 页面自动刷新实时数据 (#34)
2026-09-24 13:17:52 +08:00
134
30f5df2206 fix: auto refresh MKH live data 2026-09-24 13:15:53 +08:00
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
db2362307d Merge pull request 'feat: 新增每日进销存(大货库存监控)' (#30) from codex/daily-inventory-0923 into main 2026-09-24 08:01:48 +08:00
e4b6bbcf31 feat: 新增每日进销存(大货库存监控) 2026-09-23 17:41:03 +08:00
eaa8489600 feat: 新增每日进销存(大货库存监控) 2026-09-23 17:41:02 +08:00
b57fc1ad5b feat: 新增每日进销存(大货库存监控) 2026-09-23 17:41:01 +08:00
cd936f5e92 feat: 新增每日进销存(大货库存监控) 2026-09-23 17:41:00 +08:00
9e2f26b1c9 feat: 新增每日进销存(大货库存监控) 2026-09-23 17:40:58 +08:00
39c7933d2d feat: 新增每日进销存(大货库存监控) 2026-09-23 17:40:57 +08:00
2bd5dce3d7 feat: 新增每日进销存(大货库存监控) 2026-09-23 17:40:56 +08:00
9fd0bcaf4b feat: 新增每日进销存(大货库存监控) 2026-09-23 17:40:55 +08:00
9a77d15448 feat: 新增每日进销存(大货库存监控) 2026-09-23 17:40:54 +08:00
fce269828f feat: 新增每日进销存(大货库存监控) 2026-09-23 17:40:53 +08:00
a90c2fd4f0 feat: 新增每日进销存(大货库存监控) 2026-09-23 17:40:52 +08:00
e579f73560 feat: 新增每日进销存(大货库存监控) 2026-09-23 17:40:51 +08:00
570666f772 feat: 新增每日进销存(大货库存监控) 2026-09-23 17:40:50 +08:00
fb1b433f94 feat: 新增每日进销存(大货库存监控) 2026-09-23 17:40:22 +08:00
23e576d26e feat: 新增每日进销存(大货库存监控) 2026-09-23 17:37:48 +08:00
d3f36d5359 feat: 新增每日进销存(大货库存监控) 2026-09-23 17:37:47 +08:00
819cd08de2 feat: 新增每日进销存(大货库存监控) 2026-09-23 17:37:45 +08:00
855586d5de feat: 新增每日进销存(大货库存监控) 2026-09-23 17:37:44 +08:00
8655433e39 feat: 新增每日进销存(大货库存监控) 2026-09-23 17:37:42 +08:00
f6b755aac4 feat: 新增每日进销存(大货库存监控) 2026-09-23 17:37:41 +08:00
700d7ae96d feat: 新增每日进销存(大货库存监控) 2026-09-23 17:37:40 +08:00
37c1adf4f2 feat: 新增每日进销存(大货库存监控) 2026-09-23 17:37:39 +08:00
d52151d7dc Merge pull request 'refactor: 移除大货库存监控功能(26 仓)' (#29) from codex/remove-large-stock-monitor-0923 into main 2026-09-23 16:12:50 +08:00
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
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
2e52e4a393 Merge pull request 'feat: 新增大货库存监控(26 仓)' (#27) from codex/large-stock-monitor-0923 into main 2026-09-23 14:01:44 +08:00
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
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
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
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
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
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
f4303c0aed Merge pull request 'fix: 隧道断线自愈 + 修复配置负缓存永久固化(根治「隧道一断即整栈不可用 / 必须重启后端」)' (#21) from codex/tunnel-selfheal-config-cache-0922 into main 2026-09-22 23:58:24 +08:00
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
bbabda5016 Merge pull request 'fix: MKH-BOM 预警与库存口径修复:日销以出库为准 + 库存增加箱表兜底' (#19) 2026-09-22 23:14:37 +08:00
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