日薪預支於物流、倉儲及配送企業：如何計算工時、班次及產量？
日薪預支於物流、倉儲及配送企業：如何計算工時、班次及產量？
為在物流中實施日薪預支，企業必須明確區分已核准的固定工資與按行程、訂單、產量、津貼及獎金等變動收入。考勤、WMS、TMS、司機/配送應用及薪資數據需使用相同的員工編號、地點、班次、任務、薪資期及核准狀態。企業應從高確定性的收入開始，單獨處理延遲或取消的數據，並在擴展前對每筆交易進行對賬。
> 注意： 本文為業務-技術參考框架。工資公式、津貼、獎金、罰款/賠償、計入限額的組成部分及結算方式須由企業、薪資、法律、會計及日薪預支供應商根據合同及實際政策確認。
> 術語解釋： 日薪預支（已完成工時的工資）· WMS（倉庫管理系統）· TMS（運輸管理系統）· HRIS（人力資源信息系統）· 薪資（工資計算）· COD（貨到付款）· 截止（結算截止點）· 試點（試運行）· UAT（用戶驗收測試）· KPI（關鍵績效指標）· 樞紐（中轉中心）· 離線（脫機）。
為什麼物流中的日薪預支不能僅依賴於“已交付訂單數”？
倉庫員工可能按班次計薪，並加上產量及夜班津貼。配送員可能會有行程數、成功訂單、退貨訂單、代收款、路線津貼及其他調整。司機可能有調度計劃，但行程可能更改、取消或在午夜後完成。
如果日薪預支平台將未確認的運營事件作為已賺取的工資，限額可能會被錯誤計算。例如：
訂單已接收但未成功交付；
行程已創建但被取消；
WMS產量未排除測試交易或重複掃描；
員工在班次間調動倉庫；
路線津貼僅在對賬後確定；
代收款尚未交接；
離線數據同步延遲；
夜班在系統中被計入不同的兩天。
因此，重要原則是：運營事件不自動成為合格收入。需要一層規則和核准狀態將運營數據與薪資連接。
1. 物流企業中的系統地圖
各系統的角色
| 系統 | 數據 | 不應自行推斷 |
|---|---|---|
| HRIS | 身份、勞動狀態、單位 | 有賬戶的人一定在職 |
| 考勤 | 進出事件、班次、例外 | 每次打卡都計入工資 |
| WMS | 倉庫活動、掃描、訂單/產量處理 | 每個任務都計入產量 |
| TMS | 行程、路線、調度、狀態 | 每個新建行程都產生收入 |
| 現場應用 | 接受任務、交付、證據、位置 | 用戶點擊的每個狀態都是最終結果 |
| 薪資 | 期、規則、項目代碼、核准 | 資金已成功轉移 |
| 日薪預支 | 限額、請求、交易 | 源數據不再變動 |
| 支付 | 轉賬結果 | 薪資已正確記錄期/人 |
2. 設計日薪預支前的勞動力分類
(多班次工廠情況：參見多班次生產企業的日薪預支。)
倉庫班次員工
收入可能包括按時間計薪、加班、夜班津貼、職位津貼及按生產力計算的部分。
司機
可能按時間、行程、路線、距離、車型、等待時間、津貼或綜合機制計算。
配送員
收入可能與接單數、成功交付數、退貨數、重量、區域、代收款及質量獎金相關。
臨時/合作工
需準確確定關係、參與條件、有效時間及數據來源。不應將所有工作形式納入同一日薪預支政策。
調度及運營辦公室員工
通常數據較穩定，但需求及收入結構與現場組不同。
每組需一個eligibilitypolicyid及earningpolicyversion，而非全企業通用公式。
3. 區分確定收入與變動收入
| 收入組 | 例子 | 早期確定性 | 日薪預支考量 |
|---|---|---|---|
| 已核准的時間工資 | 完成並核准的倉庫班次 | 較高 | 可作為初始基礎 |
| 已核准的加班 | 完成的加班，經管理確認 | 相對高 | 視政策而定 |
| 已對賬的完成行程 | 有充分證據且未取消的行程 | 視流程而定 | 僅在合格狀態後 |
| 成功交付訂單 | 到達最終狀態且質量合格的訂單 | 可能因退貨/調整而變動 | 需保留或等待結算規則 |
| 路線/夜班津貼 | 取決於路線、時間段、核准 | 視數據而定 | 僅在有明確依據時計算 |
| 生產力/出勤獎金 | 通常在期末確定 | 期中較低 | 未確定時不應提前計算 |
| 補償/調整項目 | 取決於驗證及流程 | 未確定 | 不自動扣除或推測 |
企業應從最穩定的收入開始試點。數據及對賬良好後，再考慮增加變動成分。
4. 最小化員工數據及分配
勞動者檔案
employee_id;employerid或legalentity_id;employment_status及生效日期;payroll_group;role_type：倉庫、司機、配送、調度等;ewa_eligibility;版本及更新時間。
分配
assignment_id;siteid或hubid;warehouse_id;route_group若政策使用;shift_id;vehicle_id若業務需要;effectivefrom，effectiveto;分配狀態;
核准來源。
最小化原則
不要僅因可用而將所有運營、位置或車輛數據轉移到日薪預支平台。每個字段必須服務於已確定的限額計算、驗證、風險或對賬。
5. 倉庫班次及按時間計算的工資數據
(基礎概念：參見已核准工資是什麼？。)
常需字段：
| 字段 | 目的 |
|---|---|
| work_date | 業務日期 |
| shift_id | 班次編號 |
| shiftstart，shiftend | 帶時區的時間 |
| checkin，checkout | 出勤事件 |
| regular_minutes | 已確定的正常工時 |
| overtime_minutes | 按狀態的加班工時 |
| break_minutes | 按規則的休息時間 |
| attendance_status | 全勤、缺勤、缺席等 |
| approval_status | 等待、核准、拒絕、調整、鎖定 |
| record_version | 變更追蹤 |
斷班及一天多點
一人可能在兩個時段工作或支援兩個倉庫。系統需記錄每段工時，然後應用防重規則。不應僅取最早的check-in及最晚的check-out，因為中間可能不是工作時間。
夜班
考勤、WMS及薪資必須統一work_date。若一系統用開始日期，另一系統用結束日期，工時及產量可能跨期。
6. 行程及配送數據需要哪些狀態？
一個參考生命周期：
實際狀態名稱可能不同。關鍵是確定哪個點對薪資/日薪預支合格。
示例數據字段
taskid或tripid;employee_id;assignment_id;siteid/routeid;接受、開始、完成時間；
任務類型；
合格產量；
業務狀態；
核准狀態；
取消/退貨/調整原因；
核准人及時間；
數據版本。
若無必要，不應將最終客戶地址或詳細位置數據轉移到日薪預支。
7. 成功交付的訂單是否為已賺取的工資？
不能僅從“已交付”狀態得出結論。企業必須檢查：
狀態是否為最終或仍可能退貨/取消；
交付證據是否有效；
訂單是否屬於正確員工；
產量計算是按訂單、件數、重量還是路線；
是否有質量或COD對賬條件；
收入按何行為支付；
數據是否因轉線或重新分配而重複；
薪資在哪個狀態結算。
日薪預支僅應使用已被業務部門及薪資核准為合格的狀態。
8. 處理退貨訂單、取消行程及延遲數據
不刪除已發生事件
退貨訂單或取消行程應有新狀態，不刪除原記錄。系統需知道哪些日薪預支交易已使用先前數據。
處理流程
接收變更事件及新版本；
檢查是否為延遲數據；
確定受影響的收入部分；
重新計算可用限額；
若已有交易，創建差異案例；
按已核准政策處理；
若勞動者權益受影響，透明通知；
保存前/後值及核准人。
不自動將每個退貨訂單視為勞動者錯誤或自動創建扣款。責任確定須依據適當流程及依據。
9. 代收款（COD）不是工資
在配送中，勞動者可能持有或交接代收款。這是與工資不同的業務資金流。
數據設計需分離：
cod_collected;cod_remitted;codreconciliationstatus;合格收入；
日薪預支交易；
支付給勞動者的金額。
未經核准及流程，不得將持有的COD金額作為勞動者“有收入”的證據或自動與日薪預支抵扣。
10. 離線數據及事件順序錯誤
司機或現場員工可能在網絡不佳的地方工作。應用同步後，完成事件可能比調整或取消事件更晚到達。
每個事件應有：
唯一的
event_id；源發生時間；
系統接收時間；
版本號或序列；
源/設備；
簽名/驗證狀態（若適用）；
與
taskid/tripid的關聯。
若缺少版本，系統不應應用“最後到達的記錄總是正確”的原則。需有解決衝突及異常隊列的規則。
11. 計算組合收入的限額
一個概念模型：
合格收入 = 已核准的時間工資 + 已結算的產量 + 合格津貼
可用限額 = 合格收入 x 允許比例 - 保留項目 - 已接收/處理中
每個成分需要：
項目代碼；
合格狀態；
計算公式；
單位；
四捨五入規則；
上限；
生效日期；
核准人；
版本。
不應將預期產量或期末獎金計入限額，除非有控制變動的機制。
12. 集成WMS、TMS及薪資
(數據及架構要求：參見日薪預支與考勤、薪資及ERP的集成。)
不按顯示名稱連接
員工姓名、倉庫名、路線名及班次名可能更改或重複。需穩定的代碼及映射表。
數據標準化層
集成層應將不同系統轉換為通用模型：
人員；
分配；
班次/工時；
任務/產量；
核准狀態；
薪資期；
收入項目；
交易及支付。
API還是批量文件？
| 方法 | 適用 | 控制點 |
|---|---|---|
| 近實時API | 任務及工時數據持續更新 | 驗證、版本、冪等性、重試 |
| 批量文件/SFTP | 按計劃結算產量/工時 | 批次碼、校驗和、防重、部分錯誤文件 |
| 受控手動 | 小型試點或舊系統 | 標準模板、創建/核准人、日誌、對賬 |
僅當手動工作量被測量並有減少計劃時才適合擴展。
13. 六維對賬
(詳情：參見日薪預支交易與薪資及會計對賬。)
根據模型，物流企業可能需對賬：
考勤/班次計劃；
WMS/TMS或現場應用；
已核准的收入項目數據；
日薪預支交易；
支付結果；
薪資/ERP/會計。
需發現的差異
有工時但缺少分配；
有任務但錯人或錯倉；
行程被取消但收入未調整；
產量被重複記錄；
日薪預支成功但薪資缺失；
支付成功但日薪預支未更新；
因夜班/行程跨夜而錯期；
錯誤版本的津貼；
未處理的退貨交易；
總金額匹配但每員工錯誤。
每個差異需有案例、負責人、證據及核准關閉。
14. 特殊風險及欺詐管理
(完整框架：參見日薪預支中的風險管理及欺詐防範。)
數據信號
同一任務分配給多人；
在不合理時間內完成多個任務；
產量激增；
從異常位置/設備完成；
截止前大量調整；
同一人創建及核准例外；
更改接收賬戶後立即交易；
多名員工將錢轉入同一賬戶。
一個信號不足以得出欺詐結論。需結合、驗證及有申訴機制以保護合法勞動者。
任務分離
不允許一人同時：
修改產量；
核准收入項目；
更改限額；
處理交易；
關閉差異。
15. 支援多地點分散的勞動者
合適渠道
應用中的FAQ；
熱線/工單；
倉庫/樞紐聯絡人；
SMS/狀態通知；
按班次的簡短指導；
工作點的QR碼。
工單分流
| 問題 | 聯絡人 |
|---|---|
| 缺少/錯誤班次工時 | 倉庫管理/HR Operations |
| 錯誤行程/產量 | 調度/WMS/TMS Operations |
| 看不到限額 | 日薪預支Operations/薪資 |
| 交易掛起 | 日薪預支/支付支持 |
| 薪資結算錯誤 | 薪資 |
| 懷疑賬戶被盜 | 安全/風險 |
勞動者只需一個貫穿的工單號，不必向每個部門重述。
16. 保護位置及行為數據
(安全框架：參見實施日薪預支時的數據安全及隱私保護。)
物流可能使用GPS、路線歷史、交付證據及設備。這些數據需嚴格管理。
企業需確定：
哪些位置數據對日薪預支真正需要；
詳細程度及保存時間；
誰有權查看；
是否用於其他目的；
數據如何匯總/遮蔽；
勞動者反饋時如何處理；
哪些供應商可訪問；
終止服務時如何刪除/歸還。
《個人數據保護法》第91/2025/QH15號及第356/2025/NĐ-CP號法令自2026年1月1日起生效。處理須根據實際角色、目的及數據流審查；不應僅為防範未定義風險而將所有定位數據傳輸至日薪預支。
17. 物流試點的KPI
數據及運營
有效分配的員工比例；
按時核准的工時/產量比例；
數據新鮮度；
重複/延遲數據比例；
自動處理比例；
自動對賬比例；
截止後調整。
體驗
啟動比例；
成功交易比例；
收款時間；
放棄比例；
每千筆交易的工單；
工單處理時間；
對限額及費用的理解程度。
人力及財務
手動預支要求；
缺勤及辭職按群組；
高峰期出勤比例；
每用戶/交易成本；
確認的差異及欺詐價值；
誤阻比例。
若未控制高峰期、訂單、工資、獎金、路線及管理，不能僅從前後數據得出日薪預支改變人力的結論。
18. 物流行業的UAT清單
倉庫及班次
[ ] 日班、夜班及斷班。
[ ] 一人一天支援兩倉。
[ ] 缺少check-in/check-out。
[ ] 等待核准及已核准的加班。
[ ] 期中倉庫調動。
行程及訂單
[ ] 行程創建、接受、完成及核准。
[ ] 行程取消或重新分配。
[ ] 成功交付後退貨的訂單。
[ ] 延遲到達的離線數據。
[ ] 重複的任務/產量。
[ ] 錯誤的員工或路線。
限額及交易
[ ] 僅合格項目計算。
[ ] 正確生效日期的政策版本。
[ ] 重複提交不創建重複交易。
[ ] 超時創建不明狀態。
[ ] 接收賬戶變更經驗證。
薪資及對賬
[ ] 夜班/行程跨夜進入正確期。
[ ] 薪資導入交易防重。
[ ] 每個來源的差異創建案例。
[ ] 正確處理退貨交易。
[ ] 可從薪資追溯到源數據。
19. 試點及擴展設計
(標準路徑：參見企業的90天日薪預支試點計劃。)
選擇首個範圍
應選擇一個有以下特徵的倉庫/樞紐或配送組：
真實需求；
數據相對穩定；
明確的收入規則；
管理願意核准；
足夠支持；
代表擴展地點的流程。
從穩定收入開始
初期可僅使用已核准的時間工資。產量、行程及津貼在狀態及對賬證明足夠可靠後補充。
按波次擴展
組合使用相同WMS/TMS、薪資、政策及收入模型的地點。每波次需UAT、權限、培訓、儀表板、對賬及回滾。
20. 常見錯誤
用發生訂單數代替合格訂單數
訂單可能被取消、退貨或重新分配。
混合COD與收入
兩種資金流本質及流程不同。
僅用數據到達時間
離線事件可能順序錯誤；需源時間及版本。
計算所有變動項目
未結算的獎金、津貼或產量使限額大幅波動。
無分配代碼
調動倉庫/路線的人易被錯記工時或重複。
試點團隊手動處理時擴展
結果不反映擴展能力。
常見問題
成功交付的訂單能否立即用於計算日薪預支？
只有在該狀態已被業務及薪資核准為合格，並有防重、退貨/重新分配處理及可對賬時。
COD能否計入日薪預支限額？
不應將COD視為工資。這是需單獨管理及對賬的代收資金流。所有相關機制必須有依據及核准流程。
GPS數據是否必需於實施日薪預支？
不是必然。僅使用為已確定目的所需的數據。在許多模型中，任務狀態及已核准工資可能已足夠，無需將詳細位置傳輸至日薪預支。
行程在創建限額後被取消應如何處理？
系統需接收新版本，重新計算影響並創建案例（若已有交易）。不刪除舊數據或自動將責任歸於勞動者。
斷班如何計算工時？
應記錄每段工作並應用防重規則，而非將最早-最晚時間作為連續班次。具體計算依薪資政策。
能否僅用考勤數據試點？
若初期目標僅計算已核准的時間工資，則可行。行程/產量項目需在狀態及對賬足夠可靠後補充。
日薪預支適合物流高峰期嗎？
可能創造價值，但高峰期也增加負載、臨時工及異常數據。應先測試，制定容量計劃、支持，不選高峰期作首次上線，若系統未被證明。
結論
物流中的日薪預支只有在企業區分運營數據與已合格收入時才可靠。考勤、WMS、TMS及現場應用需按人員、分配、班次、任務、薪資期及數據版本標準化。
企業應從已核准的時間工資開始，分離COD，明確處理退貨訂單/取消行程及對每筆交易進行對賬。在試點證明數據及運營穩定後，才補充變動收入並按倉庫/樞紐逐步擴展。了解企業的日薪預支以探討物流、倉儲及配送力量的日薪預支模型。
參考來源
---
作者： Ho Tan Dat — 戰略副總經理助理，Nhan Kiet Manpower Supply Co., Ltd.
企業日薪預支解決方案諮詢： 熱線 0937.022.655 · 電郵 info@nhankiet.vn · 企業的日薪預支