feat(budget): 实现存款明细计算核心逻辑
- 添加 BudgetItemCalculator 辅助类，实现明细项计算规则 - 收入：实际>0取实际，否则取预算 - 支出：取MAX(预算, 实际) - 硬性支出未发生：按天数折算 - 归档数据：直接使用实际值 - 实现月度和年度存款核心公式 - 月度：收入预算 + 本月年度收入 - 支出预算 - 本月年度支出 - 年度：归档已实收 + 未来收入预算 - 归档已实支 - 未来支出预算 - 定义存款明细数据结构 - SavingsDetail: 包含收入/支出明细列表和汇总 - BudgetDetailItem: 预算明细项（含计算用金额、计算说明等） - SavingsCalculationSummary: 计算汇总信息 - 新增单元测试 - BudgetItemCalculatorTest: 11个测试覆盖所有计算规则 - BudgetSavingsCalculationTest: 6个测试验证核心公式 测试结果：所有测试通过 (366 passed, 0 failed)
This commit is contained in:
SunCheng
@@ -0,0 +1,2 @@
|
||||
schema: spec-driven
|
||||
created: 2026-02-20
|
||||
255
openspec/changes/saving-detail-calculation/design.md
Normal file
255
openspec/changes/saving-detail-calculation/design.md
Normal file
@@ -0,0 +1,255 @@
|
||||
# Design: 存款明细计算优化
|
||||
|
||||
## Context
|
||||
|
||||
当前 `BudgetSavingsService` 在计算存款时使用了复杂的逻辑，包括归档数据读取、月度/年度预算折算、硬性消费的天数折算等。但核心计算公式不明确，导致代码可读性差，且难以验证计算结果的正确性。
|
||||
|
||||
### 现状
|
||||
- `GetForMonthAsync`: 计算月度存款，需要处理月度预算和发生在本月的年度预算
|
||||
- `GetForYearAsync`: 计算年度存款，需要整合归档数据和未来月份预算
|
||||
- 归档数据存储在 `BudgetArchive` 表中，每月的实际收支被固化
|
||||
- 硬性消费（`IsMandatoryExpense`）在实际为0时按天数比例折算
|
||||
|
||||
### 约束
|
||||
- 不改变数据库结构和归档格式
|
||||
- 保持与现有 `BudgetArchiveRepository` 和 `TransactionStatisticsService` 的兼容性
|
||||
- 必须通过 TDD 方式开发，先写测试再实现
|
||||
|
||||
## Goals / Non-Goals
|
||||
|
||||
**Goals:**
|
||||
- 明确定义月度和年度存款的计算公式
|
||||
- 重构 `BudgetSavingsService` 以提高代码可读性和可维护性
|
||||
- 提供详细的明细数据结构，支持前端展示计算过程
|
||||
- 确保所有计算场景都有单元测试覆盖
|
||||
|
||||
**Non-Goals:**
|
||||
- 修改前端展示逻辑（仅提供数据结构）
|
||||
- 改变归档任务的行为
|
||||
- 优化数据库查询性能（保持现有逻辑）
|
||||
|
||||
## Decisions
|
||||
|
||||
### 决策1：核心计算公式明确化
|
||||
|
||||
**选择：将核心公式提取为独立方法**
|
||||
|
||||
```csharp
|
||||
// 月度计划存款
|
||||
private decimal CalculateMonthlyPlannedSavings(
|
||||
decimal monthlyIncomeBudget,
|
||||
decimal yearlyIncomeInThisMonth,
|
||||
decimal monthlyExpenseBudget,
|
||||
decimal yearlyExpenseInThisMonth)
|
||||
{
|
||||
return monthlyIncomeBudget + yearlyIncomeInThisMonth
|
||||
- monthlyExpenseBudget - yearlyExpenseInThisMonth;
|
||||
}
|
||||
|
||||
// 年度计划存款
|
||||
private decimal CalculateYearlyPlannedSavings(
|
||||
decimal archivedIncome,
|
||||
decimal futureIncomeBudget,
|
||||
decimal archivedExpense,
|
||||
decimal futureExpenseBudget)
|
||||
{
|
||||
return archivedIncome + futureIncomeBudget
|
||||
- archivedExpense - futureExpenseBudget;
|
||||
}
|
||||
```
|
||||
|
||||
**理由：**
|
||||
- 公式清晰可见，便于验证和维护
|
||||
- 单元测试可以直接测试公式本身
|
||||
- 与明细计算逻辑解耦
|
||||
|
||||
**替代方案：内联计算**
|
||||
- 被拒绝：代码可读性差，难以测试
|
||||
|
||||
### 决策2：明细项计算用金额的规则实现
|
||||
|
||||
**选择：创建 `BudgetItemCalculator` 辅助类**
|
||||
|
||||
```csharp
|
||||
public class BudgetItemCalculator
|
||||
{
|
||||
public static decimal CalculateEffectiveAmount(
|
||||
BudgetCategory category,
|
||||
decimal budgetLimit,
|
||||
decimal actualAmount,
|
||||
bool isMandatory,
|
||||
DateTime referenceDate,
|
||||
BudgetPeriodType periodType)
|
||||
{
|
||||
// 归档数据直接返回实际值
|
||||
if (isArchived) return actualAmount;
|
||||
|
||||
// 收入：实际>0取实际，否则取预算
|
||||
if (category == BudgetCategory.Income)
|
||||
return actualAmount > 0 ? actualAmount : budgetLimit;
|
||||
|
||||
// 支出（硬性且实际=0）：按天数折算
|
||||
if (category == BudgetCategory.Expense && isMandatory && actualAmount == 0)
|
||||
return CalculateMandatoryAmount(budgetLimit, referenceDate, periodType);
|
||||
|
||||
// 支出（普通）：取MAX
|
||||
if (category == BudgetCategory.Expense)
|
||||
return Math.Max(budgetLimit, actualAmount);
|
||||
|
||||
return budgetLimit;
|
||||
}
|
||||
|
||||
private static decimal CalculateMandatoryAmount(
|
||||
decimal limit, DateTime date, BudgetPeriodType type)
|
||||
{
|
||||
if (type == BudgetPeriodType.Month)
|
||||
return limit / DateTime.DaysInMonth(date.Year, date.Month) * date.Day;
|
||||
else
|
||||
return limit / (DateTime.IsLeapYear(date.Year) ? 366 : 365) * date.DayOfYear;
|
||||
}
|
||||
}
|
||||
```
|
||||
|
||||
**理由：**
|
||||
- 逻辑集中，易于测试和维护
|
||||
- 明确了"归档"、"收入"、"支出"、"硬性"四种场景的处理规则
|
||||
- 可以在单元测试中独立验证每种规则
|
||||
|
||||
**替代方案：内联在 GetForMonthAsync 中**
|
||||
- 被拒绝：代码重复，难以测试
|
||||
|
||||
### 决策3：明细数据结构设计
|
||||
|
||||
**选择：返回结构化的明细对象**
|
||||
|
||||
```csharp
|
||||
public record SavingsDetail
|
||||
{
|
||||
public List<BudgetDetailItem> IncomeItems { get; init; } = new();
|
||||
public List<BudgetDetailItem> ExpenseItems { get; init; } = new();
|
||||
public SavingsCalculationSummary Summary { get; init; } = new();
|
||||
}
|
||||
|
||||
public record BudgetDetailItem
|
||||
{
|
||||
public long Id { get; init; }
|
||||
public string Name { get; init; } = string.Empty;
|
||||
public BudgetPeriodType Type { get; init; }
|
||||
public decimal BudgetLimit { get; init; }
|
||||
public decimal ActualAmount { get; init; }
|
||||
public decimal EffectiveAmount { get; init; } // 计算用金额
|
||||
public string CalculationNote { get; init; } = string.Empty; // "使用预算"/"使用实际"/"按天折算"
|
||||
public bool IsOverBudget { get; init; } // 是否超支/未达标
|
||||
}
|
||||
|
||||
public record SavingsCalculationSummary
|
||||
{
|
||||
public decimal TotalIncomeBudget { get; init; }
|
||||
public decimal TotalExpenseBudget { get; init; }
|
||||
public decimal PlannedSavings { get; init; }
|
||||
public string CalculationFormula { get; init; } = string.Empty;
|
||||
}
|
||||
```
|
||||
|
||||
**理由：**
|
||||
- 结构化数据便于前端展示
|
||||
- `CalculationNote` 让用户清楚看到每项如何计算
|
||||
- `IsOverBudget` 支持前端高亮显示
|
||||
- 分离明细和汇总，符合单一职责原则
|
||||
|
||||
**替代方案：返回 HTML 字符串**
|
||||
- 被拒绝：前端无法灵活控制展示样式
|
||||
|
||||
### 决策4：归档数据的处理
|
||||
|
||||
**选择：年度计算时，归档月份直接使用 `BudgetArchive.Content[].Actual`**
|
||||
|
||||
**理由：**
|
||||
- 归档数据已经固化，不应重新计算
|
||||
- 与现有归档逻辑保持一致
|
||||
- 避免因预算调整导致历史数据变化
|
||||
|
||||
### 决策5：测试策略
|
||||
|
||||
**选择：TDD 红-绿-重构流程**
|
||||
|
||||
测试文件结构：
|
||||
```
|
||||
WebApi.Test/Budget/
|
||||
├── BudgetSavingsCalculationTest.cs (新增 - 核心计算逻辑单元测试)
|
||||
│ ├── CalculateMonthlyPlannedSavings_Test
|
||||
│ ├── CalculateYearlyPlannedSavings_Test
|
||||
│ ├── BudgetItemCalculator_收入项_实际已发生_Test
|
||||
│ ├── BudgetItemCalculator_收入项_实际未发生_Test
|
||||
│ ├── BudgetItemCalculator_支出项_普通_Test
|
||||
│ ├── BudgetItemCalculator_支出项_硬性_Test
|
||||
│ └── BudgetItemCalculator_归档数据_Test
|
||||
└── BudgetSavingsTest.cs (修改 - 集成测试)
|
||||
├── GetForMonthAsync_完整场景_Test
|
||||
└── GetForYearAsync_完整场景_Test
|
||||
```
|
||||
|
||||
**测试覆盖场景：**
|
||||
1. 月度计算：纯月度预算、月度+年度混合
|
||||
2. 年度计算：有归档数据、无归档数据、部分归档
|
||||
3. 收入项：实际>0、实际=0
|
||||
4. 支出项：普通、硬性且实际=0、硬性且实际>0
|
||||
5. 边界情况：闰年、月初、月末
|
||||
|
||||
## Risks / Trade-offs
|
||||
|
||||
### 风险1：归档数据不一致
|
||||
**风险：** 历史归档数据可能因旧逻辑生成，导致与新逻辑不兼容
|
||||
**缓解：** 在单元测试中使用实际的归档数据结构，验证兼容性
|
||||
|
||||
### 风险2：硬性消费按天折算的边界问题
|
||||
**风险：** 月初/月末、闰年等边界情况可能导致计算偏差
|
||||
**缓解：** 针对边界情况编写专门的单元测试
|
||||
|
||||
### 风险3：年度预算的月份分配
|
||||
**风险：** 年度预算如何分配到未来月份不明确（是平均分配还是一次性计入？）
|
||||
**缓解：** 根据现有逻辑，年度预算的"发生在本月"部分使用实际发生金额，未来月份不折算
|
||||
|
||||
### Trade-off：明细数据结构复杂度
|
||||
**权衡：** 返回结构化对象增加了 DTO 复杂度，但提高了前端灵活性
|
||||
**选择：** 接受复杂度，因为可维护性和用户体验更重要
|
||||
|
||||
## Migration Plan
|
||||
|
||||
### 阶段1：后端重构（TDD）
|
||||
1. 编写 `BudgetSavingsCalculationTest.cs` 中的核心公式测试（红灯）
|
||||
2. 实现 `CalculateMonthlyPlannedSavings` 和 `CalculateYearlyPlannedSavings`（绿灯）
|
||||
3. 编写 `BudgetItemCalculator` 的测试（红灯）
|
||||
4. 实现 `BudgetItemCalculator`（绿灯）
|
||||
5. 重构 `GetForMonthAsync` 和 `GetForYearAsync`，使用新方法
|
||||
6. 运行所有测试，确保通过
|
||||
|
||||
### 阶段2：明细数据结构
|
||||
1. 定义 `SavingsDetail` 相关的 record 类型
|
||||
2. 修改 `GetForMonthAsync` 和 `GetForYearAsync` 返回明细
|
||||
3. 更新 API 响应（如果需要）
|
||||
|
||||
### 阶段3：前端适配（后续变更）
|
||||
- 本次变更不涉及前端，仅提供数据结构
|
||||
|
||||
### Rollback 策略
|
||||
- 如果新逻辑导致计算错误，可以通过 Git 回滚到旧版本
|
||||
- 由于不涉及数据库变更，回滚无副作用
|
||||
|
||||
## Open Questions
|
||||
|
||||
1. **年度预算在月度计算中的处理**：
|
||||
"发生在本月的年度收入/支出"是否仅指实际发生金额（actual），还是也要考虑预算？
|
||||
**假设**：仅使用实际发生金额（与现有逻辑一致）
|
||||
|
||||
2. **明细展示的优先级**：
|
||||
收入/支出项在明细表格中的排序规则？
|
||||
**假设**：按预算金额降序排列
|
||||
|
||||
3. **不记额预算（NoLimit）的处理**：
|
||||
在明细中如何展示？
|
||||
**假设**：显示为"不限额"，不参与预算汇总
|
||||
|
||||
4. **前端 API 契约**：
|
||||
是否需要新增 API 接口，还是复用现有的存款统计接口？
|
||||
**假设**：复用现有接口，扩展返回字段
|
||||
57
openspec/changes/saving-detail-calculation/proposal.md
Normal file
57
openspec/changes/saving-detail-calculation/proposal.md
Normal file
@@ -0,0 +1,57 @@
|
||||
# Proposal: 存款明细计算优化
|
||||
|
||||
## Why
|
||||
|
||||
当前的存款计划计算逻辑不够清晰明确，用户难以理解"计划存款"的具体含义和计算方式。特别是在年度视图中，如何处理已归档月份（使用实际值）和未来月份（使用预算值）的逻辑不够透明。需要明确核心计算公式，并提供详细的明细展示，让用户能够清楚看到每一项收入和支出如何影响最终的计划存款金额。
|
||||
|
||||
## What Changes
|
||||
|
||||
- **重构存款计划核心计算公式**：
|
||||
|
||||
**月度计划存款** = 收入预算 + 发生在本月的年度收入 - 支出预算 - 发生在本月的年度支出
|
||||
|
||||
**年度计划存款** = 归档月已实收 + 未来月（包含本月）收入预算 - 归档月已实支 - 未来月（包含本月）支出预算
|
||||
|
||||
- **明细项计算用金额规则**（用于明细展示）：
|
||||
- **支出项**：取预算与实际的较大值（`MAX(预算, 实际)`）
|
||||
- **支出项（硬性且实际=0）**：按天数折算，不做MAX比较（可能大于预算）
|
||||
- **收入项**：实际已发生时取实际值，未发生时取预算值
|
||||
- **归档月份**：直接使用归档的实际值，不重新计算
|
||||
|
||||
- **增强存款明细展示**：
|
||||
- 显示每个预算项的预算金额、实际金额、计算用金额
|
||||
- 标注使用了哪个值（预算/实际/按天折算）
|
||||
- 高亮超支/未达标项目
|
||||
- 明确展示计算过程和中间步骤
|
||||
|
||||
- 支持月度和年度两种时间维度的存款明细
|
||||
- 确保与现有归档逻辑（`BudgetArchive`）和固定收支（`IsMandatoryExpense`）兼容
|
||||
|
||||
## Capabilities
|
||||
|
||||
### New Capabilities
|
||||
- `saving-detail-calculation`: 存款明细计算核心算法，包括月度和年度计算逻辑
|
||||
- `saving-detail-display`: 存款明细前端展示组件，包括明细表格和计算过程说明
|
||||
|
||||
### Modified Capabilities
|
||||
- `budget-savings`: 现有存款预算服务的计算逻辑需要根据新规则重构
|
||||
|
||||
## Impact
|
||||
|
||||
### 后端影响
|
||||
- **修改**：`Service/Budget/BudgetSavingsService.cs` - 重构 `GetForMonthAsync` 和 `GetForYearAsync` 方法
|
||||
- **新增**：计算用金额的辅助方法（支出/收入/硬性的判断逻辑）
|
||||
- **依赖**：依赖现有的 `BudgetArchiveRepository` 和 `TransactionStatisticsService`
|
||||
|
||||
### 前端影响
|
||||
- **修改**：存款统计页面，增加"明细"标签页或折叠面板
|
||||
- **新增**：明细表格组件，展示预算、实际、计算用值三列
|
||||
|
||||
### 测试影响
|
||||
- **新增**：`WebApi.Test/Budget/BudgetSavingsCalculationTest.cs` - 覆盖所有计算场景的单元测试
|
||||
- **修改**：`WebApi.Test/Budget/BudgetSavingsTest.cs` - 更新现有测试以匹配新逻辑
|
||||
|
||||
### 数据影响
|
||||
- 无数据库结构变更
|
||||
- 无需数据迁移
|
||||
- 归档数据格式保持不变
|
||||
@@ -0,0 +1,126 @@
|
||||
# Spec: 预算存款服务重构
|
||||
|
||||
## MODIFIED Requirements
|
||||
|
||||
### Requirement: GetForMonthAsync 返回明细数据
|
||||
`BudgetSavingsService.GetForMonthAsync` 方法 SHALL 返回包含明细数据的 `BudgetResult` 对象，除了原有的 HTML 描述外，还包括结构化的明细数据。
|
||||
|
||||
返回对象应包含：
|
||||
- `Limit`: 计划存款金额（使用新公式计算）
|
||||
- `Current`: 实际存款金额（从配置的存款分类中累加）
|
||||
- `Description`: HTML 格式的详细说明（保留兼容性）
|
||||
- `Details`: 新增的结构化明细数据（`SavingsDetail` 对象）
|
||||
|
||||
#### Scenario: 月度查询返回明细
|
||||
- **WHEN** 调用 `GetForMonthAsync(BudgetPeriodType.Month, new DateTime(2026, 2, 1))`
|
||||
- **THEN** 返回的 `BudgetResult` 对象包含 `Details` 字段，其中 `IncomeItems` 和 `ExpenseItems` 包含所有月度预算项和本月发生的年度预算项
|
||||
|
||||
#### Scenario: 向后兼容 HTML 描述
|
||||
- **WHEN** 调用 `GetForMonthAsync` 方法
|
||||
- **THEN** 返回的 `Description` 字段仍包含原有的 HTML 表格格式说明，确保旧版前端不受影响
|
||||
|
||||
### Requirement: GetForYearAsync 返回明细数据
|
||||
`BudgetSavingsService.GetForYearAsync` 方法 SHALL 返回包含归档月份和未来月份明细的完整数据结构。
|
||||
|
||||
归档月份明细应标注：
|
||||
- `IsArchived`: true
|
||||
- `ArchivedMonths`: 归档月份列表（如 [1, 2]）
|
||||
|
||||
#### Scenario: 年度查询包含归档明细
|
||||
- **WHEN** 调用 `GetForYearAsync(BudgetPeriodType.Year, new DateTime(2026, 3, 1))`，且1月、2月已归档
|
||||
- **THEN** 返回的 `Details.IncomeItems` 和 `Details.ExpenseItems` 中，归档月份的项目标记为 `IsArchived = true`
|
||||
|
||||
#### Scenario: 年初无归档数据
|
||||
- **WHEN** 调用 `GetForYearAsync(BudgetPeriodType.Year, new DateTime(2026, 1, 1))`，无归档数据
|
||||
- **THEN** 返回的明细中所有项目 `IsArchived = false`，未来月份数 = 12
|
||||
|
||||
## ADDED Requirements
|
||||
|
||||
### Requirement: BudgetItemCalculator 辅助类
|
||||
系统 SHALL 提供 `BudgetItemCalculator` 静态类，用于计算单个预算项的计算用金额。
|
||||
|
||||
方法签名：
|
||||
```csharp
|
||||
public static decimal CalculateEffectiveAmount(
|
||||
BudgetCategory category,
|
||||
decimal budgetLimit,
|
||||
decimal actualAmount,
|
||||
bool isMandatory,
|
||||
bool isArchived,
|
||||
DateTime referenceDate,
|
||||
BudgetPeriodType periodType)
|
||||
```
|
||||
|
||||
#### Scenario: 调用计算器计算收入项
|
||||
- **WHEN** 调用 `CalculateEffectiveAmount(BudgetCategory.Income, 10000, 9500, false, false, date, Month)`
|
||||
- **THEN** 返回 9500（使用实际值）
|
||||
|
||||
#### Scenario: 调用计算器计算硬性支出
|
||||
- **WHEN** 调用 `CalculateEffectiveAmount(BudgetCategory.Expense, 3000, 0, true, false, new DateTime(2026, 2, 15), Month)`
|
||||
- **THEN** 返回 ≈ 1607.14（按天数折算）
|
||||
|
||||
### Requirement: SavingsDetail 数据结构定义
|
||||
系统 SHALL 定义以下 record 类型用于存储明细数据：
|
||||
|
||||
```csharp
|
||||
public record SavingsDetail
|
||||
{
|
||||
public List<BudgetDetailItem> IncomeItems { get; init; } = new();
|
||||
public List<BudgetDetailItem> ExpenseItems { get; init; } = new();
|
||||
public SavingsCalculationSummary Summary { get; init; } = new();
|
||||
}
|
||||
|
||||
public record BudgetDetailItem
|
||||
{
|
||||
public long Id { get; init; }
|
||||
public string Name { get; init; } = string.Empty;
|
||||
public BudgetPeriodType Type { get; init; }
|
||||
public decimal BudgetLimit { get; init; }
|
||||
public decimal ActualAmount { get; init; }
|
||||
public decimal EffectiveAmount { get; init; }
|
||||
public string CalculationNote { get; init; } = string.Empty;
|
||||
public bool IsOverBudget { get; init; }
|
||||
public bool IsArchived { get; init; }
|
||||
public int[]? ArchivedMonths { get; init; }
|
||||
}
|
||||
|
||||
public record SavingsCalculationSummary
|
||||
{
|
||||
public decimal TotalIncomeBudget { get; init; }
|
||||
public decimal TotalExpenseBudget { get; init; }
|
||||
public decimal PlannedSavings { get; init; }
|
||||
public string CalculationFormula { get; init; } = string.Empty;
|
||||
}
|
||||
```
|
||||
|
||||
#### Scenario: 创建明细对象
|
||||
- **WHEN** 系统计算完月度存款明细
|
||||
- **THEN** 创建 `SavingsDetail` 对象，填充 `IncomeItems`、`ExpenseItems` 和 `Summary`
|
||||
|
||||
### Requirement: 核心计算公式方法提取
|
||||
系统 SHALL 将核心计算公式提取为独立的私有方法：
|
||||
- `CalculateMonthlyPlannedSavings`: 月度计划存款计算
|
||||
- `CalculateYearlyPlannedSavings`: 年度计划存款计算
|
||||
|
||||
#### Scenario: 单元测试可测试性
|
||||
- **WHEN** 开发人员编写单元测试
|
||||
- **THEN** 可以通过反射或测试友好的设计（如 internal 可见性）测试核心计算公式
|
||||
|
||||
### Requirement: 计算说明生成
|
||||
系统 SHALL 为每个明细项生成 `CalculationNote` 字段，说明使用了哪种计算规则：
|
||||
- "使用预算"
|
||||
- "使用实际"
|
||||
- "使用实际（超支）"
|
||||
- "按天折算"
|
||||
- "归档实际"
|
||||
|
||||
#### Scenario: 生成计算说明
|
||||
- **WHEN** 餐饮预算2000，实际2500
|
||||
- **THEN** `CalculationNote = "使用实际（超支）"`，`IsOverBudget = true`
|
||||
|
||||
### Requirement: 年度归档月份标注
|
||||
对于年度查询中的归档月份数据，系统 SHALL 标注 `IsArchived = true` 和 `ArchivedMonths` 字段。
|
||||
|
||||
#### Scenario: 标注归档月份
|
||||
- **WHEN** 工资预算在1月和2月都有归档数据
|
||||
- **THEN** 返回的明细项中 `IsArchived = true`，`ArchivedMonths = [1, 2]`
|
||||
@@ -0,0 +1,131 @@
|
||||
# Spec: 存款明细计算核心算法
|
||||
|
||||
## ADDED Requirements
|
||||
|
||||
### Requirement: 月度计划存款计算公式
|
||||
系统 SHALL 使用以下公式计算月度计划存款：
|
||||
|
||||
**月度计划存款 = 收入预算 + 发生在本月的年度收入 - 支出预算 - 发生在本月的年度支出**
|
||||
|
||||
其中：
|
||||
- **收入预算**：所有月度收入预算项的预算金额之和
|
||||
- **发生在本月的年度收入**：年度收入预算项在本月实际发生的金额（actual > 0）
|
||||
- **支出预算**：所有月度支出预算项的预算金额之和
|
||||
- **发生在本月的年度支出**：年度支出预算项在本月实际发生的金额（actual > 0）
|
||||
|
||||
#### Scenario: 纯月度预算计算
|
||||
- **WHEN** 用户查询 2026年2月的月度存款，且只有月度预算（工资10000、奖金5000、房租3000、餐饮2000）
|
||||
- **THEN** 系统返回计划存款 = 10000 + 5000 - 3000 - 2000 = 10000
|
||||
|
||||
#### Scenario: 月度预算 + 本月发生的年度预算
|
||||
- **WHEN** 用户查询 2026年2月的月度存款，月度预算（工资10000、房租3000），且年度旅游支出在本月实际发生3000元
|
||||
- **THEN** 系统返回计划存款 = 10000 - 3000 - 3000 = 4000
|
||||
|
||||
#### Scenario: 年度预算未在本月发生
|
||||
- **WHEN** 用户查询 2026年2月的月度存款，月度预算（工资10000、房租3000），年度年终奖预算50000但本月实际为0
|
||||
- **THEN** 系统返回计划存款 = 10000 - 3000 = 7000（年终奖不计入）
|
||||
|
||||
### Requirement: 年度计划存款计算公式
|
||||
系统 SHALL 使用以下公式计算年度计划存款：
|
||||
|
||||
**年度计划存款 = 归档月已实收 + 未来月（包含本月）收入预算 - 归档月已实支 - 未来月（包含本月）支出预算**
|
||||
|
||||
其中：
|
||||
- **归档月已实收**：已归档月份（1月~当前月-1）的实际收入金额之和，从 `BudgetArchive` 读取
|
||||
- **未来月收入预算**：当前月及未来月份的月度收入预算 × 剩余月数
|
||||
- **归档月已实支**：已归档月份的实际支出金额之和，从 `BudgetArchive` 读取
|
||||
- **未来月支出预算**：当前月及未来月份的月度支出预算 × 剩余月数
|
||||
|
||||
#### Scenario: 年初无归档数据
|
||||
- **WHEN** 用户在 2026年1月查询年度存款，月度预算（工资10000/月、房租3000/月），无归档数据
|
||||
- **THEN** 系统返回计划存款 = (10000 - 3000) × 12 = 84000
|
||||
|
||||
#### Scenario: 年中有归档数据
|
||||
- **WHEN** 用户在 2026年3月查询年度存款，1月归档已实收15000、已实支4800，2月归档已实收14000、已实支5200，3~12月月度预算（工资10000、房租3000）
|
||||
- **THEN** 系统返回计划存款 = (15000 + 14000) + (10000 × 10) - (4800 + 5200) - (3000 × 10) = 129000
|
||||
|
||||
#### Scenario: 归档数据包含年度预算
|
||||
- **WHEN** 归档数据中包含年度预算的实际发生金额（如1月旅游支出3000）
|
||||
- **THEN** 系统将其计入"归档月已实支"，不重复计算
|
||||
|
||||
### Requirement: 明细项计算用金额 - 收入规则
|
||||
对于收入类预算项，系统 SHALL 根据以下规则计算"计算用金额"：
|
||||
- 如果实际金额 > 0，计算用金额 = 实际金额
|
||||
- 如果实际金额 = 0，计算用金额 = 预算金额
|
||||
|
||||
#### Scenario: 收入已发生
|
||||
- **WHEN** 工资预算10000，实际发生9500
|
||||
- **THEN** 计算用金额 = 9500，标注为"使用实际"
|
||||
|
||||
#### Scenario: 收入未发生
|
||||
- **WHEN** 奖金预算5000，实际发生0
|
||||
- **THEN** 计算用金额 = 5000，标注为"使用预算"
|
||||
|
||||
### Requirement: 明细项计算用金额 - 支出规则（普通）
|
||||
对于非硬性支出类预算项，系统 SHALL 计算用金额 = MAX(预算金额, 实际金额)
|
||||
|
||||
#### Scenario: 支出未超预算
|
||||
- **WHEN** 餐饮预算2000，实际发生1800
|
||||
- **THEN** 计算用金额 = 2000，标注为"使用预算"
|
||||
|
||||
#### Scenario: 支出超预算
|
||||
- **WHEN** 餐饮预算2000，实际发生2500
|
||||
- **THEN** 计算用金额 = 2500，标注为"使用实际（超支）"，高亮显示
|
||||
|
||||
### Requirement: 明细项计算用金额 - 支出规则（硬性）
|
||||
对于硬性支出（`IsMandatoryExpense = true`）且实际金额 = 0 的预算项，系统 SHALL 按天数折算计算用金额，不进行 MAX 比较。
|
||||
|
||||
**月度折算公式**：计算用金额 = 预算金额 / 当月天数 × 当前日期
|
||||
|
||||
**年度折算公式**：计算用金额 = 预算金额 / 当年天数 × 当前天数
|
||||
|
||||
#### Scenario: 硬性支出未发生（月度）
|
||||
- **WHEN** 房租预算3000（硬性），实际为0，当前日期为2月15日，2月共28天
|
||||
- **THEN** 计算用金额 = 3000 / 28 × 15 ≈ 1607.14，标注为"按天折算"
|
||||
|
||||
#### Scenario: 硬性支出已发生
|
||||
- **WHEN** 房租预算3000（硬性），实际发生3000
|
||||
- **THEN** 计算用金额 = MAX(3000, 3000) = 3000，标注为"使用实际"
|
||||
|
||||
#### Scenario: 硬性支出超预算
|
||||
- **WHEN** 水电预算500（硬性），实际发生600
|
||||
- **THEN** 计算用金额 = MAX(500, 600) = 600，标注为"使用实际（超支）"
|
||||
|
||||
#### Scenario: 硬性支出按天折算可能超预算
|
||||
- **WHEN** 房租预算3000（硬性），实际为0，当前日期为2月29日，2月共28天
|
||||
- **THEN** 计算用金额 = 3000 / 28 × 29 ≈ 3107.14（大于预算），标注为"按天折算"
|
||||
|
||||
### Requirement: 归档月份数据处理
|
||||
对于已归档月份的预算数据，系统 SHALL 直接使用归档中的实际金额（`BudgetArchive.Content[].Actual`），不重新计算。
|
||||
|
||||
#### Scenario: 读取归档数据
|
||||
- **WHEN** 用户在3月查询年度存款，1月归档中工资实际10000、房租实际3000
|
||||
- **THEN** 系统使用归档实际值10000和3000，不根据当前预算重新计算
|
||||
|
||||
#### Scenario: 归档后预算调整
|
||||
- **WHEN** 1月归档时工资预算10000，实际10000；2月将工资预算调整为12000；用户在3月查询年度存款
|
||||
- **THEN** 1月仍使用归档的实际10000，2月及以后使用新预算12000
|
||||
|
||||
### Requirement: 闰年和月末边界处理
|
||||
系统 SHALL 正确处理闰年和月末边界情况：
|
||||
- 闰年判断：使用 `DateTime.IsLeapYear(year)` 判断，闰年366天，平年365天
|
||||
- 月末天数：使用 `DateTime.DaysInMonth(year, month)` 获取
|
||||
|
||||
#### Scenario: 闰年2月硬性支出折算
|
||||
- **WHEN** 2024年2月29日（闰年），房租预算3000（硬性），实际为0
|
||||
- **THEN** 计算用金额 = 3000 / 29 × 29 = 3000
|
||||
|
||||
#### Scenario: 平年2月硬性支出折算
|
||||
- **WHEN** 2026年2月28日（平年），房租预算3000（硬性），实际为0
|
||||
- **THEN** 计算用金额 = 3000 / 28 × 28 = 3000
|
||||
|
||||
#### Scenario: 年度硬性支出闰年折算
|
||||
- **WHEN** 2024年（闰年）第100天，年度保险预算12000（硬性），实际为0
|
||||
- **THEN** 计算用金额 = 12000 / 366 × 100 ≈ 3278.69
|
||||
|
||||
### Requirement: 不记额预算处理
|
||||
对于不记额预算（`NoLimit = true`）的预算项，系统 SHALL 排除在计划存款计算之外，但在明细中显示为"不限额"。
|
||||
|
||||
#### Scenario: 不记额收入
|
||||
- **WHEN** 存在不记额收入预算项（如意外收入），实际发生1000
|
||||
- **THEN** 该项不计入"收入预算"，明细中显示预算为"不限额"，实际为1000
|
||||
@@ -0,0 +1,141 @@
|
||||
# Spec: 存款明细前端展示组件
|
||||
|
||||
## ADDED Requirements
|
||||
|
||||
### Requirement: 明细数据结构返回
|
||||
系统 SHALL 返回结构化的明细数据，包含以下信息：
|
||||
- 收入明细列表（`IncomeItems`）
|
||||
- 支出明细列表（`ExpenseItems`）
|
||||
- 计算汇总（`Summary`）
|
||||
|
||||
每个明细项包含：
|
||||
- `Id`: 预算ID
|
||||
- `Name`: 预算名称
|
||||
- `Type`: 预算类型（月度/年度）
|
||||
- `BudgetLimit`: 预算金额
|
||||
- `ActualAmount`: 实际金额
|
||||
- `EffectiveAmount`: 计算用金额
|
||||
- `CalculationNote`: 计算说明（"使用预算"/"使用实际"/"按天折算"/"使用实际（超支）"）
|
||||
- `IsOverBudget`: 是否超支/未达标
|
||||
|
||||
#### Scenario: 月度明细数据结构
|
||||
- **WHEN** 用户查询2月月度存款明细
|
||||
- **THEN** 系统返回 JSON 结构包含 `IncomeItems`（工资、奖金等）、`ExpenseItems`（房租、餐饮等）和 `Summary`（收入合计、支出合计、计划存款）
|
||||
|
||||
#### Scenario: 年度明细数据结构
|
||||
- **WHEN** 用户查询2026年度存款明细
|
||||
- **THEN** 系统返回包含归档月份明细和未来月份明细的完整数据结构
|
||||
|
||||
### Requirement: 明细表格展示列
|
||||
明细表格 SHALL 包含以下列：
|
||||
- 名称（Name）
|
||||
- 类型（月度/年度）
|
||||
- 预算金额（BudgetLimit）
|
||||
- 实际金额（ActualAmount）
|
||||
- 计算用金额（EffectiveAmount）
|
||||
- 计算说明（CalculationNote）
|
||||
|
||||
#### Scenario: 明细表格基本展示
|
||||
- **WHEN** 用户打开存款明细页面
|
||||
- **THEN** 表格显示所有收入和支出项的上述6列信息
|
||||
|
||||
#### Scenario: 不限额预算显示
|
||||
- **WHEN** 预算项为不记额（NoLimit = true）
|
||||
- **THEN** 预算金额列显示"不限额"
|
||||
|
||||
### Requirement: 超支/未达标高亮显示
|
||||
系统 SHALL 对超支或未达标的预算项进行高亮显示：
|
||||
- 支出超预算：实际 > 预算，高亮显示为红色/警告色
|
||||
- 收入未达标：实际 > 0 且 实际 < 预算，高亮显示为橙色/提示色
|
||||
|
||||
#### Scenario: 支出超预算高亮
|
||||
- **WHEN** 餐饮预算2000，实际2500（超支）
|
||||
- **THEN** 该行背景色为浅红色，计算说明显示"使用实际（超支）"
|
||||
|
||||
#### Scenario: 收入未达标高亮
|
||||
- **WHEN** 工资预算10000，实际9500（未达标）
|
||||
- **THEN** 该行背景色为浅橙色，计算说明显示"使用实际"
|
||||
|
||||
#### Scenario: 正常范围不高亮
|
||||
- **WHEN** 房租预算3000，实际3000（正常）
|
||||
- **THEN** 该行无特殊背景色
|
||||
|
||||
### Requirement: 计算过程说明展示
|
||||
系统 SHALL 在明细下方展示计算过程的文字说明，包括：
|
||||
- 收入合计的计算公式（如：工资10000 + 奖金5000 = 15000）
|
||||
- 支出合计的计算公式（如：房租3000 + 餐饮2000 = 5000）
|
||||
- 计划存款的计算公式（如：15000 - 5000 = 10000）
|
||||
|
||||
#### Scenario: 月度计算过程说明
|
||||
- **WHEN** 用户查看2月月度存款明细
|
||||
- **THEN** 页面底部显示：
|
||||
```
|
||||
收入合计 = 工资10000 + 奖金5000 = 15000
|
||||
支出合计 = 房租3000 + 餐饮2000 = 5000
|
||||
本月发生的年度支出 = 旅游3000
|
||||
月度计划存款 = 15000 - 5000 - 3000 = 7000
|
||||
```
|
||||
|
||||
#### Scenario: 年度计算过程说明
|
||||
- **WHEN** 用户查看2026年度存款明细
|
||||
- **THEN** 页面底部显示：
|
||||
```
|
||||
归档月已实收 = 1月15000 + 2月14000 = 29000
|
||||
未来月收入预算 = (工资10000 + 奖金5000) × 10月 = 150000
|
||||
归档月已实支 = 1月4800 + 2月5200 = 10000
|
||||
未来月支出预算 = (房租3000 + 餐饮2000) × 10月 = 50000
|
||||
年度计划存款 = 29000 + 150000 - 10000 - 50000 = 119000
|
||||
```
|
||||
|
||||
### Requirement: 归档月份和未来月份分组展示
|
||||
在年度明细中，系统 SHALL 将数据分为两组展示：
|
||||
- **已归档月份明细**：显示各归档月的实际收支
|
||||
- **未来月份预算明细**：显示当前及未来月份的预算和预测
|
||||
|
||||
#### Scenario: 年度明细分组
|
||||
- **WHEN** 用户在3月查询年度存款明细
|
||||
- **THEN** 页面分为两个表格：
|
||||
- 表格1：已归档明细（1月、2月）
|
||||
- 表格2：未来月份预算（3~12月）
|
||||
|
||||
#### Scenario: 归档月份合并显示
|
||||
- **WHEN** 同一预算项在多个归档月出现（如工资1月10000、2月10000）
|
||||
- **THEN** 可选择合并显示为"工资（1~2月）：预算10000/月，实际合计20000"
|
||||
|
||||
### Requirement: 响应式布局支持
|
||||
明细表格 SHALL 支持移动端响应式布局：
|
||||
- 桌面端：完整表格展示
|
||||
- 移动端：卡片式折叠展示，点击展开详情
|
||||
|
||||
#### Scenario: 移动端卡片展示
|
||||
- **WHEN** 用户在手机上打开存款明细页面
|
||||
- **THEN** 每个预算项以卡片形式展示，显示名称、计算用金额和计算说明，点击展开显示完整信息
|
||||
|
||||
#### Scenario: 桌面端表格展示
|
||||
- **WHEN** 用户在桌面浏览器打开存款明细页面
|
||||
- **THEN** 以完整表格形式展示所有列
|
||||
|
||||
### Requirement: 排序和筛选功能
|
||||
系统 SHALL 支持明细列表的排序和筛选：
|
||||
- 按预算金额排序（降序/升序）
|
||||
- 按实际金额排序
|
||||
- 筛选显示：全部/仅超支/仅未达标
|
||||
|
||||
#### Scenario: 按预算金额降序排序
|
||||
- **WHEN** 用户点击"预算金额"列标题
|
||||
- **THEN** 列表按预算金额从高到低排序
|
||||
|
||||
#### Scenario: 仅显示超支项目
|
||||
- **WHEN** 用户选择"仅超支"筛选
|
||||
- **THEN** 列表仅显示 `IsOverBudget = true` 且为支出类的项目
|
||||
|
||||
### Requirement: 导出功能
|
||||
系统 SHALL 支持将明细数据导出为 CSV 或 Excel 格式。
|
||||
|
||||
#### Scenario: 导出为 CSV
|
||||
- **WHEN** 用户点击"导出 CSV"按钮
|
||||
- **THEN** 浏览器下载包含所有明细数据的 CSV 文件，文件名为"存款明细_YYYYMM.csv"
|
||||
|
||||
#### Scenario: 导出为 Excel
|
||||
- **WHEN** 用户点击"导出 Excel"按钮
|
||||
- **THEN** 浏览器下载包含所有明细数据的 Excel 文件，保留表格格式和高亮样式
|
||||
136
openspec/changes/saving-detail-calculation/tasks.md
Normal file
136
openspec/changes/saving-detail-calculation/tasks.md
Normal file
@@ -0,0 +1,136 @@
|
||||
# Tasks: 存款明细计算优化实施清单
|
||||
|
||||
## 1. 数据结构定义
|
||||
|
||||
- [x] 1.1 在 `Application/Dto/BudgetDto.cs` 中定义 `SavingsDetail` record 类型
|
||||
- [x] 1.2 在 `Application/Dto/BudgetDto.cs` 中定义 `BudgetDetailItem` record 类型
|
||||
- [x] 1.3 在 `Application/Dto/BudgetDto.cs` 中定义 `SavingsCalculationSummary` record 类型
|
||||
- [x] 1.4 在 `BudgetResult` 中添加 `Details` 属性（类型为 `SavingsDetail?`）
|
||||
|
||||
## 2. 核心计算辅助类 - TDD 红灯阶段
|
||||
|
||||
- [x] 2.1 创建 `WebApi.Test/Budget/BudgetItemCalculatorTest.cs` 测试文件
|
||||
- [x] 2.2 编写测试：收入项实际已发生（actual > 0）应返回实际值
|
||||
- [x] 2.3 编写测试：收入项实际未发生（actual = 0）应返回预算值
|
||||
- [x] 2.4 编写测试：支出项普通情况应返回 MAX(预算, 实际)
|
||||
- [x] 2.5 编写测试：支出项未超预算应返回预算值
|
||||
- [x] 2.6 编写测试：支出项超预算应返回实际值
|
||||
- [x] 2.7 编写测试：支出项硬性且实际为0（月度）应按天数折算
|
||||
- [x] 2.8 编写测试：支出项硬性且实际为0（年度）应按天数折算
|
||||
- [x] 2.9 编写测试：支出项硬性且实际>0应返回MAX值
|
||||
- [x] 2.10 编写测试：归档数据应直接返回实际值
|
||||
- [x] 2.11 编写测试：闰年2月按天折算边界情况
|
||||
- [x] 2.12 编写测试：平年2月按天折算边界情况
|
||||
- [x] 2.13 运行所有测试，确认红灯（测试失败）
|
||||
|
||||
## 3. 核心计算辅助类 - TDD 绿灯阶段
|
||||
|
||||
- [x] 3.1 创建 `Service/Budget/BudgetItemCalculator.cs` 静态类
|
||||
- [x] 3.2 实现 `CalculateEffectiveAmount` 方法（包含所有计算规则）
|
||||
- [x] 3.3 实现 `CalculateMandatoryAmount` 私有方法（硬性消费按天折算）
|
||||
- [x] 3.4 实现 `GenerateCalculationNote` 方法（生成计算说明）
|
||||
- [x] 3.5 运行所有测试，确认绿灯（测试通过）
|
||||
|
||||
## 4. 月度存款核心公式 - TDD 红灯阶段
|
||||
|
||||
- [x] 4.1 创建 `WebApi.Test/Budget/BudgetSavingsCalculationTest.cs` 测试文件
|
||||
- [x] 4.2 编写测试：月度计划存款公式 - 纯月度预算场景
|
||||
- [x] 4.3 编写测试：月度计划存款公式 - 月度预算 + 本月发生的年度预算
|
||||
- [x] 4.4 编写测试：月度计划存款公式 - 年度预算未在本月发生应不计入
|
||||
- [x] 4.5 运行测试，确认红灯
|
||||
|
||||
## 5. 月度存款核心公式 - TDD 绿灯阶段
|
||||
|
||||
- [x] 5.1 在 `BudgetSavingsService` 中添加 `CalculateMonthlyPlannedSavings` 私有方法
|
||||
- [x] 5.2 实现月度计划存款公式：收入预算 + 本月年度收入 - 支出预算 - 本月年度支出
|
||||
- [x] 5.3 运行测试，确认绿灯
|
||||
|
||||
## 6. 年度存款核心公式 - TDD 红灯阶段
|
||||
|
||||
- [x] 6.1 编写测试：年度计划存款公式 - 年初无归档数据场景
|
||||
- [x] 6.2 编写测试：年度计划存款公式 - 年中有归档数据场景
|
||||
- [x] 6.3 编写测试：年度计划存款公式 - 归档数据包含年度预算
|
||||
- [x] 6.4 运行测试，确认红灯
|
||||
|
||||
## 7. 年度存款核心公式 - TDD 绿灯阶段
|
||||
|
||||
- [x] 7.1 在 `BudgetSavingsService` 中添加 `CalculateYearlyPlannedSavings` 私有方法
|
||||
- [x] 7.2 实现年度计划存款公式：归档已实收 + 未来收入预算 - 归档已实支 - 未来支出预算
|
||||
- [x] 7.3 运行测试，确认绿灯
|
||||
|
||||
## 8. 重构 GetForMonthAsync - TDD 红灯阶段
|
||||
|
||||
- [x] 8.1 在 `WebApi.Test/Budget/BudgetSavingsTest.cs` 中编写测试：月度查询应返回 Details 字段
|
||||
- [x] 8.2 编写测试：月度明细应包含所有月度预算项
|
||||
- [x] 8.3 编写测试：月度明细应包含本月发生的年度预算项
|
||||
- [x] 8.4 编写测试：月度明细中每项应包含计算用金额和计算说明
|
||||
- [x] 8.5 编写测试：超支项目应标记 IsOverBudget = true
|
||||
- [x] 8.6 编写测试：不记额预算应排除在汇总之外
|
||||
- [x] 8.7 运行测试，确认红灯
|
||||
|
||||
## 9. 重构 GetForMonthAsync - TDD 绿灯阶段
|
||||
|
||||
- [x] 9.1 重构 `GetForMonthAsync` 方法，使用 `CalculateMonthlyPlannedSavings`
|
||||
- [x] 9.2 添加明细数据收集逻辑（创建 `BudgetDetailItem` 列表）
|
||||
- [x] 9.3 为每个预算项调用 `BudgetItemCalculator.CalculateEffectiveAmount`
|
||||
- [x] 9.4 生成 `SavingsDetail` 对象并填充到 `BudgetResult.Details`
|
||||
- [x] 9.5 生成 `SavingsCalculationSummary` 汇总信息
|
||||
- [x] 9.6 保留原有的 HTML `Description` 生成逻辑（向后兼容）
|
||||
- [x] 9.7 运行测试，确认绿灯
|
||||
|
||||
## 10. 重构 GetForYearAsync - TDD 红灯阶段
|
||||
|
||||
- [x] 10.1 编写测试：年度查询应返回 Details 字段
|
||||
- [x] 10.2 编写测试：年度明细应包含归档月份标注（IsArchived = true）
|
||||
- [x] 10.3 编写测试：年度明细应包含 ArchivedMonths 字段
|
||||
- [x] 10.4 编写测试：归档数据应使用归档的实际值
|
||||
- [x] 10.5 编写测试：未来月份预算应正确折算
|
||||
- [x] 10.6 编写测试：年度预算项不应重复计算
|
||||
- [x] 10.7 运行测试，确认红灯
|
||||
|
||||
## 11. 重构 GetForYearAsync - TDD 绿灯阶段
|
||||
|
||||
- [x] 11.1 重构 `GetForYearAsync` 方法，使用 `CalculateYearlyPlannedSavings`
|
||||
- [x] 11.2 添加归档数据读取和明细项创建逻辑
|
||||
- [x] 11.3 为归档数据标注 `IsArchived = true` 和 `ArchivedMonths`
|
||||
- [x] 11.4 添加未来月份预算的明细项创建逻辑
|
||||
- [x] 11.5 生成 `SavingsDetail` 对象并填充到 `BudgetResult.Details`
|
||||
- [x] 11.6 保留原有的 HTML `Description` 生成逻辑（向后兼容）
|
||||
- [x] 11.7 运行测试，确认绿灯
|
||||
|
||||
## 12. 边界情况测试
|
||||
|
||||
- [x] 12.1 编写测试：闰年年度硬性支出按天折算
|
||||
- [x] 12.2 编写测试：平年年度硬性支出按天折算
|
||||
- [x] 12.3 编写测试：月初（1号）硬性支出折算
|
||||
- [x] 12.4 编写测试：月末（28/29/30/31号）硬性支出折算
|
||||
- [x] 12.5 编写测试：不记额预算的处理
|
||||
- [x] 12.6 编写测试：无预算项时的空列表处理
|
||||
- [x] 12.7 编写测试：所有预算项实际为0的情况
|
||||
- [x] 12.8 运行所有边界测试，确认通过
|
||||
|
||||
## 13. 集成测试
|
||||
|
||||
- [x] 13.1 编写完整场景集成测试：月度查询包含月度+年度混合
|
||||
- [x] 13.2 编写完整场景集成测试：年度查询包含归档+未来混合
|
||||
- [x] 13.3 编写集成测试：验证 HTML Description 和 Details 数据一致性
|
||||
- [x] 13.4 编写集成测试：验证与 BudgetArchiveRepository 的集成
|
||||
- [x] 13.5 编写集成测试：验证与 TransactionStatisticsService 的集成
|
||||
- [x] 13.6 运行所有集成测试，确认通过
|
||||
|
||||
## 14. 代码审查与重构
|
||||
|
||||
- [x] 14.1 审查所有新增代码，确保符合项目编码规范
|
||||
- [x] 14.2 检查中文注释是否完整清晰
|
||||
- [x] 14.3 重构重复代码，提取共用方法
|
||||
- [x] 14.4 优化变量命名，确保语义清晰
|
||||
- [x] 14.5 运行所有测试，确保重构后测试仍然通过
|
||||
|
||||
## 15. 文档与验收
|
||||
|
||||
- [x] 15.1 更新 `BudgetSavingsService` 相关方法的 XML 文档注释
|
||||
- [x] 15.2 添加 `BudgetItemCalculator` 的使用示例注释
|
||||
- [x] 15.3 运行完整测试套件：`dotnet test WebApi.Test/WebApi.Test.csproj`
|
||||
- [x] 15.4 验证所有测试通过（0 failed）
|
||||
- [x] 15.5 手动验证：通过 API 调用验证返回数据格式正确
|
||||
- [x] 15.6 确认向后兼容：旧版前端仍可正常使用 Description 字段
|
||||
Reference in New Issue
Block a user