lunanting/cangku
1
0
Fork 1
Code Issues Pull Requests 3 Actions Packages Projects Releases Wiki Activity

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

Merged
yanhui merged 1 commits from yanhui-wst-order-source-1028 into main 2026-10-28 13:08:28 +08:00
Conversation 0 Commits 1 Files Changed 6 +696 -868
yanhui commented 2026-10-28 11:36:29 +08:00
Collaborator
Copy Link

目的与范围

业务 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% 早于审核时间，正常单差 740 分钟，夜间下单次日审的单差 69 小时
    —— 换口径后单量与「已等时长」都会变大，业务已知悉。
  • 仓库归属：主查询只回 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 定版：「核验抓取的销售订单表是错误的，应该在数据库抓 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 单）， 这类单现在按正常单算超时；如业务反馈，可单独补查。 - 回退：单文件回滚本提交即可，无数据迁移、无配置变更。
yanhui added 1 commit 2026-10-28 11:36:29 +08:00 
业务 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 单），
  这类单现在按正常单算超时；如业务反馈，可单独补查。
- 回退：单文件回滚本提交即可，无数据迁移、无配置变更。
yanhui merged commit 6c2686784d into main 2026-10-28 13:08:28 +08:00
Sign in to join this conversation.
Reviewers
No Reviewers
Labels
No items
No Label
Milestone
No items
No Milestone
Projects
Clear projects
No project
Assignees
Clear assignees
wangjie Xkh5201314 yanhui youruo lunanting
No Assignees
1 Participants
Notifications
Due Date
No due date set.
Dependencies

No dependencies set.

Reference: lunanting/cangku#88
No description provided.
Delete Branch "yanhui-wst-order-source-1028"

Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?