|
|
983fee0d8a
|
fix(wst): 起算点改为「审核时间 / 订单 modified 取较晚者」，修 13:00 轮 65 单假超时
## 业务问题
业务举证：13:00 轮不该有那么多单 —— 「9 点前的单 13:00 前已经发完了」。
线上实测 65 单，逐单核对全部不该在 13:00 轮。
## 根因（两个，都指向「起算点取错」）
### ① 状态表的审核时间会严重滞后
业务给的举证单 9978643：
| 字段 | 值 |
|---|---|
| `qmcust.modified` | **2026-10-28 14:52:29** |
| 聚水潭页面真实审核时间 | **2026-10-28 14:52:28**（秒级吻合） |
| 状态表 `last_oa_confirm_time` | 2026-10-27 17:08:43（旧了一天） |
| 状态表 `query_time` | 2026-10-28 10:29:11（10:29 后没再抓） |
只信状态表 → 这单被当成「10-27 就审核了」，混进 13:00 轮超时，冤枉仓库。
### ② 审核时间为空的单回退 created，把今天的单按历史单算
65 单里 57 单状态表审核时间为 NULL。回退 `created` 后：
| o_id | created | modified | 回退后算成 | 真实 |
|---|---|---|---|---|
| 9964841 | 10-26 17:22 | **10-28 13:40** | 10-26 审核 → 进 13:00 轮 | 今天下午才审核 |
| 9949424 | 10-25 17:03 | **10-28 13:50** | 同上 | 同上 |
| 9983773 | 10-27 23:23 | **10-28 13:59** | 同上 | 同上 |
57 单的 `modified` 全部落在今天 13:40~15:03 —— 都是今天下午批量审核的。
## 改动
- **起算点** = `max(状态表 last_oa_confirm_time, 订单表 modified, 订单表 created)`
- 取较晚者：修状态表滞后
- 纳入 created：个别单 `modified` 早于 `created`（脏数据），起算点不该早于下单时刻
- `benchmarkSource` 透出 `oa_confirm` / `modified` / `created`，页面 tooltip 说明来源
- **新增 `laterOf()`**：同格式 `YYYY-MM-DD HH:mm:ss` 直接字典序比较，不转 Date（避开时区坑）
- **主查询 SQL 增加 `x.modified`** 列（订单两表都有，无需额外查询）
## 性能修复（同批，线上 /list 曾 300s 超时）
上版状态表查询**串行 9 批实测 135s**，叠加主查询 63~105s 直接把接口顶过 300s，
页面打不开（实测 curl `--max-time 300` 超时）。改为**并发 6**：
| 方式 | 耗时 |
|---|---|
| 串行 9 批 | 135s |
| 并发 3 | 28.8s |
| **并发 6（本版）** | **10~15s** |
并发 6 是生产实测的安全值（单批约 15s，不至于把 402 万行视图的连接池打爆）。
## 改后效果（10-28 17:00 真实库）
| 轮次 | 改前 | 改后 |
|---|---|---|
| 13:00 轮 | 65 单 | **0 单** |
| 18:00 轮 | — | 927 单（全部今天 07:59~16:00 审核，无历史单） |
- `fallbackToCreated` 从 57 → **0**（不再有回退单）
- 9978643 ✅ 已剔除
- 两个轮次都验证「今天窗口上界之后起算的 = 0」
## 验证
- 后端 `npm run check`：**493/495**（2 个失败是既有环境问题：TTL 计时、Windows 权限，改动前同样失败）
- 新增 2 个测试锁定该口径：
- `modified` 晚于窗口 → 必须剔除（9978643 那类单）
- 状态表审核时间晚于 `modified` → 以状态表为准
- `modified` 早于 `created` → 取 `created`，不倒退
- 前端 lint + build 通过（35.2s）
- 真实库双轮验证通过
## 风险与回退
- **`modified` 被客服改单/改备注刷新**时起算点会推后 → 少报超时（放行方向，不冤枉仓库）。
业务已知悉并接受；这是当前唯一能拿到「今天真实审核时间」的可靠字段。
- 回退方式：`git revert <merge commit>` 即回到只认状态表审核时间的版本。
|
2026-10-28 17:02:54 +08:00 |
|
|
|
e7e0b96b46
|
fix(wst): 起算点改回「最后审核时间」，并剔除订单表漏回写的已发单
业务 2026-10-28 下午拿 9837824 指出：页面「创建时间」显示 10-19 23:44，
而该单实际是 10-28 09:58:42 才审核。逐字段核对确认起算点口径错了 ——
上午那版按 jst_Orders.created 算，等于把客服审核积压算到仓库头上。
- 起算点 = 状态表 last_oa_confirm_time（业务选「最后审核时间」）；
取不到审核时间的单回退 created，页面 / 导出 / 钉钉该列打 *
- 已发判定补一条兜底：订单表 send_date 空、但状态表 send_time 有值的按已发剔除
（实测 144 单里 6 单属此类，且有揽收轨迹）
- 明细与导出列改为「审核时间 / 下单时间 / 发货时间」并列，去掉旧「创建时间」列
- 钉钉明细第五段由「创建」改回「审核」；抬头「核验 XX 前创建」改「前审核」
- 回归测试同步改断言；stub 增加审核时间查询分支（默认空 = 全量回退 created）
实测（10-28 13:00 轮）：599 → 144（按审核时间分轮）→ 138（剔除漏回写已发单）。
599 单里 376 单是当天 08:10~10:30 才批量审核的积压单，491 单其实已有运单号。
验收：后端 check 491/493（2 个失败为既有 Windows 权限 / TTL 用例，改动前同样失败）；
前端 eslint 通过、build 23.92s 通过；本地真渲染 138 单、表头含「审核时间 / 下单时间」、
回退单带 *、无 pageerror。
|
2026-10-28 15:34:29 +08:00 |
|
|
|
6a5f6e8ae0
|
refactor(wst): 页面名去掉「24 小时」，改为「发货时效（到点未发即超时）」
规则完全不动，只改名字，消除误导。
## 为什么改
页面原名「仓储中心 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`：本次只动注释，不影响
|
2026-10-28 14:30:54 +08:00 |
|
|
|
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 |
|
|
|
f749bcc03c
|
feat(wst): 超时未发加「导出明细」+ 武进安能不考核 + 钉钉明细带快递；修复推送时区
① 导出明细（业务要求：超时未发要能导出核对）
· 新增 GET /api/warehouse-ship-timeliness/export：不分页、不截断，返回本轮全部行
· 页面「超时未发货订单」卡片右上角加「导出明细」下拉（Excel / CSV）
· 选中某个仓时只导该仓（前端按 centerKey 过滤，与后端主仓归属同一套）
· 导出列比页面多「快递公司 / 运单号」（追单要看有没有打单），单号一律转字符串
避免 Excel 显示成科学计数法
② 缓存改成「存全量、出口截断」
· 缓存键去掉 limit（原为企业级教训：WLE 核验缓存早就这么改了）
· 页面 limit=1000、导出要全量，旧实现两边永不命中 → 每点一次导出重查一遍视图
· 实测：首次查询 86.3s，导出命中缓存 5ms
· 顺带修 detailTotal / heldTotal：明细被截断时页面仍显示真实总数，
不再把「只显示前 1000 条」写成「一共就这么点」
③ 不考核快递追加「武进安能」（业务 2026-10-27）
· 包含匹配，同时覆盖「武进安能大件」
· ⚠️ 严格不泛化成「安能」：实测库里带「安能」的有 8 个写法，
常州安能新 4207 单 / 安能物流 110 单等仍照旧考核（与
warehouseLogisticsExceptionRegistry 同一口径，那里也写着这句）
④ 钉钉推送明细行在「线上单号」后加「快递」
· 一行 = 仓｜内部单号｜线上单号｜快递｜审核 时间｜已等 X 小时
· 群里直接能判断是哪家快递、要不要走站点，不用回页面逐单点开
· 「已剔除 N 单不考核快递」的快递清单改成读服务层，别再各写一份
⑤ 修复推送任务时区（生产容器 /etc/timezone = Etc/UTC）
· 症状：pushShipTimelinessNotify 把裸 new Date() 传给 getShipTimeliness，
而 service / registry 内部用 getDate()/getHours() 直读 →
北京 13:05 = UTC 05:05，被判「未到 13:00 核验时间」→ 两轮推送永不触发
· 改法：rawNow（真实时刻，给 Intl / toISOString）+ bjNow（平移后，
给本地 getter 与 service 调用）双轨，与 2026-10-21 那次同源问题的修法一致
|
2026-10-27 16:29:08 +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 |
|
|
|
dd58364593
|
fix(wle): 转仓代发（转x00005）不再计入原仓发货量
业务 2026-10-24 补充口径：转仓单的货不是从记账仓（原仓）走的，
原仓的发货量也不该算 —— 记在原仓分母里只会把分母做大、把异常率稀释。
## 改了什么
原先 PR #84 把转仓代发当「只摘异常、保留分母」（与现场拦截同类）。
这次把判定从「异常判定之后」**提到发货分母计数之前**，改成**整单不计**：
| | 改前（PR #84） | 改后 |
|---|---|---|
| 算异常 | ❌ | ❌ |
| 进原仓发货分母 | ✅ | ❌ |
| 归类 | 独立一行「另有 N 单」 | 并入「本批已剔除 N 单」 |
判定逻辑只挪了位置，`matchTransferWarehouse()` 本身没变
（`/转\s*[xX]\s*\d{3,}/`，仍不写死 `转x00005`）。
## 三处文案同步
- 前端页脚：删掉原来「仍计入发货分母、只是不再报异常」的独立段落，
改为并入「本批已剔除 N 单（……转仓代发 N 单）」，口径句也改成
「不算本仓异常，也不算本仓发货量」。
- 钉钉正文：转仓代发并入「已剔除 N 个包裹（承运商 / 已终止 / 刷单·信誉单 / 转仓代发）」，
删掉「另有 N 个包裹属转仓代发」那一行。
- registry 注释同步更新，明确写清**与现场拦截的区别**：
现场拦截是本仓发的货（留分母），转仓代发不是（不留分母）。
## 验证
- 后端单测 50/50。`转仓代发整单不计` 用例改为断言：
`exceptionPackages=1`、**`packageCount=1`**（不是 2）、`shippedOrders=1`，
崔桥仓 `shippedOrders=1 / exceptionOrders=1`。
- 全量 `npm run check` 474 项 / 472 过（2 项为既有环境失败：Windows 权限位、负缓存需隧道故障态）
- 前端 eslint 0；`npm run build` 通过
- **真实库（10-23 批）**：发货包裹 5337 → **5332**（扣掉 5 个转仓包裹），
异常 15 单不变，异常率 0.3%；转仓剔除 `packages=5 orders=5 {"转x00005":5}`；
崔桥工厂仓 发货单 2824 / 异常 6 / 0.2%。
## 影响面
- 分母会略微变小（10-23 批 -5 个包裹，约 0.09%），异常率理论上有微幅上升，
但剔掉的本来就是「必然异常」的假单，整体更准。
- 与现场拦截的口径现在明确分家：**现场拦截留分母，转仓代发不留**。
|
2026-10-24 12:25:29 +08:00 |
|
|
|
e02d1f6d66
|
fix(wle): 转仓代发（转x00005）不算转运异常 + 导出复用页面缓存
两件事，都是 2026-10-23 业务反馈直接引起的。
## 1. 转仓代发不再核对异常
业务反馈：崔桥工厂仓的单 351668937728 被判「未揽收」异常，快递却是「曹县韵达小件」，
而且这单在后台是信誉订单。
实查宽表：这单 `warehouse_name=简尚-崔桥工厂仓`，但 `order_labels` 里带一条
`转x00005` —— 聚水潭「转仓」操作留下的痕迹。记账仓还是崔桥，货却由目标仓
（x00005 = 曹县）实际发出，承运账号也跟着变成曹县韵达小件。结果就是原仓的
物流状态永远停在「未揽收 / 无物流单」，报出来全是假异常。
判据：`order_labels` 命中 `/转\s*[xX]\s*\d{3,}/`（不写死单个编码，后续可能出现
x00006）。实测近 30 天 12 仓：`转x00005` 438 单，报未揽收类 46 单（已签收 371 /
无物流单 31 / 运输中 20 / 未揽收 15）；快递分布 曹县韵达小件 133、邮政快递包裹POSTB 124。
口径要点：
- 与「转空包」（信誉单，发空包）严格区分 —— 转仓是**真发货**，只是不从记账仓发；
- 所以**保留发货分母**，只从异常清单摘掉（与「现场拦截」同类，不稀释异常率）；
- 新增 `exclusions.transferPackages/transferOrders/transferReasons`，
前端页脚与钉钉正文各加一行说明。
## 2. 缓存键只按核验日（修导出卡顿）
原来键是 `${核验日}|${limit}`：页面传 1000、导出传 5000 → 两份缓存互不命中，
点一次导出就要把整轮重算一遍。可 `limit` 只影响最后 `slice(0, limit)`，
异常实际才几十行，扫库成本一模一样。
改为：缓存只存**全量明细**（键 = 核验日），limit 在出口 `finalizeDetail()` 里截断。
生产实测（修复前，容器内直调）：页面冷启 189s、命中缓存 0ms、
**页面已缓存时点导出仍要 317s**；修复后导出复用页面结果 1~3ms。
## 验证
- 后端单测 50/50（新增：转仓标签识别 8 条断言、转仓单不进异常但进分母、
导出复用页面缓存不重查、小 limit 不污染缓存）
- 全量 `npm run check` 474 项 / 472 过，2 项为既有环境失败（Windows 权限位、负缓存需隧道故障态）
- 前端 eslint 0、`npm run build` 通过（含 router lazy 静态检查）
- 真实库（10-23 批）：异常 73 单，转仓剔除 1 单（正是 9894520），目标单已消失；
导出在页面加载后 3ms 返回 73 行
|
2026-10-23 10:46:26 +08:00 |
|
|
|
538f8edcbf
|
Merge remote-tracking branch 'origin/main' into yanhui-wle-intercept-20261023
|
2026-10-23 08:44:48 +08:00 |
|
|
|
c9e84f2151
|
Merge pull request 'fix: 缺货补货监控改为只统计待发订单（排除已发/取消/拆单/合单），不限日期' (#81) from codex/lunanting-bin-replenish-pending-004 into main
|
2026-10-23 08:43:38 +08:00 |
|
|
|
9d80b4c73e
|
fix(wle): 现场拦截（售后已签收）不再算仓储物流转运异常
业务口径（2026-10-23）：发货后被快递当场拦下、货被售后仓签收的单，物流环节
其实已经结束，不该报「转运异常」。判据 = 售后单**签收单号 `l_id` 非空** 且
明细**实退数量 `r_qty` 合计 > 0**。
改动：
- registry 新增 INTERCEPT_AFTERSALE_SOURCES，登记两张互斥的店铺售后表
（jst_returnAndRefundInfo/Item、jst_qmcust_refundlist/Item）；
- service 新增 loadInterceptedOrders()，在主循环前一次性批量判定：
· 只查「本来会报异常」的 oId（9800 单 → 几十单）；
· 两张表**并发**查（两表在 rpt 副本里都是堆表，全表扫 4.5s + 8.5s，并发后取 8.5s）；
· 售后表查询失败自动降级为「不剔除」，不让整页挂掉；
- 命中即从异常清单摘掉，但**保留发货分母**（货确实发出去了），异常率不被放大；
- exclusions 新增 interceptPackages/Orders/Reasons，页面页脚与钉钉推送各补一行说明。
实测（2026-10-22 批次）：异常 36 → 33，剔除 3 单（9854409/9850736/9858367，
全是「拒收退货 + 实退 1 件 + 签收单号=原运单号 + 卖家已收货」）；
10-21 批次剔除 2 单；同时 r_qty=0 的 9859198/9871523 正确地没被剔。
验证：
- node --test warehouseLogisticsException(+Notify)：47/47 通过；
- 本地 5173 真渲染：表格 33 行、页脚显示「另有 3 单属现场拦截（售后已签收）」、无 pageerror；
- 后端 npm run check：469/471，2 个失败为既有平台差异（secretStore 权限位、cloudDatabase 负缓存）。
|
2026-10-23 08:43:35 +08:00 |
|
|
|
e43f17fde4
|
fix: 缺货补货监控改为「崔桥主仓·仅当日待补」并修正指标
- 看板只展示当日待补 SKU（待发订单>拣货位库存，需存储→拣货补货），去除充足/无待发干扰行
- 库存收紧到崔桥工厂仓主仓（jst_packInventoryInfo 加 wh_id=1），数据源对齐「箱及仓位库存·主仓」
- 补齐「有打单拣货待发单但货位库存视图无记录」的 SKU（拣货位为0也应进待补明细）
- 指标卡改为四项：实时代发订单数 / 拣货库存数 / 存储库存数 / 缺货数（缺货=待补SKU数，脚注含存储不足子项）
- 各库底待补明细=need+short 行；范围筛「待补货/仅缺货」；移除多仓选择器，固定崔桥
- 待发订单仍取 op_OrderNotDispatched 打单拣货/发货中 每日快照（两步 querySlow）
- 副本实测：当日快照待补 45 SKU（need42/short3），待发132件/拣货40件/存储2381件/缺口5件
|
2026-10-23 08:35:11 +08:00 |
|
|
|
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 |
|
|
|
5b0c44c9e2
|
fix: 缺货补货监控「待发订单」改为聚水潭打单拣货/发货中快照口径
- loadPendingOrderMap 改用两步 querySlow（先取该仓最新快照日，再按日汇总 status='发货中'），
替换会 60s 超时的 CTE+CROSS JOIN 写法（副本库实测 ~12s 返回 697 SKU/1598 件）
- 待发口径对齐用户在聚水潭「打单拣货 → 简尚崔桥工厂仓」看到的发货中单据（每日 07:00 快照）
- 仅聚水潭线上店铺渠道，不含全民(qmcust) B2B 客户单（属预期收窄，前端已注明）
- 前端口径说明补充渠道范围与「不含全民」提示
|
2026-10-22 16:22:02 +08:00 |
|
|
|
d74b4b649a
|
fix: 缺货补货监控改为只统计待发订单（排除已发/取消/拆单/合单），不限日期
[Do] try bracketed context
|
2026-10-22 15:07:29 +08:00 |
|
|
|
a0b075dfdd
|
fix: 修正缺货补货监控 summary 中「今日无单」计数（no_order 与 noOrder 键不一致导致漏计）
|
2026-10-22 14:07:22 +08:00 |
|
|
|
88913260a3
|
Merge pull request 'feat(wle): 钉钉推送明细按仓聚集，并给每个仓保底 1 条' (#79)
|
2026-10-22 14:04:50 +08:00 |
|
|
|
fe195114e4
|
feat(wle): 钉钉推送明细按仓聚集，并给每个仓保底 1 条
业务要求：推送明细「按照仓库来，相同仓库排序在一起」，方便各仓在群里只看自己那一段。
改动：
1. 明细按仓分桶后连续输出（groupRowsByWarehouse / bucketRowsByWarehouse）
- 组间：按该仓异常包裹数降序，与上面「按仓（异常包裹）」块顺序一致；数量相同按首次出现顺序
- 组内：保持服务层原顺序（已按 pendingHours 降序，压得最久的排最前），不重新排序
- 仓名缺失的行统一归到「未知仓」一组，不会被拆成散行
2. 取前 N 条改为按仓配额（pickDetailRows）
- 真数据验证时发现：140 条异常里山东青岗集仓占大头，直接 slice(0,40) 会让
40 条明细全是同一个仓、其它 6 个仓一条都看不到
- 规则：仓数 >= 额度时每仓 1 条（砍掉异常最少的仓）；否则每仓先保底 1 条，
剩余额度按各仓剩余条数比例分（最大余数法，总数正好等于额度）
3. 明细仍是 4 段「仓｜快递单号｜快递｜异常类型」，编号全局连续，不带时间/时长
验证：
- 单测 19/19 通过（新增 4 条：同仓相邻+组内不乱序、未知仓归组、大仓不吃满额度、额度少于仓数）
- 本地真数据干跑（140 条异常 / 列 40 条 / 4219 字节）：明细覆盖 7 个仓，
同仓全部相邻、无任何仓被拆散；明细段数集合 [4]
各仓条数：青岗集 31 / 崔桥 2 / 洛宁 2 / 睢宁 2 / 山东品牌 1 / 新苏北 1 / 崔桥品牌 1
- backend check-syntax：194 文件通过
风险与回退：只改推送正文的组装顺序与取数配额，不动查询、不动页面列表；
页面仍按时长降序展示全部明细。回退只需 revert 本提交。
|
2026-10-22 14:02:43 +08:00 |
|
|
|
c374cbc713
|
feat: 缺货补货监控改为订单驱动（崔桥当日订单>拣货位库存即需从存储位补货）
- 货位口径按前缀：XA/XD/XE=拣货位，XX/X9/X5/X4=存储位
- 判断逻辑改为当日订单量>拣货位库存的超出部分=需从存储位补到拣货位的量（上限存储位库存）
- 订单取自 rpt.jst_Orders/jst_qmcust_orderlist（含组合装展开），按最近订单日
- 状态：需补货/存储不足/拣货位充足/今日无单；移除旧的货位清单导入（前缀规则取代）
- 前端列与说明同步更新
|
2026-10-22 14:01:35 +08:00 |
|
|
|
e9923d7383
|
Merge pull request 'fix(wle): 钉钉推送明细精简为「仓｜快递单号｜快递｜异常类型」' (#76) from codex/yanhui-wle-detail-no-time-20261022 into main
|
2026-10-22 13:10:31 +08:00 |
|
|
|
7939816b64
|
fix(wle): 推送明细再去掉末尾「待处理小时数」
业务三次要求（2026-10-22）：明细最后面的超时时间也不要。
- buildDetailLine 现在是 4 段：仓｜快递单号｜快递｜异常类型
- 删除仅此处使用的 formatHours()（不留死代码）
- 「无快递单号时退回内部单号」的兜底按业务确认保留
- 文件头/函数注释补第三条口径，单测断言正好 4 段且不含 17.3h 这类时长
|
2026-10-22 11:56:11 +08:00 |
|
|
|
b223db7961
|
fix(wle): 推送明细第二列改为快递单号
业务二次要求（2026-10-22）：明细里显示快递单号，不要内部单号。
- buildDetailLine 第二段从 `oId` 改为 `trackingNo`（上游 `logistic_id`）
- 未揽收 / 无物流单的包裹本来就没有快递单号 → 退回 `oId`，
否则这条在群里无法定位（不让它变成「无单号」）
- 单测：样例带 trackingNo 并断言内部单号不出现；补「无 trackingNo 时退回 oId」用例
- 文件头与函数注释同步口径
|
2026-10-22 11:46:06 +08:00 |
|
|
|
57debbe022
|
fix(wle): 钉钉推送明细去掉发货时间列
业务反馈（2026-10-22）：推送明细里不需要发货时间。
- buildDetailLine 从「仓｜内部单号｜快递｜异常类型｜发货时间｜待处理」
改为「仓｜内部单号｜快递｜异常类型｜待处理小时数」
- 删除仅此处使用的 shortTime() 及其导出，不留死代码
- 文件头补口径说明，防止以后把 sendTime 加回去
- 单测同步：断言新列序，并显式断言消息里不出现 sendTime（传了也不能渲染）
|
2026-10-22 11:40:11 +08:00 |
|
|
|
a15f289ec6
|
fix: 补回 binReplenishRoutes 引入，修复后端启动失败
|
2026-10-22 11:14:00 +08:00 |
|
|
|
55b755c1d9
|
feat: 新增「缺货补货监控」看板（拣货位缺货 → 从存货位补货）
数据源：聚水潭「箱及仓位库存」rpt.jst_packInventoryInfo（副本里是视图，
按 SKU+货位聚合单次 35~45s，因此服务端缓存 10 分钟 + 启动预热）。
口径：
- 拣货位：按业务导入的货位清单判定（本地表 bin_replenish_pick_bin，按仓库隔离）；
副本没有货位类型主数据，未导入时回退为 pack_type='Bin' 的记录，页面明确标注。
- 拣货位库存 / 存货位库存 / 现有库存合计；
- 目标库存 = max(10, 近15天日销 × 目标天数(默认7))；
- 建议补货量 = min(存货位库存, 目标 − 拣货位库存)；
- 状态：拣货位缺货 / 无货可补 / 拣货位偏低 / 未设拣货位 / 正常。
「未设拣货位」单列，避免把整箱直发商品误报成缺货。
后端：binReplenishService + binReplenishSchema + /api/bin-replenish
（list / export / pick-bins GET-POST-DELETE / ping），建表与预热挂在 localSchema。
前端：/planning/operation/bin-replenish-monitor 页面、侧栏入口、页面权限注册，
含 KPI 卡、状态分段筛选、关键字搜索、目标天数、货位清单导入/清除、服务端导出。
|
2026-10-22 11:08:20 +08:00 |
|
|
|
bdc2cf9fd6
|
feat(wle): 仓储转运异常每天定点推文本到钉钉群
在「仓储中心物流转运异常」页新增「异常通知」：每天 09:10（可改）把当天核验批次
的异常情况以**文本消息**推到钉钉群，0 条也推（用来确认任务没挂）。
为什么是 text 而不是 Excel 附件：钉钉群自定义机器人 webhook 只支持
text/markdown/link/actionCard，发文件必须走企业内部应用（AppKey/AppSecret/
robotCode/openConversationId 四项凭据 + 应用权限 + 机器人进群）。业务确认
「群里看文本就够，要明细点链接去页面导出」，于是走最轻的 webhook。
后端
- 新增 services/dingtalkRobotWebhookSender.js：POST /robot/send + msgtype=text
· 加签 urlEncode(base64(HmacSHA256(secret, "timestamp\nsecret")))，timestamp 毫秒
· text.content 按 UTF-8 **字节**截断到 20000（钉钉硬上限），不切半个汉字
· webhook 严格匹配 ^/robot/send$ 且必须有 access_token；errcode/errmsg 原样抛
- 新增 services/warehouseLogisticsExceptionNotifySettings.js：
· webhookUrl 存在 system_config（完整回显，业务要核对）；加签密钥走
resilientSecretStore，接口只回 configured + 掩码，留空=沿用已存
· sendTime 非法退回 09:10；maxDetailRows 0~50 默认 30
· 状态 lastSentDate（按推送日去重）等存 system_config
- 新增 jobs/warehouseLogisticsExceptionNotifyJob.js：
· buildNotifyText：抬头【仓储物流转运异常】→ 发货/包裹/异常/异常率 → 分类型
→ 剔除数 → 按仓（只列有异常的仓）→ 明细前 N 条 → 页面链接（带 date）
· 明细行「仓｜内部单号｜快递｜异常类型｜发货时间｜待处理」，字段内换行压平
· 超长从明细末尾逐条砍并标记 truncated（truncated 只表示被字节上限砍过，
不表示「按配置只列前 N 条」）
· 每分钟 tick 比对北京时间 HH:mm == 配置 sendTime，改时间不用重启
- api：GET/PUT /notify/settings、GET /notify/state、POST /notify/run
（dryRun 预览不校验凭据；probe 只发一句测试文本、不查业务数据）
前端
- 「导出」右侧新增「异常通知」（铃铛）弹窗：开关、推送时间、Webhook、加签密钥、
明细条数、@所有人、页面链接、上次推送结果、三段帮助说明
- 「测试通道」「预览正文」「保存」「立即推送到群」
- 预览改成弹窗内受控区块：本项目跑 React 19 + antd v5，Modal.info 静态方法
拿不到 context 会**静默不渲染**（只留一行 warning，看着像后端没返回）
同步与兼容
- 新配置首次读取为空 → ready=false，页面提示「Webhook 地址还没配」，不影响页面其它功能
- 定时任务只在 enabled=true 时生效；本地 ENABLE_BACKGROUND_JOBS=false 不跑，用页面按钮验
验证
- backend/test/warehouseLogisticsExceptionNotify.test.js 15/15：正文结构与数字、
0 条平安消息、条数上限、字节精简、Webhook 校验、加签 crypto 手算对齐、errcode 透传
- 后端全量 465 项 / 463 过（2 项既有环境失败：Windows 权限位、负缓存需隧道故障态）
- 前端 eslint 0、build 成功
- 真数据干跑：144 条异常 / 列 30 条 / 3768 字节 / 20s，按仓包裹数合计 144 对得上
- playwright 真渲染：弹窗字段 Webhook/加签密钥/明细条数/@所有人/页面链接，
旧字段 AppKey/AppSecret/robotCode/群会话 ID 零残留；预览内联渲染出正文
风险与回退
- 钉钉侧失败只会记 lastState.lastError 并在页面展示，不影响页面取数
- 回退：删除 index.js 里的 startWarehouseLogisticsExceptionNotifyScheduler 注册即可停推送
|
2026-10-22 11:00:10 +08:00 |
|
|
|
85e2db9f92
|
feat: 仓储中心物流转运异常页新增「导出异常明细」（Excel / CSV）
- 后端新增 GET /api/warehouse-logistics-exception/export：复用列表同一套口径
（getLogisticsExceptions），只把明细上限从列表 2000 放宽到 5000，不分页，
判定/剔除逻辑一行未改，避免「导出与页面两套口径」。
- 结果缓存由单槽改为按 `核验日|明细上限` 分键的 Map（上限 8 条）：
页面按默认条数取、导出按 5000 取，单槽会互相踢掉 —— 导出一次，页面下次
自动刷新就得重查库（20~40s）。分键后两者互不影响。
- 前端把明细过滤抽成 filterDetailOrders，表格与导出共用同一个函数，
保证「导出的就是页面看到的」。
- 导出列单独定义 EXPORT_COLUMNS（13 列纯文本标题）：页面列用了 Tooltip，
直接复用列定义会把表头导出成 [object Object]；运单号/物流状态/最后轨迹
为空时导出为「无运单号 / 无状态 / 无轨迹」，Excel 里不留空格。
- 导出跟随当前核验日 + 选中仓 + 选中异常类型；文件名带核验日与筛选范围
（仓储物流转运异常_<核验日>_<仓>_<类型>）；0 行时提示且不生成空文件；
超过 5000 行时如实提示「已截断」。导出按钮做 loading，防重复点。
- 测试：新增 2 个用例 —— ①导出行数等于异常包裹数、字段齐全、带剔除口径；
②缓存按 limit 分键（页面 1000 条那份不被导出 5000 条顶掉）。
warehouseLogisticsException.test.js 26/26 通过。
口径未变：承运商剔除（顺丰系全剔、京喜京东、睢宁中通按仓、武进安能/中铁/
壹米滴答/自提/线下/商家配送）、订单终止与刷单信誉单剔除、异常 5 类判定，
全部沿用 #71 已合并版本。
|
2026-10-22 09:58:22 +08:00 |
|
|
|
db1ba79416
|
feat: 新增「仓储中心物流转运异常」页面（12 发货仓 · 每日 09:00 核验前一日已发货物流）
- 后端新增 warehouse-logistics-exception 模块（Registry / Service / Api），
挂载 /api/warehouse-logistics-exception；前端新增独立页面并接入左侧栏
「仓储中心物流转运异常」（排在「仓储中心 24 小时发货时效」下面）。
- 核验口径：核验日 09:00 看**前一日已发货**订单的物流记录；12 个发货仓按仓库名
最长匹配归口（子仓并入主仓，「京仓-横林二仓京东云仓」排除）。
只统计揽收前的卡点：无物流单 / 未揽收 / 已揽收未中转 / 快递报异常 / 退回；
运输中、派送中、已签收一律正常（干线与中转轨迹本就不回传，不再按 24h 判停滞）。
明细按包裹、汇总按内部单号去重；结果缓存 5 分钟，force=1 可绕过。
- 剔除口径（业务 2026-10-21 / 10-22 定版，剔掉的既不算异常也不算发货分母）：
· 承运商：顺丰系全部（唯品顺丰 / 顺丰干配 / 顺丰大件各账号）、武进安能、中铁、
壹米滴答、京喜京东（快递·快运）、自提、线下、商家配送；
· 有条件剔除：睢宁中通只在睢宁仓考核，其它仓异地打单的剔出；
· 订单已终止：状态含取消/作废，或标签含「发货后取消」「作废」「拦截」；
· 刷单 / 信誉单：订单标签含「刷单」「转空包」。
「武进安能」「京喜京东」均按精确粒度匹配，不泛化成「安能」「京东」，避免误剔
常州安能新、京东自营快递亿家达等正常账号。
- 时区：模块内统一用 Asia/Shanghai 取「今天」，避免生产容器 Etc/UTC 导致核验批次错位。
- 页面：分仓统计卡 + 异常类型筛选 + 明细（承运商 / 运单号 / 物流状态 / 异常标签 /
最后轨迹 / 发货时间 / 待处理小时），页脚展示剔除口径与本批剔除量；
物流快照停更按黄/红两级告警，并标注「历史批次按当前物流快照重算」。
验证（本地隔离环境，非生产库）：
- node --test backend/test/warehouseLogisticsException.test.js → 24/24 通过
- npm --prefix frontend run check → 通过
- 本地真实数据接口实测：顺丰系、睢宁中通（异地仓）明细 0 条残留
|
2026-10-22 09:07:49 +08:00 |
|
|
|
f42f461430
|
fix: 仓储发货时效按北京时间取「今天」（生产容器是 UTC，每天 00:00~08:00 轮次错位）
问题（2026-10-21 生产实测，PR #69 上线后发现）：
- 生产容器 `/etc/timezone = Etc/UTC`、`date` = UTC；而 MSSQL `GETDATE()` 返回北京时间，
mssql 驱动 `useUTC:false` 把 DB 值构造成「墙钟当 UTC」的 Date ⇒ 比真实 now 快 8 小时。
- 于是**北京时间每天 00:00~08:00，服务端 `new Date()` 取到的「今天」是昨天**：
round.date / deadline / windowEnd 整体错位。
实测 08:04 跑 13:00 轮得 `overdueUnshipped=3895`（历史未发池被整段纳入），
而本地（东八区）同一轮只有 6 单。
修法（只动这一个模块，不动容器时区）：
- registry 新增 `beijingNow()`：把真实时刻平移成「本地 getter 读出来正好是北京时间」的 Date，
本机已是东八区时平移量为 0，行为不变。
- `resolveActiveRound` / `describeRounds` 的 now 默认值改为 `beijingNow()`；
service 的 `getShipTimeliness` 同样改用 `registry.beijingNow()`。
- ⚠️ 没改容器 TZ：`/opt/cangku/shared/backend.env` 里没有 TZ，改了会波及全部既有定时任务
（dailyRefresh / dailyInventorySnapshot 等都各自显式写了 Asia/Shanghai）。
测试：
- 新增 2 个用例（跨日 00:00~08:00 不取成前一天；默认按北京时间判定 13:00 前 notStarted）。
- `node --test backend/test/warehouseShipTimeliness.test.js` → 19 / 19 pass。
|
2026-10-21 08:17:52 +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 |
|
|
|
893f4d6aca
|
feat: 新增「仓储中心24小时发货时效」侧栏（11 个主仓 · 12:00/16:00 双轮核验）
需求（yanhui 2026-10-20）：在 MKH-BOM 列表左侧加一栏「仓储中心24小时发货时效」，
下列 11 个主仓（横林二仓、横林三仓、横林二仓品牌仓、崔桥工厂仓、崔桥工厂品牌仓、
崔桥工厂半成品仓、新苏北仓、睢宁仓、山东青岗集仓、山东品牌仓、河南洛宁仓），
从系统库存抓取已发货/未发货订单，按订单创建时间判定发货是否及时：
· 每天 12:00 核验「当天创建时间 7:00 之前」的订单是否已完成发货
· 每天 16:00 核验「当天创建时间 16:00 之前」的订单是否已完成发货
已确认的三条设计决策：
1. 子仓归属 → 连子仓一起算（京东云仓/自营仓/运营C专用仓/唯品仓等并入主仓）
2. 崔桥工厂半成品仓 → 系统无同名仓，先留空占位（不映射到配件仓 15718196）
3. 展示结构 → 只显示超时未发
实现要点
- 仓库归属用「关键词最长匹配」（不写死 wms_co_id），新增子仓只要名字含主仓关键词
就自动归入，缓存 1h。实测 28 个子仓全部正确归入 11 个主仓，132 个代发仓零误并。
- 12:00 之前**不做核验**：resolveActiveRound 返回 null，服务层直接返回 notStarted，
既不查订单表（接口 165ms）也不回填昨天的数据。前端显示「未到核验时间」+
「12:00 开始首轮核验（核验当日 07:00 前创建的订单）」，11 个仓结构保留、数字显示「—」。
- 订单取数：两张表店铺互斥（jst_Orders = 京东/拼多多/抖音/得物/唯品会，
jst_qmcust_orderlist = 天猫/淘宝/1688），并行分开查 + Node 侧按 o_id 去重合并，
用 Promise.allSettled 保证单表失败时另一表数据仍可用（detailDegraded 标记）。
- 三态判定 pending / shippedLate / onTime：send_date 与出库表 io_date 取先到的发货痕迹，
避免上游 send_date 回写滞后导致「已发的被判成没发」。
- 状态过滤：排除 Cancelled / Merged / **Split**（拆单父单永不发货，不排除会捞出一年前
1.3 万条历史单），Question 仍计入待发。
- freshness 字段如实报告出库表最新 io_date，前端「发货数据可能滞后」告警，
不拿一份可能滞后的数据去考核仓库。
排除的两次错误优化（均在代码注释里留了实测数据与复测脚本路径）
1. 用 created 替代 order_date 做窗口过滤（快 10 倍）—— 已证伪：2581 行里完全相等的只有 4 行，
差 >1h 的 412 行，198 行跨日；典型形态 order_date=10-18 23:58 而 created=10-19 04:00:08
（上游凌晨 4 点批量补录，created 是灌库时间不是下单时间）。业务口径是「订单创建时间」，
只有 order_date 正确。
2. 「UNION ALL 一条 SQL 慢 5~8 倍」—— 被后续实测推翻（46.3s vs 并行 48.2s，基本持平）。
验证
- 新增 backend/test/warehouseShipTimeliness.test.js，10 条用例全绿，覆盖：
最长匹配不误并、子仓命名、山东/河南高频前缀不误并、占位仓、12:00 前返回 null、
12:00 轮窗口 00:00~07:00、16:00 轮窗口 00:00~16:00、状态排除表、三态分桶互斥、
跨表重复 o_id 去重、round.windowEnd 必须带出（否则前端渲染成「核验 前」）。
- check-syntax 185 文件通过；全量 node --test 415 项 / 413 过 / 2 fail，
两条失败均为已知环境因素（负缓存带 TTL 因 .env 有 CLOUD_DB_* 短路；
resilientSecretStore 的 Windows 权限断言，基线恒失败）。
- 真渲染验收（组件级沙盒 + 真实接口数据）：两态均 0 控制台错误；
已核验态 358 单超时未发、8 个仓有数字、点仓切换选中/再点取消均正常；
多分辨率验证 1920/1600 侧栏 208px、1440/1366 收窄 176px、列表始终竖向。
|
2026-10-20 11:23:08 +08:00 |
|
|
|
c9715c0e5b
|
fix: MKH-BOM 成品库存按仓白名单多仓求和（并入横林二仓品牌仓）
## 问题
业务反馈「MKHDNZ0409260600788 库存在横林二仓品牌仓，重新加了一个品牌仓库存，
需要同步这个仓库库存」。
根因：商品档案 `jst_sku.other_3` 记录的是**归属仓**，不是**实物所在仓**。
该批 MKH 成品的归属仓仍是「简尚-崔桥工厂品牌仓」(15870495)，但实物已被整批搬到
2026-10-13 新建的「简尚-横林二仓品牌仓」(16132681)。归属仓库存为 0、新仓有货，
而 ⑦-d 的库存取数只查 `wms_co_id = 15870495` 单仓 → 这批成品库存全被算成 0。
实测影响（2026-10-17）：
- 新仓 58 个 SKU **全是 MKH 成品**（`other_3` 全为崔桥品牌仓），合计 **525 件**
- 页面 49 个 SKU 库存值错误，其中 **5 个误报「缺货」、2 个误报「预警」**
## 改动
`backend/src/services/mkhBomService.js`
- 新增 `BRAND_WMS_CO_IDS = [15870495, 16132681]` 成品库存仓白名单（`BRAND_WMS_CO_ID`
保留给仓库名文案与监控快照过滤）
- `jst_inventoryInfo` / `jst_packInventoryInfo` 两条取数改为
`wms_co_id IN (白名单)` + `SUM(qty)` + `GROUP BY sku_id`，**按 SKU 多仓求和**
- ⚠️ 原 `ORDER BY updateTime DESC`（单仓去重）在多仓下只会留一个仓，
必须换成 SUM + GROUP BY —— 本次同时修掉这个隐患
- 配件库存**不动**：新仓一个配件都没有，横林三仓/沭阳仓虽有 MKH 配件但归属别的项目，
并入会让「配件不足」漏判
`backend/test/mkhBomService.test.js`
- 新增 ⑦-e 多仓求和测试（锁 SQL 白名单 + SUM/GROUP BY，并断言求和结果）
- 新增白名单常量测试（防止后续误删横林二仓 ID）
## 验证
- `check-syntax.js`：182 文件通过
- `node --test`：**405 tests / 404 pass / 1 fail**
（唯一失败为 `resilientSecretStore` Windows 权限断言，环境固有，与本改动无关）
- **对照组实验**：stash 回修复前源码跑新测试 → 2 条**全部失败**，
报错精确指向旧 SQL（`wms_co_id = @brandWmsCoId ... ORDER BY updateTime DESC`），证明测试非空过
- **同一数据快照双口径 diff**（生产库实测）：参与比对 385 个 SKU，
差异 58 个，**全部是新值 > 旧值，反向 0 个、来源标记变化 0 个**，
合计补回 525 件（= 新仓总量，完全吻合）
- **新代码在生产容器实跑**：`total 4347`（不变）/ **`warning 30 → 23`** /
**`outOfStock 21 → 16`**，与逐 SKU 分析结论一致（消除 5 个误报缺货 + 2 个误报预警）
- **性能**：`STATISTICS IO` 两边均为 `jst_inventoryInfo scan 1 / logical reads 4683`（不增加 IO）；
实测 355ms vs 旧 356~914ms，**无退化**
## 风险与回退
- 风险：白名单常量是硬编码，后续上游再新增同类「成品发货仓-真实库存」仓时需追加 ID。
已在代码注释与文件头 ⑦-e 写明。
- 回退：单文件改动，revert 本提交即恢复单仓口径，无数据迁移、无状态残留。
|
2026-10-17 09:34:55 +08:00 |
|
|
|
62cac712db
|
fix: 动销分析多来源销量先按 仓库+商品 汇总再 join
4 个销量来源 union all 后各分支各自 GROUP BY，同一个 仓库+商品 命中多个
分支时外层层 LEFT JOIN 没有二次聚合，一个仓位行被拆成多行、每行只带某一
个分支的销量（实测 SJ038411 同时出现 sales=0 与 sales=44 两行）。
新增 shipAgg CTE：按 仓库+商品 对各来源求和成一行，再与仓位行 join。
SalesQty/分摊销量/日销/等级随之统一。
|
2026-10-14 13:57:14 +08:00 |
|
|
|
0a2fe1c3a3
|
fix: 云库新增慢查询入口 querySlow（池级超时放宽）
mssql 12.2.0 驱动 request.timeout（请求级）实测不生效，超过池默认
60s 的查询必被掐断。动销分析销量 union 4 来源后全仓窗口需 ~2 分钟，
触发 Timeout: Request failed to complete in 60000ms。
- queryWithCandidateConnection 支持 options.connectRequestTimeoutMs
覆盖候选连接的池级 requestTimeout（池级实测生效）
- 新增 querySlow(sqlText, params, options)：独立临时连接 + 池级超时
默认 300s（env CLOUD_DB_SLOW_QUERY_TIMEOUT_MS 可调）
- 动销分析取数优先走 querySlow（mock 环境无该方法时回退 query）
|
2026-10-14 13:12:05 +08:00 |
|
|
|
2bdc4b5713
|
fix: 动销分析销量补齐组合装子件与全民客户(B2B)渠道
线上订单里组合装以 ZH-子件A-N-子件B-M 拼接编码存在，按 sku_id 精确
匹配永远查不到子件销量；全民客户(jst_qmcust_orderlist)渠道此前完全
未纳入。两处缺失导致大量 SKU(尤其组合装子件)窗口销量被算成 0。
销量 ship CTE 拆为 4 个 UNION ALL 分支：
1) jst_Orders 普通行(sku_type<>combine)
2) jst_Orders 组合装行 JOIN jst_comboProductItem 展开为子件x数量
3) jst_qmcust_orderlist 普通行(排除拆单父单 Split/Question)
4) qmcust 组合装行同样展开
均按 send_date 窗口，仓库过滤不变。等级/日销/分摊销量随数据源自动重算。
|
2026-10-14 11:05:13 +08:00 |
|
134
|
fa0e604bf8
|
fix: 排除拣选位报表中的箱记录
|
2026-10-12 14:31:45 +08:00 |
|
|
|
e15898693f
|
fix: 动销分析报表恢复「类型」列（恒为拣选），存货位仍不纳入
上一版为去掉冗余把「类型」整列删了，用户要求的报表列结构中该列仍在，
现恢复：导出与列表均保留「类型」列，值恒为「拣选」（存货位不参与统计，报表中不会出现）
验证（基准日 2026-10-08、30 天）：
- 导出表头为 仓库 / 仓位 / 类型 / 商品编码 / 库存数量 / 仓位SKU数 / 商品销量 /
分摊销量 / 商品日销 / 动销等级 / 统计天数 / 统计基准日
- 11897 行，类型列取值集合仅 ['拣选']，空值 0 行；分摊销量合计 98087 = 去重商品销量合计 98087
- 列表接口 binTypes=['拣选']，明细类型集合仅 ['拣选']
- 单测 9/9 通过；语法检查 182 文件通过；eslint 无报错、vite build 成功
|
2026-10-08 16:31:20 +08:00 |
|
|
|
99fa402092
|
feat: 拣选库位动销分析固定只统计拣选位，移除仓位类型切换
- 取数固定只取拣选位：bin CTE 直接过滤 bin_group 为空（更早过滤，存货位不再进入后续 CTE）
移除可变的 binType IN 过滤与 resolveBinTypes，binType 字段恒为拣选
- 接口 payload 的 binTypes / binTypeOptions 固定为 ['拣选']；缓存键不再含类型
- 列表与导出移除「类型」列（全为拣选，冗余）；页面移除类型多选器、底部文案改为「统计范围：仅拣选位」
- 口径说明补充统计范围；Tooltip 同步
验证（基准日 2026-10-08、30 天）：
- 列表 11871 行 / 6821 个去重商品 / 库存 499141 / 去重商品销量 96847，明细类型集合仅为 ['拣选']
- 导出 11871 行，表头无「类型」列；分摊销量合计 96847 = 去重商品销量合计 96847（差异 -0.0017 浮点舍入）
- 旧参数 binType=存货 被忽略（仍返回拣选且命中同一缓存）；7 / 60 天窗口与单仓过滤均正常
- 单测 9/9 通过；后端语法检查 182 文件通过；前端 eslint 无报错、vite build 成功
|
2026-10-08 13:09:49 +08:00 |
|
|
|
88a39975d3
|
feat: 动销等级改为按商品日销统计，列表与导出统一到仓位×商品粒度
- 取数统一为 fetchPickingBinSkuRows：一行 = 一个「仓位 × 商品编码」，列表与导出共用
商品日销 = 商品窗口整档销量 ÷ 天数（不做仓位分摊）；同一商品占几个仓位都是同一等级
另输出分摊销量 = 商品销量 ÷ 占用同类型仓位数，供按行求和
- 列表页同步拆到商品粒度：新增商品编码列，去掉 SKU数列，搜索支持商品编码
- 汇总卡片主数值改为去重商品数，另显示明细行数；销量按去重商品口径统计
- 导出新增「分摊销量」「商品日销」列，表头口径标注更明确
- 性能：仓位类型选满时不拼 IN 过滤（避免参数嗅探走坏计划），全类型查询由超时降到约 30 秒
验证（基准日 2026-10-08、30 天、拣选位）：
- 明细 11871 行 / 去重商品 6821 个 / 库存合计 499141（与旧口径一致）
- 跨多仓位的 2028 个商品，销量与等级不一致 0 个
- 导出行求和：分摊销量合计 96847 = 去重商品销量合计 96847（差异 -0.0017，浮点舍入）
- 单测 9/9 通过；语法检查 182 文件通过；前端 eslint 无报错、vite build 成功
|
2026-10-08 10:58:17 +08:00 |
|
|
|
31f184edd0
|
feat: 拣选库位动销分析导出增加商品编码，按仓位×商品编码拆行
- 新增 fetchPickingBinSkuRows：仓位 × 商品编码 粒度明细
库存数量 = 该商品在此仓位的实际库存；销量 = 商品销量 ÷ 其占用同类仓位数（贡献）
- 导出列：仓库 / 仓位 / 类型 / 商品编码 / 库存数量 / SKU数 / 销量 / 日销 / 动销等级 / 统计天数 / 统计基准日
- SKU数、动销等级仍为仓位粒度（同一仓位多行重复），列表页口径不变（仍用 bin 级聚合）
- 同一次取数比对：7055 个仓位，列表与导出库存/销量 0 处差异，库存合计一致 497721
- 单测 11 条通过
|
2026-10-08 09:35:26 +08:00 |
|
|
|
817cc74a40
|
feat: 拣选库位动销分析默认按近 30 天销量划分等级
- 默认统计窗口 15 天 -> 30 天（后端 PICKING_BIN_DEFAULT_DAYS 与前端常量同步）
- 可切换窗口补充近 60 天（7 / 15 / 30 / 60）
- 等级阈值不变：爆款≥20 / 热卖 10-20 / 平销 3-10 / 滞销-1 1-3 / 滞销-2 (0,1) / 销售=0
- 单测断言同步更新；实测 30 天窗口：7091 个拣选库位，日销=销量÷30
|
2026-10-07 17:41:17 +08:00 |
|
|
|
70550b5499
|
feat: 新增二级页面「拣选库位动销分析」（大货库存监控）
- 后端：pickingBinSalesAnalysis 配置/服务/路由，仓位库存取 rpt.jst_packInventoryInfo
（bin_group 空值=拣选位、存货=存货位），销量按「SKU 占用同类仓位数平均分摊」，
恒等式「全部库位销量之和 = 有库位 SKU 销量之和」差异为 0
- 动销等级（近 N 天日销，默认 15）：爆款>=20、热卖款 10-20、平销款 3-10、
滞销款-1 1-3、滞销款-2 (0,1)、销售=0
- 前端：大货库存监控下新增二级菜单 + 页面（等级卡片、仓库/类型/天数/仓位筛选、
分页表格、xlsx 导出），路由/菜单/页面权限四处注册
- 测试：后端 8 项单测通过；前端 lint/test/build 通过
|
2026-10-07 16:59:39 +08:00 |
|
|
|
a93691f5d8
|
fix: MKH-BOM 配件库存增加箱表兜底，修正「配件有货却判配件不足」
根因
- 配件监控页取实时库存是三级兜底（inventoryInfo → 同仓箱表 packInventoryInfo
→ 监控快照 jsStock），而 MKH-BOM 的 loadComponentStock **只查 jst_inventoryInfo**，
一级来源到底就结束。
- 上游 jst_inventoryInfo 存在滞后：2026-09-30 该行停在 09-28 14:51 的值 0，
而 jst_packInventoryInfo 当日 10:30 已记 bin=ZT-30 qty=200。
- 结果：同一个仓（15718196）、同一个配件，配件监控页显示 200（判「正常」），
MKH-BOM 判「配件不足」、可组装数 0。
案例 MKHDNZ0409260600849 的配件 DNZ040947N1440V01（瓶颈唯一）。
改动
- backend/src/services/mkhBomService.js
· loadComponentStock()：一条语句同时取两张表（UNION ALL + src 标记），
库存表有正库存以它为准；为 0 / 缺行时用同仓 jst_packInventoryInfo 的
bin 非空行合计兜底。**只补 0、不覆盖正库存**，与配件监控页
buildRealtimeStockSql 同口径；查询失败仍整体 degraded（不做判定）。
· 文件头 ⑪：修正「不能用 jst_packInventoryInfo 当配件库存 —— 与 MKH 配件
零交集」这条结论 —— 它是 09-17 的表状态（当时该表 bin 全空），
09-18 上游整表重建后已失效。
· 文件头 ⑤：同理修正该表的关联列与数据现状结论。PR #22 的提交信息声称
已更新 ⑤，但实际 diff 未改，此处补齐（该表 wms_co_id 关联、目标仓
727/794 命中、配件仓 743 个 SKU 有箱记录）。
- backend/test/mkhBomService.test.js
· 新增 3 个用例：箱表兜底生效且不覆盖正库存 / SQL 形状防腐化（两张表 +
bin 非空 + 限定仓）/ 查询失败仍降级不做判定。
对照组已验证：在修复前的实现上前两个用例失败（expected 200、actual 0）。
影响与验证
- 仅影响 MKH-BOM 的「配件不足」标记与可组装数；不改预警级别、排序与预警总数。
- 同一数据快照下的新旧口径对照（监控日 2026-09-29）：
配件不足 26 → 24（2 行翻盘）、预警总数 29、缺货 23 两边一致，
0 行反向变化、0 处其他字段变化、0 处级别变化。
- 真库实测：DNZ040947N1440V01 0 → 200、DNZ040959N1440V01 0 → 200；
库存表本就有正数的对照配件（60 / 87）未被箱表覆盖。
- 负载（SET STATISTICS IO，300 编码一个分片）：jst_inventoryInfo 4543 逻辑读 +
jst_packInventoryInfo 947 逻辑读，物理读 0、Worktable 0；实测中位耗时
215ms → 391ms（+176ms/分片，配件全集 784 个约 3 个分片，占冷查 61s 的 1% 以内，
且结果按编码缓存 10 分钟）。
说明：SHOWPLAN 权限被拒（账号无该权限），改用 STATISTICS IO + 实测耗时 + 数据量
作为执行计划等价证据。
- 数据量边界：配件仓 jst_inventoryInfo 837 行、jst_packInventoryInfo 1163 行
（bin 非空 1024 行）。
- 后端：check-syntax 179 文件通过；node --test 393 项 392 通过
（唯一失败为既有环境问题 resilientSecretStore 权限断言，与本改动无关）。
|
2026-09-30 17:43:30 +08:00 |
|
|
|
30554720b2
|
feat: 客退看板新增「最晚退厂时间」列（工作平台数据，先占位待接入）
- 新增 supplierExitDateProvider.js：按供应商名匹配「最晚退厂时间」，
数据源为工作平台库 WorkbenchDataShared（同实例，另有 WorkbenchIdentity /
DataPlatformControl）。当前副本账号 cangku 无该库访问权限、系统设置里没有它的
连接配置、.env 的 JIAN_SUN_DB_* 与 WORK_ORDER_* 也为空，因此先返回不可用。
接入方式：IT 开通后配 SUPPLIER_EXIT_DATE_ENABLED=true + SUPPLIER_EXIT_DATE_SQL
（查询需返回 supplierName / exitDate 两列），或直接写死 CODE_* 常量，无需改其他文件。
- returnStockWarningService.js：composeRows 增加 latestExitDate /
latestExitDateLabel / latestExitDateAvailable；列表响应新增 exitDateMeta；
导出列在「供应商是否合作」后新增「最晚退厂时间」（未接入时导出显示「待接入」）；
口径说明补一条（含完整取证：工作平台库不可达、副本无任何退厂字段、
fys_supplier.NoCoopTime 是不可用的停更快照）。
- StockWarning.jsx：表格新增「最晚退厂时间」列，有值显示日期、未接入显示「待接入」
（Tooltip 说明数据来源与开通方式）；monitor.css 补占位符样式。
|
2026-09-28 16:06:40 +08:00 |
|
|
|
f7fc7fef4f
|
fix: 修复客退看板缓存命中时引用未定义常量导致 500
缓存 TTL 改成可配（DEFAULT_CACHE_TTL_MS / resolveCacheTtlMs）时漏改了
loadReplicaRows 里的比较表达式，仍写 CACHE_TTL_MS。缓存为空时短路不触发，
所以本地首轮没暴露；生产被预热任务写过缓存后，第二次请求命中该行即
ReferenceError 500。改为调用 resolveCacheTtlMs()。
|
2026-09-28 15:40:57 +08:00 |
|
|
|
6c3b14fc10
|
客退看板「是否出库」列改为「供应商是否合作」
- returnStockWarningService.js: 新增 supplierCoopSign 取 js_supplier.coopersgn
(LEFT JOIN dbo.js_supplier sp ON sp.scmname = sk.supplier_name)，
解析为 supplierCoop / supplierCoopLabel（1=合作 / 2=不合作 / 其它=未知），
导出列「是否出库」同步替换为「供应商是否合作」
- StockWarning.jsx: 表格列替换，新增合作状态 Tag 与判断依据 Tooltip
- returnStockWarehouseRegistry.js: 更新崔桥工厂仓客退位复测结论
（2026-09-27 已同步进副本：349 编码 / 507 件）
|
2026-09-28 15:34:55 +08:00 |
|
|
|
2745cf18ff
|
feat: 库存动销分析「销售=0」导出按仓位拆行，库存数量按实际仓位统计
上一版把同一 SKU 的多个仓位用「、」拼在一格里，库存数量仍是 SKU 总量，
无法直接按仓位盘点。现改为每个仓位独立一行：
- bin CTE 改为按 (wms_co_id, sku_id, LTRIM(RTRIM(bin))) 分组，
SUM(qty) 得到仓位级库存（各仓位行之和 = SKU 总库存，实测 240=60+69+35+76）
- 导出行 = graded（SKU 级「销售=0」判定）LEFT JOIN 仓位级明细：
有仓位数据的 SKU 按仓位展开多行、库存数量取该仓位实际 qty（qty=0 的仓位行剔除）；
仓位表未覆盖的 SKU 保留一行（仓位为空、库存取总库存），不丢数据
- 排序：仓库 → SKU 总库存倒序 → SKU → 仓位名称，同一 SKU 的各行保持相邻
- 前端按钮提示同步更新拆行与兜底规则说明
验证：后端 syntax 通过、单测 9/9（全量 389/390，唯一失败为既有 Windows 环境项）；
前端 eslint/build 通过；
本地实测：单仓（睢宁 196 行，原 128 SKU 行）样例 SKU 正确拆为 4 行且合计 240；
全仓导出 6798 行（原 3650），有仓位行 6529、仓位为空兜底行 269，覆盖 26 仓
|
2026-09-28 09:55:45 +08:00 |
|
|
|
fc280bfe27
|
feat: 库存动销分析「销售=0」导出增加系统仓位列
仓位用于定位滞销库存的实际存放位置，便于盘点与挪位处理。
数据源为 rpt.jst_packInventoryInfo.bin（jst_sku.bin 全部为空、库存表无仓位字段，
这是业务库唯一可得的系统仓位）：
- 按 (wms_co_id, sku_id) 聚合，LTRIM 去空格后 DISTINCT，STRING_AGG 按名称排序用「、」连接
- 排除无仓位（bin 为空）与零库存（qty=0）的行，避免无效仓位干扰
- LEFT JOIN 且按「仓库+SKU」双条件匹配，避免跨仓错配
- 导出列顺序：仓库 | SKU编码 | SKU名称 | 系统仓位 | 库存数量 | 销量 | 统计天数 | 统计基准日
- 前端按钮提示同步说明多仓位拼接规则与留空含义
验证：后端 syntax 通过、单测 9/9（全量 389/390，唯一失败为既有 Windows 权限环境项）；
前端 eslint/build/测试均通过；
本地实测导出 3650 行，系统仓位列就位，3381 行有仓位（92.6%，未覆盖的 7.4% 为
仓位表仅含 13 个仓库所致），销量列全为 0，最长仓位串 600 字符（Excel 上限内）；
浏览器实测点击下载，文件名与列结构正确
|
2026-09-28 09:34:55 +08:00 |
|
|
|
2c8ed86c26
|
feat: 库存动销分析「销售=0」档支持导出 SKU 明细
- 后端新增 GET /api/stock-sales-analysis/zero-sales-export：
复用与页面完全一致的分档口径（同一段 gradeCase 表达式 + 「有库存或有销量」过滤），
输出仓库/SKU编码/SKU名称/库存数量/销量/统计天数/统计基准日的 SKU 级明细；
支持.days 统计窗口、wmsCoId 逗号分隔过滤（仅允许仓库清单内的 ID，防任意拼参）、
format=xlsx|csv，复用通用导出服务 exportWorkbook
- services 新增 fetchZeroSaleSkuRows：SKU 级「销售=0」查询，LEFT JOIN rpt.jst_sku 取名称，
按仓库+库存倒序排列
- 前端工具栏新增「导出销售=0」按钮：跟随当前统计天数与仓库筛选，
文件名含业务日期与仓库范围，失败时解出错误体给出可读提示
- 测试补充 3 条：防呆抛错、空参短路、SQL 口径与参数传递断言
验证：后端 syntax 通过、单测 8/8（全量 389 条仅既有 Windows 环境项失败）；
前端 eslint/build/test 21/21 通过；
本地实测：全仓导出 3641 行、26 仓、销量列全为 0；
单仓（崔桥半成品包装 694 行）与页面「销售=0」SKU 数一致；
浏览器实测点击下载真实文件名「库存动销分析-销售0明细-20260926.xlsx」
|
2026-09-27 17:47:45 +08:00 |
|
|
|
f20bd3a487
|
feat: 侧边栏新增二级「库存动销分析」页面
按《仓库库存动销分析.xlsx》：
- 一级菜单「大货库存监控」下新增二级「库存动销分析」（路由 /planning/operation/stock-sales-analysis）
- 表头与表格结构按需求表：仓库 | 动销等级 | SKU数量 | SKU占比 | 库存数量 | 库存占比 | 销量，
每仓 6 个动销等级（爆款/热卖款/平销款/滞销款-1/滞销款-2/销售=0）+ 1 行汇总，仓库列跨行合并
- 分档口径：日销 = 统计窗口内已发货件数 ÷ 窗口天数（7/14/30 天可选，默认 30），
库存取 rpt.jst_inventoryInfo 实时库存，销量取 jst_Orders×jst_OrderItem 按 send_date
（排除 Delete/Cancelled，与每日进销存发货口径一致），只统计有库存或有销量的 SKU
- 后端 /api/stock-sales-analysis：单条 SQL 一次覆盖全部仓库×等级，5 分钟缓存 + refresh=1 强制重算；
返回逐仓 + 全仓合计、占比、无数据仓数量
- 前端页面：统计天数/仓库筛选、口径说明弹窗、合计行高亮、无数据仓计数提示
- 页面权限：前后端 sidebarPages 注册 pageKey=stock_sales_analysis，默认 planning 角色可见
验证：后端 syntax + 单测 5/5；前端 eslint、build、npm test 21/21；
本地接口 30 天窗口实测 27 仓（崔桥汇总 2080 SKU / 90822 件 / 54076 件销量），
占比逐仓闭合为 100%；浏览器实测侧边栏入口、表头、197 行渲染与截图均正常
|
2026-09-27 16:29:58 +08:00 |
|
