docs: 补充业务库库存流水单据表需求单

列出每日进销存 12 个流水列无法从业务库还原的具体原因、
缺失的 4 类单据表、以及已有采购/销售单据口径不一致的实测偏差，供 DBA 补齐。

docs/库存流水单据表需求.md

@@ -0,0 +1,101 @@
+# 业务库补表需求：每日进销存流水
+
+> 提给：DBA / 聚水潭数据同步负责人
+> 提出方：仓库系统（cangku）· 大货库存监控 → 每日进销存
+> 日期：2026-09-24
+
+## 背景
+
+「每日进销存」页面需要按仓库展示 26 个仓的日内进销存流水，表头 21 列：
+
+| # | 列 | # | 列 |
+|---|---|---|---|
+| 1 | 仓库 | 12 | 销售退货 |
+| 2 | 期初数量 | 13 | 调拨入 |
+| 3 | 加工进仓 | 14 | 期初(2) |
+| 4 | 采购退货 | 15 | 其它出库 |
+| 5 | 采购进仓 | 16 | 期末数量 |
+| 6 | 其它进仓 | 17 | 库存周转天数 |
+| 7 | 其它退货 | 18 | 滞销预警级库存量 |
+| 8 | 销售出仓 | 19 | 商品慢流级库存量 |
+| 9 | 盘点 | 20 | 商品呆滞级库存量 |
+| 10 | 加工出仓 | 21 | 商品僵尸级库存量 |
+| 11 | 调拨出 | | |
+
+其中 1、16~21 列已能从业务库算出（见下表「已具备」），**2~15 列目前无法从业务库还原**。
+
+## 已具备（无需补表）
+
+| 列 | 来源 | 说明 |
+|---|---|---|
+| 仓库 | `rpt.jst_warehouseInfo` | `wms_co_id` 与仓库名映射 |
+| 期末数量 | `rpt.jst_inventoryInfo` | 按 `wms_co_id` 单仓 `SUM(qty)`，实时 |
+| 库存周转天数 | 近 30 天发货 ÷ 实时库存 | `jst_OrderItem` × `jst_Orders`（`send_date`） |
+| 四级库存量 | 实时库存 × 发货 × `pm_stockMonitor.created` | 库龄 = 基准时刻 − SKU 建档时间 |
+
+## 缺口一：没有按天的历史库存结存表（阻塞「期初数量」）
+
+`rpt.jst_inventoryInfo` 只有**当前**库存，没有历史版本；`rpt.pm_stockMonitor` 是「归属仓」口径的每日快照（`jsStock`），与实物库存口径不一致（崔桥 115135 vs 实物 92439），不能当结存用。
+
+**现状的临时方案**：项目本地 MySQL 建了 `daily_inventory_snapshot` 表，每天 01:30 把 26 仓实时库存落一份快照，`今日期初 = 昨日快照`。这是自采数据，一旦任务漏跑就会断链。
+
+**请求**：请提供按天、按仓、按 SKU 的库存结存表，形如：
+
+```
+jst_inventoryDaily(
+  biz_date   DATE,      -- 业务日
+  wms_co_id  BIGINT,    -- 仓库
+  sku_id     VARCHAR,   -- SKU
+  qty        DECIMAL,   -- 当日结存
+  ...
+)
+```
+
+有了它，「期初数量」即可直接取上一业务日结存，本地快照表可退役。
+
+## 缺口二：缺少 4 类单据表（阻塞 12 个流水列）
+
+业务库 `rpt` 下已排查过全部 220 张表，**不存在**以下单据：
+
+| 缺失单据 | 影响的列 |
+|---|---|
+| 调拨单（调拨出 / 调拨入） | 调拨出、调拨入 |
+| 盘点单 | 盘点 |
+| 加工单（加工进仓 / 加工出仓） | 加工进仓、加工出仓 |
+| 其它出入库单 | 其它进仓、其它退货、其它出库、期初(2) |
+
+请补充按单据行（SKU 级）的明细表，至少包含：
+
+```
+业务日期 / 单据号 / 仓库 wms_co_id / sku_id / 数量 / 单据类型(出|入) / 状态
+```
+
+## 缺口三：已有单据的数值与进销存口径不一致（阻塞 销售出仓 / 采购进仓 / 采购退货 / 销售退货）
+
+这 4 类单据表**存在**，但按天汇总后与聚水潭进销存导出的数值对不上，不能直接用：
+
+| 列 | 现有来源 | 9-23 崔桥工厂仓实测 | 基准值 | 偏差 |
+|---|---|---:|---:|---|
+| 销售出仓 | `jst_OrderItem` × `jst_Orders` 按 `send_date` | 1,769 | 4,273 | **−59%** |
+| 销售出仓 | 同上，按 `order_date` | 1,723 | 4,273 | −60% |
+| 销售出仓 | 同上，按 `modified` | 5,471 | 4,273 | +28% |
+| 采购进仓 | `jst_purchaseItem.inQty` × `jst_purchase` 按 `confirm_date` | 数百 | 1,295 | 严重偏低 |
+
+其它已排除的候选：
+
+- `rpt.jst_salesOutboundInfo`：`qty` 全为 0，且 `order_type` 只含销售类订单，不含调拨 / 其它出库。
+- `rpt.jst_originalBillInfo`（1,500 万行）：是支付宝 / 财务账单表（`channel=alipayCSV`、`fee_name=交易收款`、`sku_id` 为 null），与库存流水无关。
+- `rpt.jst_qmcust_salesoutbound`（奇门出库单）：非本业务口径。
+
+**请求**：确认这 4 类表在报表库（JSReportReplica）的同步是否完整、以及「进销存导出」所用的日期字段是哪一个（发 / 审 / 确 / 记账）。给出字段口径后这 4 列即可接入。
+
+## 验收标准
+
+补表后，任一业务日应满足行内恒等式：
+
+```
+期末数量 = 期初数量 + 加工进仓 + 采购进仓 + 其它进仓 + 其它退货 + 销售退货 + 调拨入
+          − 采购退货 − 销售出仓 − 盘点 − 加工出仓 − 调拨出 − 其它出库
+```
+
+页面会以该恒等式做逐仓自校验，全部通过后才会撤下「暂缺单据来源」的提示。