26 lines
1.5 KiB
Markdown
26 lines
1.5 KiB
Markdown
# 当天应该换单数最终匹配修复计划
|
||
|
||
## 差异现象
|
||
- 明细统计（正确）：9593单
|
||
- 汇总SQL统计：8537单
|
||
- 差值：1056单，其中包含16单没有首次扫描时间的订单
|
||
|
||
## 根因分析
|
||
1. **无扫描时间订单被过滤**：当交接单没有首次扫描记录时，`FirstScanTime_UTC5`为null，GREATEST函数计算时包含null参数会返回null，导致`DATE(AssessmentBaseTime)`为null，和日期比较时返回false，这些订单被错误过滤
|
||
2. **标签率条件多余**：考核时间本身只有在标签率≥80%时才会计算，有考核时间的订单必然满足标签率≥80%，额外加`LabelRate >= 0.8`条件属于冗余，可能导致边界情况漏算
|
||
|
||
## 修复方案
|
||
### 最终统计规则
|
||
「当天应该换单数」= 所有满足以下条件的订单：
|
||
1. 有考核时间（AssessmentTime IS NOT NULL）
|
||
2. 考核基准日期是当天 或 考核截止日期是当天
|
||
> 自动满足标签率≥80%，无需额外判断
|
||
|
||
## 执行步骤
|
||
1. 修复考核基准时间计算逻辑：
|
||
- 当`FirstScanTime_UTC5`为null时，直接用`GREATEST(fr.ReceiptTime, flr.FirstQualifiedTime_UTC5)`计算基准时间，不包含null参数
|
||
2. 移除汇总SQL中「当天应该换单数」的`ofi.LabelRate >= 0.8`条件
|
||
3. 验证5月1日统计结果 = 9593（与明细完全一致）
|
||
|
||
## 验证方法
|
||
修复后运行汇总SQL，5月1日的「当天应该换单数」数值必须等于明细统计的9593，完全匹配则修复完成。 |