2023 加班申請單流程規範

原始來源與檔名：2023-加班申請單流程規範.md

來源：[公司內部 / HR] — 2024-01-05 原始檔名：電支加班申請2023.pdf

NAPKIN | 餐巾纸

餐巾紙公式

加班時數 = 總經過時間 - 休息時段 (18:00~18:30) 核准 = 初核 (單位主管) -> 複核 (部門主管) -> HR -> 總部簽核

將員工的額外工時透過標準化的表單與多層級的簽核流水線，轉換為符合法規的加班費或換休補償。

一句話

明確規範加班申請的最小刻度為 0.5 小時，並強制扣除法定休息時間，同時規範了從申請到董事長層級的核決權限流程。

餐巾紙草圖

[員工申請]
   | (單位: 0.5h, 扣除休息區間)
   v
[初核: 單位主管]
   |
   v
[複核: 部門主管]
   |
   v
[會簽: 人事/HR] -> [總經理] -> [董事長]

ROUND 1: SKELETON | 骨架掃描

“這本書在說什麼”

核心問題: 如何規範且記錄員工的加班狀況，確保工時合法且補償有據？
核心答案: 實施標準化實體/電子加班申請單，明確時數計算邏輯與簽核路徑。
論證結構: 條列式規範

章節骨架

基本資訊綁定: 申請人、工號與所屬部門。
時數計算邏輯: 0.5 小時單位制與休息時間扣除規則。
補償選擇: 切換選擇加班費或換休。
簽核管線 (Approval Pipeline): 從直屬主管到最高層級的簽核節點。

ROUND 2: DISSECTION | 血肉解剖

“憑什麼這麼說”

隱形假設: 員工在加班期間確實產出對等的工作價值，且各層級主管有能力驗證加班之必要性。
邊界條件: 短於 0.5 小時的瑣粹工時將不被系統承認（Drops off calculation）。

ROUND 3: SOUL | 靈魂提取

“還能怎么用”

知識連結: 就像是分散式系統中的兩階段提交（Two-phase commit），由員工發起，各層主管 Validate 並 Commit 狀態，最後由高層結案。
深層洞見: 強制設定 18:00 到 18:30 等休息時段不予計算，展現了法遵（勞基法）的剛性規則在業務流程上的強硬實作。
行動呼籲: 在開發 HR 系統平台時，時間區段的扣除演算法與簽核鏈的動態組態化會是這張表單數位化時的核心實作重點。

2023 加班申請單流程規範 (Architectural Deep Dive)

前言/背景

在企業級的 HR 系統管理中，「工時」往往是最敏感且與法遵稽核直接相關的資料模型。此文件展示了最原始但具體的加班申請狀態機 (State Machine) 與計算規則 (Calculation Engine)。

章節詳細總結

工時計算引擎 (Time Calculation Logic)

在實作這項業務邏輯時，系統需處理幾個關鍵的邊界與規則限制：

最小精度 (Granularity): 規定「0.5小時為時間單位」。任何小於這個精度的時間都會被 Truncate (無條件捨去/法規範進位)，這在時間軸的 Algorithm 判定上非常重要。

非工作區間扣除 (Exclusion Intervals):

def calculate_overtime(start_time, end_time):
    # Rule: 18:00/19:00 - 18:30/19:30 為休息時間不予計算
    rest_periods = [("18:00", "18:30"), ("19:00", "19:30")]
    # 計算過濾掉 rest_periods 的淨工時
    # 回傳值需 floor_divide 以 0.5小時 為單位

系統必須強硬加入這些中斷區間，避免違反連續工作時數的勞動法規。

補償機制模型 (Compensation Model)

員工在提交 Payload 時，必須在 CompensationType 提供 Boolean 或 Enum 的選擇：

OvertimePay (加班費 V)
CompensatoryLeave (換休 V) 因後續的流程分流：若為換休，則轉發事件至 Leave System (差勤系統) 增加休假額度；若為加班費，則將資料排程拋轉至 Payroll System (計薪系統) 進行月底結算。

簽核工作流管線 (Approval Pipeline)

這是一套經典的線性工作流 (Linear Workflow)：

Applicant (發起者)
Unit_Manager (初核)
Department_Manager (複核)
HR_Signoff (法規檢查與登錄)
General_Manager -> President (高層核決)

(架構決策): 簽核流程拉長到總經理與董事長層級，這在權限管理系統 (RBAC) 來說代表此動作屬於「嚴格管控的高成本行為」，藉由核決權限的上拉，達到在源頭抑制非必要的人事成本暴增。

總結與結論

狀態機與流程控制: 紙本表單數位化的本質即是實作 DAG/State Machine，系統設計需嚴謹控制流轉中的編輯權限 (Immutable Data)。
規則引擎硬核化: 最小時間單位限制以及強制休息時段，提醒了我們在寫內部系統時，必須嚴格按照法規來實作 Rules 引擎，不能任由前端自定義。
資源隔離原則: 加班的結果被明確指派為「時間 (換休)」或「金錢 (加班費)」，這種後端資源的解耦有助於跨系統的介接與運算。