Profesional
Seiri | Control de asistencia
El colaborador marca con foto y ubicación desde obra o ruta. El registro se guarda en el teléfono y sube cuando hay red, con un marcaje diario por regla.
- Móvil
- Organización
- Kaizen Apps CR
- Rol
- Desarrollo
- Periodo
- 2026-05 — 2026-08
Stack
- React Native (Expo)
- TypeScript
- SQLite
- Next.js
- MySQL
- Render
Contexto
App de marcaje de asistencia para las empresas que usan los sistemas de Kaizen. El colaborador marca con foto y ubicación. El registro se guarda en el teléfono y sube cuando hay red, porque buena parte del trabajo ocurre en obra y en ruta.
Problema
Sin sistema, la entrada se anota en un cuaderno o la toma un encargado nombre por nombre. En centros con mucho personal esa fila consume tiempo productivo cada mañana, antes de que nadie llegue a su puesto.
El objetivo fue doble. Que marcar tome segundos y no requiera a nadie tomando nota, y que el registro resultante se sostenga solo.
Cada marca lleva su hora, su ubicación y su verificación de identidad. La nómina se calcula sobre datos que no dependen de que alguien los confirme después.
Decisiones técnicas
Sin conexión, dos dispositivos pueden marcar al mismo colaborador sin verse entre sí. Al reconectar, ambos envían una marca válida según lo que cada uno observó. El esquema anterior contaba las marcas del día y después insertaba, que son dos pasos sin garantía entre ellos.
La validación se movió dentro de una transacción InnoDB con aislamiento REPEATABLE READ, que bloquea las filas del día con SELECT ... FOR UPDATE antes de decidir.
Arquitectura
El teléfono escribe primero en SQLite y encola la marca. Una tarea en segundo plano vacía la cola contra el API cuando hay red. El token se guarda en el almacén seguro del sistema, con migración desde la ubicación que se usaba antes.
Las cuatro reglas que deciden si la marca entra se aplican en el servidor.
La transacción bloquea las marcas del día antes de decidir. Dos sincronizaciones simultáneas ya no pueden pasar ambas la validación, porque la segunda espera a que la primera termine.
La ventana del día se calcula en la zona horaria del país, no en la del proceso. El servidor corre en UTC, y sin esta regla una marca a las 23:30 locales contaría al día siguiente.
La marca que pierde no se descarta. Queda registrada y señalada para revisión manual, con su dispositivo y su hora, para que alguien pueda decidir cuál era la buena.
Si el servicio de reconocimiento no responde, la marca se acepta igual y queda anotada como no verificada. Un fallo de infraestructura no puede impedir que alguien registre su jornada.
Resultado
El colaborador marca en segundos, con foto y ubicación, sin nadie tomando nota y sin depender de la señal. La marca sube sola en cuanto hay red.
La fórmula de geocerca existe dos veces, en el servidor y en el cliente, porque el cliente tiene que evaluarla sin red. Hay una prueba cuyo único trabajo es fallar si las dos versiones dejan de coincidir.
Lo que aprendí
Contar las marcas del día en el cliente no impide un duplicado: cada dispositivo lleva su propio recuento y ninguno ve al otro mientras están sin red. En la transacción del servidor el conflicto sigue ocurriendo, pero se detecta y va a revisión en lugar de resolverse por orden de llegada.