223 lines
6.2 KiB
Markdown
223 lines
6.2 KiB
Markdown
# 冻结标签率定义修正 - 不依赖扫描时间 (v7.0)
|
||
|
||
**更新日期**: 2026-05-16
|
||
**版本**: v7.0 - 标签率定义简化
|
||
**状态**: ✅ 编译通过，逻辑已简化
|
||
|
||
---
|
||
|
||
## 核心改变
|
||
|
||
### 旧定义（v6.0 - 基于扫描时间的比较）
|
||
|
||
```
|
||
冻结标签率 = (最早扫描时间 > 标签推送时间的包裹数) / 总包裹数
|
||
|
||
问题：
|
||
- 当没有扫描时间时，无法判断
|
||
- 逻辑复杂，需要时间比较
|
||
```
|
||
|
||
### 新定义（v7.0 - 直接统计有标签包裹）
|
||
|
||
```
|
||
冻结标签率 = (交接单中有标签的包裹数) / (交接单中总包裹数)
|
||
|
||
优势：
|
||
- 简单直接：只统计是否有标签
|
||
- 不依赖扫描时间：标签本身就是可用的
|
||
- 符合业务逻辑：标签率反映交接单中标签的整体情况
|
||
```
|
||
|
||
---
|
||
|
||
## 业务逻辑说明
|
||
|
||
### 为什么不需要比较扫描时间？
|
||
|
||
**关键认识**：
|
||
1. **标签是静态属性**：标签一旦被系统记录，就意味着标签可用
|
||
2. **扫描时间只是参考**：用来判断何时开始作业，但不影响标签的可用性
|
||
3. **标签率应该基于交接单整体**：而不是基于扫描的时间顺序
|
||
|
||
**场景分析**：
|
||
```
|
||
场景1：标签推送于09:00，扫描开始于10:00
|
||
└─ 无论扫描是否已开始，标签在09:00就已经可用
|
||
└─ 这个交接单应该被标记为"高标签率"（如果有足够的标签）
|
||
|
||
场景2：标签推送于10:30，扫描开始于10:00
|
||
└─ 标签在扫描开始后推送
|
||
└─ 但标签仍然是可用的，只是稍晚推送
|
||
└─ 不应该因为时间顺序就判定为"低标签率"
|
||
|
||
场景3：标签推送于10:00，但没有扫描记录
|
||
└─ 标签在10:00就已经可用
|
||
└─ 即使还未开始作业，标签仍然是可用的
|
||
└─ 应该根据交接单的总体标签率判断（如果≥80%就是高标签率）
|
||
```
|
||
|
||
---
|
||
|
||
## SQL实现
|
||
|
||
### InterchangeUnitLabelRates CTE
|
||
|
||
**新逻辑**：
|
||
```sql
|
||
labeled_requests = COUNT(DISTINCT CASE
|
||
WHEN l.Label IS NOT NULL AND l.Label != ''
|
||
THEN l.Id
|
||
END)
|
||
|
||
label_rate_percent = labeled_requests * 100.0 / total_requests
|
||
```
|
||
|
||
**优点**：
|
||
1. ✅ 逻辑简单：只需要判断是否有标签
|
||
2. ✅ 计算高效：无需子查询比较时间
|
||
3. ✅ 处理边界情况自动化：没有扫描时间时仍然能计算
|
||
4. ✅ 符合业务：标签率反映的是交接单的实际标签可用性
|
||
|
||
---
|
||
|
||
## 场景对比
|
||
|
||
### 场景：交接单中100个包裹，80个有标签
|
||
|
||
```
|
||
交接单标签率 = 80 / 100 = 80%
|
||
|
||
情况1：所有包裹都已扫描，且标签推送时间 < 扫描时间
|
||
├─ v6.0（基于时间比较）：冻结标签率 = 80%（高标签率）✓
|
||
├─ v7.0（直接统计）：冻结标签率 = 80%（高标签率）✓
|
||
└─ 结果一致 ✓
|
||
|
||
情况2：30个包裹未扫描，70个包裹已扫描
|
||
├─ v6.0（基于时间比较）：
|
||
│ └─ 未扫描的包裹无法比较 → 不计入分子
|
||
│ └─ 冻结标签率可能 < 80%（低标签率）✗ 不合理
|
||
├─ v7.0（直接统计）：
|
||
│ └─ 30个未扫描的包裹仍有标签 → 计入分子
|
||
│ └─ 冻结标签率 = 80%（高标签率）✓ 正确
|
||
└─ v7.0 更合理
|
||
|
||
情况3：部分标签推送时间晚于扫描时间
|
||
├─ v6.0（基于时间比较）：
|
||
│ └─ 这部分标签不计入分子 → 冻结标签率偏低 ✗ 误导
|
||
├─ v7.0（直接统计）：
|
||
│ └─ 所有标签都计入分子 → 冻结标签率 = 80%（高标签率）✓ 正确
|
||
└─ v7.0 更准确
|
||
```
|
||
|
||
---
|
||
|
||
## 考核规则应用（不变）
|
||
|
||
冻结标签率一旦确定，后续的考核规则保持不变：
|
||
|
||
```
|
||
IF 冻结标签率 >= 80% THEN
|
||
├─ 16点前到仓：考核时间 = 当日16:00 ~ 次日16:00
|
||
└─ 16点后到仓：考核时间 = 当日16:00 ~ 次日23:59:59
|
||
ELSE
|
||
└─ 完成即达标（考核时间 = NULL）
|
||
END IF
|
||
```
|
||
|
||
---
|
||
|
||
## 完整的数据流示例
|
||
|
||
### 100个订单、80个有标签的交接单
|
||
|
||
```
|
||
交接单统计：
|
||
├─ 总订单数：100
|
||
├─ 有标签的订单：80
|
||
└─ 冻结标签率 = 80 / 100 = 80%（高标签率）
|
||
|
||
子情况1：所有订单都未扫描
|
||
├─ 扫描状态：无扫描记录
|
||
├─ v7.0处理：仍然按冻结标签率80%处理
|
||
├─ 考核规则：按高标签率规则（16点分段）
|
||
└─ 说明：标签是可用的，即使未开始作业也按这个标签率处理
|
||
|
||
子情况2：部分订单未扫描
|
||
├─ 扫描状态：混合
|
||
├─ v7.0处理：仍然按冻结标签率80%处理
|
||
├─ 考核规则：按高标签率规则（16点分段）
|
||
└─ 说明：标签的可用性不依赖于扫描时间
|
||
|
||
子情况3：部分标签推送晚于扫描
|
||
├─ 时间关系：标签推送时间 > 扫描时间
|
||
├─ v7.0处理：仍然按冻结标签率80%处理
|
||
├─ 考核规则：按高标签率规则（16点分段）
|
||
└─ 说明：标签无论何时推送，都是可用的
|
||
```
|
||
|
||
---
|
||
|
||
## 与之前版本的对比
|
||
|
||
| 版本 | 计算方式 | 依赖条件 | 复杂度 | 正确性 |
|
||
|------|--------|--------|--------|--------|
|
||
| v6.0 | 最早扫描时间 > 标签推送时间 | 需要扫描时间 | 高 | 有边界问题 |
|
||
| v7.0 | 有标签的包裹数 / 总包裹数 | 只需标签属性 | 低 | ✅ 正确 |
|
||
|
||
---
|
||
|
||
## 简化的好处
|
||
|
||
### 1. 业务逻辑更清晰
|
||
|
||
**冻结标签率 = 标签可用性 = 交接单中有标签的比例**
|
||
|
||
### 2. 不依赖扫描数据
|
||
|
||
- 即使没有扫描记录，也能正确判断标签率
|
||
- 避免了复杂的时间比较逻辑
|
||
|
||
### 3. 计算更高效
|
||
|
||
- 减少了子查询和时间比较
|
||
- SQL逻辑更简单，执行更快
|
||
|
||
### 4. 边界情况自动处理
|
||
|
||
- 未扫描的包裹：自动按有/无标签计算
|
||
- 标签推送时间晚：仍然计入高标签率
|
||
- 无需特殊处理逻辑
|
||
|
||
---
|
||
|
||
## 编译状态
|
||
|
||
✅ **编译成功** (exit code 0)
|
||
- InterchangeUnitLabelRates CTE 已简化
|
||
- 逻辑更清晰
|
||
- 无编译错误
|
||
|
||
---
|
||
|
||
## 核心总结
|
||
|
||
**标签率的定义**：
|
||
```
|
||
冻结标签率 = 交接单中有标签的包裹比例
|
||
|
||
这个比例反映的是：
|
||
- 该交接单中标签的整体可用情况
|
||
- 与扫描时间无关
|
||
- 与推送时间先后无关
|
||
- 只要标签被记录就是可用的
|
||
```
|
||
|
||
**应用方式**：
|
||
```
|
||
根据冻结标签率的大小，判断整个交接单的所有包裹应该按什么规则处理：
|
||
- >= 80%：按高标签率规则（16点分段）
|
||
- < 80%：按低标签率规则（完成即达标）
|
||
```
|
||
|