多班次製造企業的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的海報；

• 短片；

• 應用程式/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