日薪預支對零售、餐飲及連鎖店企業：如何靈活管理班次？

日薪預支對零售、餐飲及連鎖店企業：如何靈活管理班次？

要在零售、餐飲或連鎖店企業中實施日薪預支，企業需要準確確定誰在何時何地工作，班次由誰批准，以及哪些收入符合條件。輪班、分班、換班、多點支援、加班和延遲修正數據必須通過穩定的代碼和明確的狀態進行管理。日薪預支的限額應從已批准的工時工資開始；銷售額、佣金、獎金、小費和櫃檯收入僅在有適當政策和對賬流程時才考慮。

> 注意： 這是一個業務和技術參考框架，不是所有企業的工資計算公式或法律建議。工作時間、班次間休息、加班、津貼、佣金、小費、保留款、限額和結算政策必須由人力資源、薪資、法律、會計和日薪預支供應商根據實際模型確認。

> 術語解釋： 日薪預支（已完成工作的工資）· POS（櫃檯銷售系統）· HRIS（人力資源信息系統）· 薪資（工資計算）· F&B（餐飲服務）· shift/ca（班次）· cutoff（結算點）· pilot（試點）· UAT（用戶驗收測試）· KPI（關鍵績效指標）· tip（小費）。

為什麼零售和餐飲中的日薪預支比單價工時更難？

一個商店可能會使用全職、兼職、臨時工、班次管理和從其他地點調動的員工。每週初的註冊時間表不一定是實際工作時間表。一個人可能會換班、補班、提前下班、在高峰時段支援或在同一天內工作兩段時間。

收入也不僅僅是一個組成部分。根據政策，勞動者可能會有：

• 按月、日或小時計算的工資；

• 夜班、餐飲、職位或商店津貼；

• 已批准的加班費；

• 銷售佣金；

• 銷售、出勤或質量獎金；

• 根據規定分配的小費；

• 期末的調整款項。

如果日薪預支基於預計時間表、粗略的工時記錄或POS銷售收入作為已賺取的收入，限額可能會高於實際。相反，如果工時批准數據延遲，員工已經工作但看不到限額。因此，核心問題不僅僅是快速轉賬，而是創建一個可解釋和對賬的合格收入記錄。

1. 連鎖店的日薪預支數據地圖

企業需要一個中間的標準化層。不應讓日薪預支平台自行從不同文件中連接員工姓名和商店名稱。

2. 設計政策前的勞動者分組

(其他行業：參見多班次製造業的日薪預支和物流、倉儲和配送的日薪預支。)

按班次的全職員工

通常有相對穩定的時間表，但仍會發生換班、加班、休假、支援或跨日工作。如果享受月薪，企業仍需規則來換算已賺取的收入以計算限額。

兼職員工

實際工時可能每天變化。對於這一群體，註冊時間表不足以創建限額；完成並已批准的班次數據更為重要。

臨時員工

在節假日、開業或銷售活動中快速增加。需要控制開始/結束日期、合同類型、支付檔案和參加日薪預支的條件。

有佣金的銷售員工

佣金可能取決於成功的訂單、支付、退換、個人或商店目標。不應將產生的銷售額視為已確定的佣金。

商店和班次管理者

這一群體既有自己的收入，也參與批准他人數據。必須分開創建、修改和批准的權限以避免利益衝突。

每個群體應與一個eligibilitypolicyid和earningpolicyversion相關聯。單一政策通常無法正確反映品牌、地區、工作形式和薪酬方式之間的差異。

3. 班次時間表、實際班次和已批准工時是三個不同的層次

(基礎概念：參見已批准工時是什麼？。)

班次時間表

是計劃：誰預計在哪裡工作，從什麼時間到什麼時間。時間表用於調度，但尚未證明工時已發生。

實際班次

是勞動者打卡進出後的數據，可能附有商店確認。實際班次仍可能有例外，如缺少打卡、錯誤打卡、設備故障或未更新的換班。

已批准工時

是應用規則並由有權人員確認後的結果。這才是適合用於計算已賺取工資的基礎數據。

| 數據層次 | 狀態示例 | 是否應立即用於限額？ |
|---|---|---|
| 班次時間表 | Scheduled | 否 |
| 粗略工時記錄 | Captured | 尚未 |
| 例外 | Exception | 否 |
| 管理者確認 | Manager approved | 可能，視政策而定 |
| 薪資檢查/鎖定 | Payroll eligible/locked | 更高的確定性 |
| 批准後被修改 | Adjusted | 必須重新計算和對賬 |

此原則有助於明確回答員工：“為什麼我有時間表但沒有限額？”或“為什麼應用上的工時與預計不同？”。

4. 最小班次數據模型

每個班次或工段應包括：

• 穩定的employee_id；

• employer_id或支付工資的法人；

• brandid、regionid、store_id；

• assignment_id；

• shiftid和workdate；

• 預計開始/結束時間；

• 實際開始/結束時間；

• 根據政策的休息分鐘數；

• 如果已確定，則為regularminutes、overtimeminutes；

• 班次中的實際角色；

• 例外狀態和原因；

• 批准狀態；

• 批准人和時間；

• record_version和更新時間。

為什麼需要work_date？

從晚上10點到次日早上6點的班次涉及兩個日曆日。系統必須統一班次屬於哪個業務日，尤其是在工資期交接時。如果POS按交易日記錄，工時記錄按開始日記錄，而薪資按結束日記錄，對賬將會出錯。

為什麼需要數據版本？

已批准的班次可能因員工補充打卡或管理者確認調動而被修改。沒有版本，系統難以知道限額是從哪個數據生成的。

5. 正確處理換班

換班通常至少涉及三個主體：讓出班次的人、接收班次的人和管理者。僅在時間表上更改姓名而不保存歷史記錄將給工時記錄、薪資和日薪預支帶來困難。

一個參考的生命周期：

stateDiagram-v2
    [*] --> Scheduled
    Scheduled --> SwapRequested
    SwapRequested --> SwapApproved
    SwapRequested --> Rejected
    SwapApproved --> Worked
    Worked --> AttendanceApproved
    AttendanceApproved --> PayrollEligibleDo Huy LeTổng Giám Đốc
系統需要記錄：
原始班次和最初分配的人；
提議人和接收人；
提議時間；
批准人；
生效時間；
實際工時記錄結果；
取消或更改原因；
前後版本。
日薪預支僅基於實際工作和已批准的工時。原時間表上的人如果班次已合法轉給他人，則不計算收入。
6. 分班、重疊班次和一天內在兩個商店工作
分班
在餐飲業，一個人可能在午餐時間工作，休息幾個小時後再回來晚餐時間工作。系統應記錄兩段工時。如果僅取第一次打卡和最後一次打卡，長時間的休息可能會被錯誤計算為工作時間。
重疊班次
重疊班次可能由於時間表錯誤、換班或手動輸入而出現。限額系統需要在計算收入之前阻止重疊時間。
支援多個商店
一名員工可能在早上在商店A工作，晚上在商店B工作。需要知道：
哪個法人支付工資；
哪個單位承擔成本；
哪個單價/角色適用；
誰批准每段工時；
當天的總工時是否合法；
數據是否進入一個或多個薪資期。
不應僅因為一個人在兩個商店工作而創建兩個獨立的員工檔案。應有一個employee_id和多個有效的分配記錄。
7. 在商店和品牌之間調動員工
調動可以是短期的班次調動或長期的決定。每種情況都需要明確的effectivefrom和effectiveto。
同一法人內的調動
通常影響成本單位、商店工時批准、角色和津貼。
不同法人間的調動
需要明確勞動者使用主體、支付工資主體、共享數據和結算方式。如果實際更改了承擔責任的單位，不應僅更改store_id。
轉換到不同角色
一名服務員可能支援收銀或倉庫。如果單價/津貼取決於角色，系統必須記錄已批准的實際角色，而不是從HRIS中的默認職稱推斷。
8. 在納入日薪預支前分類收入項目
企業應建立“收入項目目錄”，包括項目代碼、公式、合格條件、生效日期、上限、四捨五入方式和批准人。不應使用“其他津貼”等自由名稱，因為難以檢查和對賬。
9. POS銷售收入不是已賺取的工資
POS記錄銷售活動，而不是工資表。一張發票可能：
由多個人共同服務；
在班次管理者賬戶下輸入；
被取消、退款或調整；
屬於商店銷售而非個人；
先發生但後支付；
包括稅、運費或不計算佣金的項目。
如果企業有佣金，需要一個單獨的規則層將交易數據轉換為合格佣金項目。這一層必須處理人員分配、最終狀態、退換、結算時間和政策版本。日薪預支不應直接從POS總銷售額計算佣金。
10. 小費、櫃檯現金和代收款必須分開
小費
小費可能由客戶直接給予、通過POS支付或集中分配。享有權和確定時間取決於企業的規則。只有當小費已確定、分配、批准並屬於日薪預支政策時，才會考慮。
櫃檯現金
收銀員持有的現金是企業的資產/運營資金，不是個人收入的證據。
從配送平台代收款
通過平台的銷售收入、代收現金和合作夥伴結算款是不同的業務流。沒有依據和批准的流程時，不得自動抵消日薪預支交易。
系統設計應至少分開：
storecashcollected；
cashhandoverstatus；
tippoolamount和分配狀態（如有）；
eligibleearningamount；
ewatransactionamount；
payment_status。
11. 限額概念公式
一個參考模型：
$$
\text{合格收入} = \text{已批准的工時} + \text{已合格的津貼} + \text{已結算的變動項目}
$$
$$
\text{可用限額} = \text{合格收入} \times \text{允許比例} - \text{保留款} - \text{已接收/正在處理}
$$
這不是默認應用的公式。各組成部分需根據企業政策確認。限額系統還需檢查：
勞動關係狀態；
當前商店/法人；
工資期和結算日；
每次/每日/每期上限（如有）；
正在處理的交易；
延遲工時調整；
政策版本；
風險鎖定或有理由的手動鎖定。
勞動者應清楚看到限額是由多少已批准的工時和哪些項目未計算而形成的。
12. 分散的工時批准：快速但需控制
大型連鎖通常讓商店管理者或班次管理者批准工時。這是最接近業務的方式，但容易在不同地點之間產生差異。
應有的機制
按日或班次的批准結算；
例外隊列而非無痕跡直接修改；
按商店和有效時間限制權限；
不允許自我批准工時；
大量或延遲調整的二級批准；
未批准商店的儀表板；
所有更改的前後日誌；
異常批量批准警告。
13. 與排班、工時記錄、POS和薪資軟件集成
(數據和架構要求：參見日薪預支與工時記錄、薪資和ERP的集成。)
鎖定標識符
不要通過姓名、電話號碼或顯示的商店名稱連接。需要穩定的代碼：
employee_id；
legalentityid；
brand_id；
store_id；
assignment_id；
shift_id；
payrollperiodid；
earning_code；
transaction_id。
事件順序錯誤
換班請求可能在工時記錄數據之後更新，或者商店設備同步延遲。每個事件應有eventid、源發生時間、系統接收時間和recordversion。如果缺乏版本和業務狀態，不應使用“後到的記錄總是正確”的規則。
14. 按員工–商店–日期–工資期對賬
(詳情：參見日薪預支交易與薪資和會計的對賬。)
整個連鎖的總金額可能一致，但在每個員工層面仍可能錯誤。日薪預支需要對賬到足夠低的層次以找出原因。
六層對賬
HRIS和分配；
班次時間表/工時記錄；
已批准的工時和收入項目；
限額和日薪預支交易；
支付結果；
薪資、ERP和會計。
需要發現的差異
有班次但員工已離職；
工時記錄錯誤商店或超出分配日期；
兩個班次時間重疊；
已批准的換班但工時仍在原人員；
工時在創建限額後被修改；
一個收入項目被重複上傳；
交易成功但缺少薪資；
支付成功但日薪預支仍顯示處理中；
未更新的退款交易；
因跨夜班次而錯誤的工資期；
總金額一致但人員或商店錯誤。
每個差異需要有案例編號、嚴重程度、所有者、處理期限、證據、根本原因和批准關閉的人。
15. 員工已收到款後工時被修改的處理
這是必須在上線前測試的情況。
參考流程：
系統接收新的工時版本；
與已用於創建限額的版本比較；
計算差異部分；
檢查相關交易；
如果未支付，更新限額或停止請求；
如果已支付，根據政策創建處理案例；
如果權益受影響，透明通知勞動者；
保存所有前後數值和處理決定。
不應默默刪除歷史記錄或因數據減少而自動從工資中扣除。處理必須遵循政策、合同和適用規定；需要為勞動者提供反饋/申訴機制。
16. 連鎖店特有的風險和欺詐控制
(完整框架：參見日薪預支中的風險管理和欺詐防控。)
應監控的信號
多名員工從同一異常設備打卡；
當政策使用位置時，打卡距商店過遠；
班次時長超過限額或商店重疊；
管理者在結算前大量調整；
班次在結束後創建和批准；
銷售額或佣金異常增加；
一人既修改工時又批准例外；
更改收款賬戶後立即交易；
多名員工使用同一收款賬戶；
交易數量或頻率急劇增加。
信號僅用於警告或驗證，不自動得出欺詐結論。過於嚴格的控制但缺乏解釋機制可能誤阻合法勞動者。
任務分離
不應讓一人同時擁有修改時間表、修改工時、批准收入項目、更改限額、更新收款賬戶和關閉對賬案例的權限。
17. 保護工時記錄、位置和銷售行為數據
(安全框架：參見實施日薪預支時的數據安全和隱私保護。)
連鎖店的實施可能涉及處理身份數據、工作時間表、位置、設備、POS交易和收款賬戶。企業需要確定：
每個數據字段的目的；
各方處理的依據和角色；
哪些數據實際需要傳給日薪預支；
誰可以查看詳細數據；
保存期限；
權限分配、日誌記錄和加密機制；
數據主體要求的回應流程；
與供應商合同結束時的處理方式；
事故應對流程。
《個人數據保護法》第91/2025/QH15號和第356/2025/NĐ-CP號法令自2026年1月1日起生效。企業應與法律和安全部門審查實際數據流；當目的僅需已批准的工時時，不應將所有發票、客戶購買的商品或詳細位置歷史傳給日薪預支。
18. 商店員工的體驗
用戶需要看到四個問題的簡短答案：
我已經有多少工時/小時被批准？
當前限額是多少？
我已收到多少，交易處於什麼狀態？
如果工時錯誤或未收到款，我應聯繫誰？
應使用一個貫穿始終的工單編號，設置SLA和狀態，以便員工不必向多個部門重述問題。對於分散的勞動力，可以結合應用內指導、商店的QR碼、熱線和管理者聯繫人。
19. 零售和餐飲的試點KPI
數據
具有employeeid、storeid和有效分配的班次比例；
在截止日期前正確批准的工時比例；
在計算限額前更新的換班比例；
重疊班次、缺少打卡或錯誤商店的比例；
批准後的調整數量；
數據的新鮮度；
自動處理比例。
體驗和運營
符合啟動條件的員工比例；
成功交易比例；
收款時間；
流程中放棄比例；
每千筆交易的工單數；
與工時錯誤相關的工單比例；
處理時間和重新開啟比例；
對限額、費用和結算的理解程度。
人力資源和財務
手動預支請求數量；
每用戶/交易的運營成本；
按時間表上班的員工比例；
缺勤和離職按群組；
對賬後的差異值；
已確認的欺詐；
錯誤警告/誤阻比例。
在評估對招聘、缺勤或離職的影響時，需要比較群組/群體並控制季節性、開業、工資、獎金、商店管理和地區。不要將所有變化歸因於日薪預支。
20. 連鎖店的UAT檢查清單
時間表和工時
[ ] 常規班次、夜班和跨日班次。
[ ] 兩段時間的分班。
[ ] 兩個重疊班次。
[ ] 批准和拒絕的換班。
[ ] 接收班次的人有工時，讓出的人不計算。
[ ] 員工在一天內在兩個商店工作。
[ ] 缺少打卡進出。
[ ] 商店設備斷網，延遲同步。
[ ] 在結算前後修改工時。
收入
[ ] 工時工資正確的單價和版本。
[ ] 等待批准的加班不提前計算。
[ ] 根據班次/職位的正確條件津貼。
[ ] 取消/退換的發票不創建錯誤的佣金。
[ ] 小費和櫃檯現金不混入限額。
[ ] 調整項目不重複上傳。
限額和交易
[ ] 僅合格項目被計算。
[ ] 處理中的交易被保留。
[ ] 重複請求不支付兩次。
[ ] 超時創建“未確定”狀態，不自動視為失敗。
[ ] 更改收款賬戶有驗證和控制時間。
[ ] 離職或暫停的員工不創建新交易。
薪資和對賬
[ ] 跨夜班次進入正確的工資期。
[ ] 日薪預支交易進入正確的人員、法人和工資期。
[ ] 文件/API薪資防重複上傳。
[ ] 正確處理的退款交易。
[ ] 可以從薪資追溯到班次和工時版本。
[ ] 總和一致且每個員工的詳細信息也一致。
21. 按商店群組設計試點和擴展
(標準路徑：參見企業的90天日薪預支試點計劃。)
選擇試點地點
應選擇有：
明確的勞動者需求；
合作的商店管理者；
相對乾淨的班次和工時記錄；
沒有太多例外的薪酬規則；
足夠的數量以進行測量但仍能支持；
代表預期擴展模型。
不應僅選擇唯一的“最佳”商店，因為結果可能無法反映連鎖的現實。也不應在系統尚未測試時選擇高峰節日或開業作為首次上線。
從已批准的工時開始
初期階段應使用確定性高的工時工資。佣金、小費、獎金和變動項目在數據源、規則和對賬證明穩定後補充。
按波擴展
將具有相同的商店組合：
品牌/法人；
工時記錄和POS軟件；
班次、薪酬和津貼政策；
管理模型；
薪資流程；
支援能力。
每個波次必須有UAT、培訓、權限分配、儀表板、支援計劃、對賬和回滾條件。不要將開設新賬戶視為成功擴展。
22. 常見錯誤
使用預計時間表而非實際工時
換班、臨時休假和支援其他地點會導致限額錯誤。
使用首尾打卡作為分班
長時間的休息可能被計算為工作時間。
使用POS銷售收入推斷收入
銷售收入不自動是佣金，且可能被取消/退換。
混合櫃檯現金和工資
這是兩個不同的資金流，需要分開系統和對賬。
工時批准延遲但承諾實時限額
日薪預支的速度取決於源數據的速度和質量。
給管理者過多權限
一人既修改工時又批准和關閉差異削弱了控制。
從未測量的手動流程擴展
試點可能依賴項目團隊手動處理，但不能證明系統能承受數百家商店。
常見問題
員工有工作時間表就有日薪預支限額嗎？
不一定。時間表只是計劃。限額應基於已達到企業政策批准狀態的實際班次/工時。
員工換班後誰計算收入？
實際工作並有已批准工時的人。系統必須保存原班次、換班請求、接收人、批准和工時記錄結果以避免雙重計算。
如何計算分班？
應記錄為多段工時並應用休息/防重疊規則。不應將第一次打卡和最後一次打卡視為連續班次。具體公式由薪資政策決定。
POS上的銷售額可以用來計算日薪預支嗎？
不能直接使用。如果企業支付佣金，POS僅是數據源。需要規則層確定有效訂單、享有者、退換、結算狀態和合格佣金項目。
小費可以納入限額嗎？
取決於接收方式、分配規則和企業政策。在未確定和批准前，不應默認所有小費為合格收入。
員工在兩個商店工作需要兩個日薪預支賬戶嗎？
通常應使用一個員工標識和多個有效分配。限額或工資期的分離取決於法人和薪資模型，不應創建重複賬戶。
員工已收到款後工時減少怎麼辦？
系統需要創建案例，確定原因並根據已批准的政策處理。不應在缺乏依據、通知和反饋機制的情況下自動刪除數據或扣款。
應該在銷售高峰期實施日薪預支嗎？
需求可能很高，但數據、臨時人員和支援負載也會增加。應提前測試，並避免選擇高峰期作為首次上線時間，如果流程尚未證明。
小型連鎖店可以用文件試點日薪預支嗎？
可以在小型試點中使用標準文件或受控手動操作。然而，必須有批次碼、防重複、製作–審核、日誌和減少手動操作的計劃，然後再擴展。
結論
對於零售、餐飲和連鎖店的日薪預支不應從連接轉賬按鈕開始。平台應從班次數據開始：正確識別人員、商店、時間、版本和批准狀態。
企業應先從已批准的工時/小時計算的工資開始，將POS銷售收入、小費和櫃檯現金從限額中分離。當試點證明換班、調動、延遲數據、對賬和支援流程穩定後，企業才應補充變動收入項目並按商店群組擴展。了解企業的日薪預支以討論零售、餐飲和多點連鎖企業的日薪預支模型。
來源參考
勞動法第45/2019/QH14號
第145/2020/NĐ-CP號法令，詳細規定勞動法的若干內容
個人數據保護法第91/2025/QH15號
第356/2025/NĐ-CP號法令，指導個人數據保護法
---
作者： Nguyen Minh Tuan — 戰略部專員，Nhan Kiet Manpower Supply Co., Ltd.
企業日薪預支解決方案諮詢： 熱線 0937.022.655 · 電郵 info@nhankiet.vn · 企業的日薪預支