225 lines
6.6 KiB
Markdown
225 lines
6.6 KiB
Markdown
# 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. 最后补前端执行态页面与回看能力
|