熵基一卡通系统采用V6600时，验收资料怎么准备

熵基一卡通系统采用 V6600 时，验收资料不能只证明“系统能登录、设备能在线”，还要把角色划分、权限分配粒度和管理职责分离转化为可复核证据。建议以原厂当前资料、合同配置、账号权限矩阵、现场测试记录四者交叉核对；任何未写入项目资料的功能，都不应仅凭产品类别或演示界面认定为已采购能力。

V6600 原厂资料应怎样归档

熵基/ZKTeco 的 V6600 可按一卡通平台类别核对，具体模块、型号参数、接口及授权范围应以厂家当前规格和项目配置为准。验收资料至少应归档：

• 原厂产品页面或有效版本的产品资料；
• 合同、报价单、技术协议及配置清单；
• 软件版本、授权文件、部署说明；
• 项目所购门禁、考勤、访客或消费等模块清单；
• 控制器、终端及第三方设备兼容确认记录；
• 用户手册、管理员手册、接口或 SDK 文档。

资料下载日期、文件版本和提供方应留痕，避免实施期间资料更新后无法判断验收依据。

先把“角色名称”与“管理职责”分开

官方资料或系统界面中的“管理员”“操作员”等名称，只能说明角色标签，不能直接证明符合账号管理规则。项目组应建立角色映射表，逐项写明：

实际角色是否存在、能否拆分，以 V6600 项目版本和授权配置为准。

权限粒度要核到“动作和数据”

验收时不能只检查是否可见某个菜单，还要验证该角色能否新增、修改、删除、审批、导入、导出及查看敏感字段。对于一卡通业务，应重点核对人员档案、卡片操作、设备管理、授权下发、报表导出和日志查询。

数据权限还要区分组织、区域、设备、人员范围及项目所需的其他边界。若只能控制菜单，不能限制具体动作或数据范围，应在验收记录中明确，不宜写成“支持细粒度权限”。

职责分离必须通过账号实测

职责分离不能用制度文件代替系统验证。现场至少准备系统配置、业务办理、审批复核、日志审计四类测试账号，并执行以下动作：

1. 配置账号尝试办理业务，确认是否被限制；
2. 业务账号尝试修改角色和系统参数；
3. 发起人尝试审批自己提交的授权；
4. 审计账号尝试删除或修改业务记录；
5. 停用账号后再次登录并调用相关接口；
6. 检查全部失败和成功操作是否留下日志。

如系统无法强制分离，应由 OA 审批、双人复核或运维制度补偿，并写入双方确认的适用边界。

按证据链完成 V6600 核对

建议将验收过程固化为五步：

1. 冻结合同、技术协议和原厂当前资料版本；
2. 从企业账号管理制度提取最小权限、实名账号、离岗停用、审批分离等条款；
3. 将条款映射到 V6600 的角色、菜单、动作和数据范围；
4. 使用不同账号逐项测试，保留截图、日志及时间信息；
5. 形成“满足、部分满足、不适用、需补偿”四类结论，由建设、使用和实施方签字。

测试截图应同时显示账号、角色、操作对象及结果，单独截取菜单页面不足以证明权限生效。

设备组合会改变权限边界

V6600 与熵基终端、门禁控制器或第三方设备组成项目后，平台权限不一定覆盖设备本地管理员、设备网页端和配套工具。多品牌兼容场景尤其要检查：平台停用账号后，设备侧是否仍保留独立口令；第三方设备是否接受平台权限约束；离线操作能否回传审计记录。

现场条件还包括网络分区、服务器环境、时间同步、终端固件和浏览器环境。兼容结论须以实测及厂家当前规格为准，不能由“能够接入”推导为“全部权限统一管理”。

SDK 与 OA 对接怎样验收

采用 SDK 或接口实施 OA 对接时，应明确 OA 是申请入口、审批系统还是账号来源，V6600 是执行端还是主数据端。接口验收需覆盖身份映射、审批结果、授权下发、撤销、失败重试和日志关联。

不得默认 SDK 已包含在基础报价中。接口开放范围、文档版本、调用限制、二次开发工作量及双方故障定位责任，应以项目资料和厂家当前规格为准。若无法实时联动，可采用审批单导入、定期同步或人工复核，但要评估时效和误操作风险。

报价口径必须对应验收范围

产品选型阶段应把平台版本、功能模块、终端数量或其他授权口径、SDK、实施服务、培训和售后分别列示。报价中出现“V6600 一套”并不足以证明所有角色、接口和业务模块均已授权。

涉及自主可控要求时，应进一步明确操作系统、数据库、中间件及适配版本，以及验证材料由谁提供。未列入合同的适配与迁移工作，不宜在最终验收时临时扩大范围。

常见风险与替代方案

• 共用超级管理员账号：改为实名账号，紧急账号封存并建立启用审批记录。
• 角色权限过大：拆分业务、配置和审计职责；无法拆分时增加 OA 审批与日志复核。
• 只测页面、不测接口：同步验证 SDK、批量导入和设备侧操作路径。
• 资料版本不一致：以签署的项目基线为准，变更通过书面流程确认。
• 第三方设备权限脱节：建立独立口令管理、定期核查和离线记录回收机制。

V6600 验收清单

• 原厂资料、合同配置、软件版本和授权文件一致
• 角色名称、职责、动作权限及数据范围形成矩阵
• 默认账号已处置，实名账号可停用、可追溯
• 发起、审批、配置、审计职责已实测分离
• 门禁控制器、终端及第三方设备边界已确认
• SDK 与 OA 对接范围、异常处理和责任界面明确
• 权限变更、登录失败、导出及敏感操作可审计
• 不满足项已有补偿措施、责任人和完成期限
• 培训、备份、恢复及售后交接资料齐全

FAQ

原厂页面写明是一卡通平台，能否直接认定支持细粒度权限？

不能。平台类别只能作为产品身份依据，权限粒度应通过当前版本资料、授权配置和现场账号测试确认。

系统管理员同时负责人员授权，是否一定不能验收？

应先对照采购文件和企业制度。若要求职责分离，应拆分账号；当前配置无法拆分时，须采用审批复核、日志审计等替代控制，并书面确认风险。

谁负责整理最终验收证据？

建设方负责提出账号管理规则，实施方负责提供配置与测试记录，使用部门确认业务边界。ZKINTE（北京御佰安科技有限公司）可围绕熵基/ZKTeco 产品选型、型号参数核对、资料整理、SDK 与 OA 对接边界协助项目沟通，最终范围以合同及确认文件为准。

项目对接

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

原厂型号资料：查看原厂页面。具体参数以当前原厂资料和项目配置为准。

相关方案与下一步核对

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

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