3.8 KiB
3.8 KiB
Quickstart: REV-005 发票业务流计划评审与最小校验
1. 评审入口
本轮目标是:
- 明确 REV-005 一期发票业务流范围与老系统对齐口径
- 形成 backend 可实施的接口、数据模型与查询兜底方案
- 为后续
/speckit.tasks与/speckit.implement提供直接输入
本轮验收重点检查:
- 范围与老系统操作手册是否一致
- 发票申请 / 查询兜底 / 结果回写 / 客户侧消费口径是否闭环
- planning 产物是否可直接拆解为 backend 开发任务
2. 评审步骤
步骤一:范围校验
确认一期只覆盖以下核心能力:
- 后台发票申请
- 后台单笔 / 批量开票
SYS-008异步协同与查询兜底- 发票结果回写与账单关联
- 客户侧查看 / 下载 / 推送已开票电子发票
同时确认以下内容未被带入:
- 客户侧直接申请开票
- 原始单账单任意部分金额开票
- 复杂拆分合并开票策略一次性做深
- 与税务局直接对接的细节实现
步骤二:老系统对齐校验
对照以下来源:
营收系统_用户操作手册.md福建水投微网厅操作手册.md营收数据字典.md
确认 planning 已吸收以下能力语义:
- 发票查询
- 发票开具
- 批量开票
- 电子发票查看/下载/推送
- 拆账/分账后分别开票
步骤三:单一真源校验
对照以下正式口径:
spec.md12_REV_Detailed.md03_Interface_Design.md01_Database_Design.md.specify/memory/constitution.md
确认 planning 没有让 Archive 直接替代正式设计结论。
步骤四:查询兜底校验
确认以下口径已统一:
- 提交申请后先生成申请单号 / 外部受理号
- 通过查询接口轮询获取开票结果
- 幂等回写以申请单号和状态为主键
- 已成功状态不得被后续失败结果覆盖
步骤五:backend 现状核对
确认当前 backend 发票模块仍主要是配置 CRUD:
InvoiceController.javaInvoiceServiceImpl.java
并确认后续 implement 需要新增:
- 申请接口
- 查询接口
- 结果回写/补偿查询逻辑
- 账单/客户开票信息/税率校验联动
步骤六:正式文档修订闭环校验
后续进入正式主文档修订时,统一按以下顺序执行:
- 先更新
12_REV_Detailed.md的业务规则与状态机。 - 再更新
03_Interface_Design.md的接口合同与时序。 - 再更新
01_Database_Design.md的承接口径与关系快照说明。 - 每修改 1 份目标文档,执行对应
make validate-file FILE=<目标文件>。 - 涉及跨文档引用变更时执行
make check-links。 - 涉及图表或时序图时执行
make validate-mermaid。
3. 最小校验命令
make validate-file FILE=docs/design/02_Detailed_Design/12_REV_Detailed.md
make validate-file FILE=docs/design/03_Technical_Design/03_Interface_Design.md
make validate-file FILE=docs/design/03_Technical_Design/01_Database_Design.md
make check-links
make validate-mermaid
说明:
- 当前 plan 阶段以正式文档门禁为主,不强制执行 backend 构建或测试。
- backend 相关验证将在
/speckit.implement阶段展开。
4. backend 实施前建议核对点
在进入 implement 之前,至少补充核对以下对象:
- 账单对象:
biz_charge* - 发票主对象:
biz_invoice - 客户开票信息:
biz_cust_invoice - 税率配置:
biz_invoice_taxrate - 操作留痕:
biz_operat_log* - 现有发票 Controller / Service / Mapper / DO / ReqVO / RespVO
5. 通过标准
满足以下条件即可进入下一批 tasks 拆解:
- 一期范围、老系统对齐边界、查询兜底策略已明确
- 接口合同和数据模型能直接支撑 backend 任务拆解
- 最小校验动作已明确并可执行
- 后续正式文档修订与 backend 实施边界已分清