日薪預支於物流、倉儲及配送企業：如何計算工時、班次及產量？
日薪預支於物流、倉儲及配送企業：如何計算工時、班次及產量？
為在物流中實施日薪預支，企業必須明確已批准的工時薪資與按行程、訂單、產量、津貼及獎金等收入的區分，這些收入僅在對賬後確定。考勤、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 · 企業日薪預支