fujian_water_biz_doc/docs/evidence/rev004-split-adjust-current-state-comparison-summary-2026-04-14.md

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