# REV004 / 分账为什么还没做到执行态（2026-04-14）

## 1. 目的
本摘要用于解释：

为什么当前 `REV004/accountProcess` 后端已经支持 `SPLIT_ADJUST` 分账申请，
但还没有做到“审批通过后真正把一张原账单拆成多张目标账单”的执行态能力。

---

## 2. 当前结论
### 结论一句话
当前后端实现的是：
- **分账申请态**

尚未实现的是：
- **分账执行态**

也就是：
- 现在可以提交分账申请、进入待审批、被日志与查询承接；
- 但还没有真正生成多张目标账单、分摊明细和后续收费/开票承接结果。

---

## 3. 代码证据
### 3.1 当前入口
当前分账在 `accountProcess` 中的入口是：
- `POST /admin-api/business/accounting-adjust/unsold-split-submit`

对应代码：
- `AccountingAdjustProcessServiceImpl.createUnsoldSplit(...)`

其行为是把分账提交统一转成：
- `objectType = SPLIT_ADJUST`
- `adjustType = SPLIT`

然后交给统一账务处理入口：
- `chargeService.adjustAccounting(...)`

### 3.2 当前真正处理逻辑
在 `ChargeServiceImpl.handleSplitAdjust(...)` 中，当前逻辑只有：
- `approvalRequired = true`
- `resultStatus = PENDING_APPROVAL`
- `approvalStatus = PENDING_APPROVAL`
- `writeBackStatus = PENDING`
- `message = 账单拆分申请已提交，待审批`
- `needUpdate = false`

这说明：
1. 只受理申请；
2. 不改原账单；
3. 不生成目标账单；
4. 不生成拆分明细；
5. 不进入真正执行态。

### 3.3 当前校验逻辑
当前只做了最小申请校验：
- 仅未收费账单允许发起分账申请
- `splitCount >= 2`
- `splitCount <= 12`
- 必须填写原因编码
- 必须填写调整原因

这也进一步说明：
- 当前实现重心是“能不能发起分账申请”
- 不是“如何执行真正的分账结果落地”

---

## 4. 业务复杂度为什么高
真正的分账执行态，不是普通字段修改，而是**结构性重分摊**。

### 4.1 文档中的两类策略
老系统与文档明确支持：
- **按水量分账**
- **按费用组成分账**

### 4.2 按水量分账需要解决的问题
- 原账单总水量拆成多笔
- 拆分水量之和必须等于原水量
- 拆分后重新按水价重算金额
- 可能影响违约金、阶梯、费用明细

### 4.3 按费用组成分账需要解决的问题
- 原账单费用项按规则拆分
- 拆分后金额总额必须与原账单一致
- 目标账单 / 目标客户 / 金额分摊关系需要明确
- 费用项粒度如何绑定目标结果也需要独立明细结构

### 4.4 执行态至少需要的能力
若真正落地执行态，后端至少需要：
- 原账单与目标账单关系模型
- 分摊规则模型
- 分摊明细模型
- 审批通过后的执行流程
- 执行失败回滚
- 与收费/开票/日志/查询的后续承接

因此，这不是“小补丁”能力，而是**独立正式业务对象级别**的建设。

---

## 5. 文档证据
### 5.1 需求与手册口径
文档明确说明：
- 分账是“由一笔账单分成两笔独立账单信息”
- 可按“按水量”“按费用组成”进行分账调整
- 适用于：
  - 客户开多张发票
  - 不能一次缴清等场景

这说明业务真值更接近：
- **账单拆分 + 分摊结果重建**

不是单纯加一条审批记录。

### 5.2 REV004 正式对象口径
`REV004_FULL_ACCOUNTING_DOMAIN_DESIGN.md` 中已将：
- `SplitAdjust`
- `SplitAdjustDetail`

视为独立正式业务对象，并建议存在：
- `split_adjust_no`
- `split_rule_type`
- `source_charge_id`
- `target_charge_id`
- `target_cust_id`
- `split_amount`
- `split_ratio / split_basis`

这表明：
- 正式执行态设计方向已经明确；
- 但当前代码还没有真正落成这套模型。

### 5.3 文档中的关键冻结判断
文档还明确给出：
- 当前先冻结设计方向
- 分账调整后续应补规则表或规则字段组

这意味着：
- “申请态先落、执行态后补”是有设计背景的，
- 不是单纯遗漏开发。

---

## 6. 当前这轮 REV004 的实现目标
从当前整体 accountProcess 收口策略看，这轮优先解决的是：
- 统一提交入口
- 统一状态表达
- 审批边界
- 日志留痕
- 查询回看

也就是先做到：
- 用户能发起
- 系统能记录
- 前端能查看
- 审批流能承接

因此分账也被纳入了这套统一账务调整框架，先实现：
- **申请态可用**

而没有直接推进到：
- **执行态拆账**

---

## 7. 最终判断
### 当前已经做到
- `SPLIT_ADJUST` 已进入统一账务调整对象体系
- 可提交申请
- 返回 `PENDING_APPROVAL`
- 可被日志/查询/审批状态承接

### 当前还没做到
- 审批通过后真正生成多张目标账单
- 原账单与目标账单的主从关系落库
- 按水量/按费用组成的拆分明细落库
- 执行态后的收费/开票联动承接

### 最准确的一句话
> 当前 REV004 后端已经实现“分账申请态”，但由于真正的分账执行态涉及分摊规则、目标账单生成、拆分明细、重算与后续收费/开票承接，属于独立正式对象级能力，因此尚未在 `accountProcess` 这一层落地。

---

## 8. 建议下一步
如果后续要继续推进“分账执行态”，建议按顺序展开：
1. 先明确业务真值：
   - 结果对象到底是多张子账单、还是多笔待收费结果、还是两者同时存在
2. 再明确数据模型：
   - `SplitAdjust` / `SplitAdjustDetail` 主表、明细表、规则字段组
3. 再明确执行流程：
   - 审批通过 -> 拆账执行 -> 重算 -> 留痕 -> 查询回看
4. 最后补前端：
   - 按水量 / 按费用组成 两种弹窗的真实执行态交互