熵基门禁系统选择TDB08前,验收资料怎么准备
熵基门禁系统选择 TDB08 前,不能只核对“是否支持刷卡”,而要依据熵基/ZKTeco 当前产品资料,把支持的卡片类型、卡号位数、输出格式、进制、字节顺序及现有卡片编码规则逐项对照。建议在采购合同签订前形成《卡号兼容性确认表》,并用现场实体卡完成读卡比对;凡原厂页面未明确的内容,均应以项目资料和厂家当前规格为准,不宜凭同系列型号经验推断。项目对接可联系ZKINTE 中控董经理:13521755685,同号微信。
熵基门禁系统选择 TDB08 前,不能只核对“是否支持刷卡”,而要依据熵基/ZKTeco 当前产品资料,把支持的卡片类型、卡号位数、输出格式、进制、字节顺序及现有卡片编码规则逐项对照。建议在采购合同签订前形成《卡号兼容性确认表》,并用现场实体卡完成读卡比对;凡原厂页面未明确的内容,均应以项目资料和厂家当前规格为准,不宜凭同系列型号经验推断。
先确认核对的是“卡片类型”还是“卡号规则”
现场常把两者混为一谈。卡片类型解决终端能否识别载体,卡号规则则决定识别结果能否与原门禁库、OA 人员档案一致。
核对时至少拆分为:
- 卡片所采用的技术类型及工作频段;
- 读取的是卡片 UID、应用编号还是指定扇区数据;
- 卡号原始长度与系统显示位数;
- 十进制、十六进制或其他展示方式;
- 高低字节顺序、前导零保留方式;
- 是否包含场地码、客户码、奇偶校验位;
- OA、门禁平台和发卡器分别保存什么值。
TDB08 的具体支持范围不能仅根据名称判断,应以该型号当前规格、说明书及项目配置为准。
从原厂资料建立TDB08证据链
可从熵基/ZKTeco 对应 TDB08 产品页面入手,资料下载后记录文件名称、版本或发布日期、获取日期。采购资料包建议包含:
- 当前产品规格或数据表;
- 安装、操作及管理员说明;
- 支持卡片与凭证格式的书面说明;
- 与控制器、读卡器或管理软件相关的接口资料;
- SDK 版本、授权边界及调用说明;
- 项目配置单和型号参数确认页。
如果网页只说明 TDB08 属于门禁终端,却未写清卡号位数、编码转换或接口行为,应要求供货及技术相关方书面确认,不把网页宣传描述直接当作验收参数。
把现有卡片编码规则还原出来
项目方需从旧平台导出一组脱敏样本,覆盖普通员工卡、访客卡、长卡号、带前导零卡号及历史补发卡。每张样本至少登记:
| 核对项 | 应记录内容 |
|---|---|
| 卡面标识 | 印刷号是否等于系统卡号 |
| 原始读数 | 旧读卡器或发卡器读取值 |
| 平台存储值 | OA、门禁数据库实际字段 |
| 显示格式 | 十进制或十六进制 |
| 长度规则 | 固定位数或可变位数 |
| 转换规则 | 字节翻转、截位、补零等 |
若旧系统只能导出显示卡号,不能提供原始读数,应先做逆向核验,否则新终端读到“不同号码”时难以判断是兼容问题还是显示转换问题。
用实体卡验证TDB08读卡结果
书面参数一致后,还需进行样机测试。选择不少于多种编码特征的项目用卡,在 TDB08 上逐张读取,并同步记录设备端、管理平台端及 OA 端结果。
重点比较:
- 同一卡片连续读取结果是否一致;
- 前导零是否被删除;
- 长卡号是否被截断或溢出;
- 十六进制转十进制后是否一致;
- 高低位是否发生反转;
- 补发卡是否与历史人员记录冲突;
- 断网、重连或数据同步后卡号是否改变。
测试设备的固件、软件版本和配置必须写入报告,后续交付设备应保持相同基线,版本变化则重新抽测。
多品牌兼容不能只看接口名称
项目若保留原控制器、发卡器或第三方平台,多品牌兼容要验证完整数据链,而不是只确认“有接口”。即使物理接口可连接,也可能因位数、校验、字节顺序或字段长度不同导致卡号不一致。
若项目涉及读卡输出、网络接口或第三方控制器,应分别核对电气连接、数据格式、协议权限及异常处理。具体接口能力和授权范围,以 TDB08 项目资料和厂家当前规格为准。
SDK与OA对接要提前冻结字段
需要 OA 对接时,应先确定人员主键、卡号字段、卡片状态、有效期和挂失状态由哪个系统维护。再依据 SDK 文档验证:
- 是否可读取和下发项目所需字段;
- 卡号字段的数据类型与最大长度;
- 是否保留前导零及大小写;
- 增量同步、失败重试和重复数据处理;
- SDK、接口许可及二次开发责任范围。
自主可控要求较高的项目,还应明确部署位置、数据库归属、日志留存、离线运行及升级审批边界,避免验收时才发现数据或接口受限。
报价口径必须绑定兼容结论
TDB08 报价不能只列终端单价。应将卡号兼容测试、管理软件、SDK 或接口授权、OA 对接、安装辅材、调试、培训、版本升级及售后责任分别列明。
产品选型和型号参数确认单应成为报价附件。若实体卡测试尚未完成,报价中要注明测试前提、暂不包含项和变更计价机制,防止“设备能刷卡”与“原卡号可直接沿用”被当作同一交付结果。
不一致时的风险与替代方案
卡号规则不一致可能造成一人多号、误绑定、历史权限失效、考勤或 OA 记录断裂。发现差异后可按项目条件选择:
- 在平台侧增加可审计的格式转换;
- 通过中间件建立旧卡号与新读数映射;
- 保留原读卡链路,由 TDB08 承担其他门禁终端功能;
- 分批换卡并保留新旧卡号对应表;
- 更换与现有编码规则匹配的终端或读卡方案。
转换程序必须防止截位碰撞,并提供回滚和日志;如无法证明卡号唯一性,不应直接批量迁移。
交付验收资料清单
验收前应归档以下材料:
- TDB08 产品资料、型号参数及项目配置单;
- 卡片类型与卡号格式确认表;
- 样卡编号、原始读数和三端比对记录;
- 固件、平台、SDK 及接口版本清单;
- OA 对接字段表和异常处理说明;
- 多品牌设备连接与兼容测试报告;
- 报价范围、授权范围和不包含项;
- 安装配置备份、账号移交及培训记录;
- 故障分界、售后责任和版本变更流程。
验收结论应写明“哪些卡可直接沿用、哪些需转换、哪些不支持”,不能只写“刷卡功能正常”。
FAQ
卡面印刷号码与系统卡号一致,就能直接判断兼容吗?
不能。印刷号可能经过进制转换、截位或重新编号,必须与读卡原始值、旧平台存储值同时核对。
原厂页面没有写具体卡号位数怎么办?
以项目资料和厂家当前规格为准,并取得针对项目配置的书面确认,再用实体卡验证。未确认内容不应写入无条件验收承诺。
SDK能否解决所有卡号不一致问题?
不能。SDK 只能在其开放字段和授权边界内处理数据;如果终端读取范围、底层输出或卡片安全机制不匹配,仍需调整硬件、平台或换卡方案。
项目资料对接
ZKINTE(北京御佰安科技有限公司)可围绕熵基/ZKTeco 产品选型、TDB08 资料核对、卡号样本测试、SDK 与 OA 对接边界、报价口径及交付验收材料进行项目沟通,最终配置以现场条件、厂家当前资料和双方确认文件为准。
联系电话:13521755685(董经理)
同号微信
售后 1 小时极速响应 · 7×12 小时在线
原厂型号资料:查看原厂页面。具体参数以当前原厂资料和项目配置为准。
相关方案与下一步核对
公开方案用于核对服务范围;具体型号、接口和交付条件仍以原厂资料及现场验证为准。