等第分配自動平衡

等第分配自動平衡（TryAutoBalanceCounts）

HR 已核定的等第分配人數遇到 TotalCount 異動時，自動將差額吸收到甲等（最大桶），保持 IsConfirmed = true。

觸發情境

當以下任一動作改變部門總人數，等第分配會失衡：

1. 部門主管 toggle（合併/拆分虛擬部門）
2. 人員排除/恢復（ExcludedCandidates 進出）
3. DesignatedReviewer 異動（指派審核主管調整）

平衡邏輯

原本 HR 核定：特優 1 / 優等 2 / 甲等 7 / 乙等 0 / 丙等 0  (總 10 人)

異動後 TotalCount = 12（+2 人）

→ 自動平衡：
  特優 1 / 優等 2 / 甲等 9 / 乙等 0 / 丙等 0  (總 12 人)
            ↑ 差額全部吃到甲等
  IsConfirmed 維持 true

異動後 TotalCount = 8（-2 人）：

→ 自動平衡：
  特優 1 / 優等 2 / 甲等 5 / 乙等 0 / 丙等 0  (總 8 人)
            ↑ 差額從甲等扣掉

為什麼吸收到甲等

等第規則 中甲等比率最高（75%），是「最大桶」。差額吸收到甲等：

• ✅ 保持 IsConfirmed = true（不必重新核定）
• ✅ 不影響特優/優等/乙丙的「重要決策」
• ✅ 符合直覺（多 1 人 = 多 1 個甲等）

失敗 fallback

當差額過大導致甲等變負數無法平衡時：

原本：特優 1 / 優等 2 / 甲等 2 / 乙等 0 / 丙等 0  (總 5 人)
異動後 TotalCount = 1 (突然只剩 1 人)
→ 甲等會變 -2，無法平衡
→ 自動 reset 整個分配，IsConfirmed = false
→ HR 必須重新核定

實作位置

位於 HrController.TryAutoBalanceCounts，4 處呼叫：

1. ApplyTotalCount — 直接設定 TotalCount
2. GenerateGradeDistributionsAsync — 重新生成分配
3. RecalculateGradeDistributionAsync — 主動重算
4. GetGradeDistributionAsync — 讀取時偵測異動並平衡

設計理念

讓 HR 不必為了「+1 個人」就重新核定整套配額——把繁瑣自動化吃掉，但保留高優先等第（特優/優等）的決策權。

相關概念

強連結（原文明確提及）

• 等第規則 — 五等第與比率
• 等第審核流程 — IsConfirmed 在這階段確認
• ProtectionService — 異動需密碼解鎖
• GradingService — ComputeByRate 餘額法配額

← 回到 wiki