fujian_water_biz_doc/docs/superpowers/plans/2026-06-08-revenue-bugfix-clear-scope-acceptance-test.md
tangweijie 3eccab2cf9 docs: 文档治理统一 — AGENTS.md 生命周期规则 + 模块归档 + DDL 修正
1. AGENTS.md 更新
   - water-docs: 新增 specs/ 与 docs/design/ 生命周期规则章节
   - water-backend: 更新协作引用(建设期/建成后、evidence 模块化)

2. specs/ 重复合并
   - 006-reminder-event-design 合并入 003-rev006-reminder-event-design
   - 001-rev004-accounting 删除冗余 data-model.md + contracts/
   - 002-rev005-invoice-flow 删除冗余 data-model.md + contracts/

3. evidence 按模块归档
   - 35 个 REV-004 文件归入 evidence/rev004-accounting/
   - 7 个通用 bugfix 文件归入 evidence/bugfix/ 和 bugfix/frontend/
   - 新建 rev005-invoice/、rev006-reminder/、rev007-statistics/ 目录

4. guides/ 清理
   - 14 个 REV004_*.md 移入 evidence/rev004-accounting/

5. 遗留文件处理
   - docs/research/ 归档到 Archive/06_Migration_Plans/
   - backend-check detached worktrees 清理

6. 交叉引用修复
   - 006-reminder-event-design → 003-rev006-reminder-event-design
   - docs/guides/REV004_ → docs/evidence/rev004-accounting/REV004_

7. DB 设计文档修正(01_Database_Design.md)
   - biz_invoice 明确为开票配置表,非发票记录表
   - 新增 biz_invoice_record 为发票申请/结果主表
   - 新增 biz_charge_invoice_rel 账单-发票关联说明
   - REV-005 承接口径表名全部修正

8. 发票审计证据
   - 新增 evidence/rev005-invoice/2026-06-16-invoice-document-audit.md
2026-06-16 11:47:16 +08:00

20 KiB
Raw Blame History

Revenue Bugfix Clear Scope Acceptance Test Implementation Plan

For agentic workers: REQUIRED SUB-SKILL: Use superpowers:subagent-driven-development (recommended) or superpowers:executing-plans to implement this plan task-by-task. Steps use checkbox (- [ ]) syntax for tracking.

Goal: 为营收明确缺陷第一批修复提供一份可交给测试人员执行的业务验收用例计划。

Architecture: 本计划按缺陷编号拆分验收场景,每个场景包含前置条件、操作步骤、期望结果和证据要求。验收不绑定具体测试工具,测试人员可通过浏览器页面、业务后台、数据库只读查询或接口日志完成证据采集。

Tech Stack: 福建水务营收系统、营收后台页面、柜台收费、柜台结账、红冲记录、水价模板、账务调整审批流程。


适用范围

本计划对应 docs/superpowers/specs/2026-06-08-revenue-bugfix-clear-scope-design.md 中纳入本轮的缺陷:

  • #78 水价调整:执行报错后,用户不应只能关闭菜单从头开始。
  • #39 柜台结账:柜台预存缴费记录应能进入待结清并完成结账。
  • #50 柜台结账:收费员筛选不应被后端无条件覆盖为当前登录用户。
  • #53 柜台收费:预存抵扣金额需要前后端契约保护和回归验证。
  • #58/#59 红冲记录:柜台红冲后应能在红冲记录页按红冲时间查到。
  • #69/#76 未销分账、呆坏账、价差调整、违约金减免:前端应准确表达“申请已提交,待审批/待回写”,不得提示为已生效。

以下问题不纳入本次验收:

  • #70 未销调整提示成功但账单未变。
  • #9 抄表状态修改无影响。

验收环境要求

  • 使用已经部署本轮前后端修复的测试环境。
  • 测试账号至少包含:
    • 管理员账号:可查看全部收费员数据,可执行水价调整、柜台结账、红冲记录查询。
    • 收费员 A可进行柜台收费、预存充值、柜台结账。
    • 收费员 B可进行柜台收费或预存充值用于验证收费员筛选。
    • 审批相关账号:可查看账务调整提交后的待审批记录。
  • 所有测试数据应使用测试客户,不使用生产客户。
  • 每个用例执行前记录测试时间、测试账号、客户编号、业务单号、页面截图或后台记录。

测试数据准备

  • 客户 C1存在正常水表、正常用水性质、可生成账单账户预存余额为 0。
  • 客户 C2存在正常水表和未结清账单账户预存余额大于 0余额小于或等于选中账单应收金额。
  • 客户 C3存在正常水表和未结清账单账户预存余额大于选中账单应收金额。
  • 客户 C4用于柜台预存充值不要求存在当月未结清账单。
  • 客户 C5用于账务调整申请存在可分账、可呆坏账、可价差调整或可违约金减免的历史账单。
  • 收费员 A 和收费员 B 分别产生至少一笔柜台收费或预存充值记录。
  • 柜台结账测试前确认存在未结账记录,红冲测试前确认存在已结账记录。

验收通过标准

  • 所有 P0 和 P1 用例通过。
  • P2 用例不出现阻断主流程的问题。
  • 每个缺陷编号至少有一条正向用例和一条异常或边界用例完成验证。
  • 页面提示、列表数据、业务记录三类证据能够互相印证。
  • 若出现失败,必须记录缺陷编号、操作步骤、输入数据、期望结果、实际结果和证据截图。

Task 1: #78 水价调整失败恢复验收

覆盖目标: 水价调整提交失败后,用户能看到明确错误,并可继续在当前页面修正后重新提交,不需要关闭菜单或重新进入页面。

  • Step 1: 准备水价调整测试数据

前置条件:

  • 使用管理员账号登录。
  • 进入“设置 / 价格 / 水价模板”页面。
  • 选择一个允许调价的水价模板。
  • 记录模板名称、模板编号、当前生效水价。

通过标准:

  • 页面能进入水价模板详情。

  • 页面存在“开始调价”或等价操作入口。

  • Step 2: 验证开始调价失败提示

操作步骤:

  1. 使用账号 A 进入水价模板并点击“开始调价”。
  2. 保持账号 A 不提交调价。
  3. 使用账号 B 进入同一租户同一水价模板并点击“开始调价”。

期望结果:

  • 账号 B 不应静默失败。
  • 页面应提示锁被占用、当前不可调价或等价业务错误。
  • 账号 B 页面不应进入可编辑调价态。
  • 账号 A 的调价状态不被账号 B 破坏。

证据要求:

  • 账号 B 错误提示截图。

  • 账号 A 仍处于调价态的截图。

  • Step 3: 验证提交失败后可继续修正

操作步骤:

  1. 使用账号 A 在调价态修改一个价格项。
  2. 构造一条业务不允许提交的数据,例如价格为空、价格为负数、必填项缺失,或使用环境中已知会被后端拒绝的调价数据。
  3. 点击提交。
  4. 查看失败提示。
  5. 在不关闭菜单、不刷新浏览器、不重新进入页面的情况下,把错误字段修正为合法值。
  6. 再次点击提交。

期望结果:

  • 第一次提交失败时,页面显示明确失败原因。
  • 页面仍保留在可继续处理的状态,用户能继续修改表单。
  • 第二次提交成功后,页面提示调价成功或进入后续审批状态。
  • 调价结果在水价模板详情中可见,或能看到对应待审批记录。

证据要求:

  • 第一次失败提示截图。

  • 修正后再次提交成功截图。

  • 成功后的水价模板详情或审批记录截图。

  • Step 4: 验证取消调价失败提示

操作步骤:

  1. 进入水价模板调价态。
  2. 点击“取消调价”。
  3. 如环境支持模拟失败,触发取消失败;如不支持模拟失败,则在网络异常或锁失效条件下验证。

期望结果:

  • 取消失败时页面显示明确失败原因。
  • 页面不应出现无提示、按钮无响应或调试信息外露。

证据要求:

  • 取消失败提示截图,或说明当前环境无法制造取消失败但正常取消路径通过。

Task 2: #39 柜台预存缴费进入待结清并完成结账验收

覆盖目标: 柜台预存充值记录能出现在柜台结账待结清列表,并可被结账确认。

  • Step 1: 创建柜台预存充值记录

前置条件:

  • 使用收费员 A 登录。
  • 选择客户 C4。
  • 客户 C4 当前无未结账预存充值记录,或记录本次充值前的未结账数量。

操作步骤:

  1. 进入“柜台收费”或预存充值入口。
  2. 为客户 C4 办理一笔预存充值,金额使用 100.00 元。
  3. 完成支付。
  4. 记录缴费单号、客户编号、充值金额、收费员、缴费时间。

期望结果:

  • 预存充值成功。
  • 系统生成柜台缴费记录。
  • 该记录未被标记为已结账。

证据要求:

  • 充值成功页面或缴费记录截图。

  • 单号、金额、收费员、时间。

  • Step 2: 查询柜台结账待结清列表

操作步骤:

  1. 使用收费员 A 或管理员进入“柜台结账”页面。
  2. 查询未结账记录。
  3. 使用客户 C4、收费员 A 或缴费时间范围筛选。

期望结果:

  • 客户 C4 的 100.00 元预存充值记录出现在待结清列表。
  • 记录金额、客户、收费员、缴费时间正确。
  • 若该记录没有账单月份、收费单号或营业账 ID页面显示 -- 或空值占位,不应显示 undefinednull、报错或导致整行无法选择。

证据要求:

  • 待结清列表截图。

  • 可见客户、金额、收费员、缴费时间、空值占位。

  • Step 3: 完成预存充值记录结账

操作步骤:

  1. 在待结清列表选择客户 C4 的预存充值记录。
  2. 点击结账或确认结账。
  3. 核对结账汇总金额为 100.00 元。
  4. 确认提交。

期望结果:

  • 结账成功。
  • 结账汇总金额包含该预存充值金额。
  • 结账后该记录不再出现在待结清列表。
  • 已结账记录中能查询到对应结账单。

证据要求:

  • 结账确认弹窗或确认页截图。
  • 结账成功截图。
  • 结账后待结清列表无该记录截图。
  • 已结账记录或结账单详情截图。

Task 3: #50 柜台结账收费员筛选验收

覆盖目标: 柜台结账查询在指定收费员时按指定收费员查询,不被强制覆盖为当前登录用户。

  • Step 1: 准备两个收费员的未结账记录

操作步骤:

  1. 使用收费员 A 产生一笔柜台收费或预存充值未结账记录。
  2. 使用收费员 B 产生一笔柜台收费或预存充值未结账记录。
  3. 记录两笔记录的客户、金额、收费员、缴费时间。

期望结果:

  • 收费员 A 和收费员 B 各有至少一笔未结账记录。
  • 两笔记录可通过客户或时间区分。

证据要求:

  • 两笔未结账记录的业务单据或列表截图。

  • Step 2: 管理员按收费员 A 查询

操作步骤:

  1. 使用管理员进入“柜台结账”页面。
  2. 筛选收费员为收费员 A。
  3. 点击查询。

期望结果:

  • 列表显示收费员 A 的未结账记录。
  • 列表不混入收费员 B 的记录。
  • 页面筛选条件保持为收费员 A。

证据要求:

  • 查询条件和结果列表同屏截图。

  • Step 3: 管理员按收费员 B 查询

操作步骤:

  1. 保持管理员账号。
  2. 将收费员筛选改为收费员 B。
  3. 点击查询。

期望结果:

  • 列表显示收费员 B 的未结账记录。
  • 列表不再显示收费员 A 的记录。
  • 系统没有把筛选条件改回管理员或当前登录用户。

证据要求:

  • 查询条件和结果列表同屏截图。

  • Step 4: 不选择收费员时验证默认规则

操作步骤:

  1. 使用收费员 A 登录。
  2. 进入“柜台结账”页面。
  3. 不选择收费员,直接查询未结账记录。

期望结果:

  • 若系统规则为普通收费员默认查本人,则列表只显示收费员 A 的记录。
  • 页面不应显示其他收费员数据,除非当前账号被配置为可查看全部收费员。

证据要求:

  • 登录账号信息和查询结果截图。

Task 4: #53 柜台收费预存抵扣验收

覆盖目标: 预存抵扣金额受预存余额和账单应收限制,合法抵扣能扣减余额并写入支付记录,非法抵扣有明确提示。

  • Step 1: 验证预存余额为 0 时开启抵扣

前置条件:

  • 客户 C1 存在未结清账单。
  • 客户 C1 预存余额为 0.00

操作步骤:

  1. 进入“柜台收费”页面。
  2. 查询客户 C1。
  3. 选择一笔或多笔未结清账单。
  4. 开启预存抵扣。
  5. 尝试提交收费。

期望结果:

  • 系统提示当前可抵扣金额为 0或要求确认不使用预存抵扣继续收费。
  • 未经确认不应直接提交收费。
  • 若确认继续,应按普通支付金额完成收费,不应产生预存扣减。

证据要求:

  • 预存余额为 0 的页面截图。

  • 提示或确认弹窗截图。

  • 最终收费记录截图。

  • Step 2: 验证抵扣金额小于账单应收

前置条件:

  • 客户 C2 存在未结清账单,应收金额大于预存余额。
  • 客户 C2 预存余额记录为 B 元,选中账单应收合计记录为 R 元,满足 0 < B < R

操作步骤:

  1. 查询客户 C2。
  2. 选择账单应收合计为 R 的账单。
  3. 开启预存抵扣。
  4. 确认页面计算抵扣金额为 B,剩余应付金额为 R - B
  5. 完成收费。
  6. 查询客户 C2 账户余额和支付记录。

期望结果:

  • 抵扣金额不超过预存余额。
  • 抵扣金额不超过账单应收合计。
  • 支付成功后客户预存余额扣减为 0.00
  • 支付记录中能看到预存抵扣金额为 B,或业务明细中能证明本次抵扣 B

证据要求:

  • 收费前余额和应收金额截图。

  • 收费确认金额截图。

  • 收费成功后余额截图。

  • 支付记录或业务明细截图。

  • Step 3: 验证预存余额大于账单应收

前置条件:

  • 客户 C3 存在未结清账单。
  • 客户 C3 预存余额记录为 B 元,选中账单应收合计记录为 R 元,满足 B > R > 0

操作步骤:

  1. 查询客户 C3。
  2. 选择应收合计为 R 的账单。
  3. 开启预存抵扣。
  4. 完成收费。
  5. 查询客户 C3 账户余额和支付记录。

期望结果:

  • 抵扣金额为 R,不得超过账单应收合计。
  • 本次实际支付金额为 0.00 或无需额外现金支付,按页面规则展示。
  • 收费成功后客户预存余额为 B - R
  • 支付记录保留本次预存抵扣金额 R

证据要求:

  • 收费确认页截图。

  • 收费成功后余额截图。

  • 支付记录或业务明细截图。

  • Step 4: 验证非法抵扣金额被拒绝

操作步骤:

  1. 在可操作环境中尝试提交超过预存余额的抵扣金额。
  2. 在可操作环境中尝试提交超过账单应收合计的抵扣金额。
  3. 在可操作环境中尝试提交负数抵扣金额。

期望结果:

  • 三类非法金额均被拒绝。
  • 页面或后端返回明确错误原因。
  • 客户余额、账单状态、支付记录不发生错误变更。

证据要求:

  • 每类非法输入的错误提示截图。
  • 验证余额和账单状态未变的截图。

Task 5: #58/#59 柜台红冲记录验收

覆盖目标: 柜台结账红冲后,红冲记录页能按红冲时间查询到记录,并展示柜台红冲业务字段。

  • Step 1: 准备已结账记录

操作步骤:

  1. 使用收费员 A 完成一笔柜台收费或预存充值。
  2. 在“柜台结账”中完成结账。
  3. 记录结账单号、客户、收费员、结账金额、结账时间。

期望结果:

  • 存在一笔可红冲的已结账记录。

证据要求:

  • 结账单详情截图。

  • Step 2: 执行柜台红冲

操作步骤:

  1. 进入已结账记录或结账单详情。
  2. 对 Step 1 的结账记录执行红冲。
  3. 填写红冲原因,例如“验收测试红冲”。
  4. 提交红冲。
  5. 记录红冲时间、红冲金额、红冲原因。

期望结果:

  • 红冲成功。
  • 原结账记录状态变为部分红冲或全部红冲。
  • 系统生成红冲记录。

证据要求:

  • 红冲提交页面截图。

  • 红冲成功提示截图。

  • 原结账记录状态截图。

  • Step 3: 按红冲时间查询红冲记录

操作步骤:

  1. 进入“红冲记录”页面。
  2. 设置红冲时间范围,开始时间早于 Step 2 的红冲时间,结束时间晚于 Step 2 的红冲时间。
  3. 点击查询。

期望结果:

  • 列表能查询到 Step 2 产生的红冲记录。
  • 查询条件标签应表达为“红冲时间”或等价语义。
  • 返回记录展示结账单号、收费员、客户、红冲金额、红冲时间、红冲原因。
  • 红冲金额与 Step 2 记录一致。

证据要求:

  • 查询条件和结果列表同屏截图。

  • Step 4: 验证红冲时间范围边界

操作步骤:

  1. 将查询开始时间设置为红冲时间之后。
  2. 点击查询。
  3. 将查询结束时间设置为红冲时间之前。
  4. 点击查询。
  5. 将查询时间范围重新覆盖红冲时间。
  6. 点击查询。

期望结果:

  • 红冲时间不在范围内时,不显示该红冲记录。
  • 红冲时间在范围内时,显示该红冲记录。
  • 系统不应按创建时间、处理时间或其他非红冲时间字段错误命中。

证据要求:

  • 不命中截图两张。
  • 命中截图一张。

Task 6: #69/#76 待审批状态文案验收

覆盖目标: 未销分账、呆坏账、价差调整、违约金减免提交后,页面按业务状态提示“申请已提交,待审批/待回写/处理完成”,不把待审批误说成已生效。

  • Step 1: 验证未销分账申请文案

操作步骤:

  1. 进入账务调整相关页面。
  2. 选择客户 C5 的一笔可分账账单。
  3. 发起未销分账申请。
  4. 提交后观察页面提示和列表状态。

期望结果:

  • 如该操作需要审批,页面提示“申请已提交,待审批”或等价文案。
  • 页面不应提示“分账成功”“已生效”这类让用户误解为即时落账的文案。
  • 审批列表或业务记录中存在待审批申请。

证据要求:

  • 提交后提示截图。

  • 业务列表状态或审批记录截图。

  • Step 2: 验证呆坏账申请文案

操作步骤:

  1. 选择客户 C5 的一笔可做呆坏账处理的账单。
  2. 发起呆坏账申请。
  3. 提交后观察页面提示和列表状态。

期望结果:

  • 如该操作需要审批,页面提示“申请已提交,待审批”或等价文案。
  • 页面不应提示“呆坏账处理完成”“已生效”这类即时落账文案。
  • 审批列表或业务记录中存在待审批申请。

证据要求:

  • 提交后提示截图。

  • 业务列表状态或审批记录截图。

  • Step 3: 验证价差调整申请文案

操作步骤:

  1. 选择客户 C5 的一笔可价差调整账单。
  2. 发起价差调整申请。
  3. 提交后观察页面提示和列表状态。

期望结果:

  • 如该操作需要审批,页面提示“申请已提交,待审批”或等价文案。
  • 若后端返回待回写状态,页面提示“待回写”或“待执行”。
  • 页面不应把待审批或待回写状态表达为已完成。

证据要求:

  • 提交后提示截图。

  • 业务列表状态或审批记录截图。

  • Step 4: 验证违约金减免申请文案

操作步骤:

  1. 选择客户 C5 的一笔存在违约金或可减免账单。
  2. 发起违约金减免申请。
  3. 提交后观察页面提示和列表状态。

期望结果:

  • 如该操作需要审批,页面提示“申请已提交,待审批”或等价文案。
  • 若后端返回处理完成且已回写,页面可提示“处理完成”。
  • 页面文案必须与审批状态和回写状态一致。

证据要求:

  • 提交后提示截图。
  • 业务列表状态或审批记录截图。

Task 7: 回归与一致性验收

覆盖目标: 本轮修复不破坏柜台收费、柜台结账、红冲记录、水价模板和账务调整的基础链路。

  • Step 1: 柜台收费基础回归

操作步骤:

  1. 选择一个无预存抵扣的客户。
  2. 完成一笔普通柜台收费。
  3. 查询支付记录和账单状态。

期望结果:

  • 收费成功。
  • 账单状态更新正确。
  • 支付记录金额正确。

证据要求:

  • 收费成功截图。

  • 支付记录或账单状态截图。

  • Step 2: 柜台结账基础回归

操作步骤:

  1. 查询普通账单收费产生的未结账记录。
  2. 选择记录并完成结账。
  3. 查询已结账记录。

期望结果:

  • 普通账单收费记录仍可结账。
  • 结账金额正确。
  • 结账后不再出现在待结清列表。

证据要求:

  • 待结清、结账确认、已结账记录截图。

  • Step 3: 红冲记录页面基础回归

操作步骤:

  1. 不输入任何筛选条件,打开红冲记录页面。
  2. 输入客户、收费员、红冲时间范围分别查询。

期望结果:

  • 页面正常加载。
  • 查询条件可正常输入和清空。
  • 列表分页、刷新、空结果状态正常。

证据要求:

  • 默认列表或空列表截图。

  • 条件查询截图。

  • Step 4: 水价模板基础回归

操作步骤:

  1. 进入水价模板页面。
  2. 展开组织或模板树。
  3. 查看水价明细。
  4. 不进入调价态时执行普通查看和刷新。

期望结果:

  • 水价模板树正常加载。
  • 明细正常展示。
  • 未进入调价态时不会出现可编辑误状态。

证据要求:

  • 模板树和明细截图。

验收记录模板

测试人员执行时,每条用例按以下格式记录:

缺陷编号:
用例名称:
执行人:
执行时间:
测试环境:
登录账号:
客户编号:
业务单号:
前置数据:
操作步骤:
期望结果:
实际结果:
通过状态:通过 / 不通过 / 阻塞
证据文件:
备注:

自检结果

  • 规格覆盖:本计划覆盖 #78#39#50#53#58/#59#69/#76,并明确排除 #70#9
  • 占位扫描:未发现占位内容。
  • 类型一致性:缺陷编号、业务页面、状态文案、金额边界、时间字段均与设计文档保持一致。