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

yanhui · 2026-10-28T15:35:13+08:00

yanhui commented

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

业务 2026-10-28 下午用 9837824 指出「599 单创建时间不对」，逐字段核对后确认：jst_Orders.created（10-19 23:44:22）不是仓库接到单的时刻，真正的起算点是状态表 last_oa_confirm_time（10-28 09:58:42）——该单审核后 11 分钟就打了单（运单 JDVB71664383839，10:09:55 快递员上门）。

改了什么

起算点：created → last_oa_confirm_time（业务选定「最后审核时间」）。取不到审核时间的单回退 created，页面 / 导出 / 钉钉该列打 *。
已发判定补兜底：订单表 send_date 为空、但状态表 send_time 有值的，按已发剔除（实测 144 单里 6 单属此类，且有揽收轨迹）。两个方向都不会再冤枉仓库。
明细列：创建时间 → 审核时间 + 下单时间 并列，导出同步。
钉钉：明细第五段由「创建」改回「审核」；抬头「核验 XX 前创建」改「前审核」。
回归测试同步改断言；stub 增加审核时间查询分支（默认空 = 全量回退 created，老断言继续成立）。

影响（10-28 13:00 轮实测）

	单量
原口径（按 created）	599
按审核时间分轮	144
剔除漏回写已发单后	138

599 单里 376 单是当天 08:10~~10:30 才批量审核的积压单（多为 10-17~~10-27 创建），491 单其实已有运单号。

验收

后端 npm run check：491/493（2 个失败为既有 Windows 权限 / TTL 用例，改动前同样失败，已 stash 对比确认）
前端 eslint 通过；build 23.92s 通过
本地真渲染：138 单、表头 内部单号/线上订单号/店铺/发货仓/发货时间/审核时间/下单时间/付款时间/发货状态/物流状态/已等时长、回退单带 *、无 pageerror

⚠️ 分支关系

本分支基于 yanhui-wst-rename-1028（PR #89 纯改名），所以包含 PR #89 的那个提交（6a5f6e8）。合并本 PR 后 #89 即可关闭。

业务 2026-10-28 下午用 **9837824** 指出「599 单创建时间不对」，逐字段核对后确认：`jst_Orders.created`（10-19 23:44:22）不是仓库接到单的时刻，真正的起算点是状态表 `last_oa_confirm_time`（10-28 09:58:42）——该单审核后 11 分钟就打了单（运单 JDVB71664383839，10:09:55 快递员上门）。 ## 改了什么 - **起算点**：`created` → `last_oa_confirm_time`（业务选定「最后审核时间」）。取不到审核时间的单回退 `created`，页面 / 导出 / 钉钉该列打 `*`。 - **已发判定补兜底**：订单表 `send_date` 为空、但状态表 `send_time` 有值的，按已发剔除（实测 144 单里 6 单属此类，且有揽收轨迹）。两个方向都不会再冤枉仓库。 - **明细列**：`创建时间` → `审核时间` + `下单时间` 并列，导出同步。 - **钉钉**：明细第五段由「创建」改回「审核」；抬头「核验 XX 前创建」改「前审核」。 - 回归测试同步改断言；stub 增加审核时间查询分支（默认空 = 全量回退 created，老断言继续成立）。 ## 影响（10-28 13:00 轮实测） | | 单量 | |---|---| | 原口径（按 created） | 599 | | 按审核时间分轮 | 144 | | 剔除漏回写已发单后 | **138** | 599 单里 **376 单**是当天 08:10~10:30 才批量审核的积压单（多为 10-17~10-27 创建），**491 单**其实已有运单号。 ## 验收 - 后端 `npm run check`：491/493（2 个失败为既有 Windows 权限 / TTL 用例，改动前同样失败，已 stash 对比确认） - 前端 eslint 通过；build 23.92s 通过 - 本地真渲染：138 单、表头 `内部单号/线上订单号/店铺/发货仓/发货时间/审核时间/下单时间/付款时间/发货状态/物流状态/已等时长`、回退单带 `*`、无 pageerror ## ⚠️ 分支关系本分支基于 `yanhui-wst-rename-1028`（PR #89 纯改名），所以**包含 PR #89 的那个提交**（6a5f6e8）。合并本 PR 后 #89 即可关闭。

yanhui added 2 commits 2026-10-28 15:35:13 +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`：本次只动注释，不影响

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

业务 2026-10-28 下午拿 9837824 指出：页面「创建时间」显示 10-19 23:44，
而该单实际是 10-28 09:58:42 才审核。逐字段核对确认起算点口径错了 ——
上午那版按 jst_Orders.created 算，等于把客服审核积压算到仓库头上。

- 起算点 = 状态表 last_oa_confirm_time（业务选「最后审核时间」）；
  取不到审核时间的单回退 created，页面 / 导出 / 钉钉该列打 *
- 已发判定补一条兜底：订单表 send_date 空、但状态表 send_time 有值的按已发剔除
  （实测 144 单里 6 单属此类，且有揽收轨迹）
- 明细与导出列改为「审核时间 / 下单时间 / 发货时间」并列，去掉旧「创建时间」列
- 钉钉明细第五段由「创建」改回「审核」；抬头「核验 XX 前创建」改「前审核」
- 回归测试同步改断言；stub 增加审核时间查询分支（默认空 = 全量回退 created）

实测（10-28 13:00 轮）：599 → 144（按审核时间分轮）→ 138（剔除漏回写已发单）。
599 单里 376 单是当天 08:10~10:30 才批量审核的积压单，491 单其实已有运单号。

验收：后端 check 491/493（2 个失败为既有 Windows 权限 / TTL 用例，改动前同样失败）；
前端 eslint 通过、build 23.92s 通过；本地真渲染 138 单、表头含「审核时间 / 下单时间」、
回退单带 *、无 pageerror。

yanhui merged commit 85c48ebe77 into main

2026-10-28 15:40:56 +08:00

yanhui referenced this issue from a commit

2026-10-28 15:40:58 +08:00

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

Sign in to join this conversation.

1 Participants

Notifications

Due Date

No due date set.

Dependencies

No dependencies set.

Reference: lunanting/cangku#90