Gestor de reportes de campo
Capturas
Puntos clave
-
Reemplacé un flujo de tres pasos —formato por WhatsApp, captura manual por otra persona y evidencias aparte— por un formulario único donde el técnico registra el reporte y adjunta sus fotos, con los datos conocidos precargados.
-
Implementé autenticación con Supabase Auth y acceso por rol: cada técnico ve solo sus reportes y cada supervisor los de sus técnicos asignados. El supervisor revisa, corrige y aprueba; el sistema genera el PDF y exporta el historial a Excel.
-
Inventario de ONTs: el administrador las importa desde Excel con una vista previa de nuevas, existentes y repetidas; el supervisor las asigna a cada técnico, y un reporte solo acepta una ONT asignada a quien lo captura.
-
Hecho para trabajar en campo con mala señal: las fotos se comprimen en el teléfono antes de subirse, las peticiones se reintentan cuando falla la red y el formulario avisa antes de cerrarse si hay fotos sin guardar.
Problema
Cada reporte de instalación pasaba por tres pasos: el técnico llenaba un formato por WhatsApp, otra persona capturaba esos datos a mano y las fotos de evidencia se enviaban aparte. La misma información se escribía dos veces y las fotos quedaban separadas del reporte al que pertenecían.
Solución
El técnico captura el reporte desde el teléfono en cuatro secciones (información general, cliente, instalación y georreferencias) y sube las ocho fotos de evidencia que pide cada instalación. El servidor asigna el técnico, el supervisor y el equipo a partir de la sesión, y el campo de la ONT solo ofrece los equipos que ese técnico tiene asignados. Al enviarlo, el reporte pasa a revisión: el supervisor lo revisa, corrige lo necesario y lo aprueba, y en ese momento el sistema genera el PDF con los datos y las fotos. El historial se exporta a Excel por rango de fechas. Un administrador gestiona usuarios, equipos y el inventario de ONTs, que se importa desde Excel.
Decisiones técnicas
- Serví la API bajo /api del mismo dominio que el frontend, con una regla de rewrite en Render. Con frontend y API en dos subdominios de onrender.com, la cookie de sesión era de terceros y Safari la bloqueaba: el inicio de sesión fallaba en iPhone y funcionaba en Chrome de escritorio. El backend ahora se niega a arrancar si los dos orígenes no comparten sitio.
- El PDF se arma con un límite de 250 KB: primero se reducen las fotos generales y se conservan nítidas las de la ONT y el formato R20, que sirven para la verificación técnica. Al aprobar el reporte, las fotos se borran del almacenamiento y el PDF queda como registro; un trabajo semanal elimina los reportes aprobados con más de un año, según la regla de retención del negocio.
- El cliente nunca fija el estado, el técnico, el equipo ni la fecha de liquidación: los pone el servidor. Cada endpoint sensible aplica el filtro por rol y por recurso en la lectura y otra vez en la escritura, y las operaciones que pueden chocar (instalar o reasignar una ONT, aprobar o borrar un reporte) corren en funciones transaccionales de Postgres.
- Cada vulnerabilidad corregida tiene una prueba de regresión en pytest. La integración continua las ejecuta junto con pip-audit, npm audit y gitleaks.
Manejo de fallas
- Si falla la red, cada petición se reintenta dos veces antes de mostrar el error, y si la sesión expiró se renueva una vez y se repite la petición.
- Los botones de guardar y enviar se bloquean mientras la petición está en curso, para que un doble toque con señal lenta no cree un reporte duplicado. Si el borrador se guardó pero falló el envío a revisión, el reintento actualiza ese mismo borrador.
- Antes de pasar a revisión o de aprobarse, el servidor valida los campos obligatorios, las ocho fotos, las coordenadas y que la ONT pertenezca al técnico, y responde con la lista exacta de lo que falta.
- Generar el PDF y subir fotos tienen límite de concurrencia y de frecuencia; si el servidor está ocupado, responde con un mensaje claro para reintentar en lugar de quedarse colgado.
Mi rol
Lo desarrollé solo, de principio a fin: la API en FastAPI, el frontend en React y TypeScript, el modelo de datos y las migraciones en Supabase, la autenticación con Supabase Auth y el acceso por rol, la generación del PDF, la exportación a Excel y el despliegue en Render, con integración continua en GitHub Actions. Hoy le doy mantenimiento.
Resultado
- Lo usan cinco técnicos y un supervisor, y sigo dando mantenimiento.
- El técnico registra los datos y las fotos en un solo lugar; ya nadie vuelve a capturar el reporte a mano.
- Cada reporte aprobado queda como un PDF con sus datos y sus ocho fotos, listo para descargar desde el panel del supervisor.
Código privado por confidencialidad con los clientes; capturas, arquitectura y demostración disponibles a solicitud.