多班次製造企業的EWA:如何導入才能算準工時?

要在多班次製造企業中導入EWA(已賺工資提前支取),系統需要區分排班與實際出勤;區分正常工時與加班;區分待處理資料與已審核資料;區分週期內交易與薪資結算截止日後的修正。每筆紀錄都必須關聯員工編號、工作日、班次、工廠、審核狀態、更新時間和版本。企業應在資料相對穩定的一家工廠先行試點,先衡量按時審核工時的比例、額度的時效性、交易成功率與薪資核算差異,再行擴展。

> 注意: 本文是業務與技術參考框架。薪資計算公式、計入額度的項目、上限、審核流程以及結算時點,必須由企業、EWA供應商、薪資核算、法務和會計根據實際檔案共同確認。

> 術語說明: EWA(按已做工天數提前領取工資)· payroll(薪資核算)· HRIS(人力資源資訊系統)· ERP(企業資源規劃系統)· cutoff(薪資結算截止)· pilot(試點)· UAT(使用者驗收測試)· KPI(關鍵績效指標)· workflow(工作流程)· wave(擴展批次)· dashboard(儀表板)· go-live(正式上線)。

為什麼工廠環境是獨立的EWA課題?

製造企業通常擁有龐大的勞動力,按多個班次作業,加班隨訂單波動,資料經過考勤機→班組長→主管→人事→薪資→會計→銀行等多個層級。有排班不代表已上滿該班次。有刷卡紀錄不代表已經獲得認可。登記過的加班也未必是已完成並獲得審核的加班。

在這種環境下,最大的挑戰不是顯示「領取工資」按鈕,而是準確回答以下問題:

• 員工是否正在工作且屬於該專案範圍;

• 哪個班次已完成;

• 哪些工時符合計算條件;

• 哪些收入項目已經足夠確定;

• 依政策應保留哪些金額;

• 此前的交易是如何轉帳和結算的。

上述問題只要答錯一個,額度就可能高於或低於實際,導致客訴與期末修正工作量增加。

1. 從排班到EWA交易的資料地圖

```mermaid
flowchart TD
A["排班"] --> B["上下班打卡"]
B --> C["異常處理"]
C --> D["工時與加班審核"]
D --> E["計算符合條件工資"]
E --> F["EWA額度"]
F --> G["交易與付款"]
G --> H["薪資核算、會計與對帳"]
```

每一步都必須有標準資料來源和責任人。在考勤流程尚未確認的情況下,不應讓EWA平台把一次刷卡自行解讀為工資。

2. 區分排班、考勤資料與已審核工時

(核心概念:參見什麼是已審核工時?。)

排班

排班顯示員工預計何時工作。它用於發現遲到、早退、休假、換班或班次重疊,但不能證明該員工確實工作過。

上下班打卡資料

機器記錄的事件資料。可能因忘記打卡、設備故障、網路中斷、打錯機器或員工在慣常位置以外作業而缺失。

已審核工時

套用規則並處理異常之後的業務結果。視政策而定,只有這種狀態才有資格進入額度計算引擎。

為什麼不應含糊地使用「暫計工時」?

如果企業想用暫計資料顯示額度,就必須具備風險緩衝機制、狀態標籤、留存比例以及資料變化時重新計算的方式。員工需要理解可用金額可能因何種原因發生變動。當來源仍在等待審核時,不應顯示一個看似確定的數字。

3. 多班次工廠的最小資料欄位集

員工檔案

班次與工時

薪資核算與交易

• payperiodid;

• 符合條件的收入項目編碼;

• 公式版本;

• 結算截止時點;

• 薪資週期狀態;

• transaction_id;

• idempotency_key;

• 請求金額、手續費與實際轉帳金額;

• EWA與付款狀態;

• payment_reference;

• 交易前/後額度;

• 計算所用資料版本。

4. 夜班應歸屬到哪一天?

午夜前開始、次日結束的班次是常見的錯誤來源。考勤系統按曆日記錄事件,而薪資核算可能將整個班次歸屬到開始日或業務日。

企業需要確定:

1. 夜班的work_date是開始日還是結束日;

2. 工時與夜班津貼如何拆分;

3. 班後加班歸屬到哪一天;

4. 跨班的休息日/例假日如何處理;

5. 標準時區是什麼;

6. 結算截止是否會把一個班次拆成兩個週期;

7. 之後到達的回傳/資料是否重新計算。

範例

某個班次於10日22:00開始,11日06:00結束。如果考勤用11日、薪資用10日,那麼shiftid與workdate不統一時,EWA可能算少或算重。

不應只靠比較月度總時長來解決,因為EWA需要知道在每一個時點哪部分工時已經符合條件。

5. 加班何時計入額度?

加班通常有多個狀態:

1. 已計畫;

2. 員工依流程登記或同意;

3. 實際到班;

4. 主管確認;

5. 人事/薪資審核;

6. 薪資週期鎖定。

企業必須確定哪種狀態符合EWA條件。加班能讓額度更有吸引力,但波動也大於正常工時。

三個參考政策方案

無論哪種方案都必須經薪資核算、人事、法務和風險管理審核。不應讓EWA把所有overtime_minutes都視為已確定金額。

6. 有薪休假、無薪休假與考勤缺失

這些情況對額度的影響各不相同:

• 有薪休假經審核後可按政策計入;

• 無薪休假不產生相應工資;

• 補休可能涉及其他週期資料;

• 缺少上下班打卡需要異常處理;

• 遲到/早退有取整規則;

• 停工或調崗有專門機制;

• 出差/培訓可能不會出現在考勤機上。

企業應建立狀態編碼表,而不是讓每家工廠各自理解。

表中的數值應由企業確認,這裡只是結構範例。

7. 延後工時修正與額度版本管理

在工廠裡,員工完成交易後工時仍可能被修正。系統需要知道:

• 哪筆紀錄發生了變化;

• 修改前後的數值;

• 誰修改、誰審核;

• 計算額度時使用了哪個版本;

• 哪些交易受影響;

• 差額何時處理;

• 是否需要暫停下一次交易。

不應刪除舊紀錄

應建立版本或修正事件。如果直接覆蓋,企業將無法還原交易時點的額度為什麼是該數值。

追蹤欄位範例

```json
{
"employee_id": "EMP-000123",
"work_date": "2026-08-18",
"shift_id": "NIGHT-A",
"approvalstatus": "ADJUSTEDAPPROVED",
"regular_minutes": 480,
"overtime_minutes": 60,
"record_version": 4,
"sourceupdatedat": "2026-08-20T03:20:15Z"
}
```

這是用於說明的虛構資料,並非Lương Ngày的正式規範。

8. 按時審核工時是先行KPI

專案應用再好,如果工時審核滯後也可能失敗。員工看不到額度,就會認為EWA沒有生效。

建議KPI

$$
\text{按時工時審核率} = \frac{\text{截止前完成審核的待審紀錄}}{\text{全部待審紀錄}} \times 100\%
$$

應按以下維度追蹤:

• 工廠;

• 車間;

• 班次;

• 班組長/主管;

• 異常類型;

• 週期內的日期;

• 從班次結束到審核的時間。

目標不是把KPI變成處罰主管的工具。儀表板應指出原因:設備故障、員工名單錯誤、異常過多、審核權限不足或流程不適用。

9. 如何計算額度才能避免難以理解的波動?

概念公式可以表示為:

$$
\text{可用額度} = \text{已審核的符合條件收入} \times \text{允許比例} - \text{留存金額} - \text{週期內已領取金額}
$$

各組成要素必須被定義:

• 哪些收入符合條件;

• 工時處於什麼狀態;

• 允許比例依誰/哪個群體決定;

• 留存金額的用途;

• 處理中的交易是否占用額度;

• 工時修正如何改變額度;

• 額度何時對薪資週期鎖定。

未經核准不應公布詳細公式或風險門檻。員工只需要足以理解顯示金額的說明,無需知曉內部反詐欺邏輯。

10. 與考勤系統和薪資核算整合

(資料需求與架構:參見EWA與考勤、薪資核算、ERP的整合。)

近即時API

適用於系統較新、需要在審核後快速更新的工廠。必須管控驗證、版本、重試、亂序資料到達與錯誤監控。

批次檔案/SFTP

適用於舊系統或依計畫結算的流程。檔案需要批次編碼、總紀錄數、檢查碼、版本、命名規則、防重以及逐列錯誤報告。

受控手動同步

可用於小型試點。需要標準範本、編製/審核人、日誌、總額核對、安全檔案儲存區,以及擴展時消除手動操作的計畫。

不應直接串接所有端點系統

多工廠企業可能有多種考勤機或軟體。標準化整合層可以讓EWA接收同一種資料模型,而不是為每台設備單獨編寫邏輯。

11. 生產環境中的四向對帳

(詳見:EWA交易與薪資核算、會計的對帳。)

對帳應關聯:

1. 工時與額度;

2. EWA交易;

3. 付款結果;

4. 薪資核算/ERP。

常見的需排查差異

• 工時已修正但額度未更新;

• 交易成功但薪資核算缺失;

• 付款成功但EWA仍在處理;

• 交易鍵入錯誤週期;

• 一筆交易出現兩次;

• 離職人員仍有交易;

• 退款未依流程恢復;

• 員工編碼正確但法人/工廠錯誤;

• 總額一致但個別交易多–少互抵。

每項差異都需要案例、負責人、內部期限、證據和關閉審核人。

12. 工廠內的員工支援組織

輪班員工可能在非工作時段遇到問題。支援管道需要貼合實際使用時間。

三層支援

工單必備內容

• 經管控的員工編碼;

• 工廠與班次;

• 問題類型;

• 交易編碼(如有);

• 發生時間;

• 工時/額度狀態;

• 已採取的操作;

• 下一對接人;

• 期限與結果。

支援人員不得要求員工提供密碼或OTP。

13. 現場溝通應簡單但完整

訊息需要說明:

• EWA是什麼;

• 哪些金額可以領取;

• 額度為何變化;

• 手續費(如有);

• 交易如何結算;

• 工時未審核時怎麼辦;

• 更換手機號/收款帳戶時怎麼辦;

• 異常交易舉報管道;

• EWA不取代薪資單核對。

溝通管道

• 入職培訓;

• 班前會;

• 附QR Code的海報;

• 短影音;

• App/SMS;

• 班組長或工廠人事;

• 勞動力需要時提供雙語資料。

不應只培訓班組長就假定所有員工都已理解。需要衡量觸達率、啟用率和重複提問情況。

14. 生產現場的保密與隱私

(完整框架:參見EWA導入中的資料安全與隱私。)

常見風險包括共用手機、更換SIM卡、櫃台協助、他人資料可見的螢幕,以及透過不適當管道傳輸的Excel檔案。

需要具備的管控:

• 啟用和敏感交易時進行身分驗證;

• 禁止共用帳戶;

• 在公共場所顯示時遮罩帳號和金額;

• 不在聊天群拍照/發送薪資單;

• 依工廠和職責分權;

• 記錄支援操作日誌;

• 設備/手機號更換流程;

• 測試資料採用模擬或去識別化;

• 中繼檔案保存期限與刪除;

• 帳戶遺失舉報管道。

《個人資料保護法》第91/2025/QH15號及《政令》第356/2025/NĐ-CP號自2026年1月1日起生效。企業需要結合實際架構審查角色、目的、處理範圍和員工權利。

15. 單工廠EWA試點應如何設計?

(標準路線圖:參見企業90天EWA試點計畫。)

選擇範圍

應選擇一個滿足以下條件的車間或班次小組:

• 需求已確認;

• 資料相對較好;

• 主管願意按時審核工時;

• 薪資流程具有代表性;

• 有充足的現場支援;

• 與下一步擴展對象差異不過大。

至少走完關鍵生命週期

試點必須驗證:

• 啟用;

• 正常工時與加班;

• 夜班;

• 工時修正;

• 成功/失敗/未明確交易;

• 每日對帳;

• 一個完整薪資週期;

• 客訴與異常處理。

試點KPI

• 符合條件者中有效資料占比;

• 按時工時審核率;

• 從工時審核到額度更新的時間;

• 啟用率;

• 交易成功率;

• 到帳時間;

• 每1,000筆交易的工單數;

• 自動對帳率;

• 依原因分類的差異;

• 未明確交易;

• 誤阻擋率;

• 每用戶/每交易營運成本。

目標數值應基於工廠基線和能力,不應照搬其他專案。

16. 生產班次UAT檢查清單

班次與工時

• [ ] 白班滿勤。

• [ ] 跨兩天的夜班。

• [ ] 結算截止日前後的換班。

• [ ] 缺少上班打卡或缺少下班打卡。

• [ ] 遲到、早退與取整規則。

• [ ] 有薪休假與無薪休假。

• [ ] 不經考勤機的出差/培訓。

加班

• [ ] 已計畫但未實施的OT。

• [ ] 已實施但待審核的OT。

• [ ] 已審核的OT。

• [ ] 審核後被修正的OT。

• [ ] 依企業流程產生的例假日OT。

員工

• [ ] 生效日尚未到來的新進員工。

• [ ] 停職者。

• [ ] 週期內離職者。

• [ ] 更換工廠/法人者。

• [ ] 重複或對應錯誤的員工編碼。

交易

• [ ] 額度內的請求。

• [ ] 超過額度的請求。

• [ ] 用同一冪等鍵重複提交。

• [ ] 逾時與未明確結果。

• [ ] 付款失敗。

• [ ] 退款交易。

薪資核算與對帳

• [ ] 交易鍵入正確週期。

• [ ] 重複匯入檔案被阻擋。

• [ ] 延後工時修正產生可追蹤的調整。

• [ ] EWA–付款–薪資核算–ERP一致。

• [ ] 差異建立案例並獲得關閉審核。

17. 從單工廠擴展到多工廠

如果各工廠在班次、設備、薪資核算或法人上存在差異,不應原樣複製設定。

依批次劃分

將具備以下相同條件的工廠分組:

• 相同的考勤系統;

• 相同的班次編碼集;

• 相同的薪資政策;

• 相同的法人;

• 相同的支援能力;

• 相同的工時審核準備程度。

每批上線前的門檻

• 員工與班次對應已驗證;

• 工時/加班規則已簽署核准;

• 完成工廠專屬UAT;

• 主管完成培訓;

• 儀表板與對帳覆蓋新範圍;

• 存取權限已依正確單位開通;

• 上一批次錯誤已處理;

• 復原準備就緒。

依工廠追蹤KPI,以便在擴展時發現效能下降。

18. 常見錯誤

用排班當作實際出勤

在工作證據產生之前就生成額度。

將一切打卡視為有效工時

忽略打卡缺失、班次重疊、他人代打和異常。

計入全部未審核加班

加大額度波動,增加期末修正。

夜班日期不統一

導致工時缺失/重複和週期歸屬錯誤。

只衡量交易不衡量工時審核

發現不了主管環節的瓶頸。

讓HR處理所有工單

HR無法獨自解決付款錯誤、API、對帳或詐欺問題。

在手動作業的試點上直接擴展

結果好看,但不反映規模化營運能力。

覆蓋延後工時修正

喪失還原交易時點額度的能力。

結論

EWA在多班次製造企業中尤其具有潛力,但只有工時被準確且及時地確認時,價值才會顯現。平台需要區分排班–考勤–已審核工時,清楚處理夜班與加班,管理資料版本並對帳到每一筆交易。

企業應從資料相對穩定的一家工廠開始,把按時工時審核率作為先行KPI,在走完一個完整薪資週期後才依批次擴展。歡迎了解企業版Lương Ngày,就工廠考勤資料調查與Lương Ngày試點範圍進行交流。

參考資料

• 《勞動法》第45/2019/QH14號

• 《個人資料保護法》第91/2025/QH15號

• 《政令》第356/2025/NĐ-CP號——《個人資料保護法》施行細則

---

作者: Nguyễn Tấn Lộc — Công ty TNHH Cung Ứng Nhân Lực Nhân Kiệt策略部專家。

企業版Lương Ngày解決方案諮詢: 熱線 0937.022.655 · 信箱 info@nhankiet.vn · 企業版Lương Ngày