退回流程邏輯
任一關退回上一關時，系統執行的 5 個操作。退回必須填寫退回原因。
為什麼存在
PAM 的 考核審核流程 是 6 關鏈式審核，任何一關都可能發現上一關判錯（例如分數不合理、超額未說明、忘記填具體事蹟）。設計上不直接「改」舊紀錄，而是退回——把案件狀態 rewind 一格，並把已寫入的判定結果（FinalGrade、ForceFlag）清掉，回到可以重新評分的乾淨狀態。這條流程的核心是「保留歷史 + 重設當下」：歷史分數不能憑空消失（要可審計），但當下的計分要全部清空才能重來。
5 個操作
CurrentStep--（HR 退回已完成案件時 CurrentStep 不變）- 將
Step >= 退回步驟的舊 ExamRecord 標記為IsReturned = true - 新增一筆
IsReturned = true的退回記錄（含退回原因） - 清除：
FinalGrade、FinalScore、ScoreBeforeAdjust、IsLocked - 清除：
ForceFlag = "Normal"、ForceFlagReason = null
第 2 步是「軟刪除」——舊紀錄留著但標 IsReturned，後續查詢用 validRecords 過濾掉它們即可，不會在 UI 顯示，但稽核時還在。第 3 步是「立碑」——退回原因永久保存，避免「無聲退回」造成的權責不清。
查詢 ExamRecords 的關鍵規則
| 變數 | 過濾條件 |
|---|---|
validRecords | !r.IsReturned && r.Step <= p.CurrentStep |
reviewer2Record | CurrentStep < 2 時必須設為 null |
latestRecord（取 D 分） | 從 validRecords 取 |
| 前一關分數（prevA / prevRecord） | 加 r.Step < p.CurrentStep |
| 歷史紀錄排序 | 依 SubmittedAt（非 Step） |
最後一條是個容易踩的坑：同一關可能多次被退回再重交，Step 都一樣，要靠 SubmittedAt 才能排出真正的時間順序。
退回類型
| 觸發方 | 行為 |
|---|---|
| 一般審核主管 | CurrentStep--，回上一關 |
| HR 退回進行中案件 | 同上 |
| HR 退回已完成案件 | CurrentStep 不變，但解除 lock 重新評分 |
最後一種特殊：案件已走完所有關卡並 lock，HR 才發現問題，這時不能 rewind step（已經沒有「上一關」了），但要打開 lock 讓 reviewer 重新評。
退回原因（必填）
填入新增的 IsReturned = true 記錄。可選用 標語系統 預設原因模板（return tagline）——例如「具體事蹟不足」「分數未配合配額」，避免每次手打。
不填退回原因 → ReviewValidator 直接擋下，回 400。
等第審核退回
特殊：等第審核流程 Confirmed 狀態 HR 點鎖頭按鈕退回時，需 HR 管理員密碼（ProtectionService），週期若已 Locked 會自動解鎖為 Active。這是因為等第審核退回會影響整個部門的分布平衡，比個案退回影響大，所以加了密碼門檻。
跟其他流程的關係
- 觸發點：通常從 GradeReviewService 或 ReviewValidator 過不了關時觸發
- 衍生影響：清掉 異常標記 ForceFlag、清掉 超額說明歷程 中該關的記錄
- 對 等第天花板 不影響——天花板是依員工屬性算的，不會因退回變動
相關概念
強連結（原文明確提及）
- 考核審核流程 — 退回流程從屬於此 6 關鏈
- ReviewValidator — 違反驗證 → 觸發退回
- GradeReviewService — 等第審核時觸發退回的服務
- 超額說明歷程 — 退回時清除
- 異常標記 ForceFlag — 退回時清除
- ProtectionService — 等第審核退回需密碼
- 等第審核流程 — Confirmed 狀態退回
- 標語系統 — return tagline 預設原因
深入閱讀（外部資源）
← 回到 wiki