访客系统 2026-11-03 董经理 2 views

熵基访客系统现场服务结果存在分歧时，旧系统怎么改

熵基访客系统现场服务结果存在分歧时，旧系统不能只靠补签一张服务单解决。应同时改造日志留存、证据导出、账号权限和验收流程，并在采购或补充协议中明确：渠道提交什么证据、由谁复核、几天内提出异议、争议升级到哪一级。ZKINTE（北京御佰安科技有限公司）建议把技术结果与责任认定分开，避免“设备能开门”被直接等同于“全部服务已合格”。项目对接可联系ZKINTE 中控董经理：13521755685，同号微信。

分歧通常发生在旧系统的哪个环节

典型矛盾并非设备完全不可用，而是双方对结果定义不同：

访客机登记成功，但门禁控制器未收到权限；
熵基/ZKTeco 人证核验终端识别正常，OA 对接却没有回写审批状态；
现场称已升级，系统中却无法确认固件、客户端或接口版本；
人脸、身份证、二维码任一方式可通行，采购方认为其他方式也应同步验收；
渠道认定故障来自网络或第三方闸机，甲方认为属于整体交付责任。

因此，复核对象必须拆成访客登记、身份核验、审批、权限下发、门禁执行、记录回传六段，不能只看最终开门动作。

旧系统先补齐四类证据能力

旧平台改造时，至少增加以下能力：

操作留痕：记录账号、时间、终端、配置变更前后值及执行结果。
链路日志：分别保留访客机、服务端、SDK、OA 接口、门禁控制器的请求与响应。
版本固化：记录熵基设备型号参数、序列信息、固件版本、软件版本和数据库版本，具体内容以项目资料和厂家当前规格为准。
可验证导出：日志、截图、录像、测试表应带生成时间，并按工单编号归档，避免仅在微信群中零散提交。

若旧软件不能导出完整日志，可先增加独立日志服务器或接口代理层，不宜直接修改生产数据库。

与渠道约定证据提交规则

证据要求应在进场前写入服务确认单，而不是故障发生后临时协商。

证据类别	最低提交内容	提交责任方
设备状态	型号、版本、在线状态、现场接线照片	渠道实施人员
操作过程	配置步骤、测试账号权限、变更记录	实际操作人员
接口结果	请求时间、返回码、脱敏报文、OA 侧记录	双方接口人员
通行结果	登记、审批、授权、开门、回传的连续记录	项目双方
环境证据	网络连通、时间同步、供电及第三方设备状态	现场配合人员

录像应覆盖操作界面与对应设备动作，个人身份信息需脱敏。只有截图而无时间、账号和链路记录时，不应作为单独定责依据。

复核人员不能由原实施人员单独担任

复核建议采用“三方分工”：渠道安排未直接执行本次操作的技术人员复核设备配置；采购方由项目负责人或信息部门核对需求和变更授权；涉及 OA 对接、第三方闸机或原有门禁时，由对应系统负责人确认边界。

原实施人员可以说明过程，但不宜单独作出最终结论。重大分歧还应由双方项目经理共同签署复核记录，区分“已复现”“未复现”“条件不足”和“非本次范围”。

异议时限要与故障类型对应

建议在合同或工单规则中明确：

现场服务完成后，当日形成服务记录；
对配置、接线、版本等可即时核查事项，在约定工作日内提出书面异议；
对间歇性离线、数据回传延迟等问题，设置观察期并约定日志留存周期；
收到异议后，渠道在约定时间内确认是否受理并补交证据；
超期不等于当然验收，涉及安全、数据完整性或隐蔽故障的事项应保留复查权。

具体天数应结合项目规模、驻场条件和采购制度确定，不宜只写“及时处理”。

升级沟通路径写到岗位而非个人

推荐路径为：现场工程师—渠道项目经理—ZKINTE 技术协调人员—采购方项目负责人—双方管理负责人。涉及熵基/ZKTeco 产品底层问题时，再按设备来源和售后规则提交厂家技术协查。

每次升级应携带同一工单编号、问题摘要、已完成测试、现有证据、待决策事项和下一节点。口头沟通后应补书面纪要，避免人员变更后重新争论。

旧系统改造的兼容边界

多品牌兼容不等于所有旧设备都能无条件接入。改造前应核对控制器协议、读卡格式、人员编号规则、照片质量、数据库字段、网络端口、时间同步及第三方系统开放能力。

如旧门禁不支持现有 SDK，可选择协议网关、中间数据库或分阶段替换；若 OA 无开放接口，可暂用审批结果导入，但要标明其非实时性。自主可控应落实到账号权限、日志掌握、数据备份和接口文档，而非仅看设备品牌。

产品选型、报价与资料交付怎么约定

熵基/ZKTeco 产品选型应依据通行介质、访客量、安装环境、活体检测需求和旧控制器兼容性确定。具体型号参数、接口能力及系统版本，以项目资料和厂家当前规格为准。

报价口径需区分设备、授权、SDK 对接、OA 对接、旧数据迁移、安装调试、二次进场和第三方改造。资料下载应由项目对接人员按实际型号提供，包括说明书、接口资料、安装要求和适用版本，不能用其他型号文档替代。

交付验收核对清单

设备型号、版本、授权与采购清单一致
访客登记、审批、授权、通行、回传逐段验证
SDK 与 OA 接口日志能够对应同一次测试
失败场景、断网恢复和重复授权经过核查
旧门禁及多品牌设备的兼容边界已有书面说明
现场变更具备审批记录和回退方案
证据目录、复核人员、异议时限已签字确认
售后责任按设备、软件、网络和第三方接口划分

风险与替代方案

直接在生产环境升级可能造成访客数据丢失、门禁权限中断或 OA 审批积压。优先在测试环境验证；不具备测试条件时，应先备份数据库和配置，并准备版本回退。无法确认责任归属时，可采用短期旁路日志采集或替换测试终端，先定位链路，再决定由哪一方承担整改。

FAQ

渠道只提供“现场已正常”的签字单，能否作为验收依据？

不能单独作为完整依据。还需结合版本信息、连续链路日志、测试记录和采购范围判断。

OA 显示审批成功但访客无法通行，先查哪一侧？

先按同一访客编号和时间戳核对 OA 回写、接口接收、权限下发及控制器执行记录，不应先入为主认定某一方责任。

旧设备没有日志功能怎么办？

可增加接口代理、网络抓包或独立日志采集，并安排可重复测试；涉及个人信息时必须脱敏并限制访问权限。

项目对接

ZKINTE（北京御佰安科技有限公司）可协助梳理熵基访客系统旧平台改造、证据规则、兼容核查与验收边界。

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