tangweijie/fujian_water_biz_doc
1
0
Fork 0
Code Issues Pull Requests 12 Actions Packages Projects Releases 1 Wiki Activity
fujian_water_biz_doc/docs/evidence/rev004-accounting/rev004-accountprocess-split-adjust-brief-2026-04-14.md
tangweijie 3eccab2cf9 docs: 文档治理统一 — AGENTS.md 生命周期规则 + 模块归档 + DDL 修正 
1. AGENTS.md 更新
   - water-docs: 新增 specs/ 与 docs/design/ 生命周期规则章节
   - water-backend: 更新协作引用（建设期/建成后、evidence 模块化）

2. specs/ 重复合并
   - 006-reminder-event-design 合并入 003-rev006-reminder-event-design
   - 001-rev004-accounting 删除冗余 data-model.md + contracts/
   - 002-rev005-invoice-flow 删除冗余 data-model.md + contracts/

3. evidence 按模块归档
   - 35 个 REV-004 文件归入 evidence/rev004-accounting/
   - 7 个通用 bugfix 文件归入 evidence/bugfix/ 和 bugfix/frontend/
   - 新建 rev005-invoice/、rev006-reminder/、rev007-statistics/ 目录

4. guides/ 清理
   - 14 个 REV004_*.md 移入 evidence/rev004-accounting/

5. 遗留文件处理
   - docs/research/ 归档到 Archive/06_Migration_Plans/
   - backend-check detached worktrees 清理

6. 交叉引用修复
   - 006-reminder-event-design → 003-rev006-reminder-event-design
   - docs/guides/REV004_ → docs/evidence/rev004-accounting/REV004_

7. DB 设计文档修正（01_Database_Design.md）
   - biz_invoice 明确为开票配置表，非发票记录表
   - 新增 biz_invoice_record 为发票申请/结果主表
   - 新增 biz_charge_invoice_rel 账单-发票关联说明
   - REV-005 承接口径表名全部修正

8. 发票审计证据
   - 新增 evidence/rev005-invoice/2026-06-16-invoice-document-audit.md
2026-06-16 11:47:16 +08:00

2.6 KiB
Raw Blame History

REV004 / 分账短版说明（给产品 / 前端）（2026-04-14）

一句话结论

分账 不是退款，也不是减免。
它的业务含义是：

把一笔原账单按规则拆成多笔可独立处理的结果，便于分别收费、分别开票、分别承担。

当前 REV004 后端已经支持：

  • 发起分账申请
  • 进入待审批
  • 被日志/查询/审批状态承接

当前还不支持：

  • 审批通过后真正执行拆账，生成多张目标账单

当前可以怎么理解

业务上

老系统分账支持两种方式：

  1. 按水量分账
  2. 按费用组成分账

它适用于：

  • 客户需要开多张发票
  • 客户不能一次缴清
  • 一张账单需要按规则拆给多个结果对象

后端当前落地到哪里

当前后端实现的是：

  • SPLIT_ADJUST 分账申请
  • 提交后状态：PENDING_APPROVAL
  • 可以查询、留痕、审批承接

但还没有做到：

  • 真的把一张原账单拆成多张目标账单
  • 真的生成拆分明细
  • 真的进入收费/开票承接执行态

为什么还没做到执行态

因为“真正分账执行”不是普通字段修改，而是一个独立正式业务对象级能力，至少涉及：

  • 原账单与目标账单关系
  • 分摊规则
  • 分摊明细
  • 审批通过后的执行流程
  • 执行失败回滚
  • 与收费/开票的后续承接

所以当前先落的是：

申请态 / 受理态

而不是：

执行态 / 拆账落地态

现在前端该怎么处理

当前前端可以做的

  • 把“分账”当成一种待审批业务申请来用
  • 提交后展示：
    • adjustmentNo
    • resultStatus = PENDING_APPROVAL
    • approvalStatus = PENDING_APPROVAL
    • writeBackStatus = PENDING
  • 在日志/列表中查看这笔申请的留痕与状态

当前前端不要假设的

  • 不要假设提交分账后会立刻生成多张新账单
  • 不要假设已经存在完整的“分账结果明细页”可直接读取目标账单集合

如果后续要继续做

建议后续按这个顺序推进：

  1. 明确业务真值：分账结果到底是“多张子账单”为主，还是“多笔待收费结果”为主
  2. 明确数据模型：SplitAdjust / SplitAdjustDetail
  3. 明确审批后执行：真正拆账、重算、留痕、回看
  4. 再补前端执行态页面

当前最适合对外的话术

当前 REV004 已支持“分账申请”的统一受理、审批与查询回看，但尚未落到“审批通过后真正拆账生成多张子账单”的执行态。若后续要继续建设，需要按独立正式业务对象方式展开，而不是把它当成普通账单字段修改处理。