日薪预支在零售、餐饮和连锁店企业中的应用：如何灵活管理班次？

日薪预支在零售、餐饮和连锁店企业中的应用：如何灵活管理班次？

为了在零售、餐饮或连锁店企业中实施日薪预支，企业需要准确识别谁在工作、在哪家店、在什么时间段、班次由谁批准以及哪些收入符合条件。轮班、断班、换班、员工支持多个地点、加班和迟到数据必须通过稳定的代码和明确的状态进行管理。日薪预支的限额应从已批准的工时工资开始；销售额、佣金、奖金、小费和柜台收入只有在有适当的政策和对账流程时才可考虑。

> 注意： 这是一个业务-技术框架供参考，不是所有企业的工资计算公式或法律建议。工作时间、班次间休息、加班、津贴、佣金、小费、保留款项、限额和结算的政策必须由人力资源、工资单、法律、会计和日薪预支供应商根据实际模型确认。

> 术语解释： 日薪预支（根据已完成的工作日领取工资）· 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. 分散的工时审批：快速但需控制
大型连锁通常让店铺经理或班次经理审批工时。这是最接近业务的方式，但容易在各点之间产生差异。
应有的机制
按日或班次后的审批截止；
异常队列而非无痕迹直接修改；
按店铺和有效时间限制权限；
不允许自我审批工时；
对大或迟的调整进行二级审批；
未审批店铺的仪表板；
所有更改的前后日志；
异常批量审批警告。
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和状态，以便员工无需向多个部门重复问题。对于分散的员工队伍，可以结合应用内指导、店铺二维码、热线和管理联系人。
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 · 企业日薪预支