# Phase 0 Research: REV-002 开账计费与账单生成缺口补齐

## 决策 1：`IF-REV-005` 继续作为正式账单生成接口

- **Decision**: `REV-002` 继续使用 `IF-REV-005` 作为正式账单生成接口编号，不新增新的 `IF-*` 编号。
- **Rationale**:
  - 当前正式接口总表和接口章节都已使用 `IF-REV-005`，缺的是闭环内容而不是编号本身。
  - 保持现有编号可以减少与其他模块编号治理的耦合。
  - 本轮重点是补齐规则、结果表达和数据库承接口径。
- **Alternatives considered**:
  - 新增新的账单生成接口编号：否决，因为没有编号冲突，只会制造额外扰动。
  - 维持总表项不补详细定义：否决，因为不足以支撑后续实现和评审。

## 决策 2：开账生成闭环仅覆盖“抄表校验后到账单生成”

- **Decision**: 本 feature 的正式范围只覆盖从抄表校验结果进入开账计费、生成营业账及其结果表达的闭环，不扩展到收费核销、发票申请、催缴或统计分析链路。
- **Rationale**:
  - 当前缺口明确聚焦在 `IF-REV-005` 和账单生成规则。
  - 收费、发票、催缴都已有单独模块和接口编号，不应混入本轮。
  - 先收口“账单生成前后边界”更有利于后续对实现进行准确评估。
- **Alternatives considered**:
  - 把收费核销一起纳入：否决，因为会扩大到 `REV-003`。
  - 把发票和催缴后续链路一起写入：否决，因为超出当前缺口范围。

## 决策 3：账单结果以 `biz_charge` + `biz_charge_detail` 主明细表达

- **Decision**: 账单生成结果统一以 `biz_charge` 作为主表、`biz_charge_detail` 作为明细表承接，不新增平行“特殊开账表”或独立账单结果模型。
- **Rationale**:
  - 数据库主文档已明确 `biz_charge*` 是开账结果承接口径。
  - 当前 backend 也已见 `charge/chargedetail` 相关入口。
  - 这样既能覆盖普通开账，也能把特殊开账作为来源类型或业务类型扩展纳入统一表达。
- **Alternatives considered**:
  - 单独新增“特殊开账表”：否决，因为没有正式主文档或实现证据支持。
  - 仅描述账单主表、不写明细关系：否决，因为会削弱费用组成表达。

## 决策 4：异常与阻断场景采用“阻断生成 + 返回失败原因”的口径

- **Decision**: 当价格模板、阶梯规则、费用组成或必要来源数据缺失时，`IF-REV-005` 采用“阻断生成 + 返回失败原因”的统一异常语义。
- **Rationale**:
  - 现有接口主文档已经有 `1_002_002_003` 这类错误码线索。
  - 对账单生成而言，缺规则时继续生成不符合正式业务口径。
  - 统一异常语义有助于详细设计、接口设计和治理文档表达一致。
- **Alternatives considered**:
  - 自动降级生成部分账单：否决，因为缺乏正式依据且风险高。
  - 只在日志中记录、不在接口返回中表达：否决，因为不利于评审和实现。

## 决策 5：治理台账保持“部分实现，闭环未完全收口”

- **Decision**: `REV-002` 的当前实现判断继续保持“部分实现”，但增加“账单生成规则与结果表达已完成文档收口”的说明。
- **Rationale**:
  - 当前治理台账已明确部分实现，且 backend 未见完整“账单生成专用闭环接口”证据。
  - 文档补齐不应被误读为实现已完成。
  - 这种表述更利于后续继续校核实现入口与缺口。
- **Alternatives considered**:
  - 改成“已实现”：否决，因为证据不足。
  - 保持“部分实现”但不提设计进展：否决，因为无法体现本轮交付价值。