Phase 0 Research: REV-004 旧账务迁移映射与功能缺失分析

Decision 1: 迁移映射以“业务语义”而非“旧表平移”为主

Decision: 迁移映射的基本单元定义为“旧业务对象语义”，如营业账、账户流水、预存退款、已销调整、价差调整、坏账、发票关系，而不是直接按旧表名原样对应一个新表。
Rationale: 旧模型以“汇总表 + 明细表 + 流程字段”承载很多业务，而新 REV-004 正式模型强调统一账务控制入口和共性规则；若按旧表名逐表平移，会破坏现有正式口径并导致在线模型过度回退。
Alternatives considered:
- 旧表逐表原样在线重建：被否决，因为与当前 REV-004 主口径“不新增独立账务台账表族”冲突。
- 完全忽略旧表结构，只保留抽象结论：被否决，因为不满足迁移验收和历史追溯要求。

Decision: 新系统迁移承接采用三层结构：在线主模型承接层、兼容映射层、历史只读层。
Rationale: 12_REV_Detailed.md 已明确旧精细账务台账不要求全部转为独立在线实体，但必须形成可追溯闭环；03_Interface_Design.md 也要求历史查询接口只读且支持汇总对账与明细追溯。三层结构能同时满足在线处理、迁移核查和审计要求。
Alternatives considered:
- 所有旧数据统一进入在线主模型：被否决，因为会污染新模型并放大状态机复杂度。
- 所有旧数据只做历史归档：被否决，因为当前有效账单、收费、发票和部分账务场景仍需在线承接。

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: 对旧对象相对当前 backend 的承接状态，统一使用四类判定：已承接、部分承接、历史只读、功能缺失。
Rationale: 当前仓库已出现大量“旧对象无同名表，但语义已被新对象承接”的情况；若只用“有表/没表”二元判断，会把语义承接误判为缺失。四类判定更适合迁移规划和后续开发排优先级。
Alternatives considered:
- 仅用“已实现 / 未实现”：被否决，因为无法表达历史只读与弱映射。
- 仅用“有表 / 无表”：被否决，因为结构缺失不等于业务能力缺失。

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: 相对旧数据字典，当前 backend 明显缺失或未明确形成稳定在线承接的主要是：
- 退款账独立对象
- 特账 / 特账明细
- 跨周期水量
- 阶梯累计量
- 预存退款 / 已销调整 / 价差调整 / 滞纳金减免 / 呆坏账等旧汇总表和明细表的一对一在线对象
- 专门面向迁移验收的新旧标识映射层
- 历史只读查询的统一在线出口
Rationale: BACKEND_TABLE_MAPPING.md 已明确这些属于弱映射或当前缺口；ChargeServiceImpl 虽有统一账务调整入口，但并未等价于旧模型的每类精细台账对象都已在线落地。
Alternatives considered:
- 认为这些缺失都必须在线重建：被否决，因为部分对象应以历史只读和映射承接。

Decision: 旧模型中的 TaskId、StepId、FlowRemark 等审批痕迹，本轮规划为优先按历史只读和追溯字段保留，不要求在线复刻完整审批引擎。
Rationale: 当前 REV-004 一期正式口径只保留审批能力位与边界说明；若迁移阶段强行复刻旧审批流，会显著扩大范围。
Alternatives considered:
- 在线完整复刻旧审批流：被否决，因为超出一期边界。
- 完全丢弃审批痕迹：被否决，因为不满足迁移验收和审计要求。

Decision: 推荐四个迁移批次：
1. 账户与营业账主明细
2. 收费结果与交易对象
3. 账务处理历史对象
4. 发票对象与账单关系
Rationale: 这种顺序能先锁定主键和核心关系，再逐步迁入衍生对象，降低断链风险。
Alternatives considered:
- 按模块菜单顺序迁移：被否决，因为会打乱主键和依赖关系。
- 按表名前缀整体迁移：被否决，因为无法体现业务依赖。