lunanting/cangku
1
0
Fork 1
Code Issues Pull Requests 2 Actions Packages Projects Releases Wiki Activity
167 Commits 63 Branches 0 Tags
Commit Graph

167 Commits

This Branch
This Branch
All Branches
Author SHA1 Message Date
Xkh5201314
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
lunanting
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
Xkh5201314
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
lunanting
f7fc7fef4f fix: 修复客退看板缓存命中时引用未定义常量导致 500 
缓存 TTL 改成可配（DEFAULT_CACHE_TTL_MS / resolveCacheTtlMs）时漏改了
loadReplicaRows 里的比较表达式，仍写 CACHE_TTL_MS。缓存为空时短路不触发，
所以本地首轮没暴露；生产被预热任务写过缓存后，第二次请求命中该行即
ReferenceError 500。改为调用 resolveCacheTtlMs()。
 2026-09-28 15:40:57 +08:00
Xkh5201314
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
lunanting
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
youruo
aeac4bcc81 Merge pull request 'feat: 库存动销分析「销售=0」导出按仓位拆行，库存数量按实际仓位统计' (#51) from codex/ssa-zero-export-bin-0928 into main 2026-09-28 09:57:18 +08:00
youruo
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
youruo
38804f6624 Merge pull request 'feat: 库存动销分析「销售=0」导出增加系统仓位列' (#50) from codex/ssa-zero-export-bin-0928 into main 2026-09-28 09:36:10 +08:00
youruo
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
youruo
4d419c5c7c Merge pull request 'feat: 库存动销分析「销售=0」档支持导出 SKU 明细' (#49) from codex/ssa-zero-export-0927 into main 2026-09-28 08:18:53 +08:00
youruo
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
youruo
151d420831 Merge pull request 'feat: 侧边栏新增二级「库存动销分析」页面' (#48) from codex/stock-sales-analysis-0927 into main 2026-09-27 16:31:47 +08:00
youruo
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
youruo
9e0612b7f3 Merge pull request 'fix: 每日进销存截图按业务日期归档，并补充幂等与执行记录测试' (#47) from codex/daily-inventory-notify-0928 into main 2026-09-27 14:55:33 +08:00
youruo
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
youruo
f815751634 Merge pull request 'feat: 每日进销存支持导入聚水潭官方进销存校正数据' (#46) from codex/daily-inventory-official-0927 into main 2026-09-27 14:29:20 +08:00
youruo
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
youruo
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
youruo
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
youruo
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
youruo
952c57a84a fix: 修复流水取数漏传 cloudDb 导致流水列静默为空 
路由调用 fetchFlows(wmsCoIds, from) 少了第一个参数 cloudDb，
导致形参错位（cloudDb=数组、wmsCoIds=日期、fromText=undefined），
函数静默返回空 Map 且无任何报错。补传参数，并为 fetchFlows 增加
防呆校验：首参非数据库实例时立即抛 TypeError。补 1 项回归测试。
 2026-09-27 10:03:24 +08:00
youruo
dc12f6753d Merge pull request 'feat: 每日进销存补充流水与期初数据，修复合计行 NaN' (#43) from codex/daily-inventory-complete-data-0927 into main 2026-09-27 09:56:23 +08:00
youruo
c358aff781 feat: 每日进销存补充流水与期初数据，修复合计行 NaN 
数据补充（全部来自数据库，无人工填数）：
- 流水列接入 4/12：采购进仓（jst_purchase×Item，po_date，Confirmed/Finished）、
  采购退货（jst_purchaseout×Item，io_date）、销售出仓（jst_Orders×OrderItem，send_date，
  与周转率发货口径一致）、销售退货（jst_returnAndRefund×Item，as_date，实收 r_qty）。
  其余 8 列业务库确无单据表（已核实全库表清单），保持「—」待 DBA 建表
- 期初快照缺失时自动兜底：优先用 rpt.pm_stockMonitor（报表库 01:00 跑批 T-1 库存，
  按 dbWarehouse 聚合 jsStock，精确）；监控表没有的虚拟仓（运营专用/京东仓）用
  实时库存扣自期初时刻以来的带符号流水回推（近似），推导结果补写快照逐日滚动

缺陷修复：
- 合计行仓库名显示 NaN：isTotal 渲染分支拦截了所有列，'合计' 被强转数字；
  现仓库名原样显示，无数据来源的流水列合计也显示「—」而非误导性 0
- 合计行：某列全部仓库均无数据时合计置空，避免 0 误读

新增 4 项单元测试（流水符号约定、参数展开、期初双路径推导）。
 2026-09-27 09:54:59 +08:00
youruo
485097354b Merge pull request 'fix: 每日进销存截图改用系统库专用服务账号身份' (#42) from codex/daily-inventory-notify-identity-0927 into main 2026-09-27 09:29:06 +08:00
youruo
f205cb9322 fix: 截图服务改用系统库专用服务账号身份 
页面启动会调用 /api/auth/verify，该接口要求令牌 sub 必须是系统库 users 表中真实且 active
的用户。原实现签发的是一个不存在于用户表的合成身份，verify 返回 401，前端清除令牌并跳转
登录页，截图因此永远拿不到数据（等待数据行 3 分钟超时）。

改为在系统库维护一个仅供服务端使用的专用账号：
  · 账号不存在时按 role=admin、status=active、auth_source=service 创建
  · 密码哈希为随机值且无人知晓，账号无法通过密码登录
  · 已存在时复用 id，并仅对 auth_source=service 的本服务账号补齐管理员与启用状态
  · 令牌 sub 使用该账号 id，15 分钟过期，仍只注入 localStorage
  · 账号 id 进程内缓存，删除该行即可回收权限

新增 2 项单元测试：账号创建/复用与令牌 sub 校验。
 2026-09-27 09:24:39 +08:00
youruo
daf3646470 Merge PR #33: 每日进销存增加定时截图通知 
经仓库所有者 youruo 明确授权合并（2026-09-24 授权），授权覆盖最终提交 3bfc48b8b36a22ab422a6566c1637fc7d5f1c42a
 2026-09-27 08:13:03 +08:00
youruo
3f382b49d5 Merge PR #32: 每日进销存改为全部从数据库取数 
经仓库所有者 youruo 明确授权合并（2026-09-24 授权），授权覆盖最终提交 734b974f45fa96224ade9c8bc58ed0df3d978a2c
 2026-09-27 08:11:25 +08:00
youruo
3bfc48b8b3 Merge branch 'codex/daily-inventory-snapshot-0924' into codex/daily-inventory-notify-0924 
冲突文件：backend/src/index.js
处理理由：采用已解决好与他人 PR #40/#41 冲突的分支 A 版本，再补回本分支的通知接口
require、/api/daily-inventory-notification 路由注册与调度器启动，双方行为均保留。
 2026-09-26 12:18:11 +08:00
youruo
734b974f45 Merge branch 'main' into codex/daily-inventory-snapshot-0924（同步 PR #40/#41） 
冲突文件：backend/src/index.js
处理理由：main 侧（他人 PR #40、#41）新增崔桥工厂仓客退三类路由 require 与注册、统一 404 与 JSON 错误处理中间件；
本分支仅新增每日进销存快照任务的 require 与 startDailyInventorySnapshotScheduler() 调用。
采用 main 版本文件并补回本分支两处改动，双方行为均保留。
 2026-09-26 12:16:30 +08:00
Xkh5201314
28cfb1b330 Merge pull request '客退看板首仓改为崔桥工厂仓（数据源：崔桥工厂客退临时上架仓）' (#41) from codex/lunanting-cuiqiao-returns-001 into main 2026-09-25 14:17:25 +08:00
lunanting
b0f56b27f5 客退看板首仓改为崔桥工厂仓（数据源：崔桥工厂客退临时上架仓） 
按 2026-09-25 业务口径，第一张子看板由「横林二仓客退数据监控」改为
「崔桥工厂仓客退数据监控」，取数仓位同步改为聚水潭「崔桥工厂客退临时上架仓」。

- 仓库配置：简尚-崔桥工厂仓 wms_co_id=15038426，客退位 customize_qty_1
- key 由 henglin2 改为 cuiqiao，同步改路由 / 侧边栏 / 路由映射 / 权限条目
- 旧路径 returns-inventory/henlin2* 保留为重定向，避免历史链接 404
- 核销看板（returnMonitorService）仍指向横林二仓，前端入口已下线，本次未动

副本取证：该仓客退位当前只有 2 编码 / 2 件（退货单有量：ERP 3115 条 +
奇门 1812 条），属「客退上架库存未同步进副本」，页面需靠导入功能补数据。
 2026-09-25 14:16:11 +08:00
Xkh5201314
7abb75f803 Merge pull request #40: 客退数据监控五仓看板 + 本地运行稳定性加固 
from codex/cangku-returns-monitor-001 into main
 2026-09-24 16:06:04 +08:00
lunanting
90fa54bd8c Merge branch 'main' into codex/cangku-returns-monitor-001 (sync 41 commits, keep both sides) 2026-09-24 15:37:59 +08:00
lunanting
11ef98b8c1 Merge pull request #38: force MKH manual sync refresh 2026-09-24 14:51:06 +08:00
134
345214daed fix: force live refresh on MKH sync 2026-09-24 14:49:08 +08:00
lunanting
d013f1e636 Merge pull request 'fix: 拒绝本地旧后端返回的过期 MKH 库存' (#37) from codex/mkh-fresh-contract-0924 into main 
拒绝本地旧后端返回的过期 MKH 库存 (#37)
 2026-09-24 14:03:11 +08:00
134
ba6ef97a40 fix: reject stale MKH backend responses 2026-09-24 14:02:24 +08:00
lunanting
91e3d4040c Merge pull request 'feat: 显示 MKH 数据更新进度' (#36) from codex/mkh-refresh-progress-0924 into main 
显示 MKH 数据更新进度 (#36)
 2026-09-24 13:37:14 +08:00
134
22e7264438 feat: show MKH refresh progress 2026-09-24 13:36:44 +08:00
lunanting
146f98e9ee Merge pull request 'fix: 页面刷新强制更新 MKH 运营数据' (#35) from codex/mkh-fresh-refresh-0924 into main 
页面刷新强制更新 MKH 运营数据 (#35)
 2026-09-24 13:31:06 +08:00
134
ea312d9070 fix: force fresh MKH operational data 2026-09-24 13:30:09 +08:00
lunanting
1afa99a783 Merge pull request 'fix: MKH 页面自动刷新实时数据' (#34) from codex/mkh-auto-refresh-0924 into main 
修复 MKH 页面自动刷新实时数据 (#34)
 2026-09-24 13:17:52 +08:00
134
30f5df2206 fix: auto refresh MKH live data 2026-09-24 13:15:53 +08:00
youruo
3af6bd9ef2 Merge branch 'codex/daily-inventory-snapshot-0924' into codex/daily-inventory-notify-0924 2026-09-24 12:00:26 +08:00
youruo
6c753791ad Merge branch 'main' into codex/daily-inventory-snapshot-0924（同步 PR #31） 2026-09-24 12:00:14 +08:00
youruo
c4ea12e9ba fix: 修正截图站点地址与通知正文链接，生产镜像补充 Chromium 与中文字体 
- 截图默认站点改为生产主站 ck.yydd.ai（原默认值指向无关域名）
- 通知正文补充「页面地址」，便于在通知中心直接打开
- 服务身份增加 daily_inventory 页面权限声明
- Dockerfile 安装 Chromium 与 fonts-noto-cjk，否则容器内无法截图且中文显示为方块
 2026-09-24 11:59:36 +08:00
youruo
56fba389e4 feat: 每日进销存增加定时截图通知 
设置（仅管理员）
- 可配置是否启用、通知时间（默认 01:00 Asia/Shanghai）、多名通知用户
- 收件人在后端规范化：去空、去重、限长限量，配置持久化到 system_config
- 接口不返回通知中心密钥与对象存储密钥，只给是否已配置与脱敏预览

定时任务
- 单实例锁（MySQL GET_LOCK），按配置时间触发，命中后 30 分钟内失败最多补跑 3 次
- 服务端签发 15 分钟短时效 JWT 作为专用身份，令牌只写入浏览器 localStorage
- 等数据真正渲染完成（有数据行、无加载中、无错误提示）才截图，展开滚动容器后整页截图
- 对象键形如 daily-inventory/2026-09-25/daily-inventory-20260925-010000.png
- 截图上传成功后才逐用户发通知，单人失败不影响他人；正式推送按「业务日期+收件人」幂等
- 立即测试走同一链路但幂等键带随机数，不影响次日正式推送
- 每次执行记录时间、截图地址、通知对象、成功状态与失败原因

测试
- 覆盖收件人去重、通知时间校验、幂等键、业务日期与对象键、重试退避（17 项）
 2026-09-24 11:22:51 +08:00
youruo
9a5c65419d docs: 补充业务库库存流水单据表需求单 
列出每日进销存 12 个流水列无法从业务库还原的具体原因、
缺失的 4 类单据表、以及已有采购/销售单据口径不一致的实测偏差，供 DBA 补齐。
 2026-09-24 11:20:57 +08:00
youruo
9dbe2793a5 feat: 每日进销存改为全部从数据库取数 
- 期初数量改由本地快照表 daily_inventory_snapshot 提供（上一业务日期末），
  每日 01:30 定时任务落库，接口侧缺失时补写兜底，逐日自动滚动
- 新增 dailyInventorySnapshotDb / dailyInventorySnapshotJob 与手动补跑脚本
- dailyInventoryBaseline 瘦身为纯仓库映射，去掉所有硬编码业务数值
- 12 个流水列因业务库缺单据表返回空值，前端灰底显示「—」
- 修复 qty 全为 0 的仓库期末显示 null 的缺陷
- 新增 docs/库存流水单据表需求.md 给 DBA
 2026-09-24 11:20:30 +08:00