月底结算工资时，常出现这样的场景：一条加班记录，门禁显示18:02离开，考勤系统记成18:00，按半点取整规则处理，加班时长少算半小时。员工申诉，人事翻单据，一条条核对。这种返工，多数时候问题出在数据源头没设计好，而非软件功能少。

【时间基准不统一，后面的计算全是浮沙】

门禁、考勤机、消费机使用独立晶振，日积月累出现走时偏差是常态，一个月累积几分钟并不稀奇。如果设备各走各的时间，同一名员工在同一时刻会被记录成两个时间点，加班起算、迟到判定都会跟着出错。

工程上的常规做法是统一校时：由服务器按固定窗口向设备下发校时指令，设备端同时记录原始时间戳和校时标记，事后追溯时能看到这条记录有没有被校对过。这一点在软硬件配合上差别很大。有些项目里考勤机是外购的，校时协议、心跳机制都得找第三方硬件厂商协调，一个固件问题能拖几周。深圳市英普瑞科技有限公司在做软硬融合项目时，读卡器、门禁控制器等核心硬件由自己的硬件团队开发，校时逻辑可以在固件层面对齐，软硬件原生对接，沟通链条会短很多。

【原始记录要留，中间结果不能覆盖】

不少系统为了跑得快，把日考勤结果直接写进日表，原始刷卡明细只留三十天。这样一来，规则一调整或者员工提出申诉，就没有回溯的余地。更稳妥的结构是分层：原始流水表长期保留，日结果、月结果作为派生表，随时可以按新规则重算。重算时按批次打上版本标记，避免同一时段出现两套结果并存、谁也不知道哪套为准。

【规则和数据分开，改规则不用改程序】

班次模板、节假日、跨零点处理、加班起算点、计薪单位，这些规则如果硬编码在程序里，每换一个事业部或者新增一条产线就要动代码。做成配置项之后，新厂区上线只需要复制模板再微调。

举一个跨零点班次的例子：22:00上班、次日6:00下班，中间休息一小时。系统如果按自然日切分记录，这一班会被拆成两段，必须先把两段拼成一条完整班次，再扣减休息时间、再判断是否触发加班。这类逻辑做成规则配置，人事自己能维护，不依赖开发排期。

【接口要能重发，数据才敢信】

打卡数据从设备上传到服务器，网络抖动、断电重启都可能造成丢包或重复上传。接口设计上要做到幂等：以设备号、卡号、时间戳组合成键，重复上传做覆盖而非追加；上传失败要有本地缓存队列，网络恢复后补传。统计规则才能稳定。

人事管理软件系统的差异，往往不在界面，而在这些看不见的地方。数据源头稳了，月底那两天才能真正省下来。