|
|
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 |
|
|
|
3d9b12eace
|
Merge pull request 'fix: MKH-BOM 成品库存按仓白名单多仓求和（并入横林二仓品牌仓）' (#67) from codex/mkh-brand-warehouse-multi-1017 into main
|
2026-10-17 09:39:34 +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 |
|
|
|
c80d28c33f
|
Merge pull request 'fix: 动销分析多来源销量先按 仓库+商品 汇总再 join' (#66) from codex/picking-bin-ship-agg-1014 into main
|
2026-10-14 13:57:59 +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 |
|
|
|
e5030d4864
|
Merge pull request 'fix: 云库新增慢查询入口 querySlow（池级超时放宽）' (#65) from codex/cloud-db-slow-query-1014 into main
|
2026-10-14 13:12:40 +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 |
|
|
|
1d4eecb03c
|
Merge pull request 'fix: 动销分析销量补齐组合装子件与全民客户(B2B)渠道' (#64) from codex/picking-bin-combo-qmcust-1014 into main
|
2026-10-14 11:05:54 +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 |
|
|
|
c6c7feaeea
|
Merge pull request 'fix: 排除拣选位报表中的箱记录' (#63) from codex/picking-bin-pack-filter-1012 into main
|
2026-10-12 14:39:06 +08:00 |
|
134
|
fa0e604bf8
|
fix: 排除拣选位报表中的箱记录
|
2026-10-12 14:31:45 +08:00 |
|
|
|
cf8d5f68ae
|
Merge pull request 'fix: 动销分析报表恢复「类型」列（恒为拣选），存货位仍不纳入' (#62) from codex/picking-bin-restore-type-col-1008 into main
|
2026-10-08 16:32:09 +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 |
|
|
|
214ede07a5
|
Merge pull request 'feat: 拣选库位动销分析固定只统计拣选位，移除仓位类型切换' (#61) from codex/picking-bin-picking-only-1008 into main
|
2026-10-08 13:10:48 +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 |
|
|
|
8f12b889c0
|
Merge pull request 'feat: 动销等级改为按商品日销统计，列表与导出统一到仓位×商品粒度' (#60) from codex/picking-bin-grade-by-sku-1008 into main
|
2026-10-08 10:59:14 +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 |
|
|
|
195351deae
|
Merge pull request 'feat: 拣选库位动销分析导出增加商品编码，按仓位×商品编码拆行' (#59) from codex/picking-bin-export-sku-1008 into main
|
2026-10-08 09:36:58 +08:00 |
|
|
|
31f184edd0
|
feat: 拣选库位动销分析导出增加商品编码，按仓位×商品编码拆行
- 新增 fetchPickingBinSkuRows：仓位 × 商品编码 粒度明细
库存数量 = 该商品在此仓位的实际库存；销量 = 商品销量 ÷ 其占用同类仓位数（贡献）
- 导出列：仓库 / 仓位 / 类型 / 商品编码 / 库存数量 / SKU数 / 销量 / 日销 / 动销等级 / 统计天数 / 统计基准日
- SKU数、动销等级仍为仓位粒度（同一仓位多行重复），列表页口径不变（仍用 bin 级聚合）
- 同一次取数比对：7055 个仓位，列表与导出库存/销量 0 处差异，库存合计一致 497721
- 单测 11 条通过
|
2026-10-08 09:35:26 +08:00 |
|
|
|
ea2942f118
|
Merge pull request 'feat: 拣选库位动销分析默认按近 30 天销量划分等级' (#58) from codex/picking-bin-window-30d-1007 into main
|
2026-10-07 17:42:06 +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 |
|
|
|
e71607386d
|
Merge pull request 'feat: 新增每日进销存业务库校验脚本' (#57) from codex/validate-daily-inventory-biz-1007 into main
|
2026-10-07 17:04:36 +08:00 |
|
|
|
7505a04e37
|
Merge pull request 'feat: 新增二级页面「拣选库位动销分析」（大货库存监控）' (#56) from codex/picking-bin-sales-analysis-1007 into main
|
2026-10-07 17:04:10 +08:00 |
|
|
|
0afcb26119
|
feat: 新增每日进销存业务库校验脚本
- backend/scripts/validateDailyInventoryFromBiz.js <业务日>...
- 直连业务库（凭据经隧道从系统库 database_configs 现取，不落盘）：
反算 4 个可还原的流水列（销售出仓/销售退货/采购进仓/采购退货），
与 daily_inventory_official 逐仓比对；期末库存与 jst_inventoryInfo 全仓比对
- 约定：校验类需求默认走业务库，不启浏览器取聚水潭
|
2026-10-07 16:59:56 +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 |
|
|
|
ada8d09c27
|
Merge pull request 'fix: MKH-BOM 配件库存增加箱表兜底，修正「配件有货却判配件不足」' (#55) from codex/mkh-component-stock-pack-fallback-0930 into main
|
2026-09-30 19:32:34 +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 |
|
|
|
b0b618e7df
|
Merge pull request 'feat: returns board - add latest return-deadline column (workbench source, pending access)' (#54) from codex/lunanting-exit-date-001 into main
|
2026-09-28 16:07:13 +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 |
|
|
|
901212a32c
|
Merge pull request 'fix: returns board cache-hit path referenced undefined CACHE_TTL_MS (500)' (#53) from codex/lunanting-supplier-coop-001 into main
|
2026-09-28 15:41:35 +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 |
|
|
|
23e1b365d6
|
Merge pull request 'feat: returns board outbound column -> supplier cooperation status' (#52) from codex/lunanting-supplier-coop-001 into main
|
2026-09-28 15:36:14 +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 |
|
|
|
aeac4bcc81
|
Merge pull request 'feat: 库存动销分析「销售=0」导出按仓位拆行，库存数量按实际仓位统计' (#51) from codex/ssa-zero-export-bin-0928 into main
|
2026-09-28 09:57:18 +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 |
|
|
|
38804f6624
|
Merge pull request 'feat: 库存动销分析「销售=0」导出增加系统仓位列' (#50) from codex/ssa-zero-export-bin-0928 into main
|
2026-09-28 09:36:10 +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 |
|
|
|
4d419c5c7c
|
Merge pull request 'feat: 库存动销分析「销售=0」档支持导出 SKU 明细' (#49) from codex/ssa-zero-export-0927 into main
|
2026-09-28 08:18:53 +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 |
|
|
|
151d420831
|
Merge pull request 'feat: 侧边栏新增二级「库存动销分析」页面' (#48) from codex/stock-sales-analysis-0927 into main
|
2026-09-27 16:31:47 +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 |
|
|
|
9e0612b7f3
|
Merge pull request 'fix: 每日进销存截图按业务日期归档，并补充幂等与执行记录测试' (#47) from codex/daily-inventory-notify-0928 into main
|
2026-09-27 14:55:33 +08:00 |
|
|
|
117d59c9f0
|
fix: 每日进销存截图按业务日期归档并补充幂等/执行记录测试
定时任务在凌晨 01:00 推送的是「昨日」数据，但截图对象键原先直接取执行时刻的北京日期，
导致归档目录与通知里的业务日期不一致（daily-inventory/2026-09-26/... 装的是 09-25 的数据）。
现改为由定时任务显式传入业务日期，目录与文件名统一用业务日期、时间仍用执行时刻：
daily-inventory/2026-09-25/daily-inventory-20260925-010000.png
另补充验收要求 8 的测试：
· buildScreenshotNames 归档命名（含业务日期与执行日期不同的场景）
· markNotified / hasNotified 幂等：同业务日同用户只成功一次，跨日期互不影响
· appendRunRecord 保留执行时间、截图地址、通知对象与失败原因
|
2026-09-27 14:53:05 +08:00 |
|
|
|
f815751634
|
Merge pull request 'feat: 每日进销存支持导入聚水潭官方进销存校正数据' (#46) from codex/daily-inventory-official-0927 into main
|
2026-09-27 14:29:20 +08:00 |
|
|
|
0e77a70c33
|
feat: 每日进销存支持导入聚水潭官方进销存校正数据
业务库只能还原 4/12 个流水列且口径与聚水潭不一致（采购按单据日期、销售按订单发货日期，
jst_salesOutboundInfo.qty 全为 0），调拨/盘点/加工/其它出入库无单据表，故以官方导出为准：
- 新增本地表 daily_inventory_official（biz_date + warehouse 存期初/12 流水列/期末）
- 新增解析与导入服务：xlsx 解析、仓库 ID 映射、「期初+流水=期末」恒等式校验
- GET /api/daily-inventory 支持 ?date= 指定业务日，官方值优先、缺失回退推算并返回来源标记
- 新增 POST /api/daily-inventory/official-import（xlsx 上传/JSON）与 GET /official 查询
- 导入后回写本地库存快照（官方期初→上一日期末、官方期末→当日期末），使推算也对齐
- 前端：业务日切换、官方/推算来源标记、导入弹窗、口径说明同步更新
- 仓库清单补入「简尚-横林三仓主仓」（聚水潭导出中存在）
- 命令行导入：npm run inventory:import-official -- <日期> <xlsx>
|
2026-09-27 14:16:06 +08:00 |
|
|
|
2d8ef49c12
|
Merge pull request 'fix: 期初兜底弃用 pm_stockMonitor，全部改用实时库存扣流水回推（#44 追随修复）' (#45) from codex/daily-inventory-complete-data-0927 into main
|
2026-09-27 10:09:53 +08:00 |
|
|
|
c47a25b002
|
fix: 期初兜底弃用 pm_stockMonitor，全部改用实时库存扣流水回推
口径校准（对照聚水潭进销存导出 09-23 期初基准）：
崔桥工厂仓 基准 92388 / pm 路径 114286 / 回推 ≈89650
横林二仓 基准 63780 / pm 路径 1197 / 回推 ≈64029
山东青岗集 基准 88377 / pm 路径 67339 / 回推 ≈88210
河南洛宁 基准 83305 / pm 路径 76992 / 回推 ≈82473
pm_stockMonitor.jsStock 只覆盖纳入监控范围的 SKU 子集（横林二仓实测
1197 vs 全仓 63780），系统性偏低，不能充当全仓结存；「实时库存扣
流水回推」与基准偏差 0.3%~2.7%（来自缺失的 8 类单据），显著更准。
|
2026-09-27 10:09:19 +08:00 |
|
|
|
68d1fcec00
|
Merge pull request 'fix: 修复流水取数漏传 cloudDb 导致流水列静默为空（#43 追随修复）' (#44) from codex/daily-inventory-complete-data-0927 into main
|
2026-09-27 10:04:05 +08:00 |
|
|
|
952c57a84a
|
fix: 修复流水取数漏传 cloudDb 导致流水列静默为空
路由调用 fetchFlows(wmsCoIds, from) 少了第一个参数 cloudDb，
导致形参错位（cloudDb=数组、wmsCoIds=日期、fromText=undefined），
函数静默返回空 Map 且无任何报错。补传参数，并为 fetchFlows 增加
防呆校验：首参非数据库实例时立即抛 TypeError。补 1 项回归测试。
|
2026-09-27 10:03:24 +08:00 |
|
|
|
dc12f6753d
|
Merge pull request 'feat: 每日进销存补充流水与期初数据，修复合计行 NaN' (#43) from codex/daily-inventory-complete-data-0927 into main
|
2026-09-27 09:56:23 +08:00 |
|
