fujian_water_biz_doc/specs/004-rev007-revenue-statistics-design/research.md

Phase 0 Research: REV-007 营收统计查询设计

决策 1：REV-007 保持 IF-REV-010 作为正式统计查询接口

• Decision: REV-007 继续使用 IF-REV-010 作为正式统计查询接口编号，不新增新的 IF-* 编号。
• Rationale:
  • 当前正式接口总表已为 REV-007 预留 IF-REV-010，问题在于内容过薄，而不是编号错误。
  • 继续沿用现有编号可以避免与 REV-006 那类编号冲突治理混在一起。
  • 本轮重点是补齐统计主题、查询维度和输出口径，而不是重做接口编号体系。
• Alternatives considered:
  • 新增 IF-REV-014：否决，因为没有编号冲突，新增会制造不必要扰动。
  • 保持“仅总表项，不补详细定义”：否决，因为不足以支撑后续实现与评审。

决策 2：统计范围收敛为经营查询，不扩展到预测与 BI 专题

• Decision: REV-007 正式设计仅覆盖经营统计查询，包括营收、收费、欠费、客户、渠道、抄表完成率和必要的业务概览类统计；预测分析、专题大屏、独立 BI/数仓能力不纳入本轮正式范围。
• Rationale:
  • 当前正式详细设计和需求拆解都只给出了经营查询级别的描述。
  • backend 现状未见明确统计分析实现入口，过度扩展会直接变成新需求。
  • 先收口“标准查询口径”更符合“设计先行、实现待立项”的保守策略。
• Alternatives considered:
  • 把趋势预测、经营驾驶舱、大屏分析一并纳入：否决，因为超出现有正式范围。
  • 只保留一句“营收统计查询”：否决，因为无法指导后续实现或立项。

决策 3：统计结果按“主题 + 维度 + 指标”三层口径组织

• Decision: REV-007 的正式设计按“统计主题、查询维度、核心指标”三层组织，不直接写死复杂报表清单。
• Rationale:
  • 当前文档缺的是统计口径框架，而不是具体报表枚举。
  • 三层结构便于在详细设计、接口设计和数据库设计之间保持一致表达。
  • 后续若扩展某类专题报表，也能在既有三层口径下继续补充。
• Alternatives considered:
  • 直接罗列大量报表名称：否决，因为容易脱离现有实现依据。
  • 只写主题不写维度/指标：否决，因为口径仍然过空。

决策 4：数据库承接口径以在线主数据聚合和视图/汇总口径为主

• Decision: REV-007 在数据库设计中只约束“基于现有在线业务表聚合的视图/汇总口径”，不确认独立统计表或离线数仓对象。
• Rationale:
  • 当前数据库主文档只有一般性“统计分析视图”片段，未见 REV-007 专项统计表族。
  • backend 也未见明确统计模块，因此写成独立统计表会超出证据范围。
  • 以聚合视图/统计结果集描述可以满足设计收口，同时保持保守。
• Alternatives considered:
  • 臆造 stat_* 或 report_* 表：否决，因为没有实现或正式主文档证据。
  • 完全不写数据库承接口径：否决，因为接口与详设无法闭环。

决策 5：治理台账明确保持“设计收口完成，代码入口未见实现”

• Decision: REV-007 在治理台账中的当前实现判断保持“未见实现”，但增加“设计收口已完成”的状态说明。
• Rationale:
  • 现有 15_SYS002_Requirement_Breakdown.md 已明确该模块未见实现。
  • 文档补齐不应被误读为 backend 已完成统计能力。
  • 这种表述更适合后续立项与排期管理。
• Alternatives considered:
  • 直接改成“部分实现”：否决，因为暂无明确代码入口证据。
  • 只写“未见实现”不提设计进展：否决，因为无法体现本轮交付价值。