7.6 KiB
7.6 KiB
24小时换单率 分子/分母 精确定义与诊断报告
诊断完成日期：2026-05-16
问题：24H换单率超过100%（4745.83%、17924.00%、11193.10%、78075.00%）
第一部分：24H换单率的精确定义
分子（Numerator）：高标签率考核通过数
来源：DailyHighLabelRateAssessed CTE（第1037-1047行）
完整计算链：
DailyBeforeNoonPassed（第999-1015行）
↓
按照"首次成功日期"分组
统计：16点前到仓 + 完成时间<=考核时间 + 高标签率(ar.考核时间 IS NOT NULL)
结果：16点前考核通过包裹数
DailyAfternoonPassed（第1017-1034行）
↓
按照"首次成功日期"分组
统计：16点后到仓 + 完成时间<=考核时间 + 高标签率(ar.考核时间 IS NOT NULL)
结果：16点后考核通过包裹数
DailyHighLabelRateAssessed（第1037-1047行）
↓
UNION ALL两个表后，GROUP BY 日期
SUM(16点前) + SUM(16点后) = 高标签率考核通过数
精确定义：
分子 = 按"首次成功日期"分组的，
在24小时考核期限内完成的，
且冻结标签率≥80%的交接单中的包裹总数
关键特征：
- 按
首次成功日期（完成时间）分组 - 包含两部分：16点前到仓完成 + 16点后到仓完成
- 都要求"完成时间 <= 考核时间"
- 都要求"高标签率"（考核时间 IS NOT NULL）
分母（Denominator）：高标签率应该换单数
来源：DailyHighLabelRateShould CTE（第1065-1082行）
完整定义：
SELECT
DATE(CONVERT_TZ(ar.到货时间, '+00:00', '-05:00')) AS 日期,
COUNT(DISTINCT CONCAT(ar.BillOfLadingNumber, '|', ar.MasterPackageNumber)) AS 高标签率应该换单数
FROM ArrivalRequests ar
INNER JOIN (
SELECT DISTINCT
BillOfLadingNumber,
MasterPackageNumber
FROM InterchangeUnitLabelRates
WHERE label_rate_percent >= 80
) high_label_units ON ar.BillOfLadingNumber = high_label_units.BillOfLadingNumber
AND ar.MasterPackageNumber = high_label_units.MasterPackageNumber
GROUP BY DATE(CONVERT_TZ(ar.到货时间, '+00:00', '-05:00'))
精确定义：
分母 = 按"到货日期"分组的，
冻结标签率≥80%的交接单中的全部包裹总数
关键特征：
- 按
到货日期（到货时间）分组 - 只要求冻结标签率≥80%，不要求已完成
- 是该日期应该履约完成的全部包裹数
完整公式
24H换单率 = (高标签率考核通过数 / 高标签率应该换单数) × 100%
第二部分：关键发现 - 维度不一致问题
核心问题：分子和分母的日期维度不同
| 项目 | 日期维度 | 含义 | 来源CTE |
|---|---|---|---|
| 分子 | 首次成功日期 | 完成的日期 | DailyHighLabelRateAssessed |
| 分母 | 到货日期 | 应该完成的日期 | DailyHighLabelRateShould |
导致的后果
数学上不可能：分子和分母的日期不同步导致比率超过100%
具体例子：
2026-05-15：
- 应该换单数（分母）= 100个包裹（到货在05-15）
- 完成的包裹数（分子）= 0个（因为大多数在05-16完成）
- 24H换单率 = 0 / 100 = 0%
2026-05-16：
- 应该换单数（分母）= 50个包裹（到货在05-16）
- 完成的包裹数（分子）= 130个（包括05-15到货但05-16完成的100个 + 05-16到货已完成的30个）
- 24H换单率 = 130 / 50 = 260% ← 超过100%！
这正是你看到的4745%、17924%等异常值的根本原因！
第三部分：问题根源诊断
根本原因：业务逻辑定义与代码实现的矛盾
业务期望（根据用户的表述）：
24H换单率 = (实际完成并通过考核的包裹数) / (应该履约完成的包裹数) × 100%
这是一个"期望通过率"的概念：
- 对于到货在05-15的订单，期望在24H内（到05-16 16:00-23:59）完成
- 对于到货在05-16的订单，期望在24H内（到05-17 16:00-23:59）完成
代码实现（当前）：
分子：按"完成日期"分组
分母：按"到货日期"分组
导致在某一天的24H换单率 = (可能包括多天到货的完成包裹数) / (仅该天到货的包裹数)
这是数学上错误的！
为什么会出现这个错误？
推论：
- DailyHighLabelRateAssessed是按"首次成功日期"来汇总
- DailyHighLabelRateShould是按"到货日期"来汇总
- 在第1222-1223行的LEFT JOIN中：
LEFT JOIN DailyHighLabelRateAssessed dhras ON t.日期 = dhras.日期 LEFT JOIN DailyHighLabelRateShould dhlrs ON t.日期 = dhlrs.日期 - 虽然都用
t.日期作为JOIN条件，但这个日期实际上是不同含义的 - 最终导致分子和分母被错误地配对
第四部分：修复建议
选项1：修改分子为按到货日期分组（推荐）
核心逻辑：
- 分母：按到货日期统计应该换单数（已正确）
- 分子：改为按到货日期统计完成数，而不是按首次成功日期
修改步骤：
- 修改 DailyBeforeNoonPassed：改
GROUP BY DATE(CONVERT_TZ(oss.首次成功时间, '+00:00', '-05:00'))为GROUP BY DATE(CONVERT_TZ(ar.到货时间, '+00:00', '-05:00')) - 修改 DailyAfternoonPassed：同样修改
- 修改 DailyHighLabelRateAssessed：改
GROUP BY 日期的含义（来自哪个CTE）
计算含义：
某一天的24H换单率 = (该天到货的、在24H内完成的高标签率包裹) / (该天到货的、高标签率的全部包裹) × 100%
优点：符合业务逻辑，数学上正确，分子≤分母
选项2：保持按完成日期分组，修改分母
修改步骤：
- 修改 DailyHighLabelRateShould：改
GROUP BY DATE(CONVERT_TZ(ar.到货时间, '+00:00', '-05:00'))为按首次成功日期 - 只统计已经完成的、高标签率的订单
问题：这样分母的含义会变，不符合"应该履约"的业务逻辑
第五部分：精确答案总结
用户问题："你给我表述下24小时换单率的分子和分母分别是什么"
当前代码中的分子：
分子 = 按首次成功日期分组的、在24小时考核期限内完成的高标签率包裹总数
含义：某一天完成的包裹中，有多少是高标签率且满足考核时间的
当前代码中的分母：
分母 = 按到货日期分组的、冻结标签率≥80%的全部包裹总数
含义：某一天到货的、标签率≥80%的全部包裹
为什么超过100%：
因为分子和分母的日期维度不同！
例如某一天：
- 分母 = 该天到货的50个高标签率包裹
- 分子 = 该天完成的100个高标签率包裹（来自前几天到货的）
- 比率 = 100/50 = 200% ← 超过100%
正确的做法：
分子和分母应该基于同一个日期维度：
要么都按到货日期（推荐）
要么都按完成日期
推荐按到货日期，因为这样符合"履约"的业务含义：
某一天到货的订单，在24小时内完成的比例是多少
建议后续行动
-
确认业务逻辑：询问用户24H换单率到底应该统计什么？
- A) 某天到货的订单，24小时内完成的比例？（推荐）
- B) 某天完成的订单中，有多少满足考核要求？
-
根据确认结果修改代码：修改分子或分母之一，确保日期维度一致
-
验证修复：确保修复后24H换单率≤100%
关键代码位置
- DailyBeforeNoonPassed：第999-1015行
- DailyAfternoonPassed：第1017-1034行
- DailyHighLabelRateAssessed：第1037-1047行
- DailyHighLabelRateShould：第1065-1082行
- 外层JOIN：第1212-1230行