86 lines
2.6 KiB
Markdown
86 lines
2.6 KiB
Markdown
# 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 已支持“分账申请”的统一受理、审批与查询回看，但尚未落到“审批通过后真正拆账生成多张子账单”的执行态。若后续要继续建设，需要按独立正式业务对象方式展开，而不是把它当成普通账单字段修改处理。
|