Caso · operación en campo

Las horas hombre de cada técnico, en cada embarcación

Una empresa de servicios manda técnicos a dar soporte a las embarcaciones de sus clientes y cobra por horas hombre. Antes esas horas salían de lo que cada técnico anotaba. Ahora cada embarcación lleva pegado un código QR: el técnico lo escanea con su teléfono al subir y al bajar, y quedan la hora y la posición. Para marcar tiene que estar en el barco. De esas marcas salen solas las horas de cada técnico en cada embarcación, para cobrarle al cliente y pagarle al personal, y la oficina ve en un mapa quién está a bordo ahora mismo.

Qué enseña el mapa

El mapa solo pinta las asistencias abiertas, las que tienen entrada y todavía no tienen salida. Así enseña lo que está pasando ahora y no se llena con jornadas ya cerradas.

Panel con un mapa de la costa peruana y, debajo, la lista de técnicos a bordo con su embarcación y la hora de entrada
  1. Solo aparece quien entró y todavía no salió.
  2. Quién, desde qué hora, en qué embarcación y para qué empresa.
  3. Cada fila centra el mapa en su posición.
  4. Leaflet sobre teselas abiertas.
El panel de control: el mapa con quien está embarcado en este momento y, debajo, la tabla con su embarcación, la empresa y la hora de entrada. Cada fila lleva un botón para centrar el mapa en esa posición.
Reporte de horas hombre por técnico y embarcación
  1. Quien sigue a bordo todavía no tiene hora de salida.
  2. Entrada y salida, marcadas con la posición del teléfono.
  3. Las horas se calculan con las marcas; nadie las escribe.
  4. A PDF o a Excel, para quien factura.
Horas hombre por técnico y por embarcación. Es la cifra que se lleva quien factura, y sale de las marcas de entrada y salida sin que nadie la escriba a mano.
Listado de órdenes de trabajo con su estado
  1. Cada orden con su código: el trabajo en campo se cierra contra ella.
  2. El primer y el último abordaje de la orden.
  3. Su responsable (aquí, todavía nadie).
  4. Y su estado: pendiente o en progreso.
Las órdenes de trabajo y su estado. El trabajo en campo se cierra contra una orden; si no, las horas no cuadran con nada.

Permisos por recurso, porque no todos ven lo mismo

Un técnico, un supervisor y quien factura necesitan pantallas distintas del mismo sistema. Los permisos se dan por recurso y se agrupan en roles, y el enrutador del frontend respeta esa misma lista: si no tienes el permiso, la pantalla no existe para ti.

Cómo está construido

API en Node con Express y Prisma sobre MySQL, frontend en React compilado con Vite y el mapa con Leaflet sobre teselas abiertas. Todo en contenedores.

Lo que salió al levantarlo fuera de la red del cliente

Estas capturas salen de una copia levantada entera fuera de la infraestructura del cliente, con datos inventados. Por el camino aparecieron tres cosas:

  1. La lista de orígenes permitidos estaba escrita en el código, con los dominios del cliente. Desde cualquier otro sitio, el sistema responde con un error del servidor que no dice lo que pasa. Eso pertenece a una variable de entorno.
  2. Un permiso maestro que abre todas las rutas es cómodo mientras se desarrolla y es justo lo que hay que revisar antes de repartir roles reales.
  3. El servidor de desarrollo no es el de producción. Compilar y servir con nginx, como en el servidor real, quita una clase entera de sorpresas.

¿Tienes gente trabajando donde no llega la oficina?

Partes de trabajo, asistencia con posición, órdenes que se cierran en campo y una cifra fiable al final del mes. Eso se puede tener sin perseguir a nadie por WhatsApp.

Hablemos →