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

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，但内部结算、对账、失败重试、冲正和人工付款链路已经闭环。