86 lines
6.7 KiB
Markdown
86 lines
6.7 KiB
Markdown
# Phase 0 Research: REV-004 旧账务迁移映射与功能缺失分析
|
||
|
||
## Decision 1: 迁移映射以“业务语义”而非“旧表平移”为主
|
||
|
||
- **Decision**: 迁移映射的基本单元定义为“旧业务对象语义”，如营业账、账户流水、预存退款、已销调整、价差调整、坏账、发票关系，而不是直接按旧表名原样对应一个新表。
|
||
- **Rationale**: 旧模型以“汇总表 + 明细表 + 流程字段”承载很多业务，而新 `REV-004` 正式模型强调统一账务控制入口和共性规则；若按旧表名逐表平移，会破坏现有正式口径并导致在线模型过度回退。
|
||
- **Alternatives considered**:
|
||
- 旧表逐表原样在线重建：被否决，因为与当前 `REV-004` 主口径“不新增独立账务台账表族”冲突。
|
||
- 完全忽略旧表结构，只保留抽象结论：被否决，因为不满足迁移验收和历史追溯要求。
|
||
|
||
## Decision 2: 采用“三层承接模型”组织迁移
|
||
|
||
- **Decision**: 新系统迁移承接采用三层结构：在线主模型承接层、兼容映射层、历史只读层。
|
||
- **Rationale**: `12_REV_Detailed.md` 已明确旧精细账务台账不要求全部转为独立在线实体，但必须形成可追溯闭环；`03_Interface_Design.md` 也要求历史查询接口只读且支持汇总对账与明细追溯。三层结构能同时满足在线处理、迁移核查和审计要求。
|
||
- **Alternatives considered**:
|
||
- 所有旧数据统一进入在线主模型：被否决，因为会污染新模型并放大状态机复杂度。
|
||
- 所有旧数据只做历史归档：被否决，因为当前有效账单、收费、发票和部分账务场景仍需在线承接。
|
||
|
||
## Decision 3: 在线主模型优先承接账单、交易、留痕和发票主对象
|
||
|
||
- **Decision**: 在线主模型优先由 `biz_charge`、`biz_charge_detail`、`bk_transaction*`、`biz_operat_log*`、`biz_invoice*`、`biz_cust_invoice` 等对象承接。
|
||
- **Rationale**: `BACKEND_TABLE_MAPPING.md` 和当前 backend 代码已明确这些对象存在；`ChargeServiceImpl.adjustAccounting` 也证明退款、冲正、坏账申请等场景已开始围绕账单、原交易和操作日志形成统一处理骨架。
|
||
- **Alternatives considered**:
|
||
- 为退款、坏账、价差、已销调整分别新增独立在线主实体：被否决，因为当前 backend 未形成稳定一一对应对象，且与正式文档边界不一致。
|
||
|
||
## Decision 4: 功能缺失判定必须区分四类状态
|
||
|
||
- **Decision**: 对旧对象相对当前 backend 的承接状态，统一使用四类判定：`已承接`、`部分承接`、`历史只读`、`功能缺失`。
|
||
- **Rationale**: 当前仓库已出现大量“旧对象无同名表，但语义已被新对象承接”的情况；若只用“有表/没表”二元判断，会把语义承接误判为缺失。四类判定更适合迁移规划和后续开发排优先级。
|
||
- **Alternatives considered**:
|
||
- 仅用“已实现 / 未实现”：被否决，因为无法表达历史只读与弱映射。
|
||
- 仅用“有表 / 无表”：被否决，因为结构缺失不等于业务能力缺失。
|
||
|
||
## Decision 5: 当前 `REV-004` 核心账务控制能力已具备“部分承接”基础
|
||
|
||
- **Decision**: 当前 backend 对 `REV-004` 已具备部分承接基础，主要证据是：
|
||
- `ChargeController` 存在 `/business/charge/accounting-adjust`
|
||
- `ChargeServiceImpl.adjustAccounting` 已支持 `AMOUNT`、`WATER`、`REFUND`、`REVERSE`、`BAD_DEBT` 等调整类型
|
||
- `ChargeServiceAccountingAdjustTest` 已覆盖退款、冲正、坏账申请等关键路径
|
||
- `ChargeDO` / `ChargeDetailDO` / `OperatLogDO` / `OperatLogDetailDO` 已承接账单与留痕
|
||
- **Rationale**: 这些证据说明新系统不是从零开始，而是已经具备统一账务处理入口、原交易校验和日志留痕能力。
|
||
- **Alternatives considered**:
|
||
- 将 `REV-004` 判定为完全未实现：被否决，因为已有明确控制器、服务和测试证据。
|
||
- 将 `REV-004` 判定为完全闭环：被否决，因为旧模型的大量精细对象并未一一在线承接。
|
||
|
||
## Decision 6: 当前明显缺失的是“精细账务对象的独立在线承接”和“迁移专用映射/只读能力”
|
||
|
||
- **Decision**: 相对旧数据字典，当前 backend 明显缺失或未明确形成稳定在线承接的主要是：
|
||
- 退款账独立对象
|
||
- 特账 / 特账明细
|
||
- 跨周期水量
|
||
- 阶梯累计量
|
||
- 预存退款 / 已销调整 / 价差调整 / 滞纳金减免 / 呆坏账等旧汇总表和明细表的一对一在线对象
|
||
- 专门面向迁移验收的新旧标识映射层
|
||
- 历史只读查询的统一在线出口
|
||
- **Rationale**: `BACKEND_TABLE_MAPPING.md` 已明确这些属于弱映射或当前缺口；`ChargeServiceImpl` 虽有统一账务调整入口，但并未等价于旧模型的每类精细台账对象都已在线落地。
|
||
- **Alternatives considered**:
|
||
- 认为这些缺失都必须在线重建：被否决，因为部分对象应以历史只读和映射承接。
|
||
|
||
## Decision 7: 旧审批流字段优先保留为历史只读，不在线复刻
|
||
|
||
- **Decision**: 旧模型中的 `TaskId`、`StepId`、`FlowRemark` 等审批痕迹，本轮规划为优先按历史只读和追溯字段保留，不要求在线复刻完整审批引擎。
|
||
- **Rationale**: 当前 `REV-004` 一期正式口径只保留审批能力位与边界说明；若迁移阶段强行复刻旧审批流，会显著扩大范围。
|
||
- **Alternatives considered**:
|
||
- 在线完整复刻旧审批流：被否决，因为超出一期边界。
|
||
- 完全丢弃审批痕迹：被否决，因为不满足迁移验收和审计要求。
|
||
|
||
## Decision 8: 后续迁移实施必须先补四类矩阵工件
|
||
|
||
- **Decision**: 正式进入脚本开发前，必须先补四类矩阵：旧表到新对象映射、旧字段到新字段映射、旧状态到新状态映射、新旧标识映射。
|
||
- **Rationale**: 当前最大风险不是“脚本写不出来”，而是没有统一映射基线会导致每个批次各自理解旧模型，最终差异不可控。
|
||
- **Alternatives considered**:
|
||
- 先写 SQL，再回头补映射：被否决，因为会放大返工和核对成本。
|
||
|
||
## Decision 9: 迁移实施按“基础主对象 -> 收费结果 -> 账务处理历史 -> 发票关系”分批
|
||
|
||
- **Decision**: 推荐四个迁移批次：
|
||
1. 账户与营业账主明细
|
||
2. 收费结果与交易对象
|
||
3. 账务处理历史对象
|
||
4. 发票对象与账单关系
|
||
- **Rationale**: 这种顺序能先锁定主键和核心关系，再逐步迁入衍生对象，降低断链风险。
|
||
- **Alternatives considered**:
|
||
- 按模块菜单顺序迁移：被否决，因为会打乱主键和依赖关系。
|
||
- 按表名前缀整体迁移：被否决，因为无法体现业务依赖。
|