35 lines
1.8 KiB
Markdown
35 lines
1.8 KiB
Markdown
## ADDED Requirements
|
||
|
||
### Requirement: 核销审批提交失败终态与重提
|
||
|
||
核销申请 SHALL 识别业务状态 `4` 为「审批提交失败」终态，申请列表、详情及账单中的关联申请状态 MUST 一致。该状态不得恢复原审批，有原修改权限的用户 SHALL 通过既有修改表单重新提交申请。
|
||
|
||
#### Scenario: 显式失败申请
|
||
|
||
- **WHEN** 核销申请 `status=4`，或账单分摊记录 `application_status=4`
|
||
- **THEN** 页面 MUST 以失败标签展示「审批提交失败」，申请筛选 MUST 包含值 4
|
||
- **AND** MUST 隐藏恢复审批，即使陈旧数据仍返回 `recoverable=true`
|
||
- **AND** 有原修改权限时 MUST 允许通过 `PUT /api/admin/employee-collection-applications/{id}` 重新提交
|
||
- **AND** MUST 保留原表单、账单分摊与权限范围
|
||
|
||
#### Scenario: 金额释放与重提结果
|
||
|
||
- **WHEN** 核销申请失败后用户刷新账单，或通过既有接口重新提交申请
|
||
- **THEN** 页面 MUST 从后端重新读取预占和可核销金额，不本地模拟释放金额
|
||
- **AND** 成功重提后 MUST 刷新申请与关联账单
|
||
|
||
### Requirement: 核销真实审批提交状态
|
||
|
||
核销列表和详情 SHALL 根据真实 `approval_submission_status` 展示 `0 待提交 / 1 提交中 / 2 已提交 / 3 提交失败 / 4 结果未知`；后端名称为空时 MUST 按数值回退，不仅依赖名称字段。
|
||
|
||
#### Scenario: 无审批上下文
|
||
|
||
- **WHEN** 申请返回 `approval_submission_status=0`
|
||
- **THEN** 列表和详情 MUST 展示「待提交」，不得因 0 为 falsy 而展示为缺失
|
||
|
||
#### Scenario: 提交结果未知
|
||
|
||
- **WHEN** 提交状态为 4，业务单并非失败终态，且后端返回 `recoverable=true`
|
||
- **THEN** 有原恢复权限的用户 MUST 仍能看到恢复审批入口
|
||
- **AND** 前端 MUST NOT 将结果未知自行当作审批提交失败或直接生成新审批
|