forked from lunanting/cangku
yanhui
6a5f6e8ae0
规则完全不动，只改名字，消除误导。 ## 为什么改 页面原名「仓储中心 24 小时发货时效」，但判定规则是「到 13:00 / 18:00 核验时刻仍未发货即超时」，**没有满 24 小时的门槛**（业务 2026-10-20 已三次纠偏定版）。 名字和规则打架，导致看的人以为「不满 24 小时不该算超时」。 实测例子：10-27 16:00 创建的单，今天 13:00 核验时只等了 **21 小时**就被判超时； 13:00 轮 599 单里有 416 单属于 10-27 16 点后创建。业务看到就问「创建时间都在 7 点后， 为什么算超时」—— 其实是名字里的「24 小时」在误导（那些是**昨天**晚上的单， 不是今天的）。 ## 改了什么 用户可见（2 处）： - 侧栏菜单：`仓储中心24小时发货时效` → `仓储中心发货时效` （不加括号：侧栏现有最长 label 12 字，加了会到 18 字溢出） - 页面标题：`仓储中心 24 小时发货时效` → `仓储中心发货时效（到点未发即超时）` 其余为注释同步（8 个文件），代码逻辑与判定口径**零改动**： `warehouseShipTimelinessRegistry/Service/NotifyJob/NotifySettings`、 `warehouseLogisticsExceptionRegistry`、`frontend/api/warehouseShipTimeliness`、`backend/index`。 ## 不变的部分 - 核验时点、窗口上界（07:00 / 16:00）、仓级例外（山东 15:00、洛宁 13:00） - 数据源与起算点（订单两表 + `created`） - 钉钉推送抬头本来就是「【仓储中心发货时效】」，不用改 ## 验证 - 前端 eslint 通过、`npm run build` 通过（31.86s） - 浏览器真渲染（本地 5173，等足 75 秒数据返回）： - 标题 = `仓储中心发货时效（到点未发即超时）` - 侧栏项 = `仓储中心发货时效`，全页 `body` 内已无「24小时」字样 - 数据正常渲染：超时未发 599 单 / 不计考核 849 / 涉及仓库 8 个 / 最久未发 13 天 - 明细「创建时间」列完整显示 `2026-10-27 19:xx` 这类日期，不存在时区错位 - 无 pageerror - 后端 `npm run check`：本次只动注释，不影响
61 lines
2.6 KiB
JavaScript
61 lines
2.6 KiB
JavaScript
import request from './request';
|
||
|
||
// 发货时效要扫两张订单表 + 出库表（rpt 下全是视图），冷启动实测 40~50 秒，
|
||
// 超时必须放大到 3 分钟，否则前端会先断开、后端还在跑。
|
||
const TIMELINESS_TIMEOUT_MS = 3 * 60 * 1000;
|
||
|
||
// 仓储中心发货时效：每个主仓「超时未发」数量 + 超时订单明细
|
||
// params.round 'NOON' | 'AFTERNOON'（不传按当前时刻自动判定）
|
||
// params.limit 明细条数上限
|
||
export const getWarehouseShipTimeliness = (params = {}) => request.get(
|
||
'/api/warehouse-ship-timeliness/list',
|
||
{
|
||
params,
|
||
timeout: TIMELINESS_TIMEOUT_MS,
|
||
headers: { 'Cache-Control': 'no-cache' },
|
||
}
|
||
);
|
||
|
||
// 仅取今日两轮核验的描述（不打订单表，秒回），用于顶部提示
|
||
export const getWarehouseShipTimelinessRounds = () => request.get(
|
||
'/api/warehouse-ship-timeliness/rounds',
|
||
{ timeout: 30000 }
|
||
);
|
||
|
||
// 「超时未发」明细导出：不分页、不截断，返回本轮考核口径内的全部行。
|
||
// 与 /list 共用后端同一份缓存，所以页面刚刷过时这里是秒回；
|
||
// 冷启动（缓存已过期）仍要全量扫视图，超时同样放大到 3 分钟。
|
||
export const getWarehouseShipTimelinessExportRows = (params = {}) => request.get(
|
||
'/api/warehouse-ship-timeliness/export',
|
||
{
|
||
params,
|
||
timeout: TIMELINESS_TIMEOUT_MS,
|
||
headers: { 'Cache-Control': 'no-cache' },
|
||
}
|
||
);
|
||
|
||
// ── 两轮核验完成后推文本到钉钉群（2026-10-27 新增）────────────────────────
|
||
// 通道 = 群自定义机器人 webhook（不发 .xlsx，只发 text；加签密钥可选）
|
||
// 读配置：加签密钥只回掩码（webhookSecretConfigured + webhookSecretPreview）
|
||
export const getShipTimelinessNotifySettings = () => request.get(
|
||
'/api/warehouse-ship-timeliness/notify/settings',
|
||
{ timeout: 30000, headers: { 'Cache-Control': 'no-cache' } }
|
||
);
|
||
|
||
// 保存配置：加签密钥留空 = 沿用已存的，不必每次重填
|
||
export const saveShipTimelinessNotifySettings = (payload = {}) => request.put(
|
||
'/api/warehouse-ship-timeliness/notify/settings',
|
||
payload,
|
||
{ timeout: 30000 }
|
||
);
|
||
|
||
// 立即推送 / 预览正文 / 测试通道
|
||
// dryRun=true 只组装消息不发送（返回正文全文）
|
||
// probe=true 只发一句通道测试，不查业务数据
|
||
// 冷启动要全量扫订单状态视图（生产实测数十秒到几分钟），超时给足
|
||
export const runShipTimelinessNotify = (payload = {}) => request.post(
|
||
'/api/warehouse-ship-timeliness/notify/run',
|
||
payload,
|
||
{ timeout: 10 * 60 * 1000 }
|
||
);
|