上传源代码版本

2026-06-01 16:30:29 +08:00
commit b2a9b7d3c2
462 changed files with 104365 additions and 0 deletions
--- a/.trae/documents/frozen_label_rate_simplified_v7.md
+++ b/.trae/documents/frozen_label_rate_simplified_v7.md
@@ -0,0 +1,222 @@
+# 冻结标签率定义修正 - 不依赖扫描时间 (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%：按低标签率规则（完成即达标）
+```
+