Files
qipai/docs/devlogs/2026-08-11-M09-C-统计与结算收口.md
T

26 lines
2.9 KiB
Markdown
Raw Blame History

This file contains ambiguous Unicode characters
This file contains Unicode characters that might be confused with other characters. If you think that this is intentional, you can safely ignore this warning. Use the Escape button to reveal them.
# 2026-08-11 M09-C 统计与结算收口
## 工程结果
- 工程提交:`1f10715`,已推送并验证远端 `main` 与本地 HEAD 一致。
- 统一保洁任务、负责人、协作者、免清洁、驳回、完成、待结算、结算中和已结算口径;生成草稿或确认单后金额仍计入未付款口径,只有 `PAID` 才计入已结算。
- 协作任务以“任务 × 收款成员份额”为结算原子:同一份额最多存在一条有效结算明细,并发生成只有一个赢家;不同收款人分别形成付款单,任务仅在所有有效奖励份额均付款后进入 `SETTLED`
- 活动结算明细存在期间冻结成员新增、移除和奖励调整,避免旧快照与任务奖励错配;跨门店且无租户级权限的生成请求必须明确门店。
- 取消草稿或已确认结算单时保留原单和明细,创建不可变负向冲正记录、标记原明细已冲正并释放成员份额;冲正后可重新生成新有效结算。
- 新增结算状态事件,区分 `USER` / `SYSTEM` 操作人;详情页和 CSV 可追溯确认、出款、失败、冲正、付款及 traceId。
- 微信转账在外部请求前先以数据库 CAS 进入 `PROCESSING` 并固化 `CLP{settlementId}` 请求号;网络不确定结果保持处理中,只有供应商明确失败后才允许冲正,成功回调可幂等重放。
- 微信回调按已验签商户号和收款账户定位结算,避免跨租户裸查流水;人工已付只允许未发起或明确失败的已确认结算,并要求可对账流水号。
- 页面和服务端 CSV 导出复用结算列表同一查询方法、同一已提交筛选和同一排序;保洁任务、统计、运营队列与结算 CSV 的金额统一输出整数分。
## 验证证据
- Windows `scripts/dev/windows/test-all.ps1`:105.5 秒,退出码 0;仓库完整性、敏感信息、状态文档、后端全测、迁移计划、管理端构建/测试、懒加载体积和 M09-C 静态门禁全部通过。
- 管理端生产构建最大 JS 分块 `218,014 B`,低于 `500 KiB`;仅保留第三方 `@vueuse/core` PURE 注释位置警告。
- WSL 原生临时副本 + MySQL 8.4.10 完成 `up → verify → down → up → verify`160 条 up、132 条 verify、154 条 down,临时数据库与账号均已清理。
- MySQL 业务用例实测协作份额并发生成单赢家、活动明细唯一、成员冻结、冲正释放与重生成、处理中禁止取消、明确失败后取消、全部成员付款后任务最终结算,以及列表/导出同筛选同顺序。
- 历史 `CANCELLED` 结算迁移会生成基线冲正并释放成员;带“历史已冲正 + 当前有效”和“多条历史冲正”数据的 down/up 往返通过。
## 阶段结论
`M09-C=DONE`。唯一执行游标进入 `M09-D1`;真实微信商户转账仍为 `BLOCKED_EXTERNAL`,但内部结算、对账、失败重试、冲正和人工付款链路已经闭环。