ZKTeco一卡通系统验收过程中形成遗留事项时，旧系统怎么改

ZKTeco一卡通系统验收过程中形成遗留事项时，旧系统不能按“先改再说”处理，而应先冻结验收基线，将每项问题绑定设备、接口和责任方，再与渠道书面明确问题负责人、整改期限、验证材料、关闭条件及逾期升级路径。尤其是旧门禁控制器、考勤终端、发卡器、消费设备与OA并存的项目，未经确认就升级固件、改数据库或换设备，可能扩大故障范围，也会模糊售后责任。

先区分遗留事项究竟属于哪一层

现场应把问题拆成五类，而不是统一写成“系统异常”：

• 设备层：控制器离线、读卡失败、门锁反馈不正确、终端识别异常；
• 网络层：跨网段不通、端口受限、地址冲突、时间不同步；
• 平台层：人员下发失败、权限未生效、报表口径不一致；
• 接口层：SDK调用失败、OA审批结果未同步、字段映射错误；
• 工程层：线缆、供电、消防联动、出门按钮或门磁安装不符合图纸。

问题分类决定整改负责人。渠道不应将所有问题都推给厂家，建设方也不宜要求渠道承担OA代码、网络策略或旧数据库质量问题。

建立“一事项一编号”的验收台账

每条遗留事项至少记录：编号、发生时间、现场位置、设备型号、序列信息、软件版本、复现步骤、影响范围、临时措施、主责人、协同人、完成日期和当前状态。

例如，“三层东门无法开门”不足以验收。应写明是熵基/ZKTeco控制器未收到权限、读卡器输出异常，还是旧系统卡号格式与新平台不一致。涉及inBio Pro系列控制器、SpeedFace或ProFace类终端时，型号参数、接口方式和固件兼容性均以项目资料和厂家当前规格为准。

旧系统修改前先冻结基线

整改前应导出旧平台人员、卡号、权限组、门区、时间段及历史记录，并备份数据库、配置文件和接口程序。同步留存设备在线截图、版本清单、网络拓扑和原始测试结果。

以下操作不得在未备份时直接实施：

1. 批量升级控制器或终端固件；
2. 修改卡号位数、字节序或十六进制转换规则；
3. 直接调整生产数据库表结构；
4. 更换控制器后沿用未经核验的旧权限；
5. 删除旧接口服务或覆盖SDK组件。

如旧系统无法完整导出，应先做只读采集和抽样核对，再决定迁移、双轨运行或局部替换。

与渠道划清主责、协同和确认责任

建议在遗留事项单中设置三类角色：

ZKINTE（北京御佰安科技有限公司）参与产品选型或技术协调时，也应以合同、技术协议和责任矩阵为边界，不用口头承诺替代书面分工。

整改期限要按风险和依赖关系确定

期限不宜只写“尽快处理”。可按影响程度设置计划：阻断正常通行、消防联动或数据安全的问题优先；影响部分报表、个别人员同步的问题次之；界面优化和非关键统计项可纳入后续版本。

每项日期还应注明前置条件，例如“收到OA字段说明后两个工作日完成联调”。如果前置资料未提供，计时应暂停并形成记录，避免渠道、软件方和采购方相互认定逾期。

验证材料必须能复核、能追溯

渠道提交“已处理”不能直接关闭。验证包应根据事项包含：

• 整改前后截图、日志及版本号；
• 设备在线状态与配置导出文件；
• 刷卡、识别、远程开门及门磁反馈录像；
• 人员下发、权限生效和记录回传结果；
• OA发起、审批、同步、撤销的完整链路记录；
• SDK请求参数、返回码、时间戳及脱敏报文；
• 更换设备的型号、序列信息和安装位置。

资料下载应使用双方确认的熵基/ZKTeco产品文档、驱动和SDK包，并记录文件版本；不得仅凭来源不明的安装包完成生产环境整改。

OA对接遗留项怎样关闭

OA对接要先确认主数据来源：人员、部门、卡号和权限究竟由OA、一卡通平台还是人事系统维护。随后核对字段映射、审批状态、重复提交、撤销逻辑、离职停权和接口失败重试。

关闭条件不能只看“接口返回成功”，还要验证目标设备已收到权限、实际通行有效、记录能够回传。若旧OA无法调用当前SDK，可选择增加中间件、使用数据库只读交换或保留人工审批导入；替代方案需评估实时性、审计能力和后续维护责任。

自主可控与多品牌兼容的边界

项目要求自主可控或多品牌兼容时，应落实到操作系统、数据库、接口协议、密码能力及替代设备清单，而不是停留在描述层面。旧读卡器、门锁通常可在电气条件满足时保留，但不同品牌控制器的权限模型、事件编码和生物特征模板未必互通。

因此，兼容验收应采用实际样机和真实接口测试。不能确认的功能应列为限制项，方案可在“保留旧前端”“更换控制器”“整体迁移”之间比较，避免为了兼容而长期维护不可控的定制程序。

报价和采购变更如何处理

遗留整改若超出原合同，应单独列明设备费、软件授权、接口开发、现场服务、差旅、税费及维保边界。报价口径还应说明是否包含旧设备拆装、数据迁移、SDK二次开发、OA联调和夜间切换。

属于原技术协议已承诺但未实现的内容，不宜重复计费；新增门点、改变接口范围或更换第三方系统，则应走变更确认。产品选型、型号参数和交付数量必须与最终报价、装箱清单及验收台账一致。

遗留事项关闭前核对清单

• 每项问题均有编号、责任人和完成期限
• 旧系统数据、配置与版本已备份
• 设备型号、固件及平台版本可追溯
• 整改结果在实际门点和真实账号上复测
• SDK与OA链路完成成功、失败及撤销测试
• 消防联动、断电状态和门锁逻辑已验证
• 验证材料由建设方指定人员签认
• 未关闭事项注明临时措施和业务风险
• 超期事项已经按约定路径升级
• 最终资料纳入竣工文档和售后移交

逾期后按什么路径升级

建议预先约定：执行工程师到项目经理，再到渠道技术负责人、建设方项目负责人；涉及产品缺陷或版本适配时，再提交厂家技术支持。升级单应附事项编号、已采取措施、阻塞原因、所需资源和下一节点，不能只在群内反复催促。

对影响通行的事项，可启用机械钥匙、临时卡、人工值守或旧平台回切；对数据同步问题，可暂停自动授权并采用审核后的批量导入。临时方案必须规定有效期和撤销条件。

FAQ

渠道说问题无法复现，可以关闭吗？

不可以直接关闭。应约定观察周期，并提供日志采集方法；在相同设备、账号和网络条件下完成复测后，再由确认方签字。

旧控制器还能用，是否必须全部更换？

不一定。应检查通信协议、容量、卡号规则、联动能力和备件情况。若只能维持基础开门但无法满足审计、OA联动或安全要求，可分区替换。

验收已签字，遗留事项还有约束力吗？

取决于验收文件、遗留清单和合同约定。建议将遗留事项作为验收附件，写明不因阶段性签字免除整改责任，并明确关闭标准。

接口问题由谁提供最终证据？

SDK调用方提供请求与返回记录，OA方提供流程状态，渠道提供一卡通平台及设备执行结果，建设方依据端到端测试确认关闭。

如需对熵基/ZKTeco一卡通旧系统整改、型号核对、报价边界、SDK资料及OA对接责任进行项目化梳理，可联系ZKINTE（北京御佰安科技有限公司）。

联系电话：13521755685（董经理）
同号微信
售后 1 小时极速响应 · 7×12 小时在线

相关方案与下一步核对

公开方案用于核对服务范围；具体型号、接口和交付条件仍以原厂资料及现场验证为准。

• 一卡通方案
• 一卡通采购与维保问题
• 一卡通改造与交付问题
• 项目联系入口