考勤數據如何對接出糧系統？

對接的實際內容：由打卡紀錄到可付薪的工時

考勤系統輸出的是原始事件：某個員工編號在某個時間於某台機器完成一次驗證。出糧系統需要的卻是另一種東西：某個員工在某個薪酬周期內的正常工時、遲到、加班、假期扣減。兩者之間隔著一整套規則運算，因此對接的難點從來不是把數據搬過去，而是決定規則在哪一端運算、以及運算結果如何被雙方接受。

清楚劃分三個階段有助設計：採集（讀卡或生物特徵驗證產生事件）、計算（按班表及公司政策把事件換算成工時項目）、結算（把工時項目換算成薪酬金額）。多數項目失敗的原因，是把計算階段的責任留在中間無人處理，導致人力資源部門仍要人手核對整份報表。

三種常見對接方式

API 對接常以 REST（Representational State Transfer）風格設計，以資源導向的方式提供查詢與提交。選擇哪一種方式，實務上取決於出糧系統一方的支援程度，因為考勤設備通常較有彈性，而薪酬系統的介面則較固定。

欄位對應：最容易出錯的一層

兩套系統對「同一個員工」的理解往往不同。考勤系統以卡號或生物特徵模板編號識別，出糧系統以員工編號識別，中間需要一張明確的對應表，並決定誰是主資料來源。若兩邊各自維護員工名單，入職、離職及調職就會出現不同步，結果是薪酬計算漏掉新人或仍為離職員工計算工時。

異常處理與審核軌跡

實際運作中，異常紀錄的比例遠高於預期：忘記打卡、重複打卡、驗證失敗後改用其他方式、設備離線期間的紀錄補送。這些情況必須有明確流程，否則每個薪酬周期都要人手追問。設計上應把異常標示出來交由主管審批，而非在計算時靜默套用預設值。

同時要保留審核軌跡。任何人手修改的打卡紀錄都應記錄原值、新值、修改人及時間，並在傳送至出糧系統的資料中保留該標記。這一點在薪酬爭議或勞資糾紛出現時尤其重要，因為《僱傭條例》要求僱主保存僱傭紀錄，而工時紀錄的可追溯性是說明薪酬計算依據的基礎。系統設計時應確認紀錄可按需要匯出並長期保存。

個人資料方面的注意事項

香港企業的實際情況

香港中小企的常見組合是一台門禁兼考勤主機加一套本地薪酬軟件，兩者由不同供應商提供，因此檔案匯出匯入仍然十分普遍。實務上這種做法可行，但應把匯出檔案的命名、周期及核對步驟寫成程序，並保留每期的檔案副本，避免出現用錯月份或重複匯入的情況。

零售及餐飲業的多分店輪班安排是本地最常見的複雜點。同一員工可能在一個月內於數間分店上班，班次跨越午夜，並涉及頂替及調班。這代表打卡紀錄必須帶地點欄位，計算階段亦須以班次而非日曆日界定歸屬，否則夜班會被拆成兩日而影響工時統計。建築及工程業另有派工地點分散的問題，部分場地沒有固定網絡，設備需具備離線暫存及事後補送能力。

另一個本地考慮是門禁與考勤共用同一套讀卡設備。兩者目的不同：門禁關心是否准許通行，考勤關心工時計算，因此同一次刷卡不應自動視為上班紀錄。相關分別可參考本站的門禁與考勤系統的分別。

推行步驟

1. 先寫下計算規則——把上班時間、寬限、加班、跨日班次及假期扣減的規則以文字明確寫出，作為雙方共同依據。
2. 確定運算位置——決定由考勤系統或出糧系統執行規則運算，另一端只接受結果，避免雙重計算。
3. 建立員工對應表——指定主資料來源，訂明入職、離職及調職的同步流程。
4. 統一時間來源——所有考勤設備與伺服器指向同一時間來源，並定期核對。
5. 選定對接方式——按出糧系統的支援程度選擇檔案、資料庫或API方式，並訂明頻率與失敗重試安排。
6. 設計異常審批流程——忘打卡、重複打卡及離線補送的紀錄須標示並交主管審批，保留審核軌跡。
7. 並行試算一個周期——新舊方式同時運行一個薪酬周期並逐項比對差異，確認無誤後才正式切換。

第七步不宜省略。並行試算是唯一能在不影響員工薪酬的情況下驗證規則正確性的方法，發現的差異通常集中在跨日班次與假期扣減兩項。

權威資料依據

本文核對資料：Wikipedia: Time and attendance；Wikipedia: Representational state transfer（REST）；香港法例第57章《僱傭條例》（Employment Ordinance）；勞工處「勞工法例」專頁（Labour Legislation）。

常見問題

相關主題