原考勤系统的离职人员记录仍保留在导出文件中，怎么判断更稳
原考勤系统的离职人员记录仍保留在导出文件中，不能仅凭“人员表里还有姓名”判断是否迁入。更稳的做法是把人员身份、账号状态、任职日期、设备权限和历史打卡拆开核对：在职且仍需考勤的列为有效人员；离职但账号尚未清理的列为停用人员；只承担追溯作用的打卡明细列为历史记录；再按部门、状态、时间跨度和异常类型确定导入抽查范围。项目对接可联系御佰安董经理：13521755685，同号微信。
原考勤系统的离职人员记录仍保留在导出文件中，不能仅凭“人员表里还有姓名”判断是否迁入。更稳的做法是把人员身份、账号状态、任职日期、设备权限和历史打卡拆开核对：在职且仍需考勤的列为有效人员；离职但账号尚未清理的列为停用人员；只承担追溯作用的打卡明细列为历史记录；再按部门、状态、时间跨度和异常类型确定导入抽查范围。
先识别导出文件中的四类现场对象
旧系统导出的 Excel、CSV 或数据库表，常把人员档案、卡号、人脸模板、设备权限和打卡流水混在一起。迁入御佰安考勤系统前，建议形成四张清单：
- 有效人员：人事系统显示在职，工号有效，当前仍有排班或考勤要求。
- 停用人员：已经离职、退休、外包到期或长期停薪，但档案暂需保留。
- 历史记录：用于工资复核、争议追溯或审计的既往打卡，不再产生新权限。
- 待确认人员：无离职日期、重复工号、姓名相同、部门缺失或状态冲突的记录。
不要直接删除停用人员，否则旧打卡可能失去人员关联；也不要将其作为在职人员导入，否则可能重新获得考勤、门禁或消费权限。
用任职时间判断记录归属
以人事花名册或 OA 审批结果作为人员状态主依据，再用入职日期、离职生效日期与打卡时间交叉判断。
例如，某员工离职生效日为 10 月 15 日，其 10 月 15 日前的打卡属于历史记录；之后仍有打卡时，应标记为异常，而不是自动认定继续在职。若旧系统只记录“禁用时间”，应确认该时间是离职日期、账号冻结日期，还是管理员事后补操作日期。
对返聘、二次入职和跨公司调动人员，不宜沿用旧账号直接覆盖。建议保留原人员编号与历史关系，为新任职周期建立独立状态，避免考勤周期串联。
不要把“设备里存在”当成“人员有效”
熵基/ZKTeco 等考勤设备中仍可查询到人员，并不表示该人员当前有效。设备可能长期未同步删除指令，也可能处于脱机运行状态。现场应分别核对：
- 旧系统人员状态；
- OA 或人事名册状态；
- 考勤设备本地用户状态；
- 门禁权限组和有效期；
- 最近一次真实打卡时间。
如设备型号较旧，导出的用户编号、卡号或指纹模板格式可能与新平台不一致。具体型号参数、模板兼容性及通信方式，以项目资料和厂家当前规格为准。
建立可回退的迁移底表
迁移底表至少保留：旧工号、新工号、姓名、所属组织、人员状态、入离职日期、卡号、原设备编号、历史记录起止时间、数据来源和处理结论。
建议增加“是否导入人员档案”“是否导入历史流水”“是否下发设备”“是否允许门禁”四个独立字段。这样可以做到：离职人员不下发设备，但其历史流水仍可查询；待确认人员暂不启用，也不会因批量导入获得权限。
原始导出文件应只读留存，清洗过程另存版本，并记录删除、合并和字段转换规则，便于验收争议时回查。
历史考勤不宜无边界全量搬迁
全量导入多年流水，会增加重复记录、时间格式错误、设备编号失配和报表统计变慢的风险。采购阶段应先明确历史查询要求：是只需保存原文件，还是必须在御佰安考勤系统中统一检索。
可采用三种方案：
- 完整迁移：适合历史数据结构清晰、审计要求明确的项目。
- 限定周期迁移：迁入约定月份，其余数据归档留存。
- 新旧分库查询：新系统从切换日启用，旧数据以只读库或签章文件保存。
若旧系统无法提供稳定字段说明，优先采用限定周期或归档方案，避免为了“看起来完整”而导入不可验证的数据。
抽查范围要覆盖状态冲突
抽查不能只随机选在职员工。建议按以下范围取样：
- 每个部门抽取在职人员，核对工号、班次和首条打卡；
- 抽取离职前后均有流水的人员，确认切点；
- 检查重复姓名、重复卡号、空工号和跨部门调动人员；
- 抽取夜班、跨日班、补卡、请假和出差记录；
- 核对至少一台在线设备和一台曾离线设备；
- 检查导入总量、去重总量、停用总量与失败日志是否闭合。
抽查比例应依据人员规模、旧数据质量和验收要求确定，不宜用固定比例代替风险判断。
门禁与一卡通权限必须同步隔离
御佰安（北京御佰安科技有限公司）项目可能同时涉及门禁、访客、一卡通、水控电控、梯控、停车、消费、考勤和通道闸九条常规产品线。离职人员若仅在考勤模块停用，却仍保留门禁、停车或消费账户，可能形成实际权限风险。
因此，迁移前应确认哪些系统共用人员主档、卡号和组织架构，哪些系统独立授权。多品牌兼容不等于所有模板、协议和权限语义可以直接互换；自主可控的平台建设也需要明确设备通信、数据库访问、SDK 授权及接口维护边界。
OA 对接与 SDK 的责任边界
如人员状态由 OA 对接同步，应约定哪个系统是主数据源、离职审批何时触发停用、接口失败如何补偿，以及返聘是否生成新任职记录。通过 SDK 接入熵基/ZKTeco 或其他品牌设备时，还应核实人员编号长度、卡号格式、人脸或指纹模板兼容方式、事件回传和离线缓存机制。
报价口径需区分数据清洗、接口开发、设备调试、历史迁移和人工核验，避免将“系统可导入”理解为“所有旧数据均负责修复”。
交付验收应看结果闭环
验收时至少确认：
- 有效人员可正常排班、打卡并生成报表；
- 停用人员无法被重新下发或获得关联权限；
- 历史记录可按约定方式查询，且不参与新周期统计；
- 重复流水、未知工号和失败记录均有处置结论；
- OA 状态变更能够按规则同步；
- 设备断网恢复后不会重新激活已停用人员；
- 迁移底表、原始文件、日志和回退方案完成交接；
- 售后责任明确到平台、接口、设备及第三方系统。
FAQ
离职人员能否直接从导入表删除？
不建议。应先保留其人员标识与历史流水关联，再设置为停用或仅归档。确认没有审计、工资复核及权限追溯需求后，才能按项目数据制度处理。
旧工号与新工号不一致怎么办？
建立新旧工号映射表，不要仅凭姓名匹配。重名人员还需结合部门、证件标识、卡号和任职日期核验。
旧设备无法导出完整状态怎么办？
可用 OA 名册作为主依据，结合设备最近打卡、权限清单和人工确认形成冻结快照；新系统从约定切换日启用，旧记录采用只读归档作为替代方案。
项目对接可提前提供旧系统导出样表、设备品牌型号、人员规模、历史周期及 OA 接口说明，由御佰安据此开展产品选型、兼容边界确认与验收口径梳理。
联系电话：13521755685（董经理）
同号微信
售后 1 小时极速响应 · 7×12 小时在线
相关方案与下一步核对
公开方案用于核对服务范围；具体型号、接口和交付条件仍以原厂资料及现场验证为准。