yanhui
54518ab4d3
fix(wst): 把销售出库单纳入作废判据与停更监控
业务 14:34 点名 9992097 / 9992098 / 9992924 / 9992925 / 9992926 /
9993284 / 9993285 / 9995464 / 9995465「洛宁仓 16 单都是作废订单，为啥还在
考核之内」，并指明「在聚水潭的销售出库单里面找一下这个作废单据」。
## 查出来的事实
这 9 单在库里**三处全部显示「还在发货」**：
订单表 qmcust status=Delivering、send_date 空
销售出库单 status=WaitConfirm（待出库）
状态镜像表 order_status_name=发货中、logistics=无物流单
不是判据漏了，是**三条数据源全停在作废动作之前**（2026-10-29 15:13 实测）：
jst_Orders 14:45 正常
qmcust 13:25 滞后 1.8h
状态镜像表 11:52 滞后 3.4h
出库单(聚水潭/奇门) 03:10 滞后 12.0h ← 作废就落在这张表上
聚水潭的作废落在**出库单** `status='Delete'` 上，而这张表今天凌晨 3 点后
零写入，所以上午作的废一条都没进来
## 改动
1. 新增 `loadOrderIoStatus()`：按 o_id 批量取出库单状态（两表、
分批 500 / 并发 3），判据是 **「该 o_id 下没有任何非 Delete 的出库单」**。
- 只对「发货中」生效：全库「出库单全 Delete」的候选单里 127/131
状态表是「异常」，那批还挂着待处理，删出库单更可能是重开单，
当成作废剔会让业务在「不计考核」里也看不到 → 丢可见性比漏剔更糟
- 拆包/重开的单有多张出库单，删一张不算作废（实测 51 单里 7 单是这种）
- **「没有出库单」绝不判作废**：近 3 天未发单 82%（1467/1790）本来就没出库单
2. 两张出库单表纳入 `loadSourceFreshness()`（用 local_updated / updateTime
灌库时刻，**不能用 modified**，否则没变更时天天误报）
3. 新增 `freshness.voidJudgeReliable` + hint 明说「作废单/取消单可能判不出来」，
告诉业务去聚水潭「销售出库单」核对
4. 明细加「销售出库单」列（已作废/待出库/已出库/未建单），导出同步加列
## 验证
- WST 单测 27/27（新增：出库单全删必剔 / 拆包重开不剔 / 异常单不剔 /
无出库单不剔 / 停更时提示作废判不出来 / 源正常时不误报）
- 后端全量 498/500（2 个既有失败：负缓存 TTL、Windows 文件权限）
- 真实数据：ioVoidSkipped=11（发货中 + 出库单全删），overdue 仍 16 单
- 本地真渲染：表头有「销售出库单」、首行显示「待出库」、
红条列出 5 个数据源停更状态、**pageerror 0**
## 没解决（已在页面明说，不掩盖）
这 9 单今天仍然判不出作废 —— 数据没进来，判据再准也没用。
根子在 ETL：出库单表停 12 小时。ETL 恢复后判据立即生效，
但那 9 单是否作废仍需 IT 修同步或业务在聚水潭复核。
2026-10-29 15:16:25 +08:00
..
2026-09-12 11:51:44 +08:00
2026-09-12 11:51:44 +08:00
2026-09-12 11:51:44 +08:00
2026-10-07 16:59:56 +08:00
2026-09-15 16:53:12 +08:00
2026-10-29 15:16:25 +08:00
2026-10-29 15:16:25 +08:00
2026-09-12 16:53:18 +08:00
2026-09-12 17:13:59 +08:00
2026-09-12 11:51:44 +08:00
2026-09-24 11:59:36 +08:00
2026-09-12 11:51:44 +08:00
2026-09-12 11:51:44 +08:00
2026-09-12 21:34:07 +08:00
2026-09-27 14:16:06 +08:00
2026-09-12 11:51:44 +08:00