fujian_water_biz_doc/specs/005-rev002-billing-generation-gap/research.md

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:
  • 改成“已实现”：否决，因为证据不足。
  • 保持“部分实现”但不提设计进展：否决，因为无法体现本轮交付价值。