为什么假勤要连成一条闭环
很多公司的考勤管理，卡在"数据各管一摊"上：打卡记录在打卡机里，请假单在纸质表格或微信群里，加班靠月底手工统计，调休额度记在 HR 的 Excel 里。到了月底对账，HR 要把三处信息拼在一起，遇到员工离职、跨月调休、审批延迟，口径就很难对齐。
问题不在于缺工具，而在于三个环节之间没有传递关系：加班审批通过了，额度不会自动累加；请假提交了，余额不会被核对；打卡漏了，异常状态没有地方登记说明。
Inkwell Engine（AI 驱动自主开发平台）近期上线的三个模块，把这条链补齐了：考勤打卡（attendance）、请假休假（leave）、加班调休（overtime）。三者都挂在同一套员工档案（employee）之上，共用工号与姓名的快照口径，因此一张加班单和一条打卡记录指向的是同一个人，不需要再做名字匹配。
本文按"记录怎么留 → 流程怎么走 → 额度怎么算 → 余额怎么看"的顺序，讲清这三个模块各自解决什么，以及连起来之后能省掉哪一步人工。
考勤打卡：先把每天的原始事实固定下来
考勤的第一原则是"先有事实，再谈判断"。打卡模块承担的就是这个事实层。
每条记录以"员工 + 日期"为一行，字段包括：所属员工（引用员工档案）、员工姓名与工号快照、考勤日期、上班时间、下班时间、考勤状态、备注。
这里有两个设计值得说明：
- 姓名与工号做快照。记录生成时就把当时的姓名、工号写进这一行。后续即使员工改名、部门调整，历史考勤行仍然保留当时的身份信息，不会出现"这条记录到底是谁的"的争议。
- 状态用字典统一管理。正常、迟到、早退、缺卡这类判定结果，来自平台的数据字典（枚举值集中维护的地方，改一处全站生效）。企业想增加"外勤"或"出差"状态，是在字典里加一个值，而不是改代码。
检索侧支持按员工、按考勤状态、按日期区间组合筛选。月末 HR 想看"某部门本月所有非正常打卡"，选状态 + 选月份即可导出核对，不用逐条翻。
备注字段的用途是给异常留解释：设备故障、外出办事、忘打卡但已口头报备——写在当行备注里，事后追溯有据可依。
请假休假：一张单子的四段旅程
请假模块管的是"申请—审批—核减"这条流程链。一张请假单的字段构成很朴素：员工（引用员工档案）、姓名与工号快照、假期类型、开始日期、结束日期、天数、事由、状态、审批人、审批时间、审批意见。
它的生命周期是四个状态：提交 → 审批中 → 通过 / 驳回。
- 员工或 HR 代录一张单，填假期类型、起止日期和事由；天数按起止日期计算并落在单子上，避免"口头上说三天、表格里写两天"。
- 提交后进入审批中，单据上会记录当前审批人与审批时间，谁批的、什么时候批的、批的时候写了什么意见，都留在这张单上。
- 通过后，系统按假期类型去核减对应的假期余额台账；驳回则保留完整记录，事由和意见可查，方便员工重新提交时说明差异。
假期类型不是硬编码的。年假、事假、病假、调休这些名称和口径，来自数据字典。不同公司的叫法不一样，改字典就能改下拉选项，历史单据仍显示当时选用的类型。
对 HR 来说，最有价值的一点是：请假记录本身就是台账。想统计"某位员工今年请了多少天病假"，是按员工 + 假期类型筛选后直接汇总，而不是回到聊天记录里翻。
加班调休：审批通过之后，额度才真正存在
加班模块解决的是"加班换调休"这笔账最容易算错的问题。核心规则只有一句：只有审批通过的加班，才计入可调休额度。
一张加班单包含：员工（引用员工档案）、姓名与工号快照、加班类型、开始时间、结束时间、加班时长（小时）、事由、状态、审批人、审批时间、审批意见。同样走"提交 → 审批中 → 通过 / 驳回"的流转。
审批通过的那一刻，系统按单上的加班时长累计到该员工的调休额度里。这意味着：
- 未审批或已驳回的加班，不会提前占用额度，也不会被误算进去；
- 额度的每一分增量都能回溯到一张具体的加班单，员工有疑问时，把单据摊开看即可，不需要 HR 凭记忆解释；
- 加班时长以小时为单位记录在单上，跨天的夜班也能用起止时间表达清楚。
额度视图：已调休多少、还剩多少，按员工一行看全
三个模块连起来之后，最终呈现给管理者的是一张按员工维度的调休视图：已调休时长与剩余可调休时长。
这张视图的意义在于把"存"和"取"放在同一个口径下：加班审批通过是存入，请假单里选择调休类型的部分是取出，两者相减就是余额。员工问"我还剩几天调休"，HR 打开视图就能看到答案，不用再手工加减上个月的表格。
同时，考勤打卡提供的是最底层的原始事实——哪天实际到岗、哪天缺卡。当一张加班单声称"当晚加班到十点"，而当天的打卡记录里没有对应的下班时间，这个不一致会被看见。三张表互为验证，比单一来源的记录更可靠。
同一条链上还能接什么
假勤不是孤立场景。这三个模块所在的 OA 套件里，已经有一批共用同一套员工档案的模块在运行：
- 员工档案（employee）：人事信息的主数据，工号按创建时间自动生成，支持按部门、岗位、在职状态、入职日期筛选。它是假勤三件套引用人员的唯一来源。
- 日程日历（calendar）：记录主题、起止时间、地点、参与人与提醒设置，支持参与人时间冲突校验。请假期间把人从日程里排除，靠的就是同一份人员引用。
- 会议管理（meeting）：会议室预定与会议纪要，同样带时间冲突校验和审批状态流转。
- 公告通知（announcement）：全员公告的发布与下架，支持置顶、类型/优先级/状态字典。考勤规则调整、节假日安排这类通知，可以直接触达。
- 任务待办（task）：任务创建、指派负责人、优先级与状态流转、截止时间追踪，供 OA 首页聚合展示。
这些模块之间通过平台的引用机制（跨模块软外键）串起来，而不是各自维护一份人员名单。新增一个"出差申请"或"补卡申请"，走的是同样的构建路径，天然继承已有的员工口径。
这套东西是怎么建出来的
值得说明的是建设方式。上述模块不是在通用 OA 软件里做配置项勾选，而是在 Inkwell Engine 上由 AI 构建器生成的业务模块：用自然语言描述需求（要管哪些字段、走什么流程、谁能看），平台生成对应的数据结构、接口与页面，经过测试与预检后发布挂载到菜单。
对企业来说，这个路径的实际差别有三点：
- 字段跟着公司走。假期类型的叫法、加班时长的计算口径、备注要不要必填，都是这一家公司的规则，可以按现状定义，不必迁就标准产品的预设。
- 流程跟着责任走。审批人、审批意见、状态流转都写在模块里，权限沿用平台内置的角色与权限体系，谁能录、谁能批、谁能看全量数据，分开控制。
- 改动跟得上线上变化。制度调整后修改模块即可，历史数据保留原快照，不会因为改了字段就把去年的记录弄丢。
移动端与 PC 端同源，员工在手机上提交请假、查看调休余额，HR 在电脑上批量核对与导出，两边读的是同一份数据。
上线前建议先查这几件事
如果你打算把假勤这条链跑起来，上线前值得逐项确认：
- 员工档案是否干净。假勤三件套全部引用员工档案，先把在职状态、部门归属整理准确，避免离职人员在考勤列表里继续出现。
- 字典口径是否与制度一致。考勤状态有哪几种、假期类型怎么分类、加班类型如何区分工作日与休息日——这些名称一旦投入使用，历史单据会保留当时的取值，前期对齐比后期修补省事。
- 审批人由谁指定。明确每张单上的审批人是固定角色还是按部门分派，并把审批意见设为必填，留痕才有意义。
- 存量数据怎么进。过去几个月的打卡与请假记录，可以先录入模块作为起点，让调休额度从一个双方认可的数字开始累计，而不是从零重算引发争议。
- 异常处理约定。漏打卡、设备故障、代提交这类情况，统一写进备注字段并配套公告说明规则，减少个案沟通成本。
假勤管理的目标从来不是多一套系统，而是让"事实—判断—额度"这三层各归其位：打卡留下事实，审批形成判断，额度自动结算。剩下的解释工作，交给一张能追溯的单据。