jennisonzhang/LabelChange-server

Fork 0

Files

Im-Jenisson b2a9b7d3c2 上传源代码版本

2026-06-01 16:30:29 +08:00

6.2 KiB

Raw Permalink Blame History

冻结标签率定义修正 - 不依赖扫描时间 (v7.0)

更新日期: 2026-05-16
版本: v7.0 - 标签率定义简化
状态: ✅ 编译通过，逻辑已简化

核心改变

旧定义（v6.0 - 基于扫描时间的比较）

冻结标签率 = (最早扫描时间 > 标签推送时间的包裹数) / 总包裹数

问题：
- 当没有扫描时间时，无法判断
- 逻辑复杂，需要时间比较

新定义（v7.0 - 直接统计有标签包裹）

冻结标签率 = (交接单中有标签的包裹数) / (交接单中总包裹数)

优势：
- 简单直接：只统计是否有标签
- 不依赖扫描时间：标签本身就是可用的
- 符合业务逻辑：标签率反映交接单中标签的整体情况

业务逻辑说明

为什么不需要比较扫描时间？

关键认识：

标签是静态属性：标签一旦被系统记录，就意味着标签可用
扫描时间只是参考：用来判断何时开始作业，但不影响标签的可用性
标签率应该基于交接单整体：而不是基于扫描的时间顺序

场景分析：

场景1：标签推送于09:00，扫描开始于10:00
└─ 无论扫描是否已开始，标签在09:00就已经可用
└─ 这个交接单应该被标记为"高标签率"（如果有足够的标签）

场景2：标签推送于10:30，扫描开始于10:00
└─ 标签在扫描开始后推送
└─ 但标签仍然是可用的，只是稍晚推送
└─ 不应该因为时间顺序就判定为"低标签率"

场景3：标签推送于10:00，但没有扫描记录
└─ 标签在10:00就已经可用
└─ 即使还未开始作业，标签仍然是可用的
└─ 应该根据交接单的总体标签率判断（如果≥80%就是高标签率）

SQL实现

InterchangeUnitLabelRates CTE

新逻辑：

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

优点：

✅ 逻辑简单：只需要判断是否有标签
✅ 计算高效：无需子查询比较时间
✅ 处理边界情况自动化：没有扫描时间时仍然能计算
✅ 符合业务：标签率反映的是交接单的实际标签可用性

场景对比

场景：交接单中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%：按低标签率规则（完成即达标）

6.2 KiB Raw Permalink Blame History Unescape Escape