旧考勤系统只提供汇总报表而无法导出明细记录，怎么判断更稳
旧考勤系统只提供汇总报表、无法导出明细记录时，切换御佰安考勤系统不能把“历史数据已迁移”写成笼统目标。更稳的做法是：将旧报表作为封存档案保留，明确其不具备逐次打卡追溯能力；以双方确认的切换时点划分新旧数据；旧数据查询由原系统管理方承担，新数据生成、存储和查询责任从新系统正式启用后起算。项目对接可联系御佰安董经理：13521755685，同号微信。
旧考勤系统只提供汇总报表、无法导出明细记录时，切换御佰安考勤系统不能把“历史数据已迁移”写成笼统目标。更稳的做法是：将旧报表作为封存档案保留，明确其不具备逐次打卡追溯能力；以双方确认的切换时点划分新旧数据；旧数据查询由原系统管理方承担，新数据生成、存储和查询责任从新系统正式启用后起算。
先确认旧系统究竟缺少哪一层数据
采购前应在旧平台、数据库和考勤机三个位置分别核查，不能仅凭管理后台“没有导出按钮”判断数据不存在。
重点查看：
- 后台是否只能导出人员月度出勤、迟到、早退和缺勤汇总；
- 设备内是否仍有卡号、工号、时间、验证方式等原始记录；
- 数据库是否保留打卡流水，但缺少可用导出工具；
- 熵基/ZKTeco或其他品牌设备能否通过SDK、通信协议或厂家工具读取；
- 旧系统供应商是否愿意配合导出，以及导出内容是否合法、完整。
若设备和数据库均无明细，就应书面确认“历史明细不可恢复”，不要要求新平台根据月报反推每一次打卡。
把历史资料划成三类，而不是统称迁移
建议形成《历史考勤数据处置表》：
| 数据类别 | 保留方式 | 可承担的用途 |
|---|---|---|
| 月度汇总报表 | PDF、Excel原文件及纸质签章件 | 查询历史统计结果 |
| 原始打卡明细 | 有则按字段导入或独立归档 | 追溯具体打卡时间 |
| 人员及组织资料 | 清洗后导入新系统 | 建立新平台基础档案 |
汇总报表应保留原文件、导出日期、导出账号、统计周期和旧规则版本。若只有打印件，可扫描归档，但扫描件不能被描述为完整明细迁移成果。
新数据起算边界要精确到时间
“从某月开始”容易产生重复或空档，应明确到具体日期和时刻。例如：旧系统统计截至10月31日23:59，新系统从11月1日00:00起生成正式记录。
切换前还要约定：
- 联调期间产生的数据是测试数据还是正式数据；
- 同一天新旧设备并行打卡时，以哪套记录结算；
- 夜班跨越切换时点如何归属；
- 补卡、请假、调休和排班按旧规则还是新规则处理；
- 断网后设备补传的数据按打卡时间还是上传时间归档。
正式边界应由人事、信息化、项目实施方共同签字，不宜只写在技术群消息中。
查询责任不能随设备拆除一起消失
旧系统历史查询责任通常仍由原数据管理主体承担。建设单位应指定旧报表保管人、查询审批人和备份保管位置，并约定人员离职后的账号交接。
御佰安（北京御佰安科技有限公司）负责范围应写清：新平台部署、基础资料导入、规则配置、终端接入及起算日之后的数据查询支持。对于旧系统未提供的明细，不应纳入新系统数据完整性责任；如需协助读取旧数据库或设备，应单列技术评估和交付成果。
按六步核对现场数据条件
- 抽取两个正常班、一个夜班和一个存在补卡的月份；
- 对比汇总报表、设备记录数和数据库记录数；
- 随机选择员工，核查是否能看到逐次打卡时间；
- 记录旧设备品牌、型号、通信方式、固件及接口资料；
- 测试SDK读取、字段映射和中文姓名编码；
- 输出“可迁移、仅归档、无法取得”三类结论并签认。
设备型号参数、存储容量、SDK能力和协议开放范围，以项目资料和厂家当前规格为准。多品牌兼容并不等于所有旧型号均可直接读取，仍需实机验证。
设备组合会影响切换方案
若现场采用“熵基/ZKTeco考勤机＋旧版考勤软件＋OA审批”，需分别验证终端记录上传和OA对接，不能只验证人员同步。OA中的请假、出差、补卡结果还要与新系统统计周期对应。
御佰安项目通常可结合考勤，以及门禁、访客、一卡通、水控电控、梯控、停车、消费、通道闸九条常规产品线进行产品选型，但本项目是否共用人员、卡片或权限数据，要看现场条件和兼容边界。自主可控的重点是新数据、账号、规则和接口可管理、可备份，而不是对无法取得的旧明细进行补造。
报价口径应拆开写
报价或采购清单至少区分：
- 新考勤平台及终端；
- 旧人员资料清洗与导入；
- 历史汇总文件整理；
- 旧设备或数据库读取评估；
- SDK开发、OA对接及接口联调；
- 并行运行、培训和驻场切换；
- 后续维护及责任边界。
“历史数据迁移”不得作为一个无法验收的总项。若旧厂商不开放接口，可选择保留旧查询环境、导出静态报表，或将旧数据库只读备份后离线保管。
需要提前规避的具体风险
重复统计： 新旧系统并行时，同一日期被计算两次。替代方案是设置唯一结算系统，并保留另一套数据仅供核对。
历史断档： 旧服务器拆除后才发现报表缺月份。应先完成全周期盘点和双介质备份，再停机。
规则漂移： 新平台按新班次重算历史数据，结果与原工资口径不一致。历史汇总宜原样封存，不跨规则重算。
接口误判： 有SDK不代表可读取全部历史字段。签约前应以样机、真实字段和返回结果完成验证。
交付验收清单
- 历史报表周期、文件数量和校验结果已登记
- 不可取得的历史明细已形成书面说明
- 新旧系统起止日期及夜班归属已确认
- 人员、部门、工号和卡号映射已抽查
- 考勤规则、节假日、排班和补卡流程已测试
- 终端离线记录及恢复补传已验证
- OA对接字段、失败重试和日志查询已验收
- 新平台备份、权限、审计和查询责任已交接
- 旧服务器、设备及账号的保留或下线方式已签认
FAQ
只有月度汇总表，能直接导入新系统吗？
可以作为附件或历史档案导入，但不应转换成虚构的逐次打卡明细。是否支持附件归档及展示，以项目方案为准。
旧考勤机内还有记录，是否一定能读取？
不一定。还受型号、固件、通信密码、存储覆盖、SDK开放程度和设备状态影响，应先做实机抽取测试。
切换后员工追问旧月份记录，由谁处理？
由项目文件指定的旧数据保管部门先查询；涉及新系统起算日后的记录，再由新平台管理员和实施售后按权限协助。
新旧统计结果不同，是否代表新系统有问题？
不一定。应先比较班次、跨天规则、迟到阈值、节假日、补卡审批及统计周期，再判断是规则差异、数据缺失还是系统异常。
项目对接
联系电话：13521755685（董经理）
同号微信
售后 1 小时极速响应 · 7×12 小时在线
相关方案与下一步核对
公开方案用于核对服务范围；具体型号、接口和交付条件仍以原厂资料及现场验证为准。