|
|
6a5f6e8ae0
|
refactor(wst): 页面名去掉「24 小时」，改为「发货时效（到点未发即超时）」
规则完全不动，只改名字，消除误导。
## 为什么改
页面原名「仓储中心 24 小时发货时效」，但判定规则是「到 13:00 / 18:00
核验时刻仍未发货即超时」，**没有满 24 小时的门槛**（业务 2026-10-20 已三次纠偏定版）。
名字和规则打架，导致看的人以为「不满 24 小时不该算超时」。
实测例子：10-27 16:00 创建的单，今天 13:00 核验时只等了 **21 小时**就被判超时；
13:00 轮 599 单里有 416 单属于 10-27 16 点后创建。业务看到就问「创建时间都在 7 点后，
为什么算超时」—— 其实是名字里的「24 小时」在误导（那些是**昨天**晚上的单，
不是今天的）。
## 改了什么
用户可见（2 处）：
- 侧栏菜单：`仓储中心24小时发货时效` → `仓储中心发货时效`
（不加括号：侧栏现有最长 label 12 字，加了会到 18 字溢出）
- 页面标题：`仓储中心 24 小时发货时效` → `仓储中心发货时效（到点未发即超时）`
其余为注释同步（8 个文件），代码逻辑与判定口径**零改动**：
`warehouseShipTimelinessRegistry/Service/NotifyJob/NotifySettings`、
`warehouseLogisticsExceptionRegistry`、`frontend/api/warehouseShipTimeliness`、`backend/index`。
## 不变的部分
- 核验时点、窗口上界（07:00 / 16:00）、仓级例外（山东 15:00、洛宁 13:00）
- 数据源与起算点（订单两表 + `created`）
- 钉钉推送抬头本来就是「【仓储中心发货时效】」，不用改
## 验证
- 前端 eslint 通过、`npm run build` 通过（31.86s）
- 浏览器真渲染（本地 5173，等足 75 秒数据返回）：
- 标题 = `仓储中心发货时效（到点未发即超时）`
- 侧栏项 = `仓储中心发货时效`，全页 `body` 内已无「24小时」字样
- 数据正常渲染：超时未发 599 单 / 不计考核 849 / 涉及仓库 8 个 / 最久未发 13 天
- 明细「创建时间」列完整显示 `2026-10-27 19:xx` 这类日期，不存在时区错位
- 无 pageerror
- 后端 `npm run check`：本次只动注释，不影响
|
2026-10-28 14:30:54 +08:00 |
|
