# REV004 / 分账现状对照摘要（2026-04-14）

## 1. 目的
本摘要用于把 **旧设计**、**老数据字典**、**当前代码状态** 三者放在一起，对“分账（SplitAdjust）”给出一页式结论，回答：
- 旧系统/旧设计里的分账到底是什么
- 当前 REV004 设计里把它定位成什么
- 当前后端代码做到哪一步了
- 三者之间的差距到底在哪里

---

## 2. 一句话结论
> **旧系统里的分账是“真正的账单拆分/重分摊业务对象”，有汇总表、明细表和拆分后的结果对象；当前 REV004 设计也把它定义为独立正式对象，但当前后端代码只落到了“分账申请态”，还没有落到“审批通过后真正拆账生成子账单”的执行态。**

---

## 3. 旧设计口径（12_REV_Detailed.md）
来源：
- `../water-docs/docs/design/02_Detailed_Design/12_REV_Detailed.md`

### 旧设计里怎么定义分账
文档明确把：
- `SplitAdjust`
列为：
- **目标正式业务对象**
- 并且属于：
  - **L2 独立业务层**

### 旧设计里的关键语义
文档明确写到：
- `SplitAdjust | 分账调整 | 当前作为费用组成重分摊场景表达 | 支持按水量 / 按费用组成等分摊策略`

并在迁移补充里写到：
- **分账调整汇总 / 明细**
- 承接方式：
  - 在线主模型 + 费用重分摊场景
- 需要保留：
  - 原分摊结果
  - 调整后结果
  - 策略类型
  - 责任链

### 从旧设计可得的结论
旧设计的分账不是普通字段修改，也不是一条审批备注，而是：
- 有独立业务语义
- 有汇总/明细层
- 有原结果与新结果的前后对照
- 有策略与责任链

---

## 4. 老数据字典口径（营收数据字典.md）
来源：
- `../water-docs/docs/design/04_Appendix/Archive/05_Data_Dictionary/营收数据字典.md`

### 老系统真实表结构
#### 4.1 汇总表
- `PM_SEPARATE_RECORDS`

关键字段：
- `Applicant`
- `Mobile`
- `ApplyType`
- `SeparateType`
- `State`
- `Remark`
- `TaskId`
- `StepId`
- `FlowRemark`
- `BusinessType`

#### 4.2 明细表
- `PM_SEPARATE_RECORD_DETAILS`

关键字段：
- `SeparateRecordId`
- `CustId / CustCode / CustName / CustAddress`
- `FeeId`
- `NewFeeId`
- `BillMonth`
- `BillWater / NewBillWater`
- `LateFee / NewLateFee`
- `BillAmount / NewBillAmount`
- `ExtendedAmount / NewExtendedAmount`
- `ItemStr`
- `ProcType / ProcPerson / ProcDate / ProcRemark`
- `State`

### 从老数据字典可得的结论
老系统里的分账已经明显是**执行态对象**，因为它不只是有申请信息，还已经有：
- 原费用对象：`FeeId`
- 新产生对象：`NewFeeId`
- 原水量 / 分账水量
- 原金额 / 新金额
- 原滞纳金 / 新滞纳金
- 费用组成

也就是说，老系统分账不是“申请单”，而是：
> **有申请、有明细、有拆后结果对象的完整业务表族。**

---

## 5. 当前代码状态
来源：
- `sw-business/sw-business-server/src/main/java/.../AccountingAdjustProcessServiceImpl.java`
- `sw-business/sw-business-server/src/main/java/.../ChargeServiceImpl.java`

### 当前入口
当前分账提交入口：
- `POST /admin-api/business/accounting-adjust/unsold-split-submit`

调用路径：
- `AccountingAdjustProcessServiceImpl.createUnsoldSplit(...)`
- 转成统一账务调整：
  - `objectType = SPLIT_ADJUST`
  - `adjustType = SPLIT`
- 进入 `chargeService.adjustAccounting(...)`

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

### 当前校验逻辑
只校验：
- 原账单必须未收费
- `splitCount >= 2`
- `splitCount <= 12`
- 必须填写原因编码
- 必须填写调整原因

### 从当前代码可得的结论
当前代码实现的是：
- **分账申请态**

没有做到：
- 生成分账主表/明细表
- 生成目标账单
- 回填新账单 ID
- 原账单失效/已拆分标记
- 执行态回看

---

## 6. 三者对照

| 对照维度 | 旧设计 | 老数据字典 | 当前代码 |
|---|---|---|---|
| 是否独立对象 | 是，`SplitAdjust` | 是，汇总表+明细表 | 语义上是，代码上仍挂统一入口 |
| 是否支持按水量 / 按费用组成 | 是 | 是（`SeparateType`） | 申请态支持对象类型，但未落执行规则 |
| 是否有汇总表 | 有方向 | 有真实表 | 当前没有真实表落地 |
| 是否有明细表 | 有方向 | 有真实表 | 当前没有真实表落地 |
| 是否有“原对象 -> 新对象”关系 | 有方向 | 有（`FeeId -> NewFeeId`） | 没有 |
| 是否有拆前拆后水量/金额 | 有方向 | 有 | 没有执行态数据 |
| 是否只到审批申请 | 否 | 否 | 是 |
| 是否真正生成子账单 | 应该要 | 已有新费用ID表达 | 当前未实现 |

---

## 7. 当前最大的差距
最核心的差距不是“少几个字段”，而是：

### 旧系统 / 旧设计的分账
是：
- **完整业务对象**
- **有结果承接**
- **有拆后对象**

### 当前 REV004 代码的分账
只是：
- **申请态入口**
- **待审批状态表达**
- **统一日志/查询承接**

所以差距本质上是：
> **从“受理态”到“执行态”的整层能力还没有落。**

---

## 8. 为什么会停在这里
结合三者判断，原因可以归纳成：
1. 当前这轮 REV004 后端优先目标是统一入口、状态、日志、查询，不是重建所有独立执行对象。
2. 真正分账执行涉及：
   - 分摊规则
   - 主表/明细表
   - 目标账单生成
   - 守恒校验
   - 收费/开票承接
3. 因此当前才先落成：
   - `SPLIT_ADJUST` 申请态

而没有一步到位落成：
- `SplitAdjust` 执行态。

---

## 9. 最终判断
### 业务真值
分账本质上是：
- **账单拆分 / 重分摊**
- 不是退款
- 不是减免
- 也不只是审批单

### 当前状态
当前 REV004：
- 已经把“分账”纳入正式对象语义
- 但后端实现仍停在申请态

### 最适合对外讲的一句话
> 旧系统与旧设计里的分账本来就是“有汇总、有明细、有拆后结果对象”的正式业务对象；当前 REV004 后端只先落了统一申请与审批承接，没有把真正的拆账执行态一起落出来，所以它现在更像“分账申请”，还不是“已执行的分账对象”。

---

## 10. 建议下一步
若要继续推进分账执行态，建议：
1. 以老表结构 + 旧设计为真值来源，先冻结最小执行态模型
2. 先做按水量分账 MVP
3. 再扩按费用组成分账
4. 最后补前端执行态页面与回看能力