|
|
cb7d06c20c
|
feat(wst): 数据源停更熔断——订单表停更时醒目标注，别把「没同步」当「没发货」
## 业务问题
10-28 18:00 轮页面核验出 546 单超时未发，业务核对「基本都发了，怎么会核验出未发」。
## 根因（不是判定写错，是数据源停更）
`jst_Orders` 当时**从 14:40 就停止同步了**（停了 4 小时），停更之后发出的单
`send_date` 一直是空，因此全被判成「未发货」：
| 来源表 | 超时单数 | 该表状态 |
|---|---|---|
| `jst_Orders` | 540 | 最后更新 14:40（停 4 小时） |
| `jst_qmcust_orderlist` | 6 | 17:30 正常 |
两个订单表**各自独立同步**，同一天完全可能一个正常一个停更。原来只拿候选行的
`MAX(updated_at)` 判快照滞后，会被「碰巧新」的行掩盖 —— 必须直接问源表。
## 改动
后端 `warehouseShipTimelinessService.js`：
- 新增 `loadSourceFreshness()`：分别直接查 `jst_Orders.MAX(updateTime)` 与
`jst_qmcust_orderlist.MAX(local_updated)`（限轮次窗口起 30 天，避免全表扫描），
两源并行；按 `CANGKU_WST_SOURCE_STALE_MINUTES`（默认 60 分钟）判停更
- 查询失败或取不到更新时间 → **不判停更**（宁可漏报，不谎报为停更）
- 明细行新增 `src` / `srcLabel` / `sourceStale`；`summary` 新增 `sourceStaleUnshipped`
- `freshness.stale` 改为「候选行滞后 **OR** 任一源停更」；`hint` 说清停更源、
停更时刻、以及各源各贡献多少单（不能只写「这张表」）
- 导出数据带 `dataSources`，Excel 脱离页面也有上下文
- 响应新增 `dataSources` 数组（每源 label / lastUpdate / lagMinutes / stale）
前端 `WarehouseShipTimeliness/index.jsx`：
- 红条 Alert：「N 单所在订单表已停止同步，这些单很可能已经发货」（error 级），
描述里逐源列出「最后同步 14:40:05（已 3.9 小时）」
- 超时统计卡下方小字：「其中 N 单数据未同步」（悬停有说明）
- 明细「内部单号」旁「未同步」红标签 + tooltip，一眼看出哪几行不可信
- 导出新增「数据源 / 数据源是否停更」两列（`是（该单可能已发）`）
## 验证
- 后端 `npm run check`：**494/496**，2 个失败是既有环境问题（负缓存 TTL 计时、
Windows 文件权限 0o600），改动前同样失败
- `warehouseShipTimeliness.test.js` **23/23** 通过（含新增「停更表超时单必须打标
并计入 sourceStaleUnshipped」用例）
- 本地真渲染（Playwright + 手签 token，localhost:5173）：
- 真数据：13:00 前 `notStarted` 正常展示「—」，无 pageerror
- mock 停更数据：红条 / 逐源行 / 统计小字 / 3 行「未同步」标签全部渲染，无 pageerror
- 真实接口 10-28 13:00 轮：`dataSources` 正确识别 `jst_Orders` 停更（滞后 96 分钟）
而 qmcust 正常；`sourceStaleUnshipped=1146` 与明细逐行打标同源同口径
## 风险与回退
- 只新增字段与展示，**不改动分轮、起算点、候选池口径** —— 超时单量本身不变
- 阈值可用 `CANGKU_WST_SOURCE_STALE_MINUTES` 调；不配默认 60 分钟
- 低峰期（凌晨）可能出现「1 小时无新单」被判停更，但页面只在 13:00 / 18:00
核验时刻展示超时数据，这两个时点 1 小时不同步即属异常
- 回退：revert 本提交即可，无数据迁移、无新表、无新依赖
|
2026-10-29 08:25:41 +08:00 |
|
|
|
f766549b1a
|
feat(wst): 发货时效两轮核验完成后各推一次钉钉群
业务原话（2026-10-27）：「发货时效也需要钉钉通知：13 点核验 7 点前的超时单，
核验完成后通知；18:00 核验的订单，核验完成后也通知。」
## 做了什么
- 新增 `warehouseShipTimelinessNotifySettings`：配置与状态存取，两个轮次各一个推送时刻
（NOON 默认 13:05 / AFTERNOON 默认 18:05），加签密钥走 resilientSecretStore。
- 新增 `warehouseShipTimelinessNotifyJob`：正文组装 + 每分钟 tick + 启动后 30 分钟补推窗口。
- 路由：`GET/PUT /api/warehouse-ship-timeliness/notify/settings`、
`GET .../notify/state`、`POST .../notify/run`（dryRun / probe / force）。
- `index.js` 注册 `startShipTimelinessNotifyScheduler()`。
- 前端：页面右上「钉钉通知」→ 弹窗（开关、两个时刻、webhook、加签密钥、明细条数、
@所有人、页面链接、受控预览块、上次推送）。顺带把 held 明细弹窗的 `destroyOnClose`
改成 `destroyOnHidden`（antd 5.25 已弃用）。
## 口径要点
- **一天两推，各绑一个轮次**：13:00 轮核验「今天 07:00 前审核」、18:00 轮核验
「截止 16:00 前审核」（都含历史未发）。两轮互不影响，两个时刻配成同一个 HH:mm 时两轮都推。
- **默认核验点 + 5 分钟**，不是整点：状态镜像 `query_time` 要略晚于核验时刻，
整点推容易 `coversDeadline=false`（数据没覆盖核验点、超时数偏大）。
这种时候消息里会带一行提示，仍照发（业务要的是「核验完就通知」）。
- **去重键 `<北京日期>|<轮次键>`**，一天两轮各自独立；推送成功才写状态，失败不写。
- **0 单超时也推**（群里看到「本轮 0 单」= 任务没挂）。
- **明细一行 = 仓｜内部单号｜线上单号｜审核 时间｜已等 X 小时**；
历史单的审核时间带 MM-DD —— 13:00 轮含历史未发单，只写「审核 16:13」会被读成今天。
- 明细按仓聚集 + 每仓保底 1 条，钉钉 text 超长时从末尾砍。
## 验证
- `backend/test/warehouseShipTimelinessNotify.test.js` 新增 17 条，全过。
- 后端 `check-syntax` 通过；`node --test test/*.test.js` 491 条 / 489 过 / 2 失败，
失败两条是既有环境问题（`cloudDatabaseConfigCache` 负缓存用例依赖数据库不可达、
`resilientSecretStore` 的 0600 权限断言在 Windows 恒为 0o666），与本改动无关。
- 前端 `eslint src/pages/WarehouseShipTimeliness src/api/warehouseShipTimeliness.js` 0 错；
`vite build` 通过（含 `verify-router-lazy`）。
- 本地真渲染：页面右上出现「钉钉通知」，弹窗完整渲染、点「预览正文」出正文块，无 pageerror
（验收时把 `/notify/**` 全部 mock —— 本地系统库与生产是同一个，避免写坏生产配置）。
- 本地实数据预览（13:00 轮，冷查 46s）：超时 15 单 / 4 个仓 / 不计考核 672 / 剔除 1；
同一时刻请求 18:00 轮返回 `before_deadline`（未到 18:00 不推半成品）。
## 风险与回退
- 默认关闭（`enabled=false`）且未配 webhook 时一切接口只返回 `not_configured`，不会发消息。
- 想彻底停掉：`DISABLE_WST_NOTIFY=true` 或把推送开关关掉；两者都不影响页面本身。
- 回退：删掉 `startShipTimelinessNotifyScheduler()` 一行即可停调度，新增文件无副作用。
|
2026-10-27 15:43:18 +08:00 |
|
|
|
530d1ad27a
|
feat: 仓储中心发货时效独立页面 + 口径定版（审核时间分轮/快递剔除/停更告警）
一、前端：从 MkhBomData 侧栏抽成独立页面
- 新增 frontend/src/pages/WarehouseShipTimeliness/{index.jsx,style.css}，
路由 /planning/operation/warehouse-ship-timeliness，侧栏导航与 BasicLayout 各加 1 行入口。
- 删除 frontend/src/pages/MkhBomData/WarehouseShipTimelinessSidebar.jsx，
并把 MkhBomData/index.jsx、style.css 里相关代码与样式一并摘除（-131 / -277 行）。
二、业务口径（2026-10-20 业务多次纠偏后的定版）
- 轮次归属改用「审核时间」= jst_order_express_details.last_oa_confirm_time
（聚水潭订单列表「审核时间」列，最后一次审核，重审会刷新）：
13:00 轮 = 今天 07:00 前审核 + 历史未发；18:00 轮 = 截止 16:00 前审核 + 历史未发。
不再按「创建时间」切自然日窗口，也不再有「满 24 小时」门槛。
- 仓级例外（仅 18:00 轮）：山东青岗集仓 / 山东品牌仓 15:00 前审核、河南洛宁仓 13:00 前审核，
核验时刻仍为 18:00（registry 新增 windowEndHourByRound）。
- 明细去掉「创建时间」，改显示「发货时间」（send_time）；未发但有运单号的标「已打单 · 未揽收」。
三、已发判定与不考核快递
- 已发 = 状态表 send_time 非空 OR 订单表 status='Sent'（对齐聚水潭销售订单口径）。
不再用运单号反推（已发货与未揽收单都会出现运单号，判不出来）。
- 自提 / 中铁 / 壹米滴答 三家快递不做未发考核，剔除量计入 summary.carrierSkipped。
四、数据源停更必须让用户看见
- freshness 由写死 stale:false 改为实算：快照距今 >90 分钟 → 黄告警；
快照早于本轮核验时刻 → 红告警「数据未覆盖核验时刻，超时单量偏大」。
五、测试
- backend/test/warehouseShipTimeliness.test.js 扩到 17 用例（仓级例外、重审取 last_oa、
快递剔除、Sent 判已发、coversDeadline 告警）。
|
2026-10-21 07:52:02 +08:00 |
|
