refactor(wst): 页面名去掉「24 小时」，改为「发货时效（到点未发即超时）」 #89

yanhui · 2026-10-28T14:31:30+08:00

yanhui commented

2026-10-28 14:31:30 +08:00

规则完全不动，只改名字，消除误导。

为什么改

页面原名「仓储中心 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：本次只动注释，不影响

规则完全不动，只改名字，消除误导。 ## 为什么改页面原名「仓储中心 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`：本次只动注释，不影响

yanhui added 1 commit 2026-10-28 14:31:31 +08:00

refactor(wst): 页面名去掉「24 小时」，改为「发货时效（到点未发即超时）」 6a5f6e8ae0

规则完全不动，只改名字，消除误导。

## 为什么改

页面原名「仓储中心 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`：本次只动注释，不影响

yanhui referenced this pull request

2026-10-28 15:35:13 +08:00

fix(wst): 起算点改回「最后审核时间」，并剔除订单表漏回写的已发单 #90

yanhui closed this pull request

2026-10-28 17:48:36 +08:00

Pull request closed

Please reopen this pull request to perform a merge.

Sign in to join this conversation.

1 Participants

Notifications

Due Date

No due date set.

Dependencies

No dependencies set.

Reference: lunanting/cangku#89