El desafío

Muchas empresas no tenían ningún registro confiable de horarios. Las horas trabajadas se estimaban según el turno previsto o el recuerdo del encargado. Eso hacía imposible calcular la nómina sobre datos reales, y también impedía saber quién había trabajado efectivamente, cuánto tiempo permaneció en el puesto o si un turno había sido cubierto.

La salida clásica —un reloj de fichaje con tarjeta o un reloj biométrico de huella— resuelve la mitad del problema y crea otra: hay que comprar el equipo, instalarlo y mantenerlo, y el registro sigue viviendo separado de donde se liquidan los sueldos. Entre el control de asistencia y el recibo queda siempre una exportación, una planilla intermedia y una persona reconciliando.

La solución

La plataforma encadena seis piezas: una tablet en el ingreso de cada empresa, el reconocimiento facial que identifica al empleado, el evento de jornada que él mismo elige, un backend multi-tenant que recibe esa marca, un motor de liquidación que la convierte en dinero y un panel web por empresa. El dato entra una sola vez, en la tablet, y no vuelve a tocarse a mano hasta el recibo.

Visto desde el empleado, el recorrido son tres toques. Llega, se para frente a la tablet montada en el ingreso y la cámara lo reconoce: no escribe un legajo, no lleva tarjeta, no apoya el dedo en un lector. Con la identidad ya confirmada, la pantalla le ofrece los cuatro eventos posibles de la jornada —entrada, break in, break out y salida— y toca el que corresponde. La marca queda registrada con la hora exacta.

Separar la identificación del tipo de evento es lo que hace que el registro sirva de verdad. Un reloj que sólo marca «entró» obliga a inferir todo lo demás; acá el empleado declara qué está haciendo sobre una identidad que ya fue verificada por la cara, y eso cierra de raíz el fichaje por terceros. El dispositivo es fijo y compartido, así que el control de presentismo no depende de que cada persona tenga un teléfono, lo traiga cargado o tenga señal.

Del otro lado, cada empresa entra a su propio panel web y ve únicamente sus fichadas y sus empleados. Ahí el registro deja de ser una marca de asistencia y se convierte en dinero: la nómina vive en el mismo sistema, con el tipo de pago de cada persona ya cargado —por hora, por día u otras modalidades— y su valor correspondiente. La plataforma toma las horas efectivamente registradas, las cruza con el esquema de pago de ese empleado y calcula cuánto le corresponde cobrar.

Ese es el punto que separa esta plataforma de un sistema tradicional. En la mayoría de las implementaciones el reloj vive en un lado y la liquidación en otro. Acá el dato nace en la tablet y llega al cálculo sin pasar por ninguna mano.

Arquitectura de la plataforma

El frente de fichaje corre sobre React Native, de modo que la misma base de código sirve a la tablet del ingreso y a los clientes móviles. El panel web está construido en Next.js y la persistencia es MySQL. Detrás, la plataforma no es un bloque único: está separada en servicios independientes, empaquetados en contenedores Docker y publicados detrás de un balanceador de carga.

Esa separación no es una preferencia estética, la impone la forma de la demanda. El reconocimiento facial y el registro de una fichada tienen perfiles de carga opuestos: guardar una marca es una escritura mínima, mientras que comparar un rostro es trabajo de cómputo intensivo. Y las dos cosas ocurren al mismo tiempo, porque las trescientas empresas empiezan su turno dentro de la misma media hora. Con todo en un solo proceso, el pico de reconocimiento de las ocho de la mañana degrada al resto del sistema. Separado, el servicio de reconocimiento escala solo en su franja y vuelve a bajar, sin que el panel web ni el motor de nómina se enteren.

El reconocimiento ocurre del lado del servidor. La tablet captura la imagen y la envía; el servicio la compara y devuelve la identidad, y esa foto queda guardada asociada a la fichada como evidencia. Resolverlo en el servidor y no en el dispositivo tiene dos razones concretas. La primera es operativa: el modelo y los rostros dados de alta se actualizan en un solo lugar, sin depender de que trescientas tablets repartidas por el país estén en la versión correcta. La segunda es de disputa: cuando alguien reclama una fichada, la evidencia es una imagen guardada del lado del sistema y no un registro que vivía en el dispositivo del que se reclama.

Eso deja una pregunta abierta, y es la que la arquitectura contesta mejor: qué pasa cuando no hay red. La tablet puede seguir registrando fichadas aunque pierda conectividad. Las marcas quedan encoladas localmente y se sincronizan solas cuando vuelve la comunicación. No es una comodidad: el horario de ingreso es el pico de uso de todo el sistema, y una caída de diez minutos justo ahí sería, sin encolado local, la jornada de una empresa entera sin registrar. Con el registro retenido en el dispositivo, una falla de red se vuelve un retraso en la sincronización en vez de un agujero en la nómina.

El acceso es lo que ordena la convivencia de más de 300 empresas en un mismo sistema. Para usar la aplicación hay que iniciar sesión, y es el usuario autenticado —con sus permisos— el que determina sobre qué empresa está operando. Un usuario puede tener acceso a más de una y cambiar entre ellas; lo que nunca puede es ver una para la que no tiene permiso. Toda la información que devuelve la plataforma queda atada a esa selección, así que el aislamiento entre empresas no es una convención de la interfaz sino la condición de cada consulta.

Sobre ese aislamiento se apoya el tratamiento de la evidencia, que es el dato más sensible que guarda la plataforma. La imagen viaja cifrada, se almacena cifrada, queda atada a la fichada que la originó y sólo es visible desde el panel de la empresa a la que pertenece esa fichada, para los usuarios con permiso. El acceso a esa evidencia queda registrado, y la retención se define por política y no por acumulación indefinida.

Por último, la liquidación y la visibilidad corren a ritmos distintos, y es deliberado. Las fichadas se ven en las planillas del panel web apenas llegan: quien mira la jornada de hoy la tiene en el momento. El cálculo de sueldos, en cambio, se resuelve al cierre del período, cuando el conjunto de marcas ya está completo. Calcular una liquidación al vuelo sobre un período abierto es calcular sobre datos que todavía van a cambiar; separar la lectura inmediata del cálculo de cierre evita tener que recalcular y rectificar cada vez que entra una fichada tardía.

La implementación

La decisión estructural fue construirlo como una sola plataforma multi-tenant en vez de una instalación por cliente. Hoy hay más de 300 empresas conviviendo en el mismo sistema, cada una con sus empleados, sus tipos de pago y sus fichadas completamente aisladas del resto. La alternativa —una instancia por empresa— hubiera sido más simple de arrancar y absolutamente inviable a los dos años: trescientas bases de datos que actualizar, trescientos despliegues por cada corrección.

El costo de esa decisión se paga adelante y se cobra siempre. Cada consulta, cada reporte y cada pantalla tiene que estar atada a la empresa que la pide, y una filtración entre inquilinos no sería un bug más: sería la nómina de una empresa visible para otra. A cambio, sumar una empresa nueva es un alta y no un proyecto, y una mejora se despliega una vez y llega a las trescientas.

El desarrollo llevó dos años y hoy continúa con mantenimiento evolutivo y correctivo. Ese «continúa» no es un detalle administrativo: un sistema que calcula sueldos vive pegado a reglas que cambian, y la plataforma se sigue ajustando a medida que aparecen modalidades de pago y necesidades que no existían cuando se diseñó.