History

yanhui 4e4f8890c1 fix(wst): 发货时效剔除「已作废」单 —— 问题单 / 发货前售后 / 售后已作废三条兜底

业务反馈 3 单（so_id 3655421011854634 / 3658479011191285 / 110215007857459363）
在聚水潭后台都已作废，却仍出现在「仓储中心 24 小时发货时效」的超时明细里。

根因：
- 页面只认状态表 jst_order_express_details，这三单 order_status_name 仍是「发货中」
  + send_time 为空；售后状态是「暂无售后」—— 上游没把作废同步过来；
- 现有的作废兜底只认订单表 status ∈ Merged/Split/Cancelled 以及 is_merge/is_split，
  覆盖不到 status=Question（聚水潭后台显示「已作废/问题单」）和 labels 含「发货前售后」。

改动：
- registry 新增 VOID_QUESTION_STATUS='Question'、VOID_ORDER_LABEL_KEYWORDS=['发货前售后']、
  AFTERSALE_VOID_STATUS='已作废'；
- 回订单表补事实时增投一个 `CASE WHEN labels LIKE N'%发货前售后%' THEN 1 ELSE 0 END`
  布尔列（不传 labels 原文，避免宽列回表；实测冷查 42.6s，与改前同量级）；
- 状态表主查询增投一列 aftersale_status_name；
- 主循环在「发货中」分支之后判这三种作废证据，命中则并入 voidCount、不进考核。

⚠️ Question 不能直接塞进 VOID_ORDER_STATUS：那个数组在状态分类之前判定，
订单表 Question 的单有一大批在状态表是「异常」，会被从「异常待处理」清单里一起吞掉
（实测 heldCount 472 → 10，少掉 462 单）。故单独放在 SHIPPING_STATUS 之后判。

验证：
- 单测 19/19 通过（新增 38/39/40 三条作废形态用例，锁定 heldCount 不被影响）；
- 真实库 13:00 轮：超时 3 单 → 1 单（9823980 / 9880810 已剔除），
  heldCount 保持 472，voidCount 4442 → 4444（恰好 +2）；
- 剩余 9889575 未剔除：订单表 Delivering、无出库单、无任何作废标记（见 PR 正文说明）。

风险与回退：
- 仅收紧「发货中」分支的作废判定，不回退任何既有判据；
- 若业务认为 Question 单仍需考核，改 VOID_QUESTION_STATUS 一处即可恢复。

2026-10-22 17:54:34 +08:00

cubejs

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

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

database

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

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

model

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

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

scripts

feat: 新增每日进销存业务库校验脚本