考勤与排班：从打卡记录到工时台账

排班靠 Excel、打卡靠机器、月底工时靠人拼，是很多企业的常态。本文按业务语言拆解考勤与排班模块怎么落地：班次与班表怎么建、打卡与异常怎么留痕、请假加班怎么与班表联动、月度工时汇总怎么生成，以及移动端与上线前要确认的几件事。

先看三个现场现象

排班和考勤这两件事，几乎每家公司都在做，但做得很不一样：

排班表在主管的 Excel 里。 谁上早班、谁上晚班、谁周末轮休，只有那个文件知道。主管休假一周，整条线就得打电话问排班；换过一次班，文件里没人改，之后就再也说不清。
打卡记录是一堆原始事实，没人加工。 打卡设备能导出记录，但导出来的东西只是「几点几分刷了一下」，既不知道那天该上什么班，也不知道这个人该不该出现在这个门口。
月底工时靠人拼。 HR 把打卡表、请假单、加班审批、临时调班记录四处捞出来对照，拼出一张工时报给财务。拼错了没人发现，拼对了也没有留底——明年要复核，只能重拼一遍。

这三个现象指向同一件事：班表（该干什么）和打卡（实际干了什么）没有放在一个能对账的地方。本文要讲的模块方案，就是把这两条线并成一条：先有班表，打卡往上落，差异有人处理，月底工时是按记录汇总出来的，不是重新拼出来的。

这里不讨论「怎么把人管得更严」，只讲一件事怎么落地：让每天的出勤事实有据可查，让每月的工时能当场复算。

第一步：把班次、班表、人员建成基础数据

考勤模块的底子是三组基础数据，在 Inkwell 构建器里就是几张可维护的数据表。

班次。 一行一个班次：班次名称（早班/中班/夜班/常白班）、上班时间、下班时间、是否跨天、休息时长、计工时的小时数、迟到早退的容差分钟数。跨天班（比如 22:00 到次日 6:00）一定要在一开始就支持，否则夜班永远算不对——这是这类模块最常见的返工点。

人员与部门。 不要单独再造一份员工名单。人员归属引用平台已有的组织架构（部门树与成员关系，见部门与租户），考勤记录上只保留当时必要的身份快照（工号、姓名）。这样人员调动、离职之后再查历史记录，看到的仍然是当时那个人的信息。

班表。 一行 = 「某个人、某一天、某个班次」，加上状态（正常/调班/休息/请假）与备注。这张表是排班和考勤之间的桥，也是后面所有差异判断的依据。做法上有两点建议：

班次和假期类型、异常状态都用数据字典统一维护（下拉选项集中管理的地方，改一处全站生效，见数据字典）。以后加一个「外勤」或者「哺乳假」，改的是字典，不用动表结构。
班表要支持按班组批量生成和一键复制（比如「上周套用到本周」「按班组套用模板」），否则排一次班要点几百下，主管不会用。

基础数据不必一次建全。先把两三个真实在用的班次建起来，再按部门把人挂上去，班表从下一个排班周期开始记。## 第二步：打卡与异常，先把事实固定下来

考勤的第一原则是先有事实，再谈判断。打卡记录承担事实层：一行 = 「员工 + 日期」，记上班时间、下班时间、打卡方式（手机打卡/管理员补录）、当日班次、判定状态和备注。

判定这件事不要写死在程序里，而是做成一条能解释的规则：

拿「当天班表上的班次」对比「实际打卡时间」，超出容差就标迟到/早退；
该有班次却没有打卡记录，标缺卡；
判定结果放在状态字段里，走数据字典统一管理，方便筛选和统计。

异常必须有出口，不能只有标记。 缺卡、迟到、外出办事这些情况，现实里天天发生，所以每一条异常都要能提一张申请：员工在手机上提交「补卡/异常说明」，主管审批通过后回写当天的记录状态，谁批的、什么时候批的、写的什么意见，全部留在单据上。这条链如果用审批流来做（工作流与定时任务），以后调整审批层级不用重做页面。

请假和加班要能改到班表上。 请假单通过之后，如果只写在请假表里、班表上看不出这个人当天不在，那班表就变成了假的。所以请假与加班走的是同一套审批，通过后要把结果落回当天的班表状态（请假/加班），这样月底统计「应出勤」时，取的是调整后的班表，而不是原始排班。

提醒交给定时任务。 三件事最适合自动化：每天固定时间给当天未打卡的人发一条提醒；每周五提醒主管确认下周班表；每月初提醒 HR 处理上月未闭环的异常单据。这些都由后台的定时任务按 Cron 配置执行（同一篇文档里有配置方法），不需要人盯日历。

第三步：页面怎么摆，不同的人各看什么

同一个数据库，页面怎么摆决定了系统会不会真被用起来。建议按「角色 + 当天要做的动作」组织，而不是按表来摆：

主管排班页：周视图为主，横轴是日期、纵轴是班组里的人，点格子下班次；顶部两个按钮「复制上周」「套用模板」。主管每周只来这一次，所以这个页面要能在十分钟内排完一周。
HR 考勤核对页：以「待处理」为入口——今日缺卡、待批补卡、迟到早退、请假待确认，按数量排序。HR 上班先看这个页面，而不是先翻菜单。
异常明细页：按部门、人员、日期区间、状态组合筛选，每条记录能直接看到当天应该上什么班、实际打了几点、处理结果是什么。这页是日后有争议时的唯一依据，所以不许物理删除，只许作废并留原因。
员工我的班表页：本人本周排班、剩余假期额度、本月已出勤小时数。让员工自己看得到，比 HR 逐个回复「我这周上什么班」省事得多。
规则维护页：班次、容差、工时口径集中维护，谁在什么时候改过能查到。这条要靠平台的审计留痕能力，不是靠页面上的说明文字。

权限上建议三层：员工只看本人；主管看本班组；HR 看全公司并可导出。这件事由角色统一配置（角色与权限配置），不要在每个模块里各写一套口径。## 第四步：移动端接手，把当场要做的动作交到手机上

考勤这类模块，真正的用户在车间、门店、工地和路上，他们的动作发生在手机上。用 Inkwell 构建器做的模块，PC 上搭好的页面会成套出现在移动端，同一套数据、同一份权限，不用另外开发一个 App（做法见移动端使用指南）。

手机上最该有的是这几个动作：

打卡：一键记录上下班时间，当场写备注（忘带门禁卡、设备故障、外出办事）。
看班表：本人本周排班与今天该上的班次，不用再问主管。
提交申请：补卡说明、换班申请、请假与加班，表单字段和 PC 端一致，提交即进主管待办。
主管在手机上批：一屏看到申请人的当天班次、实际打卡时间、申请理由，批或驳回都有依据。

一个取舍建议：移动端只放「当场必须做的动作」，规则维护和批量排班留在 PC。 手机上入口越堆越多，一线反而更不愿意用。另外，打卡这种动作的动线要短到两步以内——能不能在三秒内打完卡，直接决定这个模块会不会被弃用。

第五步：月度工时汇总，把记录变成能核对的账

前面所有记录，最后都要收成一张能交给财务和员工本人的表。做法是引入「工时汇总单」这一层：一行 = 「某个员工、某个期间」，字段包括计薪周期、应出勤天数与小时、实际出勤、加班小时、各类请假天数、异常扣减建议，以及汇总状态（草稿/已确认/已锁定）。

生成方式不用手工做表：由定时任务在月初按上一期间自动生成，HR 打开就是填好的，只处理两类事——核对异常是否都闭环了、对有争议的行补说明。确认无误后锁定，锁定之后不许再改，需要调整只能走「新增调整行」并留原因。这一步的意义和记账一样：发出去的数和系统里的数永远对得上，事后还能解释清楚每一笔差异。

汇总单往下接两条线：

接薪资核算：工时汇总锁定后作为计薪的输入，减少月底两次录入（延伸做法见薪资核算与发放）。
接人力成本分摊：把工时按部门或项目拆开，用于分摊人工成本（项目维度的做法见项目台账）。

如果企业同时有车间计件或工序报工，工时的口径要和报工口径事先对齐——两套数字打架，通常不是系统的问题，而是口径没定。计件场景可以参考 MES 生产工单与报工的记法。

上线前要确认的五件事

工时口径写成一页纸。 计薪周期（自然月还是 21 日到 20 日）、应出勤天数怎么算、跨天班怎么归属、迟到早退扣不扣工时、加班从几点开始算。这页纸既是系统说明书，也是将来换人时的交接凭证。口径一次定死，之后改等于历史重来。
历史从哪一天起算。 建议从某个排班周期首日开始，把当期班表和人员导进来；之前的记录不追。期初口径定清楚，比补三个月历史数据有用。
班表粒度选一层。 是排到人，还是先排到班组再细化到人？前者准但费工，后者快但月度核时要多一步确认。中小团队建议先排到人、按班组批量生成，两头的好处都留一点。
异常处理的时限。 比如当月异常必须在本月 25 日前闭环，过期不再受理。没有时限的异常清单会一直堆着，到月底变成新增的人工。
两套并行多久。 建议并行一到两个完整计薪周期，把系统算出的工时与原来 Excel 的结果逐人比对，差异能全部解释清楚再停用旧表。发布前用平台的测试与预检走一遍（模块的测试与发布），把权限和必填规则先验过，比上线后被一线发现要好。