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

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

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

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

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

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

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

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

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

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

• 已批准的加班費；

• 銷售佣金；

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

• 根據規定分配的小費；

• 期末的調整款項。

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

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

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

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

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

按班次的全職員工

通常有相對穩定的排班，但仍會出現換班、加班、休假、支援或跨日工作。如果按月薪計算，企業仍需規則來轉換已賺取的收入以計算限額。

兼職員工

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

臨時員工

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

有佣金的銷售員工

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

店鋪管理和班次管理

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

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

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

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

排班

是計劃：誰預計工作，在哪裡，從幾點到幾點。排班服務於調度，但尚未證明工時已發生。

實際班次

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

已批准工時

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

此原則有助於清楚回答員工：“為什麼我有排班但沒有限額？”或“為什麼應用上的工時與預計不同？”

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. 分散的工時批准：快速但需控制
大型連鎖通常讓店鋪管理或班次管理批准工時。這是最接近業務的方式，但容易在各點之間產生差異。
應有的機制
按日或班次的批准截止；
例外情況隊列而非無痕修改；
按店鋪和有效時間限制權限；
不允許自我批准工時；
大幅或延遲調整的二級批准；
未批准店鋪的儀表板；
所有更改的前後記錄；
異常批量批准警告。
建議的責任矩陣
正式的RACI必須由企業決定；上表僅為設計建議。
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 · 企業的日薪預支