江苏金斯瑞 · 客户问题证据包
消费订单导出实付金额异常
结论不是“列表筛选错”，而是待支付订餐单提前写入 pay_price，取消后该字段仍保留；列表顶部按状态排除了取消单，列表行与导出却没有。
待研发修复
生产未修改
A 级：视频 + 生产只读聚合 + Git
全部订单4,922
有效实收订单4,915
正确实收金额¥105,706.90
导出多计¥152.80
评审结论
筛选范围正确；列表行级与导出的“实付金额”语义错误，列表顶部实收统计正确。
1 · 待支付下单
pay_price 已写入应付价2 · 取消/超时只更新订单状态，不清理应付价
3 · 页面顶部只统计 30/50/60，因此正确
4 · 列表行/导出无状态判断，取消单被误计
数据如何对上
| 状态 | 笔数 | 订单金额 | pay_price | 实际扣款 |
|---|---|---|---|---|
| 已取消、待支付、订餐 | 7 | 152.80 | 152.80 | 0.00 |
| 已付款 | 4,915 | 105,726.90 | 105,706.90 | 105,706.90 |
| 合计 | 4,922 | 105,879.70 | 105,859.70 | 105,706.90 |
导出错误实付 = 有效实收 105706.90 + 取消单应付价 152.80
= 105859.70
现金 703.16 + 补贴 105003.74 = 105706.90。账户扣款分摊与页面实收一致，证明 152.80 并未真实扣款。
直接责任提交
| 提交 | 作者 | 作用 |
|---|---|---|
5718ec399 | lanhaijun | 首次增加消费订单导出合计，对全部行累计实付，无状态门禁。 |
f323a5dc2 | lanhaijun | 流式 XLSX 重写后继续保留该累计逻辑。 |
7cde77d207 | sunqianqian | 抽取 pay_price - refund_amount helper，仍未判断状态。 |
bc02932658 | guodongwei | 页面顶部改为有效支付状态统计，导出没有同步。 |
上游订餐下单/取消提交的作者记录为占位身份 Example User <example@example.com>，不能据此归责到真实个人。
拟实施方案
P0 · 最小正确性修复
- 新增状态感知的
received_amount领域函数。 - 列表行、页面统计、导出行、导出合计共用同一状态集合。
- 待付款、已取消、已退款显示实收 0。
- 不清理历史
pay_price，不动支付/扣款链路。
P1 · 防止再次漂移
- 列表与导出共享筛选查询构造器。
- 补待付款、取消、付款、退款中、部分退款、全退款状态矩阵。
- 用真实函数/夹具测试，不用源码字符串断言代替业务测试。
- 测试同条件业务行数、订单金额和实收金额恒等式。
人工评审清单
- 确认有效实收状态为 30/50/60。
- 确认退款中是否立即扣减待审核退款金额。
- 确认不修改历史
pay_price数据。 - 确认是否需要向业务重发历史导出。
- 确认上线后用本次相同条件回验 105706.90 / 4915。
评审状态：待 Jack / 产品负责人 / 财务或运营口径负责人确认。