fix(db): 渠道迁移顺延为 113–115，避让远程 112 补资料链接
远程 main 新增 112_work_order_material_link，本地原 112–114 顺延为 113–115： - 113_fulfillment_channel_split - 114_drop_legacy_fulfillment_mode - 115_rename_facts_channel 同步更新文档与代码里的迁移编号引用。
This commit is contained in:
yml2213
+7
-7
@@ -1,17 +1,17 @@
|
||||
-- 112_fulfillment_channel_split.sql
|
||||
-- 113_fulfillment_channel_split.sql
|
||||
--
|
||||
-- 目标：把「渠道 / 状态 / 决策来源」从一列拆成三列，并把渠道决策从
|
||||
-- 「有没有任务」反推改为「配置驱动」。
|
||||
--
|
||||
-- 生产前置：
|
||||
-- · 生产迁移停在 111（2026-10-30 20:32）；本迁移为 112，编号未被占用。
|
||||
-- · 生产迁移停在 111（2026-10-30 20:32）；本迁移为 113，编号未被占用。
|
||||
-- · 生产数据：orders 438,740 / order_items 438,750 / 10.1 GB。
|
||||
-- · order_items 上任何全表 UPDATE 约 34s，超过 15s 语句超时——
|
||||
-- 所以本迁移**只做 DDL 与小表种子**，438k 行回填交给
|
||||
-- `scripts/backfill-fulfillment-channel.ts`（分批、幂等、可续跑）。
|
||||
--
|
||||
-- 本迁移不做的事：
|
||||
-- · 不删除 fulfillment_mode（等代码切换完成后由 113 删除）
|
||||
-- · 不删除 fulfillment_mode（等代码切换完成后由 114 删除）
|
||||
-- · 不清派生数据（由断代脚本执行）
|
||||
-- · 不改历史订单（回填脚本按断代日归档）
|
||||
--
|
||||
@@ -104,9 +104,9 @@ COMMENT ON COLUMN order_items.fulfillment_locked IS
|
||||
COMMENT ON COLUMN order_items.fulfillment_decided_by IS
|
||||
'最近一次渠道决策的后台用户；自动决策为空';
|
||||
|
||||
-- 旧列标记为废弃（113 删除）。保留是为了让过渡期代码仍可读历史值。
|
||||
-- 旧列标记为废弃（114 删除）。保留是为了让过渡期代码仍可读历史值。
|
||||
COMMENT ON COLUMN order_items.fulfillment_mode IS
|
||||
'【已废弃，勿写入】旧履约方式四值枚举；读取请改用 fulfillment_channel + fulfillment_status。计划由 113 迁移删除';
|
||||
'【已废弃，勿写入】旧履约方式四值枚举；读取请改用 fulfillment_channel + fulfillment_status。计划由 114 迁移删除';
|
||||
|
||||
-- ---------------------------------------------------------------------------
|
||||
-- 2. 新索引：按状态与渠道取数，全部走部分索引
|
||||
@@ -143,7 +143,7 @@ COMMENT ON INDEX idx_order_items_channel_product IS
|
||||
'成本快照管道：渠道 + 商品维度覆盖索引';
|
||||
|
||||
-- 注意：旧索引 idx_order_items_fulfillment_pending_id（108）与
|
||||
-- idx_order_items_fulfillment_product（110）在 113 里删除；
|
||||
-- idx_order_items_fulfillment_product（110）在 114 里删除；
|
||||
-- 过渡期保留，避免旧代码路径失速。
|
||||
|
||||
-- ---------------------------------------------------------------------------
|
||||
@@ -398,7 +398,7 @@ COMMENT ON TABLE finance_watermarks IS
|
||||
-- 8. 销售事实：允许新渠道与「未分类」桶
|
||||
-- ---------------------------------------------------------------------------
|
||||
|
||||
-- 销售事实继续复用 fulfillment_mode 列承载渠道值（113 再改列名），
|
||||
-- 销售事实继续复用 fulfillment_mode 列承载渠道值（115 再改列名），
|
||||
-- 但必须允许第三方卡券、未分类与归档状态。
|
||||
ALTER TABLE sales_daily_facts
|
||||
DROP CONSTRAINT IF EXISTS chk_sales_daily_facts_fulfillment_mode;
|
||||
+4
-4
@@ -1,9 +1,9 @@
|
||||
-- 113_drop_legacy_fulfillment_mode.sql
|
||||
-- 114_drop_legacy_fulfillment_mode.sql
|
||||
--
|
||||
-- 强制新模型：彻底删除旧 `order_items.fulfillment_mode` 及其索引/约束。
|
||||
--
|
||||
-- 背景：
|
||||
-- · 112 已加入 fulfillment_channel + fulfillment_status + fulfillment_source；
|
||||
-- · 113 已加入 fulfillment_channel + fulfillment_status + fulfillment_source；
|
||||
-- · 代码侧已全部改为读写新列，`fulfillment_mode` 不再有任何读写方；
|
||||
-- · 保留旧列只会让「新旧并存」继续存在，因此这一版直接删除。
|
||||
--
|
||||
@@ -11,9 +11,9 @@
|
||||
-- 1. 本迁移只做 DDL，不搬运数据；
|
||||
-- 2. 升级时应在维护窗口内先跑迁移，紧接着执行 `npm run finance:cutover-v2`
|
||||
-- 完成断代归档与派生数据清理，避免中间态被业务读到；
|
||||
-- 3. 已被 112 标记为 archived 的历史行不受影响。
|
||||
-- 3. 已被 113 标记为 archived 的历史行不受影响。
|
||||
|
||||
-- 上一版 113 曾加过「旧异常写入口」兼容触发器，这里一并清理，不再保留兼容层。
|
||||
-- 旧版迁移曾加过「旧异常写入口」兼容触发器，这里一并清理，不再保留兼容层。
|
||||
DROP TRIGGER IF EXISTS trg_cost_exceptions_fill_scope_key ON cost_exceptions;
|
||||
DROP FUNCTION IF EXISTS cost_exceptions_fill_scope_key();
|
||||
|
||||
+2
-2
@@ -1,7 +1,7 @@
|
||||
-- 114_rename_facts_channel.sql
|
||||
-- 115_rename_facts_channel.sql
|
||||
--
|
||||
-- 命名统一：销售事实的维度列由 fulfillment_mode 改为 channel。
|
||||
-- 值本身在 112 之后已经是渠道（含 unclassified），旧名字只会误导。
|
||||
-- 值本身在 113 之后已经是渠道（含 unclassified），旧名字只会误导。
|
||||
-- 唯一约束与索引会自动跟随列重命名，这里只额外修正索引名。
|
||||
|
||||
ALTER TABLE sales_daily_facts
|
||||
@@ -10,7 +10,7 @@ import { nowIso } from '../../utils/time.js'
|
||||
* 2. 归档订单（archived）不进事实；
|
||||
* 3. 成本来自 `cost_snapshots`，缺失就记 0 并计数，不把 0 当真实成本。
|
||||
*
|
||||
* 事实表暂时沿用 `channel` 列承载渠道值（113 再改列名）。
|
||||
* 事实表暂时沿用 `channel` 列承载渠道值（115 再改列名）。
|
||||
*/
|
||||
|
||||
export type ChannelFactsResult = {
|
||||
|
||||
+1
-1
@@ -97,7 +97,7 @@
|
||||
## 三、统一实施顺序
|
||||
|
||||
```text
|
||||
0. 统一履约事实（渠道 + 成本模型正交） 已完成（迁移 112–114）
|
||||
0. 统一履约事实（渠道 + 成本模型正交） 已完成（迁移 113–115）
|
||||
1. 商品主数据 + 渠道 SKU 映射 已完成 P0（仅自动发货/接单平台）
|
||||
2. 成本中心 + 销售事实 已完成 P0
|
||||
2.5 人工成本链路收敛（确认履约 → 扣积分/备用金 → 写快照） 已完成 P0（迁移 104）
|
||||
|
||||
@@ -1,7 +1,7 @@
|
||||
# dev 合并 main 评估（2026-10-27）
|
||||
|
||||
|
||||
> **历史文档（2026-10-31 前口径）**：文中 `fulfillment_mode` / `legacy_platform` 已随迁移 112–114 删除；
|
||||
> **历史文档（2026-10-31 前口径）**：文中 `fulfillment_mode` / `legacy_platform` 已随迁移 113–115 删除；
|
||||
> 现行口径为 `order_items.fulfillment_channel + fulfillment_status`，销售事实维度为 `sales_daily_facts.channel`。
|
||||
> 本文保留用于追溯当时的决策，不再作为实现依据。
|
||||
> 评估对象：`main`（2fb7aae1）与 `dev`（0de0fd7b + 当前未提交的财务 P0/P1 改动）。
|
||||
|
||||
+1
-1
@@ -1,7 +1,7 @@
|
||||
# 成本中心 API 契约
|
||||
|
||||
> 状态：**现行**。后端服务与前端页面都必须严格按此实现，不得各自发挥。
|
||||
> 最后校准：2026-10-31（履约渠道模型，迁移 112–114）
|
||||
> 最后校准：2026-10-31（履约渠道模型，迁移 113–115）
|
||||
> 代码基线：`main`
|
||||
> 详细业务口径见 [财务与履约口径总纲-2026-10-23.md](财务与履约口径总纲-2026-10-23.md)；数据模型见 [成本中心与履约模型.md](成本中心与履约模型.md)。
|
||||
|
||||
|
||||
+1
-1
@@ -1,7 +1,7 @@
|
||||
# 成本中心与履约模型
|
||||
|
||||
> 状态：**现行**。2026-10-31 起履约事实改为「渠道 + 状态」两列，旧 `fulfillment_channel` 已删除。
|
||||
> 最后校准：2026-10-31（迁移 112–114）
|
||||
> 最后校准：2026-10-31（迁移 113–115）
|
||||
> 代码基线：`main`
|
||||
> 数据基线：2026-10-29 生产 dump；历史数字仅作迁移参照。
|
||||
> 上线初始化/验收见 [财务上线初始化与验收-2026-10-26.md](财务上线初始化与验收-2026-10-26.md)。
|
||||
|
||||
@@ -1,7 +1,7 @@
|
||||
# 财务与履约口径总纲（2026-10-23 重写版）
|
||||
|
||||
|
||||
> **历史文档（2026-10-31 前口径）**：文中 `fulfillment_mode` / `legacy_platform` 已随迁移 112–114 删除；
|
||||
> **历史文档（2026-10-31 前口径）**：文中 `fulfillment_mode` / `legacy_platform` 已随迁移 113–115 删除；
|
||||
> 现行口径为 `order_items.fulfillment_channel + fulfillment_status`，销售事实维度为 `sales_daily_facts.channel`。
|
||||
> 本文保留用于追溯当时的决策，不再作为实现依据。
|
||||
> 状态：**已归档**。现行口径见《成本中心与履约模型》（2026-10-31 校准）与《成本中心API契约》。
|
||||
|
||||
@@ -1,7 +1,7 @@
|
||||
# order_site 财务系统深度分析（2026-10-27）
|
||||
|
||||
|
||||
> **历史文档（2026-10-31 前口径）**：文中 `fulfillment_mode` / `legacy_platform` 已随迁移 112–114 删除；
|
||||
> **历史文档（2026-10-31 前口径）**：文中 `fulfillment_mode` / `legacy_platform` 已随迁移 113–115 删除；
|
||||
> 现行口径为 `order_items.fulfillment_channel + fulfillment_status`，销售事实维度为 `sales_daily_facts.channel`。
|
||||
> 本文保留用于追溯当时的决策，不再作为实现依据。
|
||||
> 分析对象：订单履约、成本中心、客服备用金/积分、销售事实、影子总账、期间关账与平台对账。
|
||||
|
||||
+1
-1
@@ -20,7 +20,7 @@
|
||||
| 商品主数据 / 渠道 SKU 映射 / 成本中心 | **已实施 P0（`dev` 分支）**，迁移 `103/104`；标准商品 745 个，只覆盖自动发货 38 + 接单平台 707 |
|
||||
| `sales_daily_facts` / 订单级毛利 | **已实施 P0（`dev` 分支）**，迁移 `105`；94 天收入 ¥2,650.87 万、成本 ¥950.27 万 |
|
||||
| 人工成本录入（确认履约 → 扣积分/备用金 → 写快照） | **已实施 P0（`dev` 分支）**，迁移 `104/107`；2026-10-24 人工履约页下线、入口收敛到订单页；**无登记单、无审批、无报销** |
|
||||
| 履约渠道统一 `fulfillment_channel + fulfillment_status` | **已实施（2026-10-31，迁移 112–114）**；旧 `fulfillment_mode` 已删除，订单/成本/事实统一读渠道 |
|
||||
| 履约渠道统一 `fulfillment_channel + fulfillment_status` | **已实施（2026-10-31，迁移 113–115）**；旧 `fulfillment_mode` 已删除，订单/成本/事实统一读渠道 |
|
||||
| `finance_accounts` / `finance_journal_entries` / `finance_journal_lines` | **已实施 P0（迁移 108）** |
|
||||
| `finance_periods` / `finance_reconciliations` / `finance_reconciliation_items` | **已实施 P0（迁移 108）** |
|
||||
| `finance_business_events` / `finance_settlements` | 未实施（当前用条目唯一键幂等） |
|
||||
|
||||
Reference in New Issue
Block a user