# REV004 / 分账短版说明（给产品 / 前端）（2026-04-14）

## 一句话结论
**分账** 不是退款，也不是减免。  
它的业务含义是：
> 把一笔原账单按规则拆成多笔可独立处理的结果，便于分别收费、分别开票、分别承担。

当前 REV004 后端已经支持：
- **发起分账申请**
- **进入待审批**
- **被日志/查询/审批状态承接**

当前还不支持：
- **审批通过后真正执行拆账，生成多张目标账单**

---

## 当前可以怎么理解
### 业务上
老系统分账支持两种方式：
1. **按水量分账**
2. **按费用组成分账**

它适用于：
- 客户需要开多张发票
- 客户不能一次缴清
- 一张账单需要按规则拆给多个结果对象

### 后端当前落地到哪里
当前后端实现的是：
- `SPLIT_ADJUST` 分账申请
- 提交后状态：`PENDING_APPROVAL`
- 可以查询、留痕、审批承接

但还没有做到：
- 真的把一张原账单拆成多张目标账单
- 真的生成拆分明细
- 真的进入收费/开票承接执行态

---

## 为什么还没做到执行态
因为“真正分账执行”不是普通字段修改，而是一个独立正式业务对象级能力，至少涉及：
- 原账单与目标账单关系
- 分摊规则
- 分摊明细
- 审批通过后的执行流程
- 执行失败回滚
- 与收费/开票的后续承接

所以当前先落的是：
> **申请态 / 受理态**

而不是：
> **执行态 / 拆账落地态**

---

## 现在前端该怎么处理
### 当前前端可以做的
- 把“分账”当成一种**待审批业务申请**来用
- 提交后展示：
  - `adjustmentNo`
  - `resultStatus = PENDING_APPROVAL`
  - `approvalStatus = PENDING_APPROVAL`
  - `writeBackStatus = PENDING`
- 在日志/列表中查看这笔申请的留痕与状态

### 当前前端不要假设的
- 不要假设提交分账后会立刻生成多张新账单
- 不要假设已经存在完整的“分账结果明细页”可直接读取目标账单集合

---

## 如果后续要继续做
建议后续按这个顺序推进：
1. 明确业务真值：分账结果到底是“多张子账单”为主，还是“多笔待收费结果”为主
2. 明确数据模型：`SplitAdjust / SplitAdjustDetail`
3. 明确审批后执行：真正拆账、重算、留痕、回看
4. 再补前端执行态页面

---

## 当前最适合对外的话术
> 当前 REV004 已支持“分账申请”的统一受理、审批与查询回看，但尚未落到“审批通过后真正拆账生成多张子账单”的执行态。若后续要继续建设，需要按独立正式业务对象方式展开，而不是把它当成普通账单字段修改处理。