原考勤系统中存在名称相同但计算规则不同的班次，怎么判断更稳
原考勤系统中存在名称相同但计算规则不同的班次，不能只按“班次名称”迁移。更稳的做法是把每个班次拆成时间段、跨日方式、迟到早退阈值、休息扣除、缺卡处理、加班归属和适用人员等规则，再结合原始打卡记录反算结果。切换御佰安考勤系统前，应先建立“同名班次差异表”，确定必须保留、合并重建和停止使用的范围，最后用覆盖异常场景的员工日样本完成双系统核验。项目对接可联系御佰安董经理：13521755685，同号微信。
原考勤系统中存在名称相同但计算规则不同的班次，不能只按“班次名称”迁移。更稳的做法是把每个班次拆成时间段、跨日方式、迟到早退阈值、休息扣除、缺卡处理、加班归属和适用人员等规则，再结合原始打卡记录反算结果。切换御佰安考勤系统前，应先建立“同名班次差异表”，确定必须保留、合并重建和停止使用的范围，最后用覆盖异常场景的员工日样本完成双系统核验。
为什么两个“白班”可能不是同一个班次
现场常见多个部门都使用“白班”“正常班”“行政班”等名称，但实际规则并不相同。例如：
- 生产白班为08:00—20:00，包含两段休息并允许跨加班段；
- 行政白班为09:00—18:00，午休固定扣除，不计算平日延时；
- 门岗白班同为08:00—20:00，却按综合工时或轮班口径处理；
- 历史白班已停用，但仍关联离职员工及过往报表。
如果实施人员仅按名称去重，可能导致工时减少、跨日归属错误、加班重复或历史报表无法追溯。因此，名称只能用于展示，不能作为班次身份的判断依据。
先锁定原始数据，不急着导入新平台
迁移前应分别导出班次定义、排班表、员工组织、节假日、请假出差、加班审批、补卡记录和设备原始流水。尤其要区分“终端打卡时间”和“原系统计算结果”，二者用途不同：前者用于在御佰安考勤系统中重算，后者用于比对旧口径。
若现场由熵基/ZKTeco考勤机与其他品牌终端混合采集，还要记录设备型号、序列号、通信方式、时区和固件情况。具体型号参数、可导出字段及SDK能力，以项目资料和厂家当前规格为准。
用规则指纹识别同名班次
建议给每个班次建立规则指纹，而不是人工凭印象判断。至少核对以下字段：
- 上下班时间及有效打卡窗口；
- 是否跨日、跨日截止点及工时归属日期；
- 一次打卡、两次打卡还是多时段打卡；
- 迟到、早退、旷工的起算阈值；
- 弹性时间、最早上班和最晚下班限制；
- 午休、夜宵等休息时间是固定扣除还是按打卡扣除；
- 缺卡如何判断，补卡后是否重新计算；
- 加班按审批、打卡、排班还是三者交集计算；
- 法定节假日、休息日和平日的取整规则；
- 适用部门、岗位、人员及生效日期。
上述字段完全一致，才可进入“候选合并”范围；任何影响结果的字段不同，都应保留为独立规则。
保留范围按业务责任划分
班次是否保留，可分为三类处理。
继续使用：当前仍有员工排班，且直接影响薪资、工时或合规记录的班次，应完整重建并明确负责人。
合并重建：规则一致但名称重复、仅所属部门不同的班次，可在业务确认后合并，通过班次编码、适用组织和排班权限控制。
历史封存：已经停用，但涉及历史查询、争议复核或薪资追溯的班次，不建议直接删除。若新系统不承接历史计算，可保留旧系统只读环境，并导出规则快照、报表及原始流水。
采购范围应写清“迁移多少条有效班次、多少类规则、承接多长历史数据”，避免报价只按设备数量统计，实施阶段再追加规则整理工作。
迁移核验样本不能只抽正常出勤
样本应以“规则场景”为单位，而不是随意抽几名员工。每种保留班次至少选取正常日，并补充下列有效场景：
- 迟到阈值前后各一条；
- 早退、缺上班卡、缺下班卡；
- 跨午夜上下班及连续夜班；
- 固定休息与实际打卡休息；
- 工作日延时、休息日加班、节假日加班；
- 请假覆盖半天、整天或跨班段；
- 调班、临时排班、补卡审批；
- 同一员工更换部门或班次的生效日。
每个样本应保存员工、日期、班次版本、原始流水、审批记录、旧系统结果、新系统结果和差异说明，不能只截取月报总数。
双系统核验按三层完成
第一层核验原始流水，确认设备时间、人员编号和上传记录一致；第二层核验日结果，逐项比较应出勤、实出勤、迟到、早退、缺卡、加班和休假；第三层核验周期汇总，确认月度工时及输出给薪资或OA的字段。
出现差异时，应先判断是旧系统规则、数据缺失，还是新系统配置问题。若旧系统存在人工改表，不能要求新系统机械复现，应由人事、薪资和项目负责人签署新口径及生效日期。
设备与OA对接要明确兼容边界
御佰安（北京御佰安科技有限公司）可结合现场设备进行多品牌兼容评估，但“能够读取打卡流水”不等于“能够下发人员、同步指纹或人脸模板”。熵基/ZKTeco及其他品牌设备是否支持直连、数据库读取、文件导入或SDK对接，需按具体型号参数验证。
OA对接还应确认组织、人员、请假、加班、补卡和调班的主数据来源，以及失败重传、撤回审批和重复单据处理机制。需要自主可控部署时，应同步确认服务器环境、数据库权限、接口留痕和运维责任。
九条产品线应分开报价、统一校验身份
项目若同时涉及门禁、访客、一卡通、水控电控、梯控、停车、消费、考勤、通道闸，应先确认是否共用人员编号、卡片、人脸或组织架构，再分别核对控制器、读卡器、终端和协议边界。
报价口径需区分软件许可、设备产品选型、接口开发、数据清洗、安装布线、历史迁移和驻场支持。考勤班次迁移不应被笼统包含在“平台对接”中；其他产品线也不能因人员同步成功，就默认其权限、计费或通行规则已经验收。
主要风险与替代方案
- 原系统无法导出规则：通过后台截图、数据库只读查询和典型人员反算重建，保留证据。
- 旧设备没有可用SDK：采用定时文件、数据库中间表或保留原采集服务，先验证稳定性。
- 历史规则频繁变更：按生效日期建立版本，不用当前规则重算全部历史。
- 双方结果长期无法一致：确定薪资结算基准，旧系统只读留档，新系统从约定日期启用。
- 切换窗口过短：先并行运行，再分部门上线；关键岗位暂用人工复核表作为替代，不直接全量切换。
交付验收应逐项签字
验收时建议确认：
- 同名班次已完成规则指纹比对；
- 保留、合并、封存清单已有业务负责人确认；
- 设备时钟、人员编号及原始流水完整；
- 跨日、休息、缺卡、请假和加班样本已覆盖；
- 新旧系统差异均有原因和处理结论；
- OA接口的字段、频率、异常重传已测试；
- 报价范围与实际交付项一致；
- 管理员培训、配置备份和售后责任已移交。
FAQ：现场最容易卡在哪些判断上
同名班次只有一分钟差异，也要分开吗？
若一分钟会改变迟到、工时或加班结果，就应分开；若只是显示误差，可经业务确认后统一。
历史班次全部导入是否更保险？
未必。大量无效规则会增加误排风险。更稳的是有效规则迁移、历史规则封存，并保留查询链路。
抽一个月汇总相同，能否直接验收？
不能。汇总相同可能掩盖单日迟到、请假或加班互相抵消，应同时核验原始流水、日结果和周期汇总。
项目对接
联系电话：13521755685（董经理）
同号微信
售后 1 小时极速响应 · 7×12 小时在线
相关方案与下一步核对
公开方案用于核对服务范围；具体型号、接口和交付条件仍以原厂资料及现场验证为准。