cangku

History

yanhui 776a2cbde2 feat(wst): 发货时效改用订单两表 + 起算点改为订单创建时间

业务 2026-10-28 定版：「核验抓取的销售订单表是错误的，应该在数据库抓
jst_Orders（订单）+ jst_OrderItem（明细），审核时间就是 jst_Orders 里的创建时间」。

## 为什么换数据源（状态镜像表的硬伤，均有实测）

1. `send_time` 漏回写：近 7 天「状态表说发货中+未发」的 4157 单里，
   订单表已有 `send_date` 的 563 单、status 已是 Sent 的 492 单 —— 发了还算超时。
2. 被合并 / 拆单父单不回写：89 + 755 单被冤枉。
3. 会整批停更：2026-10-27 11:54:59 之后 6.8 小时零写入，18:00 轮推出的
   34 单里混着已发货的。
4. 两张表发货时间其实同源：27387 单逐条比对**零偏差** ⟹ 订单表才是权威。

## 改了什么

后端
- 主查询改打 `rpt.jst_Orders` + `rpt.jst_qmcust_orderlist`（店铺互斥，UNION ALL，
  按 o_id 去重），SQL 侧过滤 `send_date IS NULL` + `status IN (Delivering/WaitConfirm/Question)`。
- 起算点由状态表 `last_oa_confirm_time` 改为订单表 `created`；
  实测 created 100% 早于审核时间，正常单差 7~40 分钟，夜间下单次日审的单差 6~9 小时
  —— 换口径后单量与「已等时长」都会变大，业务已知悉。
- 仓库归属：主查询只回 `wms_co_id`，Node 侧用仓表缓存换仓名再走 `resolveCenter()`
  （实测 SQL 里 LEFT JOIN 仓表会把查询从 28s 拖到 61~105s）。
- `OPTION (RECOMPILE)` + 时间字面量：qmcust 不加 RECOMPILE 实测 33~50s，加上 0.4s。
- 删除 `backfillOrderFacts()` 与 `mapLimit()`（起算点/状态/仓名已由主查询一次取全）。
- 不再按 `is_split / is_merge` 过滤 —— 实测 `is_split=1` 恰是拆单**子单**
  （同一 so_id 多行、各自要发货，近 30 天 1096 行），老逻辑 `is_split=0` 会把它们全排掉。
- 钉钉明细第 5 段「审核 HH:mm」→「创建 HH:mm」，无值文案「未审核」→「无创建时间」。

前端
- 明细/挂起清单/导出列「审核时间」→「创建时间」，Tooltip 与说明文案同步改写；
- 顶部说明补「数据源 = 订单两表」「已发未发取 send_date」；
- 「已支付待审核」统一为「待审核」（新数据源里就是 WaitConfirm）。

测试
- 两个测试文件的桩改成「订单两表 UNION」的返回形状，断言改为
  created 起算、候选状态白名单、SQL 必须带 RECOMPILE / 不含状态镜像表 / 不 JOIN 仓表。

## 验证

- `npm --prefix backend run check`：491/493 通过。2 项失败是既有环境问题：
  `resilientSecretStore`（Windows 文件权限 0o666≠0o600）、
  `cloudDatabaseConfigCache` 负缓存 TTL（依赖隧道状态），均与本改动无关，单独跑同样失败。
- 前端 eslint + build 通过。
- 真实库：NOON 1553 单 / AFTERNOON 1866 单（本地 2026-10-28），
  数据质量：无仓名 0 / 时间异常 0 / 含 undefined|null|NaN 0；
  单次查询耗时 35~38s（30 天护栏，冷缓存）。
- 浏览器真渲染（playwright，强制 round=NOON）：
  表头 `…发货时间 / 创建时间 / 付款时间…`、轮次提示「核验今天 07:00 前创建的订单」、
  「导出明细」导出 CSV 表头含「创建时间」共 1551 行数据 + 1 行表头，无 pageerror。

## 风险与回退

- 口径变化是可感知的：单量上升，夜间下单/次日审核的单「已等时长」增加 6~9 小时，
  属业务确认后的预期结果。
- 状态表「售后已作废」判据随换源放弃（实测在「发货中+未发」里只命中 4 单），
  这类单现在按正常单算超时；如业务反馈，可单独补查。
- 回退：单文件回滚本提交即可，无数据迁移、无配置变更。

2026-10-28 11:34:45 +08:00

alibaba1688ImageSearchExpiryJob.test.js

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

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

alibaba1688ImageSearchSettings.test.js

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

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

alibaba1688ProductEncodingService.test.js

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

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

alibaba1688ProductService.test.js

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