History

yanhui 1139e4c364 fix(wst): 用聚水潭状态终态判作废/已发，修「作废单已发单还在考核里」

业务 2026-10-29 第三次报同一件事：13:00 轮里作废的单、已经发货的单还在考核。
根因不是判定写错，而是**订单两表各自停更**，停更期间聚水潭做的「取消 / 发货」
订单表完全看不到 —— status 仍是 Delivering、send_date 仍是空。

## 现场证据（2026-10-29 13:00 轮）

- 当天 qmcust 停在 07:25（6 小时），13:00 轮 159 单**全部**来自它
- 订单表侧：159 单 status 全 Delivering、send_date 全空、labels 里**没有**
  「发货前售后」⟹ 原来的 `presaleVoid` 判据（订单表 labels 含关键词）完全失效
- 状态镜像表（停在 11:52，比订单表新鲜 4 小时）：
  `order_status_name='已取消'` **11 单**，`order_labels` 里才有「发货前售后」
  「已打印被取消」；其余 145 单「发货中」

qmcust 13:25 补数后重算，误判量比想象大得多：
**overdue 159 → 16，作废剔除 195 单、已发剔除 17 单。**

## 改动

判据（新增，排在窗口判断与「不计考核」之前）：

| 判据 | 处理 |
|---|---|
| `order_status_name='已取消'` | 作废，剔除（计 `stateVoidSkipped`） |
| `send_time` 有值 | 已发，剔除 |
| `order_status_name='已发货'` | 已发，剔除 |
| `logistic_status_name` ∈ 已揽收/运输中/派送中/已签收/拒收 | 已发，剔除 |

- `loadOaConfirmInfo` → `loadStateInfo`，同一次 IN 多取 4 个语义列，**不增加往返**
- ⚠️ **判据只用 `order_status_name`**：`aftersale_status_name='已作废'` 是「售后单被撤销、
  订单照常发货」，近 2 天 1387 单全是这种，混为一谈会把该考核的单全放跑
- ⚠️ `未揽收` / `无物流单` **不算已发**（后者是连快递单都没录，当天 39/159 单是这种）
- 状态镜像表纳入 `dataSources` 停更监控（它停了，「取消了吗」的依据就过期了）
- 明细/导出新增「聚水潭状态」「物流状态（聚水潭）」「状态表抓取时间」；
  页面「发货状态」列改优先显示聚水潭终态，与订单表不一致时打 ⚠

## 验证

- 后端 `npm run check` 496/498（2 个失败是老问题：负缓存 TTL、Windows 文件权限）
- WST 单测 **25/25**，新增两组：终态剔除（含「售后已作废不能误剔」的反向保护）、
  状态表纳入新鲜度监控
- 真实数据（本地直连生产 MSSQL，2026-10-29 13:00 轮）：
  `overdue=16 / stateVoidSkipped=195 / stateShippedSkipped=17`，
  明细里「已取消」残留 **0**；剩余 16 单全是河南洛宁仓「发货中 + 无物流单」的真积压
- 作废证据交叉核对：状态表近 2 天「已取消」59263 单，94% 带「发货前售后」标签，
  与业务口径一致

2026-10-29 13:45:41 +08:00

public

Initial public PDD edition without market, Claw, skills or platform switching

2026-09-12 11:51:44 +08:00

scripts

fix(router): 补回 BinReplenishMonitor 的 lazy 声明，修复全站白屏

2026-10-22 12:06:48 +08:00

src

fix(wst): 用聚水潭状态终态判作废/已发，修「作废单已发单还在考核里」

2026-10-29 13:45:41 +08:00

test

fix: reject stale MKH backend responses