fujian_water_biz_doc/docs/evidence/rev004-accounting/rev004-accountprocess-split-adjust-gap-summary-2026-04-14.md

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