ZKTeco, BioTime y ADMS: diferencias antes de integrar asistencia

Separa las cuatro capas

El reloj captura una identificación y un evento local. El middleware, como ZKBio Time, administra dispositivos, personas, horarios y transacciones. ADMS puede ser una función de comunicación del equipo hacia un servidor, pero la FAQ de ZKTeco indica que depende del modelo y puede requerir una licencia pagada. PUSH es una familia o vía de integración que necesita su propio contrato; no significa que cualquier reloj hable con cualquier API.

La página oficial de ZKBio Time describe una plataforma web que conecta dispositivos push por Ethernet, Wi-Fi, GPRS, 3G o 4G y ofrece gestión de horarios y reportes. Esa descripción no garantiza que un reloj concreto, una instalación antigua de BioTime o una cuenta del cliente tenga la misma capacidad. Pide versión exacta, manual y alcance licenciado.

• Dispositivo: modelo, firmware, reloj y almacenamiento local.
• Transporte: ADMS, PUSH, LAN u otra vía documentada.
• Middleware: BioTime o ZKBio Time, edición, versión y permisos.
• API: endpoints, autenticación, paginación, límites y licencia.
• Destino: identidad de empleado, sede, zona horaria y estado de procesamiento.

Integra eventos, no una caja negra de horas

Una integración responsable recibe eventos originales, conserva hora del dispositivo y de recepción, identifica terminal y fuente, y deduplica usando el ID nativo o una clave documentada. No copies el cálculo de horas del middleware como si fuera el cálculo legal de StaffPass. Primero normaliza entrada, salida, pausa y eventos ambiguos; después compara con turnos y solicita una revisión cuando la transición no es segura.

Protege el límite entre sistemas. La credencial de API debe ser exclusiva, con permisos mínimos y revocación. Un empleado desconocido, un ID reutilizado o un evento fuera de orden queda en cuarentena; no crea una persona nueva ni modifica una planilla cerrada. Si el reloj estuvo desconectado, concilia el log del dispositivo con recibidos, aplicados y pendientes.

1. Inventaria modelo, serial, firmware, middleware y licencias sin poner secretos en el chat.
2. Obtén manuales y ejemplos oficiales de la combinación concreta.
3. Diseña un puerto de intercambio y un simulador con muestras identificadas como sintéticas.
4. Prueba paginación, reenvíos, cursor retrocedido, mala hora y desconexión.
5. Homologa con equipo real antes de mencionar el modelo como compatible.

Ejemplo hipotético: tres relojes, una empresa

Ejemplo hipotético: una empresa tiene un SpeedFace-V5L en recepción, un MB560-VL en bodega y un iClock680 en una sede antigua. El administrador supone que todos usan la misma ruta porque el proveedor menciona ADMS en sus fichas. Sin embargo, cada modelo tiene firmware, configuración y capacidad de licencia distintos.

El piloto registra el inventario, prueba primero el middleware existente y consulta si la API está habilitada. Los eventos llegan a una cola de cuarentena; un ID desconocido no crea empleado y un evento nocturno se revisa con la zona de la sede. El equipo no copia fotos o plantillas biométricas. Solo después de comparar logs reales, eventos recibidos y resultados de asistencia se decide si una combinación puede homologarse.

Checklist accionable

Completa una ficha por combinación de modelo, firmware y plataforma. «ZKTeco compatible» sin esa ficha es una descripción demasiado amplia para un contrato.

• El modelo y firmware fueron confirmados en el equipo real.
• Se conoce si ADMS/PUSH está habilitado, licenciado y documentado.
• La versión de BioTime o ZKBio Time y su API están identificadas.
• La cuenta de integración tiene permisos mínimos y secretos protegidos.
• Empleado, sede, terminal, zona y tipo de marca tienen mapeo versionado.
• Eventos duplicados, atrasados, offline y fuera de orden fueron probados.
• ID externo desconocido entra en cuarentena y no crea personas.
• No se importan fotos, huellas o plantillas faciales sin base y contrato.
• Se comparan logs del reloj con eventos aplicados y rechazados.
• El resultado se etiqueta como simulador, implementado o hardware homologado.

Cómo documentar la prueba con tu proveedor

Solicita una prueba con el reloj que ya tienes o con una unidad prestada por el distribuidor antes de renovar todos los equipos. Anota modelo, versión, conexión, cantidad de eventos y resultado esperado. Haz una entrada, una salida y una recuperación después de desconectar la red; compara los registros del dispositivo con el sistema de destino. El proveedor debe explicar cómo detecta duplicados y quién atiende los eventos pendientes cuando se restablece la conexión.

Conserva el acta de prueba junto con las licencias y el contacto de soporte. Si cambias el reloj, el firmware o el software de administración, consulta si debes repetir alguna comprobación. StaffPass no cuenta actualmente con un conector ZKTeco disponible: esta guía permite preparar preguntas para un proyecto futuro y para cualquier proveedor de asistencia. La compatibilidad de una marca no debe asumirse como compatibilidad de todos sus modelos, versiones o métodos de comunicación.