日薪预支在物流、仓储和配送企业中的应用：如何计算工时、班次和产量？

Doanh nghiệp · 15/09/2026 · 作者: Nguyễn Minh Khang (Chuyên viên ban chiến lược)

日薪预支在物流、仓储和配送企业中的应用：如何计算工时、班次和产量？

为了在物流中实施日薪预支，企业必须明确已批准的工时工资与按行程、订单、产量、津贴和奖励在对账后确定的收入之间的区别。来自考勤、WMS、TMS、司机/配送应用和工资单的数据需要使用统一的员工代码、地点、班次、任务、工资周期和审批状态。企业应从高确定性的收入部分开始，单独处理延迟或取消的数据，并在扩展之前对每笔交易进行对账。

> 注意： 本文是业务-技术框架参考。工资公式、津贴、奖励、罚款/赔偿、计入限额的组成部分及结算方式必须由企业、工资单、法律、会计和日薪预支供应商根据合同和实际政策确认。

> 术语解释： 日薪预支（根据已完成的工时领取工资）· WMS（仓库管理系统）· TMS（运输管理系统）· HRIS（人力资源信息系统）· 工资单（工资计算）· COD（货到付款）· 截止（周期截止点）· 试点（试运行）· UAT（用户验收测试）· KPI（关键绩效指标）· 枢纽（中转中心）· 离线（offline）。

为什么物流中的日薪预支不能仅依赖于“已交付订单数”？

仓库员工可能按班次领取工资，加上产量和夜班津贴。配送员工可能产生行程数、成功订单、退货订单、代收款、线路津贴和调整项。司机可能有调度计划，但行程可能更改、取消或在午夜后完成。

如果日薪预支平台将未确认的运营事件视为已赚取的工资，限额可能会被错误计算。例如：

订单已接收但未成功交付；
行程已创建但被取消；
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 | 变更追踪 |

断班和一天中的多个地点

一个人可能在两个时间段工作或支持两个仓库。系统需要记录每段工时，然后应用防重叠规则。不应仅取最早的签到和最晚的签退，因为中间可能不是工作时间。

夜班

考勤、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/状态通知；
按班次的简短指南；
工作地点的二维码。

工单分配

| 问题 | 联系人 |
|---|---|
| 缺少/错误的工时 | 仓库管理/HR运营 |
| 错误的行程/产量 | 调度/WMS/TMS运营 |
| 看不到限额 | 日薪预支运营/工资单 |
| 挂起的交易 | 日薪预支/支付支持 |
| 工资结算错误 | 工资单 |
| 怀疑账户被占用 | 安全/风险 |

员工只需一个工单编号贯穿始终，无需向每个部门重复描述。

16. 保护位置和行为数据

(安全框架：参见实施日薪预支时的数据安全和隐私保护。)

物流可能使用GPS、线路历史、交货证据和设备。这些数据需要严格管理。

企业需要确定：

哪些位置数据对日薪预支确实必要；
细节和存储时间；
谁有权查看；
是否用于其他目的；
数据如何汇总/遮蔽；
员工反馈时如何处理；
哪些供应商可以访问；
服务结束时如何删除/归还。

《个人数据保护法》第91/2025/QH15号和第356/2025/NĐ-CP号法令自2026年1月1日起生效。处理必须根据角色、目的和实际数据流进行审查；不应仅为预防未定义的风险而将所有定位数据传输到日薪预支。

17. 物流试点的KPI

数据和运营

有效分配的员工比例；
按时批准的工时/产量比例；
数据的新鲜度；
重复/延迟数据比例；
自动处理比例；
自动对账比例；
截止后调整。

体验

激活比例；
成功交易比例；
收款时间；
放弃比例；
每千笔交易的工单；
工单处理时间；
对限额和费用的理解程度。

人力资源和财务

手动预付款请求；
按队列的缺勤和离职；
高峰期出勤比例；
每用户/交易成本；
确认的差异和欺诈金额；
错误拦截比例。

如果未控制高峰期、订单、工资、奖励、线路和管理，不应仅根据前后数据得出日薪预支导致人事变动的结论。

18. 物流行业的UAT检查表

仓库和班次

[ ] 白班、夜班和断班。
[ ] 一人一天支持两个仓库。
[ ] 缺少签到/签退。
[ ] 等待审批和已批准的加班。
[ ] 周期内仓库调动。

行程和订单

[ ] 行程创建、接收、完成和审批。
[ ] 行程取消或重新分配。
[ ] 成功交付后退货的订单。
[ ] 离线数据延迟到达。
[ ] 重复的任务/产量。
[ ] 错误的员工或线路。

限额和交易

[ ] 仅符合条件的项目被计算。
[ ] 政策版本正确的生效日期。
[ ] 重复发送不创建重复交易。
[ ] 超时创建不明确状态。
[ ] 接收账户更改得到验证。

工资单和对账

[ ] 夜班/行程跨夜进入正确周期。
[ ] 工资单导入交易防重。
[ ] 每个来源的差异创建案例。
[ ] 退货交易得到正确处理。
[ ] 可以从工资单追溯到源数据。

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 · 企业的日薪预支

← 新闻