196 lines
5.6 KiB
Markdown
196 lines
5.6 KiB
Markdown
# 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. 最后补前端：
|
||
- 按水量 / 按费用组成 两种弹窗的真实执行态交互
|