Antes de una demostración, se puede leer exactamente qué hace el sistema.

Resumen ejecutivo

Maptainer es una plataforma GMAO con GIS nativo: el mapa no es una vista añadida sobre un gestor de mantenimiento, sino la estructura sobre la que se apoyan el inventario de activos, la creación de órdenes de trabajo, la planificación de rutas, el seguimiento del trabajo en campo y la analítica.

Cubre el ciclo completo de mantenimiento de infraestructuras distribuidas geográficamente: inventario georreferenciado del patrimonio → detección de incidencias → creación y planificación de órdenes de trabajo → asignación por competencias y cercanía real por carretera → ejecución en campo con app móvil offline → consumo de materiales y coste → cierre, validación y analítica.

Modelo de despliegue. Multi-tenant: cada organización (empresa mantenedora, operador de activos, gestor de red) opera en un entorno aislado con su propia jerarquía de clientes, activos, personal, inventario y configuración. Un superadministrador global gestiona las organizaciones y mantiene catálogos sectoriales («verticales») que se clonan al dar de alta una organización nueva.

Cuatro superficies de uso:

Infraestructura de cálculo propia. A diferencia de un GMAO que consume servicios de mapas de terceros, Maptainer aloja su propia infraestructura geoespacial: servicio de mapas con caché, cálculo de rutas por carretera, optimización de rutas con varios vehículos, mapa base propio y cartografía offline, incluida la ortofoto oficial del PNOA/IGN. El aislamiento entre organizaciones se aplica también en la propia base de datos.

Modularidad comercial y complejidad parametrizable. Existe un catálogo explícito de módulos contratables, diez capacidades organizativas que la propia organización activa sin coste, niveles de detalle que gradúan el rigor dentro de cada proceso, tres perfiles de arranque que lo configuran todo de un clic, y un sistema de permisos granular resuelto en cuatro capas, con roles propios de cada organización. La interfaz, los correos, los PDF y los manuales están en castellano e inglés, y cada organización trabaja en su moneda. La misma instalación se presenta como un producto de pocas pantallas a una ingeniería de seis personas y como una plataforma completa a un operador con delegaciones.

1. Autenticación, usuarios y permisos

Disponibilidad: núcleo, siempre activo Superficies: Web · Móvil · Portal cliente · API pública Para qué sirve: garantiza que cada persona ve exactamente lo que su organización ha contratado y su rol le permite, con tres sistemas de identidad separados (empleado, cliente final y máquina) que no se contaminan entre sí.

1.1 Tres sistemas de identidad independientes

La plataforma distingue tres tipos de identidad, cada uno con su propio registro de credenciales, su propio flujo de login y su propio ciclo de vida de sesión:

• Usuario interno — empleado de la organización. Accede a la web de gestión y a la app móvil.
• Usuario del portal — persona del cliente final. Solo accede al portal de cliente, desde el navegador. Credenciales completamente separadas.
• Clave de API — identidad de máquina para la API pública. Sin usuario asociado.

La separación se impone en el servidor, no solo en la interfaz: el acceso interno (web, móvil, ficheros y cartografía) rechaza las sesiones del portal aunque sean válidas, y un usuario del portal no puede darse de alta con el correo de un usuario interno.

1.2 Inicio de sesión web

Login con email y contraseña. El correo de acceso se compara sin distinguir mayúsculas: «Juan.Perez@…» y «juan.perez@…» son la misma cuenta.

• Duración de la sesión: sin «recordarme», la sesión caduca tras 90 minutos sin actividad, no a los 90 minutos de entrar. Solo la renueva la actividad real del usuario —teclado, ratón, toques—, no los refrescos automáticos de fondo. Con «recordarme» dura 30 días.
• Sesión única por superficie: si la misma cuenta inicia sesión en otro navegador, la sesión anterior se invalida con el mensaje explícito «tu sesión ha expirado porque se ha iniciado sesión en otro dispositivo». Las sesiones web y móvil se controlan por separado: entrar en el móvil no expulsa de la web ni al revés. La misma regla rige para la descarga de ficheros y de cartografía, de modo que una sesión revocada deja de servir en todas partes a la vez.
• Bloqueo temporal por intentos fallidos, no desactivación. Los fallos seguidos bloquean la cuenta durante un tiempo creciente (de un minuto a media hora), con límites adicionales por dirección de origen, y una ráfaga de intentos simultáneos no consigue más intentos que el máximo. El bloqueo se levanta solo; el administrador puede además consultar y desbloquear las cuentas bloqueadas. Al bloquearse una cuenta, su titular recibe un aviso por correo.
• Respuesta uniforme: unas credenciales incorrectas reciben el mismo mensaje exista o no el correo, y un bloqueo indica cuánto dura. Que la cuenta está desactivada solo se le dice a quien ha acertado la contraseña.
• Dispositivo de confianza: el navegador o la instalación de la app desde la que ya se ha entrado correctamente queda marcada durante 180 días, y desde ella se puede seguir entrando aunque un tercero haya provocado el bloqueo de la cuenta desde fuera.
• Organización operativa: si la organización está dada de baja o su suscripción ha vencido, el login lo explica (ver A.5).
• Cierre de sesión real: cerrar sesión anula la sesión en el servidor, no solo en el navegador.
• El rol, los permisos y el idioma que usa la interfaz se resuelven siempre en el servidor; nada de eso viaja en datos que el navegador pueda modificar.

Los mismos controles de intentos se aplican al cambio de contraseña (1.10) y al acceso del portal de cliente.

1.3 Inicio de sesión móvil

Flujo propio de la app, independiente del web: la sesión queda guardada de forma segura en el dispositivo, pensada para que un técnico en campo no tenga que volver a identificarse cada jornada. No caduca mientras se use, pero caduca a los 60 días sin usarse, de modo que un teléfono perdido no sigue sincronizando indefinidamente.

La sesión móvil se cierra:

• desde la propia app, con un cierre de sesión que la anula también en el servidor;
• desde el perfil web del usuario (1.11), por ejemplo tras perder el teléfono;
• al cambiar o restablecer la contraseña;
• al desactivar la cuenta o suprimirla (1.5).

La respuesta del login trae ya resuelto todo lo que la app necesita para decidir qué pantallas monta: permisos, módulos contratados, capacidades organizativas, niveles de detalle, vocabulario e idioma (capítulo 2).

Ficha de personal obligatoria. Un usuario sin ficha de personal vinculada no puede entrar en la app, y recibe un mensaje que pide al administrador la vinculación. Vale también para administradores: la app trabaja siempre sobre la ficha.

Existe además una verificación ligera de sesión para que la app compruebe si sigue conectada sin descargar datos, útil al recuperar cobertura.

1.4 Recuperación de contraseña

Flujo de «he olvidado mi contraseña» con envío de enlace por correo, que caduca a la hora. Disponible tanto para usuarios internos como para usuarios del portal, con flujos separados.

• La solicitud responde siempre el mismo mensaje, exista o no el correo. Si la cuenta está desactivada, se le envía un correo explicándolo; si está pendiente de activación (1.5), un enlace de activación nuevo.
• Las solicitudes tienen límite por cuenta y por origen, para que no se pueda inundar el buzón de nadie.
• La nueva contraseña debe cumplir la política común (1.10), y una contraseña rechazada no gasta el enlace.
• Restablecer la contraseña cierra todas las sesiones de la cuenta, web y móvil.
• Los enlaces enviados dejan de valer cuando la cuenta se bloquea a mano, cuando cambia su correo de acceso y cuando se cambia la contraseña.

1.5 Alta, activación y baja de usuarios

Crear, modificar y suprimir cuentas es cosa del administrador de la organización o del superadministrador. Un administrador no puede crear ni gestionar cuentas de superadministrador.

Al crear un usuario se genera un enlace de activación válido durante 24 horas. La cuenta no es operativa hasta que el usuario abre el enlace, elige su contraseña —que debe cumplir la política común (1.10)— y acepta la política de privacidad y el aviso legal. La aceptación queda registrada (documento, versión, fecha, origen y navegador) y no se puede alterar. El mismo requisito se aplica a los usuarios del portal.

• La cuenta puede crearse desde Usuarios o desde la ficha de Personal al darle acceso a la aplicación; en los dos casos lo decide un administrador (ver 1.9).
• Una cuenta sin activar se distingue de una desactivada: la ficha de personal la muestra como «Pendiente de activación» y ofrece «Reenviar activación», que genera un enlace nuevo y anula el anterior.
• Desactivar una cuenta cierra en el acto sus sesiones web y móvil.
• Siempre queda un administrador: un cambio que dejaría a la organización sin ningún administrador activo se rechaza, pidiendo nombrar antes a otro.
• Cada alta cuenta contra el límite de usuarios de la suscripción (ver A.4).
• El listado completo de usuarios solo lo ve el administrador; el resto recibe únicamente lo necesario para elegir a un compañero en un desplegable.

Eliminar un usuario es suprimirlo (RGPD, art. 17). La cuenta no se borra físicamente: se anonimiza, de modo que las órdenes de trabajo, comentarios e historiales en los que aparece siguen cuadrando sin nada que identifique a la persona. Es irreversible, nadie puede suprimirse a sí mismo y la cuenta suprimida deja de contar para el límite de usuarios. El administrador puede descargar antes los datos personales del usuario (capítulo 25).

1.6 Roles

Los roles son de cada organización: cambiar los permisos de un rol en una organización no afecta a ninguna otra.

• Seis roles de sistema: el superadministrador, que es el único global, y cinco que tiene cada organización: administrador, supervisor, técnico, almacén y solo lectura. Se crean automáticamente al dar de alta la organización, con sus permisos por defecto (ver A.3).
• El superadministrador y el administrador conceden todo dentro de su ámbito y no admiten edición de permisos. Los permisos de los otros tres roles de sistema sí los ajusta cada organización.
• Los roles de sistema no se pueden eliminar.
• Cada organización puede crear roles propios, partiendo en blanco o copiando los permisos de otro rol.
• Un rol propio con usuarios no se puede eliminar: el sistema dice qué usuarios lo tienen, para cambiárselo antes.
• Un usuario solo puede tener un rol de su propia organización.

1.7 Catálogo de permisos

Los permisos se agrupan por área funcional. Cada uno concede una acción concreta sobre un área:

Algunas separaciones relevantes:

• La configuración de medida (plantillas de puntos de medida y reglas) se separa del trabajo diario con lecturas: un técnico que toma lecturas no cambia la configuración que llega a los móviles de todos.
• Resolver solicitudes de cambio de activos se separa de editarlos. Nadie resuelve las suyas propias, salvo el administrador.
• Dentro de los informes, lo económico (importes en el panel, en la orden, en los informes y el inventario valorado) y el seguimiento de personas (flota, geovalla y utilización por persona) se separan de las cifras operativas.
• Los permisos de avisos no abren pantallas: deciden qué avisos generales llegan a la campana de cada usuario (capítulo 24). El de conflictos de sincronización da además acceso a su pantalla de revisión. Los avisos dirigidos a una persona concreta no dependen de ellos.

Algunas operaciones exigen un permiso más alto que el de su pantalla: configurar el catálogo de trabajo (tipos de tarea, tareas, plantillas de formulario y tipos de incidencia) exige editar la configuración; las programaciones que borran órdenes ya generadas, permiso de eliminar; la tarifa, el domicilio, las notas y el motivo de las ausencias del personal, permiso de edición de personal.

Cada rol de sistema trae un conjunto de permisos por defecto (A.3): un técnico ve y edita sus órdenes de trabajo (1.13), da partes rápidos y crea incidencias desde la app, pero no las cierra y no ve el panel ni los informes; un supervisor añade el cierre de órdenes, la configuración de activos y de medida, la aprobación de cambios, los informes con exportación, costes y seguimiento, y todos los avisos; el rol de almacén gestiona el inventario completo y recibe los avisos de stock; el de solo lectura únicamente consulta.

1.8 Resolución de permisos en cuatro capas

Toda comprobación de acceso atraviesa cuatro capas, en este orden:

1. Módulo contratado. Si el módulo que gobierna el permiso no está activo en la organización, se deniega siempre. Una organización sin módulo de flota nunca verá vehículos, aunque el rol de la persona incluya el permiso de ver flota.
2. Rol con acceso total. El superadministrador concede todo; el administrador concede todo dentro de su organización, una vez superada la capa anterior.
3. Excepciones por usuario. Cada usuario puede tener excepciones explícitas que conceden o retiran un permiso concreto sin cambiar su rol. Sirve para el caso real de «este técnico sí puede cerrar órdenes» sin crear un rol nuevo. Solo las gestiona un administrador.
4. Permisos del rol. El permiso debe estar en el conjunto de permisos del rol, y el rol debe pertenecer a la organización del usuario.

Dos decisiones de diseño relevantes: un permiso desconocido deniega a todos, el superadministrador incluido, y un módulo desconocido también deniega. Un error de escritura no puede convertirse en una pantalla ni en un servicio sin protección.

Por debajo de estas capas, que deciden qué puede hacer una persona, la base de datos impone de qué organización son los datos que ve cada operación (2.14): aunque una consulta olvidara filtrar por organización, no devolvería datos de otra.

Los recursos compartidos por toda la plataforma (el SLA global, los catálogos de verticales o la biblioteca de iconos) solo los modifica el superadministrador. Algunas funciones de la organización se reservan al administrador: usuarios, auditoría (1.12), claves de API y copia completa de datos, conexiones remotas, webhooks y reglas de escalado de avisos.

La interfaz replica la misma lógica para decidir qué se muestra, pero la autorización real se aplica siempre en el servidor. El menú y las funciones asociadas a un módulo o a una capacidad apagada se omiten, de modo que no queden funciones colgando.

1.9 Vinculación usuario ↔ personal

Un usuario puede estar ligado a una ficha de personal. Esa relación es la que permite que un técnico con login vea sus propias asignaciones en el móvil y en la web (1.13), que se registre su posición GPS y que se le impute coste horario. Existe también personal sin usuario: operarios que aparecen en las asignaciones y en la planificación pero no acceden a la aplicación.

• La ficha es requisito para entrar en la app móvil (1.3).
• Dar acceso a la aplicación desde la ficha de personal, o cambiar desde ella el rol, las excepciones, el correo de acceso o la activación del usuario vinculado, es gestionar usuarios y solo lo puede hacer un administrador. Esos cambios quedan en la auditoría.

1.10 Política de contraseñas

Una sola regla para todos los caminos en los que alguien elige su contraseña: cambio desde el perfil, restablecimiento por correo, activación de la cuenta, alta en el portal y restablecimiento del portal.

• Entre 10 y 128 caracteres.
• No puede repetir casi siempre el mismo carácter.
• No puede figurar en una lista de contraseñas filtradas conocida.
• No puede ser una palabra obvia (el nombre del producto, «contraseña», un mes…) rodeada de números o símbolos.
• No puede contener la parte local del correo del propio usuario.

No hay reglas de composición (mayúscula, número, símbolo), siguiendo la recomendación de NIST SP 800-63B: la longitud y la lista de filtradas hacen el trabajo. Las pantallas de activación, restablecimiento y perfil marcan cada regla mientras se escribe, con la misma comprobación que se aplica al guardar.

El cambio de contraseña desde el perfil exige la contraseña actual, tiene su propio límite de intentos, cierra la sesión de la app móvil y mantiene abierta la sesión del navegador desde el que se cambia; cualquier otra copia de la sesión anterior deja de valer.

1.11 Página de perfil

Cada usuario interno tiene una página Perfil propia, accesible desde el menú de usuario:

1.12 Registro de auditoría

Las acciones sensibles quedan registradas, para poder reconstruir quién hizo qué ante un incidente:

• Accesos: logins correctos, fallidos y bloqueados en la web, la app y el portal.
• Sesión y credenciales: cierre de sesión, cambio, solicitud y restablecimiento de contraseña, activación de cuenta y cierre de la sesión móvil.
• Cuentas y roles: altas, cambios (con el antes y el después de rol, estado y excepciones), supresiones, desbloqueos y reenvíos de activación de usuarios internos y del portal; creación y borrado de roles y permisos concedidos o retirados.
• Configuración y estructura: cambios de la configuración general, perfil aplicado, horario de la empresa, delegaciones y ciclo de vida de los clientes.
• Datos personales: exportaciones y supresiones (capítulo 25).
• Integraciones: claves de API, copias completas de datos, conexiones remotas y webhooks.
• Operación: decisiones sobre solicitudes de cambio de activos, facturabilidad y conformidad del cliente, correcciones de fechas reales, avisos atendidos y escalados, conflictos de sincronización resueltos y revisiones de geovalla.

Garantías: el registro nunca hace fallar la operación que registra, se conserva aunque la operación se deshaga, no guarda secretos y no se puede modificar ni borrar desde la aplicación. La retención por defecto es de un año y nunca inferior a 90 días.

Pantalla de consulta. El administrador de la organización la abre en Administración → Auditoría: lista paginada con filtros por tipo, acción, persona, resultado y fechas; detalle de cada entrada con los cambios como antes → después; e historial de un objeto concreto. Siempre acotada a su organización. Cuando quien actúa es el soporte de la plataforma, la organización lo ve como «Soporte de la plataforma».

1.13 Alcance de las órdenes de trabajo del técnico

Los permisos deciden qué acciones puede hacer alguien; el alcance decide sobre qué órdenes de trabajo. En la web se aplica el mismo criterio que en la app móvil:

• Quien edita órdenes sin poder cerrarlas (el caso del rol Técnico) solo ve y modifica las órdenes de trabajo en las que figura su ficha de personal: listado, tablero, ficha, pulso del día, mapa, cronograma, buscador y selección múltiple. Una orden ajena responde como si no existiera.
• Quien solo consulta (Solo lectura, Almacén) las ve todas.
• El administrador y quien puede cerrar órdenes ven todas.

En el historial de un activo, el técnico ve todas sus intervenciones, pero las de otros aparecen como «De otro técnico», sin descripción y sin poder abrirlas.

Por la misma razón el rol Técnico de partida no ve el panel de control ni los informes, que dan cifras de toda la empresa. El administrador puede devolverle ese permiso.

2. Multi-tenant, verticales y suscripción

Disponibilidad: núcleo Superficies: Web (panel de administración global y configuración de la organización) Para qué sirve: permite operar una sola instalación para muchas organizaciones distintas, con datos completamente aislados y con catálogos sectoriales preconfigurados que reducen el alta de un cliente nuevo de semanas a minutos.

2.1 La organización

Unidad raíz de aislamiento. Todas las entidades del sistema cuelgan de una organización, y la base de datos impone ese aislamiento por debajo de la aplicación (2.14). Cada una guarda:

• Datos fiscales y de identidad: nombre comercial, razón social, CIF, dirección completa, logotipo.
• Estado (de alta o de baja) y fecha de validez de la suscripción, que se comprueban al iniciar sesión (A.5 y 2.16).
• Módulos contratados: mantenimiento, gestión de clientes (que incluye el portal), SLA, lecturas de contador y los módulos de flota, campo en tiempo real y planificación (2.2).
• Límites de suscripción: usuarios, clientes y usuarios de portal por cliente (A.4).
• Configuración de trabajo: formatos de fecha y hora, idioma por defecto y moneda, horizonte de planificación, capacidades organizativas, niveles de detalle y perfil, y los ajustes de geovalla, SLA y objetivos del panel.
• Vertical asociado.

Lo que es relación comercial —módulos, límites, vigencia y vertical— lo gestiona el proveedor.

2.2 Catálogo de módulos contratables

Tres módulos, deliberadamente pocos:

Además, siete áreas están siempre activas como núcleo del sistema: activos, personal, delegaciones, informes, configuración, sectores y avisos. Que un área sea de núcleo no impide que la propia organización la oculte con su capacidad organizativa (2.3), como ocurre con delegaciones y sectores.

Gestión de clientes se contrata como un módulo propio, que incluye el portal de cliente, más el número de clientes. Sin él, la organización tiene un único cliente, el propio (3.2). Retirarlo a una organización que tenía clientes no borra nada: los suspende (3.2).

2.3 Capacidades organizativas

A diferencia de los módulos, no se contratan: las declara el propio administrador de la organización en la configuración general, porque describen cómo trabaja esa empresa, no qué ha contratado. Son gratuitas por decisión de producto: nadie debe pagar por simplificarse, ni toparse con un muro comercial al crecer.

Lo que no se ha declarado se considera activo, para no alterar el comportamiento de las organizaciones que nunca han tocado su configuración: un fallo de lectura nunca recorta funcionalidad, degrada hacia lo completo.

Una capacidad apagada se aplica en tres capas: el servidor cierra todas sus funciones, el menú y los botones se ocultan, y la interfaz ni siquiera carga sus pantallas.

2.4 Niveles de detalle

Las capacidades responden a «¿usas esto?». Los niveles de detalle responden a algo distinto: cuánto rigor quieres dentro de un proceso que sí usas. Nadie renuncia a las órdenes de trabajo, pero pocas empresas necesitan distinguir «el técnico ha terminado» de «el supervisor lo ha revisado» de «está cerrado y es facturable».

El valor por defecto de todos ellos es el más completo, por el mismo motivo que en las capacidades.

2.5 Perfiles de arranque

Dar de alta una empresa no puede consistir en decidir quince cosas antes de haber visto el producto. Un perfil escribe de una vez las capacidades organizativas y los niveles de detalle.

Tres propiedades deliberadas:

• El perfil es un punto de partida, no un candado. Cualquier capacidad se mueve después.
• Los perfiles son crecientes: Esencial ⊆ Profesional ⊆ Avanzado. Subir de perfil no quita nunca nada.
• Ningún perfil exige más de lo necesario. Los perfiles solo relajan la disciplina de datos; lo que es obligatorio para todos —el tipo de mantenimiento— no lo puede relajar ningún perfil.

Apagar una capacidad no borra nada. El stock registrado sigue donde estaba y reaparece al reactivarla; la interfaz lo advierte antes de confirmar.

2.6 Verticales

Un vertical es un sector de negocio (agua y saneamiento, alumbrado, instalaciones…) con nombre y descripción multilingües. Sobre cada vertical se mantiene un catálogo completo:

• Familias de activos (jerárquicas).
• Tipos de activo, con su jerarquía de composición, si son medibles y sus puntos de medida.
• Propiedades de tipo de activo.
• Estilos cartográficos.
• Tipos de mantenimiento, con firma obligatoria y duración estimada, y sus tareas.
• Plantillas de formularios, con secciones (también repetibles), campos y asignaciones.

Verticales de partida. La plataforma trae siete verticales completos: Agua y saneamiento, Alumbrado público, Parque eólico, Planta fotovoltaica, Instalaciones y parques empresariales, Riego inteligente y Señalización vial.

Un vertical en uso no se borra: se desactiva y deja de ofrecerse en el alta.

2.7 Clonado de vertical a organización

Al asignar un vertical a una organización, toda esa estructura se copia a su catálogo propio, respetando el orden de dependencias. A partir de ese momento la organización es dueña de su copia y puede modificarla libremente sin afectar al catálogo global ni a otras organizaciones.

Es el mecanismo que permite dar de alta una organización nueva con su tipología completa de activos, sus formularios de inspección y su simbología ya cargados.

2.8 Configuración general de la organización

Pantalla propia donde el administrador define:

• Días y horario de trabajo: un horario semanal con hasta dos franjas por día, que pueden ser nocturnas. Es el horario de la empresa; cada delegación puede heredarlo o tener uno propio (3.5). Es también la jornada de quien no tiene turno asignado (capítulo 9), y guardarlo recalcula los plazos del SLA.
• Formato de fecha y hora, idioma por defecto y moneda (2.15). El formato elegido se aplica a la web, los PDF, los informes programados, los correos y las hojas de cálculo de las copias.
• Horizonte de planificación: días a planificar y días de antelación con que se crean las órdenes.
• Cómo trabaja tu empresa — la sección que gobierna la complejidad, solo para el administrador, con tres bloques: sugerencias de activación (2.10), arriba del todo y solo si hay algo que sugerir; perfil de arranque (2.5), como tarjetas con la frase en la que la empresa se reconoce; y «Ajustar en detalle», plegado, con los diez interruptores y la consecuencia de apagar cada uno.
• Geovalla de órdenes de trabajo, con el módulo de campo en tiempo real (capítulo 15).
• Objetivos del panel de control: los umbrales que colorean cada indicador (capítulo 20).
• Módulos contratados, en solo lectura.
• SLA, si la organización lo tiene: plazos, correspondencia con la prioridad, umbral de «en riesgo» y objetivos (capítulo 19).
• Tipo de lecturas, con el módulo de contadores.

La zona horaria no se configura aquí: la determina la delegación principal (2.13). Los cambios quedan en la auditoría.

2.9 Alta de una organización en cuatro preguntas

Quien da de alta a un cliente no sabe todavía si necesita «capacidades organizativas»: sabe cuánta gente tiene y qué mantiene. Existe un alta guiada por cuatro preguntas:

Una vista previa devuelve en lenguaje de negocio lo que va a quedar configurado, legible en voz alta al cliente antes de confirmar. La respuesta sobre el almacén gana al perfil: alguien de tres personas puede tener nave, y alguien de treinta puede no tenerla. Una respuesta ausente cae en el valor más conservador.

2.10 Sugerencias de activación progresiva

Lo apagado no se presenta como «no lo tienes» sino como «todavía no lo necesitas», y el sistema lo propone cuando los datos de la propia organización ya justifican la necesidad:

Solo se evalúa lo que está apagado, cada sugerencia cita su evidencia y su recuento («en 14 de tus órdenes has apuntado materiales a mano»), las gratuitas y la de flota van en listas separadas, y solo se miran los últimos 180 días.

2.11 Vocabulario del producto

«Orden de trabajo» es el término correcto del sector y es exactamente lo que hace que una empresa de cuatro personas sienta que el programa no habla su idioma.

En perfil Esencial se sustituyen las etiquetas visibles: Orden de trabajo → Trabajo, Incidencia → Aviso, Tipo de mantenimiento → Tipo de trabajo, Personal → Equipo, Responsable → Quién lo hace, Fecha planificada → Para cuándo. En los demás perfiles se conserva el vocabulario del sector.

Solo cambia lo que se ve escrito en pantalla: la API y los datos exportados conservan siempre los mismos nombres. Hoy se aplica en las pestañas del panel operativo, la barra superior, el menú de administración y el informe de la orden de trabajo; el resto de pantallas mantiene el vocabulario del sector.

2.12 Lo que se crea al dar de alta una organización

El alta deja siempre creado lo mínimo para trabajar desde el primer minuto:

• Sus cinco roles de sistema con sus permisos por defecto (1.6).
• Su horario laboral semanal por defecto (2.8).
• Una delegación principal, aunque la empresa no trabaje con delegaciones: es la sede implícita y la que fija su zona horaria (2.13).
• Su cliente propio (3.2).
• El catálogo de sistema que usan los partes rápidos de la app.
• El catálogo del vertical (2.7), si se indica uno.

2.13 Zona horaria de la organización

Los instantes se guardan en tiempo universal y se leen en hora local con la zona de cada entidad. La zona de la organización es la de su delegación principal; con una delegación en Madrid y otra en Canarias, la organización se lee en la hora de Madrid si la principal es la de Madrid.

• Cada orden de trabajo se lee con la zona de su delegación; si no la tiene, la de su primer operario, y si no, la de la organización.
• Cada persona puede tener zona propia; si no, hereda la de su delegación. Así, las ausencias y la capacidad de una persona de Madrid no se calculan en la hora de Canarias.
• Cada usuario de la web escribe y lee las horas en la zona de su delegación.

Esa misma regla la usan los días laborables, los vencimientos del día, los plazos del SLA y los informes.

2.14 Aislamiento por organización en la base de datos

Además de los filtros por organización que aplica la aplicación en cada consulta, la base de datos impone el aislamiento por su cuenta, con seguridad a nivel de fila en modo estricto:

• Cada operación declara de qué organización es, y todas las tablas con datos de una organización solo dejan ver y escribir las filas de esa organización.
• Sin organización declarada no se ve nada. Los procesos programados trabajan organización a organización.
• El superadministrador, al actuar sobre una organización concreta, trabaja dentro de ella.

La consecuencia es que un olvido en una consulta de la aplicación no puede devolver datos de otra organización: la base de datos los oculta igualmente. Hay pruebas automáticas que fallan si una tabla nueva queda sin esta protección.

2.15 Idiomas y moneda

La aplicación está traducida al castellano y al inglés.

• Idioma de cada persona. La empresa fija un idioma por defecto; cada usuario puede elegir otro en su perfil. La pantalla de acceso y el portal tienen su propio selector, y la app móvil usa el idioma del dispositivo.
• Qué se traduce. Las pantallas de la web y del portal, los mensajes de error, los avisos de la campana (que se leen en el idioma de quien los mira), los nombres de catálogo, los PDF, los informes programados y los correos, que van en el idioma del destinatario.
• Formatos. El formato de fecha y hora de la empresa y los separadores decimales del idioma del usuario se aplican en toda la web.
• Moneda. Cada organización elige la moneda en que se muestran sus importes: euro, libra, dólar estadounidense y canadiense, franco suizo y las principales monedas latinoamericanas. Es solo de presentación: no se convierte ningún importe.

Algunas notas automáticas de historial o de stock se guardan en castellano sea cual sea el idioma de la empresa.

2.16 Ciclo de vida de la organización: baja y eliminación

Una organización pasa por tres estados: de alta → de baja → eliminada, y cada paso es una acción propia del proveedor.

Dar de baja pide un motivo y avisa por correo a los administradores de la organización. Desde ese momento nadie entra —web, app, portal ni API— y los procesos programados la saltan. Nada se borra: reactivarla devuelve la organización tal como estaba.

Eliminar borra todo rastro de la organización: datos, ficheros subidos y cachés. Solo es posible para organizaciones de baja desde hace al menos 7 días, con confirmación expresa, y antes se puede descargar una copia completa con sus ficheros. La eliminación es un proceso por fases que se reanuda si se interrumpe, termina verificando que no queda ningún dato de la organización y emite un justificante en PDF.

2.17 Ayuda y manuales de usuario

El menú de usuario tiene una entrada «Ayuda» que abre los manuales de usuario: veintiuno, uno por área de la aplicación (primeros pasos, mapa, activos, capas, órdenes de trabajo, preventivo, incidencias, planificación, personal, calendario laboral, delegaciones y sectores, clientes y SLA, portal del cliente, inventario, flota, lotes de lectura, formularios, costes, panel de control, administración e integración con un ERP), con capturas, índice con buscador y versión completa en inglés.

Los manuales son públicos: se leen sin iniciar sesión. Algunas pantallas de administración llevan además una ayuda plegable, «¿Para qué sirve esta pantalla?», con enlace a la sección del manual.

3. Estructura organizativa

Disponibilidad: núcleo; la gestión de clientes (con su portal) es un módulo, y las delegaciones, los equipos y los sectores dependen de la capacidad organizativa correspondiente Superficies: Web · Móvil (consulta) · Portal cliente (implícito) Para qué sirve: modela dos realidades organizativas muy distintas —la empresa que presta servicio a varios clientes y el operador que gestiona su propio patrimonio— sin obligar a ninguna de las dos a usar conceptos que no le sirven.

3.1 Los dos modelos: clientes o sectores

El sistema soporta dos organizaciones territoriales alternativas:

• Con clientes (empresa de servicios, contratista, mantenedora): el trabajo se organiza por cliente, y cada cliente tiene sus zonas.
• Sin clientes (operador que gestiona su propia red): el trabajo se organiza por sectores geográficos directamente.

El selector superior del mapa cambia de «Seleccionar cliente» a «Seleccionar sector» según el modelo.

El cliente elegido acota todo el mapa. En el modelo con clientes, el desplegable no solo encuadra el mapa: filtra todo lo que se ve —activos, órdenes, incidencias, lecturas, planificación, mapa de calor y contadores del día— hasta que se elige «Todos».

Todo pertenece a un cliente (3.2), también en el modelo sin clientes: allí existe uno solo, el propio de la organización.

3.2 Clientes

Ficha completa: nombre, persona de contacto, email, teléfono, dirección postal completa, logotipo propio.

• Ámbito geográfico del cliente, dibujable en el mapa, y encuadre calculado de todas sus instalaciones para centrar el mapa al seleccionarlo, recalculado automáticamente.
• SLA propio activable por criticidad y tipo (capítulo 19).
• Política de firma propia (5.9), conformidad del cliente al cierre y pausas justificadas del SLA, activables por cliente (capítulos 19 y 22).
• Vertical y delegación responsable.

Cliente propio. Cada organización tiene exactamente un cliente interno, «Propio», que recoge el trabajo sobre su propio patrimonio. No puede darse de baja ni eliminarse, y no cuenta para el límite de clientes.

Cliente obligatorio. Activos, órdenes de trabajo, incidencias, lecturas y el resto del trabajo llevan siempre un cliente, que resuelve el servidor en todas las entradas (web, app, sincronización, cargas):

• Sin el módulo de clientes, siempre el propio.
• Con el módulo, el indicado o el heredado —de la orden padre, de la incidencia o de los activos—; si no hay de dónde sacarlo, se pide.
• Los activos tienen que ser del mismo cliente que el trabajo, y un cliente de baja o suspendido no admite trabajo nuevo.
• La única excepción son las incidencias sin clasificar: pueden entrar sin cliente, pero hay que clasificarlas antes de convertirlas en orden o darlas por resueltas.

Asignar cliente en bloque. Lo que haya quedado sin cliente se puede repartir desde la web.

Ciclo de vida: alta → baja → eliminado.

• Dar de baja pide un motivo y muestra antes un resumen de lo que afecta: órdenes pendientes y en curso, incidencias abiertas, preventivo, programaciones y rutas de lectura, usuarios del portal y activos. Para cada bloque se decide qué hacer, con un valor por defecto: las órdenes pendientes se cancelan, las que están en curso se dejan terminar, las incidencias abiertas se cierran, el preventivo y las lecturas programadas se apagan. Siempre se cierra el portal y sus activos salen de la app móvil (en la web se conservan).
• Reactivar devuelve el cliente a alta y devuelve la lista de lo que hay que revisar; cada programación se reactiva aparte. Los activos de un cliente se pueden traspasar a otro.
• Eliminar completamente solo se ofrece para clientes de baja y exige escribir su nombre exacto. Antes se puede descargar una copia completa. Es un proceso por fases que se reanuda si se interrumpe y termina con un justificante descargable.

Límite de clientes. El número de clientes es un límite de la suscripción (A.4). Un cliente de baja sigue ocupando su plaza; solo la eliminación la libera.

Módulo de clientes suspendido. Si el módulo deja de estar contratado, nada se borra: los clientes quedan suspendidos, se cierra el portal y la web muestra los clientes en solo lectura hasta que vuelve.

3.3 Sectores y tipos de zonificación

Un sector es un área geográfica de trabajo con geometría propia, código, nombre, color y nivel. Los sectores son jerárquicos, sin ciclos.

• Se clasifican mediante tipos de zonificación (zonas de servicio, zonas de inspección, distritos…).
• Se pueden importar desde ficheros GIS, con un paso previo de análisis que muestra los campos antes de confirmar.
• Un sector se asigna a una delegación y puede tener equipos asignados, uno de ellos principal.
• Metadatos libres en formato clave-valor.

Sector de cada activo. El sistema asigna a cada activo el sector que lo contiene. Cuando un activo lineal o superficial cruza varios, gana el que se lleva la mayor parte de su longitud o área, con un margen para que pequeñas ediciones no lo hagan saltar de sector. Las órdenes de trabajo guardan además el reparto entre los sectores afectados (5.22).

Cambios de geometría y bajas. Dibujar o mover un sector solo reasigna las órdenes abiertas; las terminadas conservan el sector con el que se hicieron. Un sector con órdenes o programaciones de lectura no se borra: se desactiva.

3.4 Zonas de cliente

Subdivisiones geográficas dentro de un cliente, con su propio tipo de zonificación y geometría editable en el mapa. Sirven para filtrar activos y trabajo por área dentro de un mismo cliente, y para limitar lo que ve cada usuario del portal (capítulo 22).

• Jerárquicas y sin ciclos.
• Importación desde fichero (GeoJSON, Shapefile comprimido o GeoPackage), con el mismo análisis previo que los sectores.
• Una zona con subzonas o con usuarios del portal no se borra: se desactiva.

3.5 Delegaciones

Unidad organizativa interna: delegación regional, oficina, centro de trabajo. Es la pieza que conecta la estructura administrativa con la geografía y con la contabilidad.

• Nombre, dirección, ciudad, código de región.
• Una delegación marcada como principal, creada automáticamente al dar de alta la organización.
• Ubicación en el mapa, con capa propia en el panel de capas: son las sedes desde las que arrancan operarios y equipos, y verlas explica los desplazamientos que propone el planificador.
• Radio o polígono de base, para saber cuándo un operario está en su delegación.
• Zona horaria, elegible en el formulario. La de la principal es la de toda la organización (2.13), y cambiarla recalcula los plazos de SLA abiertos.
• Horario laboral: hereda el de la empresa o tiene uno propio.
• Festivos propios (capítulo 9).
• Almacén por defecto.
• Activa/inactiva.

La delegación se propaga a órdenes de trabajo, incidencias, sectores, clientes, personal, vehículos, almacenes, lotes de lectura y avisos, y es el eje de la imputación contable y del reparto de responsabilidad. Un aviso general que afecta a una delegación solo lo ven los usuarios de esa delegación, los que no tienen delegación y los administradores (capítulo 24).

Resolución automática de delegación. Al crear una orden, una incidencia o un lote de lectura, el sistema determina la delegación responsable por una cascada explícita: activos → sector → delegación más frecuente; si no, la ubicación propia del trabajo → el sector que la contiene; si no, cliente; si no, el personal asignado; si no, la ficha de quien lo crea; y en último término la delegación principal.

Borrado protegido. Una delegación no se puede eliminar mientras algo la referencie, aunque esté inactivo o cerrado. El rechazo dice qué y cuántos, y la web ofrece desactivarla.

3.6 Equipos de trabajo

Grupos de personal, con:

• Miembros, cada uno con su papel dentro del equipo.
• Turno por defecto del equipo, que el planificador usa como ventana horaria de la unidad completa.
• Delegación de adscripción. Todos los miembros son de la misma delegación que el equipo.
• Sectores asignados, con uno principal.

Un equipo es, para el planificador, una sola unidad de ruta: se le asigna trabajo como si fuera un único recurso, y sus capacidades diarias son la unión de las de los miembros presentes ese día.

3.7 Almacenes

Nodos logísticos que pertenecen a una delegación. Tres tipos:

• Físico — la nave o el almacén de la delegación, con ubicación obligatoria.
• Móvil — la furgoneta. Se vincula a un vehículo y/o a una persona; un vehículo y un técnico tienen como mucho una furgoneta activa cada uno.
• Virtual — para movimientos sin ubicación física.

Cada uno con su propio stock por artículo (capítulo 16). En la app, «Mi furgoneta» resuelve el almacén de cada operario: la furgoneta de su vehículo, la suya, la de su ficha, la de su delegación o la principal.

Un almacén solo se desactiva sin stock, y no se borra si tiene historia.

4. Gestión de activos (GIS)

Disponibilidad: núcleo, siempre activo Superficies: Web · Móvil · Portal cliente (consulta) · API pública Para qué sirve: es el inventario del patrimonio a mantener. Todo lo demás —órdenes, incidencias, lecturas, rutas— cuelga de aquí. Un activo puede ser una luminaria, una válvula, un tramo de red, un edificio, una zona verde o un inversor.

4.1 Familias y tipos de activo

• Familias: agrupación de primer nivel, jerárquica, con orden de presentación reordenable en bloque y vista de árbol. Una familia en uso no se borra: se desactiva.
• Tipos de activo (las capas del mapa): la clasificación operativa. Cada tipo define:
• Nombre y descripción multilingües.
• Uso de la capa: operativa (genera activos sobre los que se trabaja) o cosmética (solo visualización).
• Tipo de geometría esperado (punto, línea, polígono, sus variantes múltiples o genérico).
• Campos identificativos: qué propiedades identifican al activo. Sus valores forman el código del activo, que se calcula en altas, ediciones, cargas y sincronizaciones y se puede regenerar en bloque. Son además la clave con la que una reimportación reconoce los activos existentes (4.4).
• Orden de presentación, visibilidad por defecto y si la capa se cachea.
• Si es medible (admite lecturas de contador), si la lectura exige fotografía y qué oficio se asigna por defecto a sus lecturas.
• Reglas de jerarquía (4.2).
• Si está activa. Una capa con historia no se borra: se desactiva, y una capa desactivada no admite activos nuevos por ninguna vía.

Familias y tipos existen en dos planos: globales (dentro de un vertical) y propios de la organización (la copia clonada, editable).

4.2 Jerarquía de activos

Reglas por capa. En el bloque Jerarquía de cada capa se indica de qué capas pueden colgar sus activos (un cuadro eléctrico contiene interruptores, una estación de bombeo contiene bombas). Cada regla admite cantidad máxima de hijos por padre y si el padre es obligatorio.

El padre de cada activo. Al dar de alta o editar un activo, el campo «Cuelga de» busca candidatos por código o por cualquier campo, los ordena por cercanía, permite elegirlo en el mapa y propone el más cercano. El servidor valida el padre en todas las vías: tiene que existir y estar vivo, ser de una capa padre permitida, ser del mismo cliente, no crear ciclos y no superar la cantidad máxima.

Ficha. La sección Jerarquía muestra el padre y los hijos agrupados por capa, y permite añadir un hijo.

Asignación en bloque. Para colgar de una vez una capa ya cargada, la ventana Asignar padres… ofrece tres métodos, con vista previa antes de aplicar:

Respeta el máximo de hijos, puede limitarse a los activos sin padre y al mismo cliente, y está pensada para volúmenes grandes. En el listado de una capa se puede además cambiar el padre de una selección de hasta 1.000 activos, y las cargas de ficheros admiten una columna con el código del padre.

Lo que todavía no hace. Una orden de trabajo sobre un activo padre no incluye a sus hijos, y la app móvil no tiene pantalla para elegir el padre.

4.3 Propiedades personalizadas

Cada tipo de activo define su ficha técnica: un conjunto de campos con etiqueta multilingüe, tipo, valor por defecto, obligatoriedad, reglas de validación, ancho en el formulario, visibilidad (visible, oculto, solo lectura) y orden reordenable.

Tipos de campo: texto y área de texto, número, entero, decimal, autonumérico, fecha, fecha y hora, hora, selección simple, múltiple y botones de opción, casilla, sí/no, correo, URL, teléfono, color y archivo. El autonumérico lo numera el servidor sin duplicados, también al añadirlo a una capa con activos. El campo archivo enlaza un documento de la documentación del activo.

Además:

• Campo clave: qué propiedades identifican al activo.
• Opciones en cascada: las opciones de un campo pueden depender de lo elegido en otro (por ejemplo, modelo dependiente de fabricante).
• Campos de referencia a otro tipo de activo: la propiedad toma sus valores de los activos de otra capa.
• Propiedades específicas de un cliente, además de las comunes al tipo.
• Campos ocultos y de solo lectura: el servidor conserva su valor guardado aunque el formulario envíe otra cosa.
• Renombrar un campo lleva el nombre nuevo a los valores, a los estilos, a la documentación y a las referencias de otras capas; un campo que usan reglas de medida, documentos o referencias no se puede borrar.

4.4 Alta de activos

• Manual, dibujando la geometría directamente sobre el mapa, con cliente o sector, delegación, estado, padre y propiedades. Un alta que falla conserva el dibujo.
• Importación masiva desde ficheros GIS: GeoPackage, Shapefile comprimido, GeoJSON y DXF, hasta 150 MB por fichero, en segundo plano con seguimiento de progreso y creación automática de las propiedades a partir de los campos del fichero cuando la capa aún no tiene ninguna. El sistema de referencia de origen se puede indicar y es obligatorio en DXF.
• Importación masiva desde CSV, también en segundo plano. Cada columna pasa a ser una propiedad; los activos se crean sin geometría, que se dibuja después o se trae con una importación GIS.
• Sincronización desde APIs REST externas (21.10 y 25.3): una capa puede mantenerse desde un servicio remoto, con sincronización incremental a las horas que se elijan. Las peticiones solo salen hacia direcciones públicas de Internet.

Añadir o reemplazar. Una carga añade activos o reemplaza los datos de la capa. El reemplazo valida el fichero completo antes de tocar nada, da de baja (no borra) los activos anteriores, y se rechaza entero si algún activo vivo tiene trabajo, lecturas, fotos, documentos u otros datos que dependen de él.

Qué hace la importación con las filas problemáticas.

4.5 Estados del activo

Catálogo de estados con nombre y descripción multilingües, color e icono. El estado se cambia de forma puntual desde web y móvil, se refleja en el mapa y se puede ver en todas las capas con el temático por estado (4.11).

Baja definitiva. Hay una sola forma de darla, la misma para el borrado del activo, el cambio de estado, la aprobación de una solicitud de baja y el rechazo de una solicitud de alta. Un activo de baja no se pinta en el mapa ni baja a la app, no puede ser padre y no vuelve a otro estado. Desde la aplicación nunca se borra físicamente.

4.6 Fotografías y documentación

• Fotografías múltiples por activo, optimizadas automáticamente con miniatura.
• Documentación adjunta por activo, y también por tipo de activo o por valor de una propiedad, lo que permite adjuntar por ejemplo la ficha técnica común a todos los equipos de un modelo.
• Control de lo que se sube: cada fichero se comprueba por dentro según su formato, no por su extensión. Las imágenes tienen que abrirse como imagen; los PDF, sin acciones ejecutables; los documentos Office modernos, sin macros ni objetos incrustados; los formatos antiguos y los que admiten macros se rechazan. Tope de 20 MB por foto y 50 MB por documento.
• La descarga exige sesión, y cada organización solo accede a sus propios ficheros.

4.7 Consultas espaciales y listados

• Selección por polígono dibujado en el mapa, y selección por punto con radio.
• Listado de una capa: paginado, con columnas Código, Estado y Cuelga de, orden por cualquier columna o propiedad, búsqueda, acotado por cliente y con selección para cambiar padre. Exportación CSV con los mismos filtros, hasta 50.000 filas, protegida contra fórmulas y registrada en la auditoría.
• Encuadre de todo el patrimonio, guardado por organización para cargar el mapa al instante.
• Localización de un activo por su código, para integración o búsqueda rápida.

4.8 Geovalla del activo

La llegada del técnico al punto de trabajo se detecta con un radio fijo de 200 m alrededor de los activos de la orden, el mismo para toda la aplicación. La salida se cuenta, con los ajustes por defecto, a 300 m. El detalle está en el capítulo 15.

4.9 Histórico y puntos de medición

Los activos medibles acumulan histórico de lecturas consultable con estadísticas, y tienen puntos de medición con umbrales de validez y frecuencia (capítulo 17).

4.10 Historial de trabajo del activo

La ficha del activo muestra su código y su sector y, en sus pestañas:

• Órdenes de trabajo: todas las que lo han tenido como objeto, con estado y fechas. Un técnico ve también las de otros, pero resumidas como «De otro técnico» (1.13).
• Incidencias: las abiertas y las cerradas de los últimos 12 meses, también las que lo incluyen entre varios activos.

4.11 Estilos cartográficos

Cada tipo de activo tiene uno o varios estilos. El editor cubre el vocabulario cartográfico completo:

• Puntos: color, opacidad, radio, contorno.
• Líneas: color, opacidad, grosor, unión y remate, discontinuo, desplazamiento, desenfoque.
• Polígonos: relleno, opacidad, contorno, patrón.
• Etiquetas: campo, tamaño, color, halo, anclaje, desplazamiento.
• Iconos: imagen, tamaño, opacidad y color del icono.
• Zoom mínimo y máximo de la capa y filtro por tipo de geometría, de modo que un mismo tipo pueda pintar sus puntos y sus líneas de forma distinta.

Los estilos pueden depender de los valores de una propiedad (estilo temático: colorear por material, por año de instalación), y el sistema enumera los valores disponibles para construir la clasificación. De ahí se deriva automáticamente la leyenda de cada capa.

Temático por estado. Todas las capas de activos del mapa web ofrecen, sin configurarlo, el temático «Estado del activo», con su propia leyenda.

Cambiar un estilo se aplica en los mapas abiertos sin recargar. Igual que familias y tipos, hay estilos globales por vertical y estilos propios de la organización.

4.12 Iconos

Biblioteca de iconos del sistema, organizada por temas, con color por defecto y previsualización. Reúne unos trescientos iconos de licencia libre en diez temas alineados con los verticales, presentados con proporción casi cuadrada en el mapa. El color lo pone el estilo. Se usan en estilos de capa, estados, criticidades y catálogos.

4.13 Copia de los activos para el móvil

Además de la cartografía para pintar el mapa (21.7), cada organización tiene una copia de sus activos para el móvil (tipo, cliente, sector, estado, padre, código, propiedades y geometría) que la app descarga en su primer arranque.

• Se genera cada noche y, bajo demanda, desde la app.
• Se construye aparte y solo sustituye a la publicada cuando está completa y verificada: la app nunca descarga una copia a medias.
• Activos que dejan de servir en campo. Los activos de un cliente dado de baja y los eliminados no van al móvil, y la sincronización le dice a la app cuáles quitar. La web los sigue mostrando con el filtro de clientes de baja.

4.14 Histórico de posiciones del activo

Mover un activo no sobrescribe su posición sin rastro: cada cambio de geometría deja registro de la posición anterior y la nueva, cuándo, quién y desde dónde:

El registro lo hace la propia base de datos, de modo que ningún camino se lo salta. La ficha tiene la sección plegable «Historial de ubicaciones», con la distancia entre posiciones y botones para ver cada una en el mapa. El histórico se ofrece también en la API pública y en la copia completa de datos (25.17).

5. Órdenes de trabajo

Disponibilidad: módulo de mantenimiento Superficies: Web · Móvil · Portal cliente (consulta y conformidad) · API pública (indirecta) Para qué sirve: la orden de trabajo es la unidad de ejecución y de coste. Agrupa qué hay que hacer, dónde (sobre qué activos o en qué punto o zona), quién lo hace, cuándo, con qué materiales y con qué resultado documentado.

5.1 Ciclo de vida: siete estados

Transiciones permitidas en el ciclo completo, aplicadas por el servidor:

Una transición que no está en la tabla se rechaza. Dos cambios simultáneos sobre la misma orden no pueden llevar una orden cancelada a completada.

Permisos de cada cambio de estado: una sola regla para la web y la app.

La aplican el formulario, el menú «⋯», el tablero Kanban, las acciones masivas y la sincronización del móvil. Una organización que quiera que el técnico cierre le da el permiso de cierre a su rol.

Toda orden nace pendiente, en todos los ciclos y para cualquier usuario. Las órdenes generadas por una programación (capítulo 6) también. La única excepción es el parte rápido de la app, que es trabajo ya hecho y nace completado.

Asignar no es un estado. Una orden está asignada cuando tiene al menos una persona, esté en el estado que esté: así la ve el técnico en su app. Asignar, cambiar o quitar personal no cambia el estado y queda en la cronología de la orden (5.16). Una orden está planificada cuando tiene personal operativo y ventana (inicio y fin previstos); es lo que mira el planificador (capítulo 11) para no volver a proponerla.

La separación entre completada, validada y cerrada es deliberada: distingue «el técnico ha terminado» de «el supervisor lo ha revisado» de «está cerrado y es facturable». Cada cambio de estado se registra en un histórico con marca de tiempo, autor y notas —y, en las pausas, su causa (5.20)—, que alimenta los indicadores del panel, los tramos de trabajo (5.18) y el parte de horas (5.19).

Qué se puede tocar en cada estado. Cerrada y cancelada son terminales. Una orden completada o validada solo admite cambiar de estado; para editarla hay que reabrirla.

Lo que bloquea el cierre. Completar, validar o cerrar exige, además del permiso:

• la firma del cliente o una excepción de firma cuando la política la pide (5.9);
• los formularios obligatorios completados (5.7);
• para cerrar, la conformidad del cliente cuando el cliente la exige (5.21 y capítulo 22).

Si el cierre llega desde la app y falla alguna de estas comprobaciones, la orden vuelve al estado anterior con sus fechas reales de antes.

Ciclos reducidos. Una empresa pequeña no tiene supervisor que valide, y obligarla a atravesar tres estados para cerrar un trabajo hace que el producto parezca de otra liga. El nivel de detalle del ciclo (2.4) elige entre tres flujos, que solo se diferencian en cuántos pasos hacen falta para cerrar:

Al quitar estados se reconecta el ciclo, de modo que en todo nivel existe un camino hasta el cierre; la pausa existe en todos, porque la autopausa de fin de jornada (14.6) la necesita. El menú «⋯» y el Kanban solo ofrecen los cambios válidos para el ciclo de la organización y los permisos del usuario. El histórico no cambia, de modo que la analítica sigue leyendo lo mismo.

5.2 Prioridades

Cuatro niveles: Baja, Media, Alta, Urgente. Independientes de la criticidad, que se deriva de la prioridad para el SLA. Una orden urgente avisa a sus responsables como orden crítica.

5.3 Creación de una orden de trabajo

Formulario completo en el panel lateral, sobre el mapa, en seis bloques (información principal, ubicación, tipo de trabajo, planificación, equipo y recursos). Se abre desde el panel de órdenes, con clic derecho en el mapa («Nueva orden aquí» o «Nueva orden para este activo»), desde una incidencia o desde un hueco del calendario.

• Título, descripción, dirección textual.
• Cliente: obligatorio con el módulo de clientes; se hereda de la orden padre, de la incidencia o de los activos, y todos los activos tienen que ser del mismo cliente (3.2).
• Tipo de mantenimiento —obligatorio siempre— y tareas concretas dentro de ese tipo. Los tipos y tareas inactivos no se ofrecen.
• Dónde: activos seleccionados en el mapa (por clic o dibujando un polígono) o una ubicación propia —un punto o un área— para el trabajo que no recae sobre un activo inventariado (5.14).
• Sector y delegación, resueltos automáticamente (3.5 y 5.22).
• Prioridad, inicio previsto, fin previsto y fecha límite opcional (5.25).
• Duración estimada, calculada automáticamente (capítulo 12) y sobrescribible.
• Asignación a personal, con uno o varios responsables, y ayuda para añadir un equipo entero (5.5).
• Formularios asociados propuestos por tipo, tareas y activos; los obligatorios no se pueden desmarcar (5.7).
• Recursos: lo que piden las tareas —material, herramientas y EPIs— y materiales previstos con cantidad y almacén (5.6 y 5.23).
• Documentación adjunta desde el alta.
• Propiedades libres.

El alta devuelve, sin impedir que se cree, dos tipos de aviso: de stock (la cantidad planificada supera lo disponible o deja el material bajo mínimo) y de cualificación (nadie del personal asignado cubre una habilidad obligatoria vigente o un oficio requerido).

Existe además la creación desde una incidencia (7.6), que hereda su cliente, sus activos y su ubicación. Una incidencia solo puede tener una orden viva que la resuelva, salvo que la anterior haya terminado sin resolver el problema (5.24). Y está el parte rápido desde el móvil (23.8).

Qué es obligatorio. El título y el tipo de mantenimiento son obligatorios para todos: sin tipo no se resuelve la duración estimada, no se enganchan los formularios ni las tareas, y el panel no puede separar lo planificado de lo correctivo. El resto lo decide la organización entre cuatro campos: responsable asignado, fecha planificada, al menos un activo y ubicación. Por defecto se exige solo el responsable; en perfil Esencial, ninguno. El error habla el idioma del formulario: «La orden de trabajo necesita un responsable asignado».

Edición. Editar conserva lo que sigue en la orden (fecha de asignación, estado y notas de cada tarea, respuestas de los formularios) y solo quita lo desmarcado; un formulario con respuestas no se puede desmarcar. Si otra persona u otra pestaña ha guardado la orden entretanto, el guardado se rechaza para no pisar sus cambios.

5.4 Asistentes de planificación en el alta

Tres ayudas integradas en el formulario, todas basadas en datos reales:

• «Planificar esta OT» — busca la primera franja en la que exista una unidad disponible y apta —equipo u operario— y las ordena por cercanía real por carretera. Detallado abajo.
• «Sugerir siguiente hueco» — busca, en los próximos 30 días, la primera fecha y hora en que el personal indicado está libre, respetando turnos, horario semanal, festivos, ausencias y órdenes ya asignadas.
• «Comprobar disponibilidad» — valida antes de guardar que las personas elegidas están disponibles en esa franja, con el motivo legible de cada bloqueo (fuera de turno, festivo, ausencia, solape). No impide guardar.

«Planificar esta OT»: unidades aptas y cercanía real

Responde a la pregunta operativa completa del alta —«¿a quién le doy esto, y para cuándo?»—:

1. Evalúa equipos además de personas. Muchas empresas no mandan a Juan: mandan a la cuadrilla. Un equipo es una sola unidad y sus capacidades del día son la unión de las de sus miembros presentes. Una cuadrilla con un electricista y un peón puede ejecutar un trabajo que exige certificado eléctrico aunque el peón no lo tenga. Un equipo sin turno definido usa el horario de la empresa.

2. La proximidad se mide desde donde cada unidad arranca de verdad: el domicilio del operario si así lo tiene declarado, su delegación si no. El destino es el centro de los activos de la orden o su punto o área propios. Funciona también en una organización que no trabaja con delegaciones.

Franjas. Los candidatos son el comienzo de cada franja del horario semanal de la delegación, y el trabajo tiene que caber entero en esa franja: con jornada partida hay dos candidatos por día y nunca se propone la hora de comer. La búsqueda mira un horizonte de 45 días.

Salida. Las unidades se ordenan por aptitud, puntuación (competencias deseables y proximidad) y tiempo de viaje. Se devuelven también las no aptas, con su motivo. Para cada candidato se comprueba además si llega a su siguiente orden de las 12 horas posteriores, con 20 minutos de margen; si no, se marca con un aviso.

Si el cálculo de rutas no responde, las unidades se devuelven sin proximidad en lugar de fallar: la cercanía mejora el orden, no decide la aptitud. Si la orden no tiene dónde medir, se planifica solo por aptitud, y la respuesta lo dice.

5.5 Asignación de personal y equipos

• Asignación a personal operativo (con o sin usuario de la aplicación), marcando uno o varios responsables.
• Equipos: el formulario permite añadir un equipo de una vez; se incorporan sus miembros activos como personas asignadas.
• Reasignación posterior desde el formulario, desde Asignar personal… en el menú «⋯», desde el Kanban, desde las acciones masivas (5.15), desde el despacho y desde «Asignar al más cercano…» (capítulos 10 y 20). En ningún caso cambia el estado.
• Si nadie del personal asignado cubre una habilidad obligatoria o un oficio requerido, la orden se guarda igualmente con un aviso de cualificación.

Alcance de cada usuario: el mismo en la web y en la app. Un técnico solo ve y puede actuar sobre las órdenes en las que figura su ficha de personal (1.13).

5.6 Materiales consumidos

Cada orden lleva un listado de materiales con cantidad planificada y cantidad realmente usada. Cada línea fija además el almacén del que saldrá y lleva cuenta de lo que tiene sacado del stock en cada momento, de modo que ninguna vía cuenta dos veces.

De qué almacén sale. En cada línea, «Sale de» ofrece Automático o un almacén concreto con lo libre que tiene. En automático decide el servidor: la furgoneta de quien hace el trabajo —o la del vehículo que lleva ese día—, el almacén de su ficha, el de la delegación o el de la principal; nunca «el que más tenga». Lo elegido a mano no lo cambian el personal ni el planificador. Lo que las órdenes abiertas aún tienen que sacar de cada almacén cuenta como comprometido (capítulo 16).

El material se descuenta del almacén al consumirse, no al planificarse:

Da igual que el consumo llegue de la web, de la app, de la sincronización offline o del parte rápido: todas las vías mueven el stock del mismo modo y dejan el movimiento con su coste, que alimenta el coste real de la orden (5.10).

5.7 Formularios de campo

A una orden se le vinculan formularios según el tipo de mantenimiento, la tarea o el tipo de activo. Cada vínculo declara si el formulario se rellena una vez por orden o una vez por cada activo, y si es obligatorio. Detalle en el capítulo 18.

Los obligatorios bloquean el cierre. Una orden no se completa, valida ni cierra con un formulario obligatorio sin completar, y el sistema dice cuáles faltan. Una respuesta marcada como completada con campos obligatorios vacíos no cuenta. Se comprueba en la web, en las acciones masivas y en la app; cancelar no se bloquea.

Las tareas se completan con sus formularios. Una tarea pasa a completada cuando todos los formularios vinculados a ella tienen una respuesta completada, y vuelve a pendiente si alguno deja de estarlo.

La pestaña Formularios de la ficha muestra las respuestas, incluidas las fotos, y avisa de las pendientes de subir; la ficha PDF incluye firmas y fotos de formulario.

5.8 Adjuntos y evidencia

Ficheros vinculados a la orden: fotos, vídeos, PDFs, planos. Cada adjunto guarda su miniatura, tipo de fichero, descripción, autor, coordenadas GPS de captura y fecha de captura (la de la foto, no la de la subida), de modo que la evidencia fotográfica queda georreferenciada y datada. Las fotos se eliminan desde la app como baja lógica, y en una orden validada, cerrada o firmada ya no se eliminan.

También hay documentación de orden con título, descripción y fichero, con descarga protegida y enlace temporal.

5.9 Firma del cliente

Al cerrar el trabajo en campo se puede recoger la firma del cliente: nombre, DNI, papel (cliente, técnico, supervisor), imagen de la firma, ubicación GPS, fecha e información del dispositivo.

Cuando no es posible obtener firma, se registra una excepción de un catálogo tipificado (cliente ausente, cliente se niega…), donde cada motivo declara si exige foto de evidencia.

Qué órdenes exigen firma lo decide la política de firma de cada cliente: siempre, nunca, o según el tipo de mantenimiento. La política se exige al completar: sin firma ni excepción, la orden no pasa a completada, validada ni cerrada, desde la web, las acciones masivas o la app. Los partes rápidos quedan exentos.

Cada firma lleva además un sello de integridad de lo firmado y un sellado de tiempo de una autoridad externa, que la ficha muestra junto a la firma (25.16).

5.10 Coste de la orden

Informe que calcula el coste real de una orden, para quien puede ver importes y en organizaciones que trabajan con costes. Agrega tres componentes:

• Mano de obra: el parte de horas (5.19) de cada persona por su tarifa vigente el día trabajado: cambiar una tarifa no reescribe los periodos pasados. Las horas pendientes de revisión no suman hasta que se aprueban. Las de personas sin tarifa cuentan en horas pero no en importe, y marcan el coste como incompleto.
• Materiales consumidos, valorados al coste del movimiento, descontando las devoluciones.
• Vehículo: con el módulo de flota, los trayectos imputados a la orden y su combustible al precio de cada día, con desglose por vehículo y «Ver ruta en el mapa» (capítulo 13).

Las órdenes de revisión por «no conforme» y las marcadas como no facturables se señalan en el coste y en los informes (5.21, 20.10). Los importes nunca aparecen en el PDF de la orden.

5.11 Visualización y listados

• Capa de órdenes sobre el mapa, con filtros por estado, prioridad, tipo, responsable, personal, cliente y fechas, y leyenda propia. Las órdenes con ubicación propia se pintan en su punto o su área (5.14).
• Listado paginado en el panel derecho, con búsqueda, orden por vencimiento, fecha, prioridad o «sin asignar primero», acotado a la zona del mapa si se quiere y con recuentos por estado. Cada tarjeta muestra al personal, el inicio y fin previstos, la fecha límite, los avisos de vencimiento y SLA y la incidencia que resuelve.
• Contadores del día sobre el mapa (20.14.1).
• Línea temporal por operario: qué tiene cada persona asignado y cuándo.
• Informe PDF de la orden: hoja de trabajo antes de completarla, informe de lo realizado después y ficha de trabajo no realizado si se canceló; con fechas previstas y reales, tiempo en curso, firmas con su sello y respuestas de formulario, sin importes.

Todas estas vistas respetan el alcance del técnico (1.13).

5.12 Vistas de planificación

La pestaña de Planificación ofrece seis vistas sobre el mismo trabajo:

Mover una orden en el calendario cambia su franja planificada, nunca su fecha límite (5.25).

5.13 Órdenes pendientes de revisión

Una tarea diaria detecta las órdenes que quedaron pausadas y llevan demasiado tiempo sin retomarse (3 días por defecto, configurable) y las marca como «necesita revisión» sin cambiar su estado, para que sea el supervisor quien decida.

5.14 Ubicación propia: un punto o un área

No todo trabajo recae sobre un activo inventariado: una poda en una calle, un vertido en una parcela, una revisión de zona. Una orden puede situarse, además de por sus activos o en lugar de ellos, en un punto o en un área propios, y esa ubicación manda sobre la de los activos.

• El área se dibuja en el mapa y se rechaza si no tiene superficie o supera los 50 km².
• Con ubicación propia, el sector y la delegación salen de esa ubicación (5.22).
• El punto de una orden situada por sus activos cae sobre uno de ellos, no en un centro que podría quedar fuera de una tubería en L.
• La ubicación propia la usan la geovalla (capítulo 15), «Planificar esta OT», la app y el portal.
• El panel de control y los listados distinguen el trabajo con activo del trabajo sin activo (capítulo 20).

5.15 Acciones masivas

Sobre una selección de órdenes —marcadas en el listado o con un rectángulo sobre el mapa— se aplica una misma acción a hasta 200 órdenes de una vez:

Cada orden pasa por las mismas reglas que la edición individual y se guarda por separado: una que falla no impide las demás. El resultado dice cuáles se aplicaron y, de las que no, por qué; en la web siguen seleccionadas.

5.16 Cronología de la orden

La ficha tiene una pestaña Actividad que reúne en orden temporal lo que le ha pasado: cambios de estado (las pausas, con su causa), llegadas y salidas registradas por la geovalla, pausas automáticas, avisos de revisión y tramos de trabajo.

Incluye los eventos de asignación: cada persona que entra o sale de la orden deja un evento con quién lo hizo, cuándo y desde dónde —formulario, listado o tablero, acción masiva, despacho, planificador o programación—.

La pestaña Info reúne además la programación, las pausas del SLA, las firmas con su sello, las tareas, el personal con su parte de horas, los activos, los materiales, EPIs y herramientas (5.23), los formularios, la documentación, el coste real y, en las revisiones, la orden de origen (5.21).

5.17 Fechas como instantes y zona horaria de la orden

Toda fecha de una orden se guarda como instante y se muestra en la zona horaria de la orden: la de su delegación; si no, la de su primer operario; si no, la de la organización (2.13). Se presentan con el formato de la organización.

• Fechas planificadas introducidas solo como día: el inicio es la hora de inicio de jornada de ese día y el fin la de fin de jornada, según el turno del responsable, el del equipo o el horario semanal (9.8).
• Días y duraciones se calculan como diferencia de instantes: los cambios de hora no descuadran nada.
• Desde la app, las fechas llegan con su zona horaria.

5.18 Fechas reales, tramos de trabajo y tiempo en curso

Fechas reales. El inicio y el fin reales de cada orden se guardan junto con de dónde salen: la geovalla, un cambio de estado, la app, una corrección manual. Cuando algo no cuadra —fin anterior al inicio, un tramo continuo de más de 24 horas, completada sin fin, inicio anterior al alta, fechas imposibles o lejos de la evidencia—, la orden queda marcada con el motivo.

La pantalla Fechas reales por revisar lista esas órdenes con un resumen por motivo, y permite marcarlas como revisadas o corregir el inicio o el fin con un motivo obligatorio, que queda en la auditoría.

Tramos de trabajo. Una orden que se empieza un día, se pausa y se termina otro no ha durado «fin menos inicio», que contaría las noches. Cada paso a en curso abre un tramo y la pausa o el cierre lo termina. La suma de los tramos es el tiempo en curso de la orden.

La ficha muestra fechas reales, duración total y tiempo en curso, y la pestaña Actividad lista los tramos. El mismo dato llega al PDF, al portal, a la exportación y a la app, y es la base del presupuesto de tiempo (capítulo 12) y del parte de horas (5.19).

5.19 Parte de horas por persona

La duración de una orden no es su mano de obra. Cada orden tiene un parte de horas: una fila por persona, día y tipo de hora, que es lo que leen el coste (5.10), las horas por operario, la capacidad del personal (20.11) y la exportación.

Cómo se calcula. Para cada persona que trabajó la orden —el personal operativo siempre; un responsable solo si hay rastro de que la trabajó—:

• Trabajo: los tramos de la orden o, si la app lo manda, el cronómetro de cada técnico, de modo que la pausa de un compañero no le corta el tiempo.
• Hora normal: el trabajo que cae dentro de su jornada de ese día, sin festivos, días libres ni ausencias.
• Hora extra: lo de fuera de la jornada con evidencia de trabajo (un inicio o fin desde campo, presencia en la geovalla o seguimiento activo). Nace pendiente de revisión y no cuenta hasta que se aprueba. Lo de fuera de jornada sin evidencia —las noches de una orden olvidada en curso— no se imputa.
• En un trabajo de más de 7 días seguidos, los días sin evidencia salen pendientes de revisar.

El parte se recalcula al cambiar el historial, las fechas o el personal de la orden, y cada noche para recoger cambios de turnos, festivos y ausencias.

Revisión. La ficha muestra el parte por persona y día. Quien gestiona personal aprueba o rechaza lo pendiente, corrige una franja, quita horas o añade horas a mano (por ejemplo, de alguien que trabajó sin la app). Lo revisado queda fijo y el recálculo no lo toca. La bandeja Horas por revisar reúne lo pendiente de todas las órdenes.

Horas por operario. Pantalla y exportación CSV, en rangos de hasta un año, que suma el parte por persona y día, con las horas extra aparte.

5.20 Plazos SLA y pausas justificadas

Cada orden guarda sus plazos de respuesta y de resolución, de dónde salen (SLA del cliente, de la organización o global) y desde cuándo está en riesgo. Los plazos se cuentan en horario laboral: solo consumen las franjas del horario semanal, saltan festivos y usan la zona de la delegación. El plazo cuenta desde una base fija —la creación o, en el preventivo, su fecha prevista—: mover la orden en el calendario no mueve su plazo. Detalle en el capítulo 19.

Pausas justificadas. Al pausar una orden se indica la causa —atribuible al cliente, tercero o suministro, fuerza mayor o propia—. Las tres primeras paran el plazo de resolución si el contrato del cliente lo admite; la propia no. La web pregunta siempre la causa, porque alimenta también el desglose del tiempo hasta el cierre del panel. La ficha lista las pausas con su causa y lo descontado, y la causa de una pausa ya registrada se puede corregir, quedando en la auditoría (19.8).

5.21 Revisión por «no conforme» del cliente

Cuando el cliente responde No conforme a una orden terminada en el portal (capítulo 22), el sistema abre en ese momento una orden de revisión en lugar de reabrir la original:

• Pendiente, prioridad alta y sin operario, con el cliente, la delegación, los activos, la ubicación, el tipo y las tareas de la original, y el comentario del cliente en la descripción.
• Nace no facturable; quien puede cerrar órdenes puede cambiarlo, y cada cambio queda en la auditoría.
• Una sola revisión por ciclo de terminación de la original: otro «no conforme» se suma a la que ya hay.
• La original no cambia de estado y ya se puede cerrar; la conformidad se pide sobre la revisión.
• Si la original resolvía una incidencia, la incidencia vuelve a abierta y pasa a resolverla la revisión.
• Sale el aviso «Cliente no conforme», que se cierra solo al asignarle personal a la revisión.

La ficha de la revisión enlaza la original y quién trabajó en ella; los costes separan lo gastado en revisiones y en trabajo no facturable.

5.22 Sector responsable y sectores afectados

Una orden tiene un sector responsable y puede afectar a varios:

• Situada por sus activos: el responsable es el sector más repetido entre ellos.
• Con punto o área propios: el reparto de su ubicación entre los sectores, con un margen para que pequeños cambios no la hagan saltar.
• Sectores afectados: todos por los que pasan sus activos o su ubicación, con su parte. Sirven para filtrar y contar trabajo por zona (una orden que cruza dos sectores cuenta en los dos); los costes van solo al responsable, para no contarlos dos veces.

Al cambiar la geometría de los sectores solo se reasignan las órdenes abiertas.

5.23 Material, herramientas y EPIs de las tareas

Cada tarea del catálogo puede declarar lo que hace falta para hacerla (8.8). En la orden:

• El formulario muestra «Lo que piden las tareas elegidas». Añadir material de las tareas lo copia como líneas normales, multiplicando la cantidad por activo si así se definió. Es una propuesta, no una reserva.
• Las herramientas salen en la ficha y en la app como lista para preparar el trabajo; no descuentan stock.
• Los EPIs los pide confirmar la app al iniciar la orden. La ficha muestra lo que confirmó cada técnico: lo lleva o no lo lleva, con su motivo. Iniciar sin algún EPI genera un aviso de seguridad para el supervisor, que se cierra solo si el técnico corrige después. El inicio nunca se bloquea, porque la app trabaja sin conexión.

5.24 Orden que no resuelve su incidencia

Al terminar una orden que resuelve una incidencia, la web y la app preguntan «¿Queda resuelto el problema?»:

• Sí (o sin respuesta): la incidencia sigue el estado de la orden como siempre.
• No, hace falta otra intervención, con una nota de lo que falta: la incidencia sigue abierta con su SLA en marcha, queda anotado en su historial, sale el aviso de nueva intervención y admite otra orden, que lleva en su descripción lo que faltaba.

Así, un diagnóstico o un arreglo provisional no dan la incidencia por resuelta. Reabrir la orden borra la respuesta, que se vuelve a preguntar.

5.25 Franja planificada y fecha límite

La orden distingue su franja planificada de su fecha límite:

• Inicio previsto y fin previsto son la planificación: los cambian el formulario, el calendario, el despacho, las acciones masivas y el optimizador.
• Fecha límite, opcional: la que pide el cliente o el contrato. Solo la cambia quien la edita, nunca la planificación. El preventivo nace con fecha límite igual al fin generado.

El vencimiento que usan avisos, contadores, panel, mapa, listados, despacho, portal y planificador es, por este orden, la fecha límite, el plazo de resolución del SLA y el fin previsto. Replanificar nunca falsea un vencimiento contractual. El cumplimiento del preventivo se mide contra la fecha límite y el del SLA contra su plazo.

6. Programación recurrente de órdenes de trabajo

Disponibilidad: módulo de mantenimiento, con la capacidad de preventivo Superficies: Web Para qué sirve: convierte el mantenimiento preventivo en algo que ocurre solo. Se define una vez la revisión trimestral de los cuadros eléctricos y el sistema genera las órdenes con la antelación configurada, avisando si el almacén no da para el material.

6.1 Reglas de recurrencia

Sobre una orden de trabajo «base» se define una regla en el bloque Recurrencia del formulario, que aparece con los tipos de mantenimiento periódicos:

• Fecha de inicio y fecha de fin (o recurrencia indefinida).
• Frecuencia: diaria, semanal, mensual o anual, con intervalo (cada N periodos).
• Días de la semana concretos (por ejemplo, lunes y miércoles), en la frecuencia semanal.
• Días del mes concretos (por ejemplo, los días 1, 15 y 30), en la mensual. Un día que el mes no tiene cae en el último día de ese mes, en lugar de saltarse el mes.
• Meses del año concretos (por ejemplo, marzo y septiembre), en la anual.
• Hora del día de cada ocurrencia, en hora local: un preventivo de las 10:00 sigue a las 10:00 después de un cambio de hora. Sin hora, toma la de la orden base.
• Siguiente visita: fija o flotante (6.5).

Días laborables. Una ocurrencia que cae en día no laborable se traslada al siguiente laborable, según el horario semanal de la delegación y sus festivos.

Fin y fecha límite de cada orden generada. Conservan la duración de la orden base, contada en días laborables.

6.2 Generación automática

La generación trabaja con dos horizontes de la configuración de la organización:

Se ejecuta al crear o editar la programación y cada noche. La ventana se desliza: cada noche las previsiones que entran en el primer horizonte pasan a órdenes y el horizonte se alarga un día.

• Nunca genera días pasados.
• Se puede repetir sin duplicar. Cada orden recuerda el día de la ocurrencia que cubre: un día que ya tiene su orden no recibe otra, y mover una orden generada a otro día no hace que se regenere en su día original.
• Los días excluidos (previsiones eliminadas a mano, 6.4) no se generan.

Cada orden generada nace pendiente, con su propio código y el título de la base con su número de secuencia («#017»); nace con fecha límite igual a su fin generado, y su plazo SLA cuenta desde la fecha prevista, no desde que se generó días antes; copia activos, tareas, personal, materiales y formularios sin lo que ya no sirve (activos de baja, personal desactivado, tareas inactivas); y avisa a sus responsables. Si la orden base se queda sin activos o sin personal activo, se genera igual y sale un aviso.

6.3 Aviso de material

Al crear la programación, la respuesta avisa si el almacén de cada línea no da para el material de la orden base o lo deja bajo mínimo: se sabe antes de que empiecen a salir órdenes. Las órdenes generadas no mueven stock al generarse: el material queda comprometido y se descuenta al consumirse (5.6).

6.4 Consulta y limpieza

• Consulta de las previsiones por rango de fechas y por cliente.
• Crear orden desde una previsión la convierte en orden real, y la previsión desaparece.
• Eliminar una previsión concreta deja su día excluido, para que la generación nocturna no lo vuelva a crear.
• Editar la programación solo regenera si cambia la regla o el contenido de la orden base. Al regenerar se sustituyen las órdenes generadas pendientes e intactas de hoy en adelante; las que tienen algo propio (adjuntos, comentarios, personal cambiado, respuestas, otra fecha) o ya tienen trabajo se conservan, y la web avisa de sus códigos para que el usuario decida. Las pendientes de días pasados se conservan: son preventivo atrasado.
• Quitar la programación conserva la orden base; de las generadas, se borran las pendientes intactas y el resto se queda como historia del activo.
• La ficha de una orden base cerrada o cancelada con programación activa ofrece Quitar programación.

6.5 Siguiente visita: fija o flotante

Dos maneras de calcular cuándo toca la siguiente visita (UNE-EN 13306):

En modo flotante la regla es solo «cada N días, semanas, meses o años», y mientras haya una visita abierta no se crea la siguiente orden, solo previsiones.

6.6 Cumplimiento del preventivo

El indicador Cumplimiento del preventivo del panel (capítulo 20) y su listado usan el mismo criterio: órdenes generadas por programaciones con fecha de hoy hacia atrás, sin canceladas, medidas contra su fecha límite. El portal del cliente muestra el preventivo previsto (capítulo 22).

7. Incidencias

Disponibilidad: módulo de mantenimiento, con la capacidad de incidencias Superficies: Web · Móvil · Portal cliente · API pública Para qué sirve: separa el aviso del trabajo. Una incidencia es algo que alguien ha reportado —un cliente, un técnico, un sistema externo— y que aún no es necesariamente una orden. Permite triar, medir el tiempo de respuesta y decidir qué se convierte en trabajo y qué no.

7.1 Orígenes

Catálogo de canales de entrada con nombre multilingüe, icono, color y orden. Los orígenes de sistema son ocho: App técnico, Portal de cliente, Llamada / teléfono, Email / registro, Sensor IoT, Inspección / auditoría, Lectura de contador (las que abre el sistema por una lectura fuera de rango, 7.15) e Integración (API) (7.16). La organización puede añadir los suyos. Es lo que permite responder a «¿cuántos avisos entran por el portal frente al teléfono?».

7.2 Reportador

Una incidencia puede venir de:

• Un usuario del sistema (queda vinculado).
• Un usuario del portal de cliente, vinculado a su cuenta: puede ver siempre las incidencias que comunicó (22.2).
• Un externo: nombre libre y contacto (email o teléfono) para poder notificarle.

7.3 Contenido y clasificación

• Código legible generado automáticamente, con secuencia por organización y año (formato INC-2026-00056).
• Título, descripción pública y notas internas separadas: las notas internas no las ve el reportador ni el portal.
• Tipo de incidencia (catálogo propio, 7.14), estado y nivel de criticidad.
• Revisor asignado.
• Cliente: el indicado o el de los activos. Una incidencia puede quedar «sin clasificar» mientras está abierta, porque quien avisa no siempre sabe de quién es el problema; pero sin cliente no se puede resolver, cerrar ni convertir en orden.
• Delegación responsable, resuelta automáticamente.

Fecha de resolución. Se sella al pasar a resuelta o cerrada, y es la que mide el plazo del SLA. Volver a un estado abierto la vacía.

Edición según el estado. Pendientes y aprobadas se editan; una resuelta solo la reabre o la cierra un administrador; cerradas, rechazadas y eliminadas no se editan.

7.4 Ubicación

Una incidencia se sitúa sobre uno o varios activos, un punto o un área:

• Activos afectados: una incidencia puede tener varios; el primero es el principal.
• Posición GPS tal como la capturó el dispositivo.
• Área afectada propia —una acera, un tramo de parque— dibujada sobre el mapa, de hasta 50 km².
• Dirección textual de respaldo.

Sobre el mapa, el menú contextual ofrece «Nueva incidencia aquí», y la ficha de un activo lista sus incidencias. Las que llegan de la app guardan además si el teléfono marcó su posición como simulada (14.10).

7.5 SLA y plazos

Cada incidencia de una organización con SLA recibe sus fechas límite de respuesta y de resolución, con el mismo criterio que las órdenes: el SLA de incidencias para su criticidad, del cliente, la organización o el global, contado en horario laboral. Se recalculan al cambiar la criticidad, el cliente o la delegación mientras está abierta; una incidencia resuelta, cerrada o rechazada conserva su plazo.

El estado de cada plazo es visible en la tarjeta y en la ficha:

La respuesta se cumple cuando la incidencia sale por primera vez de pendiente; la resolución, con la fecha de resolución. Los plazos alimentan el panel y el portal de cliente.

7.6 Conversión a orden de trabajo

• Generar orden desde la incidencia: crea la orden pendiente, con tipo, prioridad (propuesta a partir de la criticidad) y responsable, y hereda el cliente, todos los activos o el punto o área y la dirección. La incidencia pasa a Aprobada / OT creada.
• Una incidencia se atiende con una sola orden viva: un segundo intento se rechaza indicando qué orden la atiende, aunque dos personas pulsen a la vez.
• Solo se atiende con una orden una incidencia abierta y clasificada.
• Vincular una orden existente, con relación «resuelve» o «detecta» y notas.

7.7 Ficheros

Adjuntos con título, descripción y miniatura, desde la web, el móvil y el portal. Cada fichero se comprueba por dentro, no por su extensión:

• Web: imágenes, PDF, documentos Office modernos sin macros y texto, hasta 20 MB.
• App y portal: imágenes.

Los ficheros se sirven comprobando el acceso, y el portal solo descarga los de su cliente. La ficha muestra las fotos en una galería.

7.8 Visualización y estadísticas

• Capa de incidencias sobre el mapa, con leyenda y filtros propios (estado, criticidad, tipo, fechas, cliente, responsable o personal de la orden que las atiende), aplicados igual en el mapa, el encuadre y el listado. Las áreas afectadas se pintan en una capa propia.
• Listado en tarjetas con el estado del SLA y un menú de acciones.
• Estadísticas: reportadas, resueltas, rechazadas, pendientes, tasa de resolución, tiempo medio de primera respuesta y de resolución.

7.9 Avisos automáticos

Toda incidencia que se crea pendiente genera un aviso, venga de donde venga (web, app, portal, lectura fuera de rango o API): de severidad alta o crítica si su criticidad lo es, media en el resto. Lo reciben quienes tienen asignados los avisos de incidencias en su delegación, nunca quien la creó, y se cierra para todos en cuanto la incidencia deja de estar pendiente.

Cuando una orden termina sin resolver el problema (7.12), sale además el aviso «Incidencia sin resolver», para que alguien cree la siguiente intervención.

7.10 Histórico de estados

Cada cambio de estado queda registrado con el estado anterior, el nuevo, el autor, la fecha y notas, incluidos los que provoca la orden vinculada, las órdenes que terminaron sin resolver el problema y la eliminación con su motivo.

7.11 Eliminación

La eliminación es un borrado lógico con reglas estrictas:

• Solo la pueden hacer un supervisor o un administrador.
• El motivo es obligatorio y queda guardado.
• No se puede eliminar una incidencia con una orden de trabajo vigente.
• La incidencia desaparece de listados, indicadores y mapa, y se retiran sus avisos.
• Solo se elimina desde la web; la app la retira en su siguiente sincronización.

7.12 Estado sincronizado con la orden de trabajo

Con la respuesta «Sí, queda resuelto» (5.24), el estado de la incidencia sigue al de la orden, se cambie desde la web o desde la app:

Con «No», la incidencia sigue abierta con su plazo corriendo, admite una orden nueva y sale el aviso de incidencia sin resolver. Si el cliente responde «no conforme» en el portal, la incidencia vuelve a abierta y pasa a resolverla la orden de revisión (5.21).

7.13 Incidencias sin conexión

La app puede crear incidencias sin cobertura y subirlas después. Un reenvío no la duplica. Al subirla se validan todos sus datos, y los activos dados de alta sin cobertura en la misma subida se procesan antes, para que la incidencia los encuentre.

La app no hace retroceder el estado: lo que la oficina ya aprobó, resolvió o cerró no vuelve a pendiente. Los cambios sobre una incidencia que la oficina también ha tocado se resuelven como conflictos de sincronización (23.15).

7.14 Tipos de incidencia

Catálogo propio de cada organización, con nombre, descripción y marca de activo. Un tipo en uso no se puede eliminar: se desactiva.

7.15 Incidencias por lecturas fuera de rango

Cuando una lectura de contador sale del rango válido de su punto de medición, y el punto lo tiene activado, el sistema abre una incidencia «Posible contador averiado / Fuga», de criticidad alta, con la foto de la lectura si la hay. Como mucho una por lectura. Detalle en 17.9.

7.16 Alta de incidencias por API

Un sistema externo (un ERP, una plataforma de avisos) puede dar de alta incidencias por la API pública, con la referencia del sistema de origen, protección frente a reenvíos y claves que pueden estar limitadas a un cliente. Pasan por el mismo proceso que el alta web —mismas validaciones, avisos y plazos— y entran con origen Integración (API). Los cambios posteriores se pueden notificar por webhooks (capítulo 25).

8. Tipos de mantenimiento, tareas, oficios y habilidades

Disponibilidad: núcleo; los tipos de mantenimiento y las tareas requieren el módulo de mantenimiento; oficios, habilidades y formación dependen de la capacidad de competencias, y el material de las tareas, de la de almacén Superficies: Web · Móvil (consulta y confirmación de EPIs al iniciar) Para qué sirve: define qué trabajo existe, qué hace falta saber para hacerlo y qué hay que llevar. Es la capa que convierte la asignación de trabajo de «a ver quién está libre» en «quién está cualificado, certificado, disponible y cerca», y la preparación del trabajo de «acordarse» en «lo que pide la tarea».

8.1 Tipos de mantenimiento

Catálogo de la organización (clonado del vertical). Cada tipo define:

• Nombre y descripción.
• Si es cíclico (mantenimiento preventivo recurrente).
• Si exige firma del cliente, que se aplica en los clientes cuya política de firma es «según el tipo de mantenimiento» (5.9).
• Duración estimada de una orden de este tipo (capítulo 12).
• Si está activo.

Toda organización tiene además el tipo de sistema «Correctivo inmediato» y el formulario «Parte de trabajo rápido», que usan los partes rápidos de la app.

Un tipo que ya se ha usado en alguna orden no se puede eliminar: se desactiva.

8.2 Tareas

Dentro de cada tipo de mantenimiento se definen las tareas concretas. Cada tarea tiene:

• Nombre y descripción.
• Duración estimada propia, que si está vacía hereda del tipo.
• Si es recursiva: se desglosa por los componentes del activo según su jerarquía.
• Si está activa.
• Lo que hace falta para hacerla: material, herramientas y EPIs (8.8).

En una orden, cada tarea tiene su estado (pendiente, en curso, completada), y se completa con sus formularios (5.7).

8.3 Oficios

Catálogo de especialidades: electricista, fontanero, jardinero, operador de plataforma elevadora… Se relacionan en dos direcciones:

• Tarea → oficios requeridos: qué especialidad hace falta para ejecutarla.
• Persona → oficios: qué especialidades tiene cada operario.

Cuando una tarea requiere oficios, basta con tener uno de ellos; no tener ninguno bloquea la elegibilidad. Un oficio en uso no se elimina: se desactiva.

8.4 Habilidades y certificaciones

Catálogo con nombre, código, categoría y tipo, si es oficial (certificación reconocida), si caduca y su validez por defecto en meses, y la autoridad emisora por defecto.

8.5 Habilidades del personal

Cada persona acumula sus habilidades con:

• Nivel de competencia: básico, intermedio, avanzado, experto.
• Fecha de emisión y fecha de caducidad.
• Número de certificado, autoridad emisora y documento adjunto.
• Estado (activa, caducada, revocada, suspendida) y verificación: quién la verificó y cuándo.

En la aplicación esto aparece como el módulo «Formación / Cursos», y cada usuario ve las suyas en su perfil.

• La verificación tiene valor de constancia: ni quien dio de alta el registro ni la propia persona pueden verificarlo, y cambiar el nivel, las fechas, el certificado o el documento anula la verificación.
• Quitar una habilidad la marca como revocada; no se borra.

Una habilidad cuya fecha de caducidad ya ha pasado no cuenta, aunque siga marcada como activa: el motor de elegibilidad, el planificador, el despacho y la validación de una orden exigen que esté vigente el día del trabajo.

8.6 Requisitos de habilidad en el trabajo

Las habilidades se exigen en dos niveles, con herencia: por tipo de mantenimiento (todas sus tareas lo heredan) y por tarea, que puede sobrescribir lo heredado. Cada requisito declara:

Las obligatorias filtran: quien no las tiene vigentes y con su nivel no es apto. Las recomendadas y preferidas nunca descartan a nadie: puntúan en el motor de elegibilidad (10.1) y en el despacho, y el planificador intenta dar cada orden a quien las tiene (11.10).

8.7 Control de caducidades

Consulta de habilidades por caducar con horizonte configurable, filtrable por nivel de alerta, delegación y categoría, con un resumen agregado, para anticipar renovaciones antes de que un operario deje de ser elegible para su trabajo habitual.

8.8 Material, herramientas y EPIs de las tareas

Cada tarea del catálogo puede declarar lo que hace falta para hacerla:

Catálogo de EPIs. Nombre, descripción y si está activo, con una lista básica (casco, guantes…) que se carga de un clic. Un EPI en uso no se elimina: se desactiva.

Lo que pide una orden se calcula con sus tareas actuales: una orden pendiente recoge los EPIs que se añadan después a sus tareas.

Los EPIs no bloquean el trabajo. La app trabaja sin conexión, así que no se impide el inicio: se registra lo que confirma cada técnico, EPI a EPI, con el motivo si le falta alguno, y se genera un aviso de seguridad «Inicio sin EPI» para el supervisor (capítulo 24).

9. Personal, turnos y disponibilidad

Disponibilidad: núcleo; turnos, festivos, ausencias y excepciones dependen de la capacidad de calendario laboral Superficies: Web · Móvil (declaración de guardias y horas extra) Para qué sirve: modela la disponibilidad real de la plantilla. Es lo que hace que el planificador no asigne trabajo un festivo, durante unas vacaciones o fuera del turno de la persona.

9.1 Ficha de personal

• Nombre, teléfono, email, notas.
• Interno o externo (subcontrata), con nombre de la empresa.
• Coste horario, con histórico de tarifas por fecha (5.10).
• Usuario de la aplicación vinculado (opcional); a una ficha sin acceso se le puede dar acceso después (1.9).
• Delegación de adscripción y almacén por defecto.
• Turno por defecto y vehículo por defecto.
• Zona horaria propia (opcional); vacía, hereda la de su delegación.
• Ubicación de domicilio.
• Dónde empieza y acaba la jornada: en su delegación o en su domicilio. Lo usan los trayectos de flota (capítulo 13) y la proximidad de «Planificar esta OT» (5.4).

Datos reservados. La tarifa, las notas, el domicilio y el motivo de las ausencias (una baja médica es un dato de salud) solo los ve quien puede editar personal; el resto ve quién está disponible, no cuánto cobra ni dónde vive.

Baja y supresión. Pasar a una persona a inactiva con órdenes sin terminar o con material en su almacén personal avisa de lo pendiente y permite confirmar. Eliminarla es una supresión RGPD: se anonimiza con su cuenta y su localización, se conservan sus órdenes, costes e historiales, y se congela su parte de horas (capítulo 25).

9.2 Turnos

Catálogo de turnos:

• Nombre, hora de inicio y de fin.
• Días laborables del turno.
• Descanso dentro del turno, que el planificador respeta como pausa.
• Turno vinculado a una delegación.
• Si está activo.

Los turnos se asignan a personas y a equipos. Un turno en uso no se elimina: se desactiva.

Las horas de un turno son hora local del operario. Un turno que cruza la medianoche (por ejemplo, de 22:00 a 06:00) pertenece al día en que empieza y termina al día siguiente. Así lo leen la disponibilidad, el planificador, la capacidad del panel, el seguimiento GPS y el cierre automático de jornada.

9.3 Festivos

Calendario de festivos, con:

• Fecha, nombre y ámbito (nacional, autonómico, local o de empresa).
• Delegación concreta, o global para toda la organización.
• Si está activo: un festivo desactivado (se trabaja ese día) no cuenta.
• Alta en bloque del calendario de un año. La carga se cruza por fecha con lo existente: lo que sigue se conserva, lo que cambia de nombre se renombra y lo nuevo se añade; lo que ya no viene se propone quitar, pero no se quita sin confirmar.

Cada festivo vale solo en su fecha: los festivos de fecha variable (Pascua) no se pueden repetir correctamente de un año a otro, así que cada año se importa o se crea su calendario. En un mismo calendario, un día es festivo o no lo es: no puede haber dos festivos en la misma fecha.

El calendario de una delegación muestra sus festivos y los de toda la organización, que es como los descuentan la disponibilidad, la capacidad, el SLA y el planificador.

9.4 Ausencias

Vacaciones, bajas y permisos, con:

• Rango de fecha y hora, y marca de jornada completa o parcial, en la hora del trabajador.
• Tipo de ausencia (vacaciones, baja, asunto propio, formación, maternidad/paternidad, sin sueldo, otra) y estado (confirmada, provisional, cancelada).
• Persona que cubre la ausencia.
• Comprobación de solapamiento con las confirmadas.
• Cancelación sin borrar el registro. Una ausencia ya empezada no se elimina, porque forma parte del calendario pasado: se cancela.

Solo las ausencias confirmadas recortan la disponibilidad: en el planificador, en el motor de elegibilidad, en el despacho y en el parte de horas.

9.5 Excepciones puntuales de calendario

Para el día concreto en que alguien entra más tarde, hace turno partido o cambia de turno. Cinco tipos:

Una guardia o jornada extra puede cruzar la medianoche, igual que un turno nocturno.

El propio operario puede declarar desde la app una guardia, una jornada extra o una ampliación de jornada. Existe porque en una urgencia nocturna nadie la crea a tiempo, y sin ella su seguimiento GPS y su kilometraje no se registrarían. Surte efecto al momento, queda marcada como autodeclarada y por revisar, y un responsable la da por buena, la edita o la elimina.

Cada usuario con ficha ve «Mi calendario» en su perfil (1.11).

9.6 Cascada de resolución del horario efectivo

Para una persona y una fecha, el horario que realmente aplica se resuelve en cascada:

1. Excepción puntual de ese día, si existe.
2. Turno por defecto de la persona, si ese día es laborable en el turno.
3. Sin turno, el horario semanal de su delegación o de la empresa (9.8).
4. Descontando el festivo aplicable a su delegación.
5. Descontando las ausencias confirmadas.

Las horas se leen en la zona horaria de la persona. La misma cascada la usan el planificador, el seguimiento GPS, el cierre automático de jornada, el parte de horas, el motor de elegibilidad y los asistentes del alta.

9.7 Consulta de disponibilidad

Consulta de disponibilidad de una persona para un instante y una duración, que devuelve si está disponible y el motivo: dada de baja, ausencia, otra orden que solapa, día libre, guardia o jornada extra, festivo, sin turno pero dentro del horario de la empresa, turno desactivado, día no laborable, fuera de horario, en el descanso o dentro de su turno. El formulario de la orden muestra estos motivos con su etiqueta legible.

9.8 Horario laboral de la empresa y jornada sin turno

El horario laboral semanal se configura para la empresa (2.8) y, si una delegación lo necesita, como horario propio de la delegación (3.5). Tiene hasta dos franjas por día de la semana (jornada partida) y admite franjas nocturnas; un día sin franjas no es laborable. Lo leen la disponibilidad, el SLA (19.9), la jornada de la orden, el seguimiento GPS, el parte de horas y el planificador.

• Una persona sin turno asignado trabaja en las franjas del horario de su delegación o de la empresa, también en el planificador.
• El planificador ajusta la ventana de turno de cada recurso al horario de su delegación día a día y toma el hueco entre franjas como pausa. Un turno nocturno no se recorta con la jornada de oficina.

9.9 Zona horaria

Turnos, ausencias y horarios están en hora local. Una persona se lee en su zona, o en la de su delegación, o en la de la organización (2.13). Así, la capacidad del panel descuenta las ausencias de cada persona en su zona, el planificador arma la jornada de cada recurso en la suya y las ausencias se editan en la hora del trabajador.

9.10 Horas por operario

Pantalla y exportación CSV con las horas trabajadas por persona y día en un rango de hasta un año, filtrables por persona y delegación. Salen del parte de horas de las órdenes (5.19), con las horas normales y extra separadas y lo pendiente de revisar aparte.

10. Elegibilidad y despacho inteligente

Disponibilidad: núcleo; la planificación de una orden desde su alta requiere el módulo de planificación; el despacho al más cercano y la inserción en la jornada, el módulo de campo en tiempo real Superficies: Web Para qué sirve: responde a la pregunta operativa real —«¿a quién le doy esto y para cuándo?»— combinando cualificación, certificación vigente, disponibilidad horaria y distancia real por carretera, no distancia en línea recta. Los tiempos de viaje son los de la red viaria, sin tráfico.

10.1 Motor de elegibilidad

Para una tarea, una fecha y hora y una duración, el sistema evalúa a toda la plantilla activa y devuelve por cada persona:

Puntuación por competencias: solo puntúan los candidatos elegibles, con 30 puntos por cada habilidad recomendada que cumplen y 10 por cada preferida.

Las personas con rol de solo lectura o de almacén salen como no disponibles: no hacen trabajo de campo.

10.2 Puntuación por proximidad real

Sobre esa base, el sistema añade una puntuación de proximidad de 0 a 50 puntos:

1. Toma la ubicación de la orden: su punto propio o el centro de sus activos.
2. Calcula el tiempo de viaje real por carretera hasta cada delegación activa.
3. Lo convierte en puntos: menos de 15 min, 50; menos de 30, 35; menos de 60, 20; menos de 90, 10; más, 0.

Si la orden no tiene ubicación o el cálculo de rutas no está disponible, se devuelven los resultados sin proximidad en lugar de fallar. «Planificar esta OT» (5.4) usa una variante que mide desde el punto de arranque real de cada unidad.

10.3 Elegibilidad de equipos

Existe un motor equivalente para equipos, con el mismo criterio aplicado a la unión de los miembros presentes en la franja: un equipo es elegible si algún miembro está disponible, la unión de todos cubre las habilidades obligatorias y alguno tiene el oficio requerido. Devuelve también por qué no lo es cuando no lo es: ningún miembro disponible, día no laborable o franja fuera del turno del equipo, habilidades u oficio que faltan.

10.4 Múltiples tareas en una orden

Cuando la orden tiene varias tareas, una persona es elegible solo si cumple los requisitos de todas. Las habilidades deseables se cuentan sin inflar la puntuación por compartirse entre varias tareas.

10.5 Búsqueda de la primera franja con recurso apto

Sin fecha fijada, el sistema busca la primera fecha y hora en que existe al menos una unidad —equipo u operario— cualificada y libre, en las franjas del horario semanal, con el trabajo cabiendo entero en una franja y sin proponer nunca la hora de comer. Recorre como mucho 45 días. Si no encuentra a nadie, devuelve la evaluación de la primera franja, para que la interfaz pueda explicar por qué no hay nadie en lugar de mostrar un vacío.

10.6 Despacho al más cercano

Despacho para la urgencia: dado un punto en el mapa, devuelve los operarios más cercanos (5 por defecto, hasta 20) entre los que tienen seguimiento activo y una posición de las últimas dos horas, con:

• Su última posición y hace cuánto se recibió.
• Su vehículo activo.
• Si tienen ya una orden en curso: siguen saliendo, marcados como ocupados.
• Filtro por habilidades requeridas, vigentes y con su nivel mínimo.
• Radio máximo de búsqueda (20 km por defecto, hasta 200), que se amplía una vez si no hay nadie.

Solo propone a quien puede ir: personal activo y sin ausencia confirmada. Una posición reciente no basta, porque el móvil de alguien de vacaciones puede seguir enviando puntos.

La ordenación usa tiempos reales de viaje por carretera: el operario a 2 km al otro lado del río no es el más cercano.

Para una orden concreta, el despacho exige además la formación obligatoria de sus tareas con su nivel mínimo, y muestra en cada candidato su formación deseable (con estrellas, sin descartar a nadie) y si le faltaría material (11.11). Lo usa la acción «Asignar al más cercano…», desde la orden, el mapa o el tablero de despacho.

10.7 Avisos del asistente

«Planificar esta OT» añade dos avisos, que no descartan a nadie:

• No llega a su siguiente orden: si terminar, desplazarse y dejar 20 minutos de margen no cabe antes de su próxima orden de las 12 horas siguientes.
• La orden no tiene dónde medir: sin activos situados ni ubicación propia, se planifica solo por aptitud, y se dice expresamente.

10.8 Meter una orden en la jornada de un técnico

Para una orden pendiente, cada candidato sale con lo que cuesta meterla en su jornada: el sistema recalcula su ruta del día sin la orden nueva y con ella, y la diferencia es el impacto.

Candidatos. Los cercanos con posición GPS y, además, los que tienen su delegación cerca, con o sin GPS, con la formación obligatoria y sin roles de oficina.

Qué día. Primero hoy, con lo que le queda de jornada; si no cabe, cada uno de los tres días siguientes, hasta el primero en que cabe. La jornada es la del planificador: turno, horario, festivos, ausencias y descansos.

Su agenda. Se pueden mover las órdenes pendientes que solo tiene él, dentro de su plazo; no se mueven las compartidas, las pausadas ni las que no tienen ubicación, y la orden en curso se respeta. Una orden urgente puede desplazar a las de menos prioridad, que vuelven a «Por despachar»; una no urgente no echa a nadie de más prioridad.

Qué enseña cada candidato. Si es viable y qué día; a qué hora llegaría y si llega dentro de su plazo; cuánto conduce de más; qué órdenes de su agenda cambian de hora y cuáles dejan de caberle; su formación deseable; y si el material está disponible o tendría que pasar a recogerlo (11.11).

Nada se aplica solo. El supervisor elige un candidato y, al confirmar, el sistema comprueba primero que ninguna de las órdenes implicadas ha cambiado desde la propuesta; si alguna lo ha hecho, hay que volver a calcular. Cada cambio queda en la cronología de su orden.

11. Planificador multi-día de órdenes de trabajo

Disponibilidad: módulo de planificación Superficies: Web (vista «Optimizador» de la pestaña Planificación) Para qué sirve: reparte automáticamente la cartera de órdenes pendientes entre los recursos disponibles a lo largo de varios días, minimizando desplazamiento y respetando todas las restricciones reales de la plantilla. Sustituye la planificación manual sobre un calendario.

11.1 Qué resuelve

Un problema de rutas con ventanas temporales en varios días, sobre tiempos y distancias reales por carretera (sin tráfico). El ámbito es local: no está pensado para rutas de cientos de kilómetros.

Cada combinación de recurso × día disponible es un vehículo del problema, de modo que una sola optimización reparte el trabajo en todo el horizonte, en lugar de resolver día a día y encadenar decisiones subóptimas.

Un equipo es una sola unidad de ruta: sus capacidades diarias son la unión de las de sus miembros presentes ese día.

Qué órdenes entran. Las pendientes aún no planificadas cuyo vencimiento (5.25) no sea posterior al rango. Si no se eligen órdenes concretas, solo entran las cercanas a las delegaciones de los recursos y, con un cliente elegido en el mapa, solo las suyas. Si se eligen, manda la selección, y las que no son candidatas se explican con su motivo. Una orden sin ubicación queda sin asignar con ese motivo.

11.2 Restricciones que respeta

La vigencia de las certificaciones se comprueba día a día: un certificado que caduca a mitad del horizonte vale hasta ese día y no después.

Turnos nocturnos. Un turno que cruza la medianoche se planifica entero, con su pausa dentro, y lo que cae pasada la medianoche se marca «(+1)».

Equipos. Un día cuenta con los miembros presentes, sin los ausentes ni los que tienen festivo en su delegación; al aplicar, solo se asigna a los presentes.

Punto de salida. Cada operario sale de su delegación y vuelve a ella. Si la delegación no tiene ubicación, sale de un almacén y el plan avisa para que se complete.

Días excluidos. El plan lista cada recurso-día que no se ha podido usar y por qué: sin turno, día no laborable, festivo (con su nombre), ausencia, todos los miembros ausentes, turno nocturno del día anterior o agenda completa.

11.3 Prioridad con presión por vencimiento

La prioridad que usa el optimizador suma a la de la orden una presión por vencimiento:

(con un total máximo de 100). Una orden de prioridad media ya vencida compite de tú a tú con una alta sin urgencia: las órdenes que aprietan expulsan de la ruta a las que no. Una orden vencida se planifica en el primer hueco disponible.

11.4 Reparto equilibrado

Opción «equilibrar carga» (activa por defecto): limita las órdenes nuevas por recurso y día, para que el trabajo se reparta en lugar de concentrarse en quien tiene la ruta más barata.

11.5 Límites operativos

• Horizonte máximo: 14 días.
• Hasta 500 recurso-días y 500 ubicaciones distintas por plan.
• Ventana mínima útil de 1 hora tras los recortes de horario, ausencias y descansos.
• Cada recurso se planifica en su zona horaria.
• Hay que seleccionar al menos un equipo o un operario.

11.6 Ciclo del plan: borrador → aplicado

Un plan no modifica nada al generarse. Se crea como borrador y guarda el rango, el autor, la entrada y la salida completas del cálculo (para poder explicar cada decisión) y un resumen: rutas por recurso y día con la hora de llegada y salida de cada orden, órdenes asignadas, órdenes sin asignar con su explicación (11.8), días excluidos, avisos, distancia y duración totales.

Desde ahí se puede:

• Aplicar — antes de escribir nada se comprueba que el plan sigue valiendo: si alguna orden ha cambiado, si alguien ya no está disponible a esa hora o si la hora planificada ya ha pasado, no se aplica nada y se informa de los cambios, para generar otro plan. Si vale, las órdenes reciben su personal y sus fechas planificadas, siguen pendientes y aparecen en el calendario, el Kanban y la vista por técnico. La agenda que ya tenía cada recurso no se toca.
• Descartar — el plan queda archivado sin efecto.

11.7 Resiliencia

Si el servicio de cálculo de rutas o de optimización cae, el sistema deja de intentarlo unos minutos y lo dice con claridad, en lugar de dejar las peticiones esperando. Si no se pueden obtener los tiempos por carretera, se planifica igualmente con una estimación aproximada y el plan lleva un aviso para revisarlo antes de aplicarlo.

11.8 Por qué se queda una orden sin cubrir

El detalle del plan explica bajo cada orden sin asignar el motivo y qué tocar para resolverlo:

Antes del cálculo, una orden puede quedar fuera también por no tener ubicación, porque su personal fijado no está en el plan, o por falta de material (11.11).

11.9 Agenda ya asignada

El tiempo que el personal ya tiene comprometido no está libre. Las órdenes abiertas de los operarios elegidos con franja en el rango entran como paradas fijas: ocupan su trabajo y su desplazamiento, solo dentro de su franja, y no se replanifican. El detalle las muestra en su sitio de la ruta como «ya en su agenda». Una jornada ya llena no recibe nada nuevo.

11.10 Formación recomendada y preferida

La formación deseable no descarta a nadie, pero el planificador intenta dar cada orden a quien la tiene. El resultado solo se acepta si cubre al menos lo mismo que el plan sin preferencias; si no, se queda el de siempre y el plan lo avisa. Cada orden indica cuántas de sus habilidades deseables tiene quien la hace.

11.11 Material al planificar

Con almacén, la organización elige qué hacen el optimizador y el despacho con el material pendiente de las órdenes:

En el modo Exigir, para cada recurso: si lo lleva en su furgoneta, va directo; si está en su almacén de salida, lo carga al salir; si está en otro almacén, pasa antes a recogerlo (una parada de recogida); si no, la orden queda sin cubrir con la lista de lo que falta. Al aplicar el plan, las líneas pasan a salir del almacén elegido. Las herramientas no cuentan.

12. Presupuesto de tiempo (duración efectiva)

Disponibilidad: núcleo Superficies: Web (alta de orden, fichas de tipos de mantenimiento y de tareas) · lo usan el planificador, el despacho, la capacidad y los asistentes Para qué sirve: que la duración estimada de una orden no sea un número inventado. Es la pieza que convierte el histórico real de ejecución en una estimación que mejora sola con el uso.

12.1 Jerarquía de resolución

Única fuente de verdad para «cuánto va a durar esto», con esta prioridad:

1. Duración fijada a mano en la orden: si está informada, manda siempre.
2. Si la orden tiene tareas, cada tarea aporta su duración explícita o, si no la tiene, la mediana histórica real de esa tarea, si hay al menos 5 muestras. Si todas resuelven, se suman; si alguna no, se toma el mayor entre esa suma y la duración del tipo (regla de suelo: nunca estimar por debajo de lo que dice el tipo).
3. Sin tareas, la duración del tipo de mantenimiento: su mediana histórica si hay al menos 5 muestras; si no, la configurada; y en último término, 30 minutos.

El formulario de alta dice siempre de dónde sale la cifra.

12.2 Qué gana a qué

El histórico gana a la estimación configurada del tipo —el dato real vale más que la configuración inicial—, pero nunca gana a la duración fijada en la orden ni a la duración explícita de una tarea. Un planificador que sabe que esta orden concreta va a llevar cuatro horas puede decirlo, y el sistema no le corrige.

12.3 Quién la usa

• El planificador, como tiempo de servicio de cada parada, y el despacho, para medir el impacto en una jornada.
• La capacidad del personal (20.11).
• El alta de la orden, que rellena la duración automáticamente y propone el fin previsto. La fecha límite no se deriva de la duración.
• Los asistentes de planificación, que exigen que la duración quepa entera en una franja del horario.
• El informe PDF, junto a la duración real, y las fichas de tipos y tareas, con su mediana histórica y el número de muestras.

La duración estimada es un presupuesto, no la mano de obra: el coste de cada persona sale de su parte de horas (5.19).

12.4 De dónde sale el histórico

La mediana se calcula sobre las órdenes terminadas, con la primera fuente disponible:

El tiempo en curso excluye las pausas y las noches: una orden empezada un día y terminada al siguiente no aporta un día entero de trabajo. La mediana de una tarea solo se nutre de órdenes que tienen esa única tarea. El histórico se actualiza cada 15 minutos.

13. Flota de vehículos

Disponibilidad: módulo de flota y costes Superficies: Web · Móvil (check-in de vehículo) Para qué sirve: imputar el coste real de desplazamiento a cada orden de trabajo, separar los kilómetros de trabajo de los de ir y volver, y saber en todo momento quién conduce qué. Sin flota, el coste de una orden cubre materiales y horas; con flota, cubre también kilómetros y combustible a precio real.

13.1 Inventario de vehículos

Ficha con:

• Matrícula, tipo (furgoneta, turismo, camión ligero o moto), marca, modelo y año.
• Combustible: diésel, gasolina, eléctrico, híbrido, GLP o GNC.
• Consumo en l/100 km o kWh/100 km, obligatorio según el combustible.
• Capacidad del depósito y odómetro, que se actualiza solo con cada trayecto.
• Delegación.
• Estado activo/inactivo. Un vehículo no se borra: se desactiva, y no se puede desactivar con asignaciones en curso.

Una furgoneta de almacén (3.7) se enlaza con un vehículo: el material va con el vehículo, lo conduzca quien lo conduzca.

13.2 Precios de combustible

Dos fuentes complementarias:

a) Precios propios de la organización, con periodo de validez, en su moneda. Reflejan el precio real de la tarjeta de flota o del contrato de suministro. Un precio nuevo cierra el anterior, y un precio puntual dentro de otro más largo lo parte en dos sin perderlo.

b) Índice oficial automático. El sistema consulta cada 30 minutos los precios de carburantes que publica el Ministerio para la Transición Ecológica y guarda el precio medio por tipo de combustible. Solo se aplica a organizaciones que trabajan en euros; con otra moneda, o en vehículos eléctricos, hace falta precio propio.

13.3 Asignación operario ↔ vehículo

El registro de qué persona lleva qué vehículo y desde cuándo, con periodo de vigencia, método, nivel de confianza, estado y revisión.

Reglas de solape:

• Un vehículo, un operario a la vez, para que el mismo viaje no se cuente dos veces. En el check-in, quien escanea el vehículo se lo lleva.
• Una asignación por operario a la vez: la nueva recorta la anterior, y una asignación puntual dentro de otra más larga la parte sin perderla.

13.4 Revisión de asignaciones dudosas

Una asignación de confianza baja genera un aviso de vehículo pendiente de revisión, con un listado propio y acciones de confirmar o corregir. Solo existe en organizaciones con el módulo de flota. La pestaña Avisos de Vehículos reúne estos avisos y los de autopausa (14.6).

13.5 Tramos de ruta y coste real

Cada desplazamiento relevante se guarda como tramo de ruta con:

• Origen y destino (base, domicilio, orden de trabajo…) y su momento.
• Distancia y duración reales por carretera, con el trazado del recorrido.
• Vehículo vigente en ese momento.
• Fotografía del coste: precio del combustible ese día, consumo del vehículo y coste del tramo. Se guarda el coste del momento: recalcular meses después con el precio de hoy falsearía la contabilidad.
• Categoría: trabajo, desplazamiento desde la base, vuelta a la base o administrativo.
• Orden de trabajo a la que se imputa, solo en los tramos de trabajo.

Cómo nacen los tramos. Cada vez que la geovalla confirma la llegada de un operario a la zona de una orden (capítulo 15):

• Si en la misma jornada había salido ya de otra orden, se genera el tramo de trabajo entre las dos, imputado a la orden de destino.
• Si es la primera llegada de la jornada, el tramo sale de su base —delegación o domicilio, según su ficha— como desplazamiento, sin imputarse a ninguna orden.
• La vuelta a la base de cada jornada terminada se calcula sola. Si la jornada terminó con el operario dentro de una zona (móvil apagado), no se inventa la vuelta.

La jornada es la del turno, no el día natural: un turno de noche no genera a medianoche una vuelta y una salida que nadie recorrió. Una base a más de 150 km de la orden no genera tramo, y las llegadas detectadas con posiciones simuladas (14.10) tampoco: no prueban el viaje.

Dónde se ve el coste.

• El combustible de los tramos de trabajo forma la partida de vehículo del coste real de la orden (5.10), con desglose por vehículo y el trayecto en el mapa.
• Los kilómetros de desplazamiento y vuelta no se imputan a ninguna orden: el informe de costes los da aparte (20.10).

13.6 Consulta de tramos: pestaña Recorridos

La pestaña Recorridos de Vehículos muestra, para un vehículo y un periodo, el número de trayectos, los kilómetros separados en trabajo y desplazamiento, el tiempo al volante y el combustible, el mapa con los trazados y la tabla de trayectos. Los trayectos de una persona se ven también desde su seguimiento GPS, y los de una orden, desde la orden. Se puede crear un tramo a mano. La pestaña avisa de los operarios sin base con ubicación, cuyo primer trayecto y vuelta no se pueden contar.

13.7 Flota en el panel de control

Sección «Flota y seguimiento» del panel de control (20.12), para periodos de hasta un año: trayectos, kilómetros (y cuántos no son de trabajo), horas de conducción y combustible, por persona, vehículo o mes, con los tramos sin coste contados aparte para que el total no parezca completo cuando no lo es.

14. Telemetría y tracking GPS

Disponibilidad: módulo de campo en tiempo real Superficies: Móvil (emisión) · Web (consulta, mapa y pantalla Tracking GPS) Para qué sirve: saber dónde está el equipo en campo para despachar urgencias, registrar la presencia en el punto de trabajo y calcular desplazamientos reales — con un diseño construido alrededor de las obligaciones legales de geolocalización laboral.

Ver la posición de otras personas es un permiso propio, separado de ver el personal: por defecto lo tienen el supervisor y el administrador.

14.1 Sesiones de seguimiento: el ancla legal

El seguimiento no es continuo: se organiza en sesiones con inicio y fin explícitos. Cada sesión guarda el momento y la posición de inicio y de fin, el motivo de cierre (el operario cierra su jornada, fin de jornada automático, inactividad, retirada del consentimiento o franja recuperada tras estar sin cobertura), la versión del consentimiento bajo la que se capturó y el dispositivo.

Esta estructura es la que materializa el cumplimiento del artículo 90 de la LOPDGDD (geolocalización en el ámbito laboral): hay un consentimiento versionado y registrado, un inicio y un fin acotados, y no una recogida indefinida.

14.2 Recepción de posiciones con validación de horario y de consentimiento

La app acumula posiciones y las envía en lotes. El sistema:

1. Las ordena por su hora de captura.
2. Descarta una a una las que no se pueden guardar (demasiado antiguas, en el futuro, imposibles), sin rechazar el lote entero.
3. Comprueba el consentimiento contra el registro de la organización: si el operario no ha aceptado el aviso vigente, o lo ha retirado, no se guarda nada y la app sabe si debe pedir la aceptación.
4. Comprueba por cada posición si cae dentro del horario laboral de esa persona, con 15 minutos de cortesía, teniendo en cuenta turnos, cambios de turno, días libres, guardias, horas extra y turnos nocturnos. Las posiciones fuera de horario se rechazan.
5. Descarta los reenvíos, para que un lote repetido no duplique nada.
6. Pasa las posiciones nuevas por la geovalla (capítulo 15).

Cada posición aceptada guarda: lugar, precisión, velocidad, rumbo, batería, si el dispositivo está en movimiento, si la posición era simulada (14.10) y el vehículo activo de esa persona en ese instante.

14.3 Conservación

Las posiciones se conservan 60 días y se eliminan automáticamente. Los demás rastros de localización también caducan: a los 60 días se vacían las posiciones de inicio y fin de las sesiones, el trazado de los tramos de ruta y la posición de los eventos de las órdenes, y se conservan las fechas, los kilómetros, la duración y el coste. El registro de accesos a la localización se conserva dos años.

14.4 Consultas

• Posiciones actuales: la última posición de cada operario de las últimas 2 horas, con hace cuánto llegó, batería, velocidad, vehículo, si era simulada y la orden que tiene en curso, enlazada en el mapa. Es la capa «Posiciones GPS».
• Mi recorrido, mis sesiones y mi exportación: cada operario consulta y descarga su propio historial desde la app.
• Recorrido de una persona para un rango de fechas, junto con sus trayectos de flota.
• Exportación de la localización de una persona en JSON o CSV.

Cuando un recorrido o una exportación llegan a su tope, se dice expresamente y se indica desde dónde continuar.

Cada acceso a la localización de una persona queda registrado: quién, sobre quién, qué acción, qué rango y cuántos puntos, en cumplimiento del principio de integridad y confidencialidad (art. 5.1.f RGPD).

14.5 Derechos LOPDGDD

14.6 Cierre de jornada automático

Cada 15 minutos el sistema comprueba, en la zona horaria de cada operario con seguimiento abierto, si su jornada ha terminado (con su margen). Nunca cierra con el operario dentro de su horario. Si ha terminado:

1. Cierra la sesión de seguimiento.
2. Pausa cada orden en curso en la que ya no queda nadie trabajando: si dos operarios comparten una orden y uno termina a las 15:00 y el otro a las 19:00, la orden sigue en curso hasta que acaba el segundo.
3. Emite un aviso de «Orden pausada al cierre de jornada» para que al día siguiente se confirme la reanudación.

Resuelve un problema real y muy común: las órdenes que quedan «en curso» durante días porque nadie se acordó de cerrarlas. La pausa automática no detiene el plazo del SLA.

14.7 Actividad fuera de turno y regularización

Las posiciones rechazadas por caer fuera del horario no se guardan —fuera de la jornada no hay base legal para guardarlas—, pero el sistema anota por operario y día cuántas fueron y entre qué horas, sin coordenadas.

La pestaña Actividad fuera de turno de Tracking GPS lista esas franjas, para detectar la guardia o la hora extra que nadie declaró. El responsable crea la excepción de calendario que la cubre, y la franja queda regularizada; la excepción habilita el seguimiento hacia delante.

14.8 Aviso de geolocalización y consentimiento

El responsable del tratamiento es la organización, así que el texto del aviso lo publica ella:

• La pestaña Aviso de geolocalización publica redacciones versionadas. Las anteriores no se borran, porque los datos recogidos bajo ellas necesitan su texto para acreditar qué se informó.
• Sin ninguna versión publicada no se captura nada.
• El operario acepta el aviso desde la app (se registran versión, fecha y dispositivo), puede retirarlo y puede consultar su historial.

14.9 Ventanas de horario para la app

La app conoce las ventanas de horario propias del operario para los próximos días, con el mismo criterio que aplica el servidor, para no gastar batería ni datos en posiciones que se van a rechazar.

14.10 Posiciones simuladas

El sistema operativo del móvil marca las posiciones que proceden de una aplicación de ubicación falsa. Se guardan señaladas (o, si la organización lo prefiere, se descartan), también en fotos, firmas, incidencias, partes rápidos y campos GPS de formularios, y el supervisor recibe un aviso de «Posiciones simuladas» que dice cuántas y cuándo, nunca dónde. Una llegada detectada con posiciones simuladas no genera kilómetros (13.5). Detecta el caso habitual, no es una prueba: un móvil manipulado puede ocultarlo.

14.11 Captura con la pantalla apagada

La app puede capturar y enviar la posición con la pantalla apagada. Esos lotes pasan por exactamente las mismas comprobaciones de horario, consentimiento, duplicados y geovalla, y una posición mala nunca hace perder el resto del lote.

14.12 Pantalla Tracking GPS

Pantalla web del módulo con tres pestañas: Actividad fuera de turno (14.7), Revisión de geovalla (15.9) y Aviso de geolocalización (14.8).

15. Geovalla y registro de presencia en campo

Disponibilidad: módulo de campo en tiempo real; el coste de los tramos requiere además el de flota Superficies: Móvil (detección y pregunta al operario) · Web (actividad de la orden, revisión y configuración) Para qué sirve: que la llegada y la salida del técnico queden registradas con evidencia geoposicionada, que la app le pregunte en el momento justo si inicia o termina el trabajo, y que el desplazamiento se calcule con su coste. El sistema nunca cambia el estado de una orden por la geovalla: los cambios de estado los decide siempre el operario.

15.1 Detección de llegada y salida

Cada posición se compara con las zonas de las órdenes abiertas asignadas a esa persona: sus activos y, si la tiene, su ubicación propia (5.14). La distancia se mide a la geometría, no a su centro: dentro de un polígono es cero.

El radio de llegada es fijo: 200 m. La salida se cuenta a 300 m: entre los dos radios no se confirma nada, para que un operario en el borde no genere entradas y salidas en bucle.

Por eso pasar por delante sin parar no es llegar. El cruce se fecha en la primera posición de la racha, que es cuando de verdad se cruzó, y un reenvío no genera cruces dos veces. Las posiciones que llegan con mucho retraso registran sus cruces, pero no generan tramo ni aviso.

15.2 Eventos geoposicionados de la orden

Cada detección relevante genera un evento de la orden con su tipo, qué lo disparó, momento, posición, nivel de confianza y contexto (activo alcanzado, distancia, precisión). Es un registro complementario al histórico de estados: el histórico dice qué cambió, el evento dice dónde y por qué. La posición del evento caduca a los 60 días (14.3).

15.3 Inicio al llegar: lo decide el operario

El sistema no inicia, no reanuda, no pausa ni cierra ninguna orden por la geovalla.

• La app detecta y pregunta. Al llegar a una orden pendiente pregunta al operario si la inicia (o si reanuda una pausada); al salir con la orden en curso, si la ha terminado. No lo ofrece si ya tiene otra orden en curso, ni por órdenes planificadas para otro día. Las zonas viajan a la app para funcionar sin conexión.
• El sistema registra y avisa. Registra llegadas y salidas (prueba de presencia, duraciones, tramos) y, si el operario sale con la orden en curso, avisa al supervisor con «Operario fuera de zona con OT en curso», salvo que otro operario de la orden siga dentro. El aviso se cierra solo cuando vuelve o la orden deja de estar en curso.

Cuando el operario acepta la pregunta, el cambio de estado queda marcado como «Iniciada al llegar» o «Reanudada al llegar», con la posición del móvil. Nadie cierra una orden automáticamente: el cierre lleva fechas, formularios, fotos y firma que solo el operario puede aportar.

15.4 Tramo de ruta automático

Con el módulo de flota, cada llegada confirmada genera el tramo de ruta hasta la orden, con distancia y duración reales por carretera, trazado y coste: desde la última salida de la jornada, como trabajo imputado a esa orden, o desde la base si es la primera llegada del día, como desplazamiento (13.5). Si el cálculo falla, las posiciones se guardan igualmente.

15.5 Avisos que se resuelven solos

Cuando una orden cambia de estado, se cierran solos los avisos cuya causa ha desaparecido: el de pausa al cierre de jornada cuando se reanuda o termina, y el de operario fuera de zona cuando deja de estar en curso. Si un cierre desde la app se deshace (por falta de firma, formulario o conformidad), los avisos vuelven a su estado anterior.

15.6 Detección de órdenes estancadas

Una tarea diaria marca como «necesita revisión», sin cambiar su estado, las órdenes pausadas más días de los configurados (3 por defecto). La decisión sigue siendo humana.

15.7 Órdenes en curso sin posiciones

Sin posiciones no se puede confirmar una salida. Cada 10 minutos el sistema busca órdenes en curso cuyo operario estaba dentro de la zona y lleva más de 45 minutos (configurable) sin enviar posiciones —móvil apagado, sin batería o app cerrada— y las marca para revisión sin tocar su estado.

15.8 Ajustes de la organización

En Configuración → Geovalla, cada ajuste con su explicación: avisar o no al salir con la orden en curso, precisión máxima, posiciones y minutos para confirmar llegada y salida, velocidad por debajo de la cual se considera parado, margen del radio de salida, minutos sin posiciones antes de marcar una orden y si se descartan las posiciones simuladas. El radio de llegada (200 m) no es configurable.

15.9 Revisión en la web

• Pestaña Actividad de la orden: línea de tiempo con el historial de estados y su origen, llegadas y salidas, avisos de revisión y fechas planificadas y reales. Con permiso de seguimiento se ven además la distancia y la precisión de cada cruce y «Ver en el mapa» dibuja las posiciones alrededor; ese acceso queda registrado.
• Revisión de geovalla en Tracking GPS: operarios fuera de zona con orden en curso, órdenes en curso sin posiciones, móviles con posiciones simuladas y posibles visitas sin registrar pendientes de confirmar o descartar.

16. Inventario, almacenes y compras

Disponibilidad: módulo de mantenimiento, con la capacidad de almacén; el coste de una orden exige además la de costes Superficies: Web · Móvil (consumo en la orden y «Mi furgoneta») Para qué sirve: controlar el material por almacén —incluida la furgoneta de cada operario—, saber cuánto está ya comprometido por las órdenes abiertas, valorarlo correctamente y saber cuánto material se ha ido en cada activo y en cada orden.

16.1 Categorías y artículos

• Categorías jerárquicas con color e icono.
• Artículos con código interno, nombre, descripción, fabricante y referencia, unidad de medida, precio de coste (el precio medio, con 4 decimales), último precio de compra, precio de venta, impuesto, imágenes, proveedor preferente, si es una herramienta —las herramientas nunca mueven stock— y a qué tipo de activo corresponde.

El catálogo muestra todos los artículos, también los que no tienen stock, con su stock total, lo comprometido y lo libre (16.2). Eliminar un artículo que usa una orden abierta no se permite; si se puede, su stock se regulariza a cero con su movimiento y el artículo queda en una papelera consultable.

16.2 Stock por almacén y comprometido

El stock no vive en el artículo, sino en cada almacén: cantidad, stock mínimo propio de ese almacén, ubicación dentro del almacén (pasillo, estantería) y fecha del último inventario. Así, la misma referencia puede tener mínimo 50 en el almacén central y mínimo 2 en cada furgoneta.

Comprometido y libre. El comprometido de un artículo en un almacén es lo que las órdenes abiertas aún tienen que sacar de él; libre es el stock menos lo comprometido. Se muestra en el catálogo, en la ficha del artículo y en el stock de cada almacén, y se puede consultar qué órdenes lo comprometen.

Los almacenes son de tres tipos (3.7): físico, móvil (la furgoneta, vinculada a un operario o a un vehículo) y virtual. Con la furgoneta enlazada a un vehículo, el material va con el vehículo: lo saca quien lo lleva ese día.

Un almacén solo se desactiva sin stock, y un almacén inactivo no recibe entradas ni traspasos.

16.3 Movimientos de stock: una sola vía

Todo cambio de existencias pasa por una única vía, que actualiza la cantidad y deja el movimiento en el mismo paso: no se puede cambiar el stock sin dejar rastro, venga el cambio de la web, de la app o de un proceso programado. Los movimientos no se editan ni se borran, y dos operaciones simultáneas no se pisan.

Cada movimiento registra tipo, cantidad, stock resultante, almacén, almacén relacionado (en traspasos), coste unitario, proveedor, orden de trabajo, notas y autor.

16.4 Valoración: precio medio ponderado

Al dar entrada con precio de compra, el sistema recalcula el precio medio ponderado del artículo, con 4 decimales. El coste de la entrada guarda el precio real de compra.

El consumo en una orden se valora con el precio medio vigente al consumir, que queda fijado en el movimiento: el coste de una orden ya cerrada no cambia aunque después el precio medio se mueva. Una devolución vuelve con el mismo coste con el que salió.

16.5 Operaciones

• Añadir stock con precio de compra y proveedor.
• Ajustar stock a una cantidad concreta (recuento físico), con motivo obligatorio.
• Salida directa con motivo: consumo interno, pérdida, rotura, caducidad u otro.
• Traspaso entre almacenes.
• Consumo y devolución desde la orden de trabajo (16.6).
• Histórico de movimientos de un artículo, filtrable por almacén.
• Stock mínimo de un artículo en cada almacén.

Las operaciones avisan en pantalla si el almacén queda bajo mínimo o en negativo.

16.6 Material de la orden de trabajo

El material se descuenta al consumirlo, no al planificarlo, y solo lo usado que se informa mueve stock:

Cada línea mueve solo la diferencia sobre lo que ya tiene sacado: reenviar lo mismo desde la app no descuenta dos veces.

De qué almacén sale. En la web, cada línea tiene un selector «Sale de»: Automático o un almacén concreto con lo libre que tiene. En automático decide el sistema, por este orden: la furgoneta del vehículo que el operario lleva ese día, su furgoneta, el almacén de su ficha, el de la delegación y el de la principal. Lo elegido a mano se conserva. El operario no elige almacén: lo que añade en campo sale del suyo.

Negativos permitidos. Un consumo nunca se rechaza por falta de stock: el almacén puede quedar en negativo y se avisa (16.7).

Aviso al planificar. Al guardar una orden con material, se avisa por almacén de lo que supera el stock o lo deja bajo mínimo, y se abre un aviso de «Falta material para una OT» para el responsable del almacén, que se pone al día al volver a guardar y se cierra al completar o cancelar la orden.

Preventivo, planificador y despacho. Las órdenes del preventivo nacen con el almacén de cada línea fijado y su material comprometido (6.3). Según el ajuste de material de la organización, el optimizador y el despacho avisan de lo que falta o solo dan la orden a quien puede llevarlo (11.11).

En la app. El operario informa lo usado por línea y puede añadir material no planificado. Cada línea dice de qué almacén sale y cuánto lleva consumido, y «Mi furgoneta» muestra, en solo lectura, las existencias de su almacén con su mínimo, lo comprometido y las herramientas.

16.7 Avisos de stock

Los avisos de existencias se abren, actualizan y cierran solos con cada movimiento, uno por material y almacén:

• Stock bajo: la cantidad de ese almacén ha caído por debajo de su mínimo.
• Stock en ruptura: la cantidad ha quedado en negativo.

El aviso nombra el material y el almacén e indica lo que queda; si se repone, se cierra solo. A ellos se suma «Falta material para una OT» (16.6). Los reciben el administrador, el supervisor y el rol de almacén, acotados a la delegación del almacén.

Consulta de artículos bajo mínimo por almacén, ordenada por mayor déficit, con el proveedor preferente y el último precio de compra, exportable a CSV.

16.8 Proveedores

Ficha de proveedor con estado activo/inactivo y catálogo de artículos por proveedor con su precio. Permite marcar un proveedor como preferente de un artículo y registrar de quién vino cada entrada.

16.9 Informes de inventario

• Valor de inventario, por categoría y por almacén, con ranking de artículos por valor.
• Consumo por activo en un rango de fechas: cuánto material se ha ido en cada activo, exportable a CSV. Es la base del análisis de «activos que salen caros».
• Coste de una orden de trabajo: materiales, mano de obra y vehículo (5.10).

16.10 Lo que todavía no hay

Para no prometer de más, quedan fuera de esta fase:

• Reservas de unidades y material en tránsito: planificar compromete (16.2), pero no aparta unidades.
• Pedidos de compra con recepción formal y solicitudes de traspaso o de compra: la reposición se registra como entrada de stock con su precio y su proveedor.
• Control por número de serie o lote.
• Importación del catálogo de artículos, hoja de recuento con ajuste en bloque, kits de material y códigos QR por artículo.

17. Lectura de contadores

Disponibilidad: módulo de lectura de contadores, con sus opciones de lecturas dinámicas y de rutas de lectura (las rutas requieren trabajar con equipos) Superficies: Web · Móvil (offline completo) · API pública Para qué sirve: campañas de toma de lecturas en campo (contadores de agua, energía, horas de funcionamiento, presiones) con planificación por periodos, trabajo sin cobertura y detección de lecturas fuera de rango con incidencia automática.

17.1 Puntos de medición

Se definen en dos niveles:

a) Por tipo de activo — la plantilla: nombre, unidad, valores mínimo y máximo válidos, base del rango (17.9), frecuencia de lectura, días de tolerancia y la casilla «Abrir incidencia si la lectura sale de rango». Sobre la plantilla se definen reglas condicionales: «si la propiedad calibre vale DN80, entonces el máximo válido es otro y la frecuencia también», con prioridad entre reglas, que se aplican a los activos existentes. La configuración de medida es un permiso propio: un técnico que toma lecturas no la cambia.

b) Por activo concreto — la instancia real, que hereda de la plantilla y puede sobrescribirse individualmente. Guarda además la próxima fecha de lectura prevista, que avanza sola con cada lectura válida.

Desactivar una plantilla desactiva sus puntos (salvo los personalizados), y una plantilla con lecturas no se borra: se desactiva.

17.2 Umbrales recalculables

Los umbrales de validez de un punto pueden recalcularse estadísticamente a partir del histórico real, en lugar de fijarse a mano. El punto guarda con qué método se calcularon, con cuántas muestras y cuándo. Una tarea diaria los recalcula en bloque; en los contadores acumulativos, sobre la serie de consumos.

17.3 Rutas estáticas de lectura

Secuencias fijas y ordenadas de activos que se leen siempre en el mismo orden: el recorrido del lector. Cada ruta tiene nombre, cliente, equipo asignado y una programación que genera sus lotes.

Orden de visita. El formulario muestra la lista numerada y arrastrable y la línea del recorrido sobre el mapa. «Optimizar orden» calcula el recorrido más corto:

• Agrupa los activos por tramos de calle y recorre cada tramo en fila, de modo que en una calle con cinco pozos no se calculan rutas entre ellos.
• Ordena los tramos a pie o en vehículo (respetando el sentido único), con distancias y tiempos reales. A pie se elige si se recorren las dos aceras a la vez o una y vuelta por la otra. El punto de salida puede ser el primer activo, una delegación o un punto, con o sin vuelta.
• El resultado dice cuántos tramos ha encontrado, la distancia y el tiempo totales.

Edición. Cambiar la ruta puede aplicarse también al lote en curso, mientras no tenga lecturas.

17.4 Lotes de lectura (campañas)

El lote es la unidad de trabajo. Contiene nombre y tipo, origen (una ruta o una selección por tipo de activo y sector), equipo asignado, cliente y delegación, periodo y frecuencia, y estado del lote y de cada activo y punto, para saber exactamente qué falta.

Un lote está Pendiente al generarse, En curso en cuanto llega su primera lectura y Cerrado al cerrarlo; un lote cerrado no se reabre.

El resumen del lote cuenta pendientes, completados, en curso y con incidencia, y lista las lecturas que requieren atención: no válidas, fuera de rango (con la incidencia que abrieron), con notas o con fotos.

Operaciones: alta, asignación de fechas de vencimiento, calendario de lotes, cierre y borrado. Un activo dado de alta después de generar el lote entra en los lotes abiertos que le corresponden. Cerrar informa de los puntos que quedaron sin leer, y desde ese momento el lote no admite más lecturas, tampoco las que lleguen de la app sin conexión. Solo se borra un lote en el que nadie ha trabajado.

17.5 Programación automática de lotes

Reglas que generan lotes solos:

• Tipo de activo medible o ruta de origen, y cliente.
• Frecuencia (días, semanas, meses o años) y días de antelación. Las rutas admiten además ejecución única.
• Equipo asignado, con posibilidad de un equipo distinto por sector.
• Fechas de inicio y fin.
• Ejecución manual («Ejecutar ahora») además de la automática.

Los periodos se cuentan desde la fecha de inicio, de modo que una programación mensual del día 31 no se queda en el 28. Solo entran activos con algún punto de medida activo, y al crear la programación se avisa de los sectores sin equipo y de los activos sin sector que quedarían fuera.

17.6 Trabajo offline por lote

Cada lote tiene un paquete offline con todo lo necesario para trabajarlo sin cobertura: activos, puntos de medición e historial. La app lo descarga de una vez y trabaja íntegramente en local.

• Se prepara en cuanto se crea el lote, y se regenera antes de descargarlo si ha habido cambios.
• Se construye aparte: una descarga nunca se lleva un paquete a medias.
• Al cerrar el lote, el paquete desaparece.

Combinado con la cartografía offline de activos y el mapa base (capítulo 21), el técnico puede hacer una jornada completa de lecturas sin conexión.

17.7 Lecturas

Cada lectura registra valor, fecha, punto de medición, activo, lote, persona que la tomó, fotografía (obligatoria si el tipo lo exige), notas, si es válida y si está fuera de rango (17.9). Las lecturas no válidas no cuentan como última lectura ni hacen avanzar la próxima fecha prevista. Las lecturas se ofrecen también en la API pública (capítulo 25).

17.9 Lecturas fuera de rango e incidencia automática

Al recibir cada lectura, el sistema la compara con el rango válido de su punto. Cada punto declara su base del rango:

• Consumo (contador acumulativo): se compara la lectura menos la anterior válida. Es el valor por defecto de los puntos nuevos.
• Lectura (medida instantánea): se compara el valor tal cual.

El rango ya incluye la plantilla, la regla aplicable, el umbral recalculado o el ajuste a mano. La web muestra «Consumo fuera del rango válido» o «Lectura fuera del rango válido».

La incidencia. Si la lectura está fuera de rango y el punto tiene marcada «Abrir incidencia si la lectura sale de rango», se abre una incidencia «Posible contador averiado / Fuga», de criticidad alta y origen Lectura de contador, sobre el activo de la lectura, con el valor, la lectura anterior, el rango y la foto, y con el aviso de incidencia nueva. Como mucho una por lectura. Si la lectura se corrige después, la incidencia no se cierra sola: se le añade una nota y la decide una persona.

Listados. Los listados (20.6) ofrecen «Lecturas fuera de rango» y «Lecturas atrasadas» (puntos cuya fecha prevista más la tolerancia ya ha pasado).

18. Formularios dinámicos

Disponibilidad: módulo de mantenimiento, con la capacidad de formularios Superficies: Web (diseño y consulta) · Móvil (cumplimentación) Para qué sirve: que cada organización capture en campo exactamente los datos que su proceso exige —un checklist de inspección, un acta de puesta en marcha, una ficha de estado— sin que haya que programar nada, y que lo exigido no se pueda saltar al cerrar el trabajo.

18.1 Plantillas

Plantilla con nombre, descripción, versión y estado activo, en dos planos: globales (del vertical) y propias de la organización (clonadas y editables). Desactivar una plantilla siempre se puede: deja de proponerse y lo ya rellenado se conserva. Una plantilla en uso no se borra.

18.2 Secciones

Cada plantilla se organiza en secciones con nombre, descripción y orden, colapsadas por defecto si se quiere, y repetibles: una sección de detalle que se rellena N veces (por ejemplo, una fila por luminaria revisada), con número mínimo de filas. Una sección con respuestas no se borra: se retira, deja de salir en los formularios nuevos y lo ya rellenado se conserva.

18.3 Campos

Catorce tipos de campo:

Sí/no · Texto · Número entero · Número decimal · Selección simple · Selección múltiple · Botones de opción · Casillas · Fecha · Hora · Fotografía · Firma · Posición GPS · Texto informativo

Cada campo define:

• Etiqueta y texto de ayuda multilingües.
• Opciones (para los tipos de selección).
• Obligatoriedad y reglas de validación (mínimo, máximo, patrón, «debe marcarse»).
• Reglas de dependencia: mostrar, ocultar, hacer obligatorio u opcional, habilitar o deshabilitar el campo según lo respondido en otros.
• Diseño adaptable: columnas que ocupa en móvil, tablet y escritorio, de modo que no hay que duplicar plantillas por dispositivo.

Lo ya respondido se protege. Un campo con respuestas no se borra (se retira), no cambia de tipo y no pierde una opción ya respondida; las etiquetas sí se pueden cambiar.

Hay un editor visual del diseño y una previsualización del formulario tal como lo verá el técnico.

18.4 Asignación de formularios

Un formulario se vincula al trabajo mediante asignaciones que combinan tipo de mantenimiento, tarea y tipo de activo. Cada asignación declara si es obligatoria, su orden y su ámbito: una vez por orden o una vez por cada activo.

Al crear o editar una orden, el sistema deja en ella los formularios elegidos más los obligatorios que le corresponden, y cada uno guarda la tarea a la que pertenece y si es obligatorio en esa orden: una orden abierta no se bloquea por una regla nueva que su técnico no ha visto.

Editar la orden conserva las respuestas: se añaden los obligatorios nuevos y solo se quitan los formularios desmarcados que no tienen respuestas.

18.5 Respuestas

• Lote de respuestas: agrupa varias respuestas de una orden bajo un nombre («Lote correctos», «Grupo avería»), para despachar en bloque activos que están todos igual en lugar de repetir el mismo formulario N veces.
• Respuesta: vinculada a la orden, al formulario, al activo y al lote, con quién la rellenó, cuándo, su estado (borrador o completada) y la ubicación GPS.
• Valores: guardados con su tipo, con índice de fila en las secciones repetibles.

Los valores tipados permiten explotar las respuestas analíticamente, no solo mostrarlas. Las respuestas se muestran agrupadas por lote y por sección, en el orden del diseñador, con las fotos y las firmas; la misma lectura alimenta el informe PDF de la orden.

18.6 Tareas completadas por sus formularios

Una tarea de la orden pasa a completada cuando todos los formularios vinculados a ella tienen una respuesta completada, y vuelve a pendiente si alguno deja de estarlo. Las tareas sin formularios conservan su estado.

18.7 Cumplimentación desde el móvil

• Las respuestas se validan registro a registro al subirlas, y la autoría sale de la sesión, no del contenido enviado.
• Una orden validada, cerrada o firmada ya no admite cambios en sus respuestas.
• Los campos de foto y firma solo admiten imágenes.
• En los campos GPS se guarda si la posición era simulada (14.10).
• La sincronización envía a la app las respuestas sustituidas y los campos retirados para que los quite.

18.8 Formularios obligatorios y cierre de la orden

Un formulario obligatorio bloquea el cierre: la orden no se completa, valida ni cierra mientras falte alguno, y el sistema dice cuáles. Cancelar no se bloquea, y los partes rápidos quedan exentos.

Qué cuenta como completado: una respuesta completada si el formulario es por orden, o una por cada activo al que aplica si es por activo. Una respuesta marcada como completada con campos obligatorios vacíos no cuenta, teniendo en cuenta las reglas de dependencia y fila a fila en las secciones repetibles.

Se comprueba en la web, en las acciones masivas y en la app; si un cierre desde la app no lo cumple, el cambio de estado se deshace y el resto del envío se guarda.

19. SLA

Disponibilidad: módulo de SLA; además, activable cliente a cliente Superficies: Web · Móvil (causa de la pausa) · Portal cliente (plazos y cumplimiento) Para qué sirve: comprometer plazos por escrito y medirlos automáticamente. Es la funcionalidad que convierte un contrato de mantenimiento en algo verificable por ambas partes.

19.1 Niveles de criticidad

19.2 SLA global y SLA de la organización

Para cada combinación de criticidad × tipo se define un tiempo máximo de respuesta y un tiempo máximo de resolución. El tipo distingue las incidencias de las órdenes de trabajo, porque el compromiso de atender un aviso y el de ejecutar un trabajo no son el mismo.

Los plazos existen en dos niveles: el SLA global de la plataforma y el SLA de la organización, que hereda cada valor del global hasta que lo personaliza, con la opción de restaurar el global.

19.3 SLA personalizado por cliente

Cada cliente puede tener SLA propio, con tiempos específicos por criticidad y tipo que sustituyen a los de la organización. El orden de aplicación es cliente → organización → global. En la ficha del cliente se activa también si admite pausas justificadas (19.8).

19.4 Aplicación

Órdenes de trabajo. Cada orden recibe sus fechas límite de respuesta y de resolución, y guarda de qué nivel salen:

• La criticidad sale de la prioridad de la orden, según una correspondencia configurable (por defecto, Urgente → Crítica, Alta → Alta, Media → Media, Baja → Baja).
• Desde cuándo cuenta: un correctivo, desde su creación; una orden de preventivo, desde su fecha prevista, para que no llegue al día previsto con el plazo medio gastado. Mover una orden en el calendario no mueve su plazo.
• Los plazos se cuentan en horario laboral (19.9). Una orden creada fuera de horario empieza a contar en la siguiente apertura.
• El plazo de resolución se alarga con las pausas justificadas (19.8).
• En las órdenes abiertas se recalculan al cambiar el SLA, el horario, los festivos o la zona horaria. Las cerradas conservan el plazo con el que se cerraron.

Incidencias. Reciben sus plazos igual, sobre su criticidad y siempre desde su alta (7.5). Una incidencia resuelta, cerrada o rechazada conserva su plazo.

19.5 «SLA en riesgo»

Una orden abierta pasa a «SLA en riesgo» cuando ha consumido un porcentaje de su plazo de resolución —75 % por defecto, configurable—, contado en la misma jornada laboral. Es proporcional al plazo: una orden de 4 horas avisa antes que una de 5 días. Las incidencias usan el mismo porcentaje.

Lo usan el indicador del panel, el pulso del día, la etiqueta de las tarjetas y el aviso de SLA en riesgo sin personal (19.10).

19.6 Configuración

Todo el SLA se configura en un único apartado, con ayuda en cada concepto y una etiqueta que distingue lo que cambia los plazos o cambia los avisos de lo que solo cambia colores:

1. Plazos por criticidad, de incidencias y de órdenes, con su origen (heredado o personalizado).
2. Qué plazo usa cada prioridad de orden.
3. Aviso de «SLA en riesgo», con ejemplos calculados sobre los plazos configurados.
4. Cómo se valora el cumplimiento en el panel: los objetivos que deciden el color de los indicadores, sin mover ningún plazo.
5. Pausas justificadas: para qué sirven y el nombre que ve la organización de cada causa.

19.7 Visibilidad y control

• Tarjetas y fichas. Órdenes e incidencias muestran el estado de cada plazo —cumplido, incumplido, en plazo, en riesgo o vencido— con su fecha límite y, en las órdenes, las pausas justificadas y los minutos descontados.
• Panel de control: resolución y respuesta en plazo de órdenes e incidencias, órdenes en riesgo y con el SLA incumplido, y la tabla de resolución y MTTR por criticidad con media, mediana y percentil 90 (20.3).
• «Dónde se va el tiempo hasta el cierre»: gráfico que reparte el tiempo de las incidencias resueltas entre la espera hasta empezar, la reparación, las pausas por causa, otras esperas y el cierre administrativo.
• Portal de cliente: cada incidencia y cada orden lleva el estado de sus plazos, con las pausas que paran el plazo, su causa y su duración; el panel del portal da el nivel de servicio del periodo y su evolución mensual (22.5).

19.8 Pausas justificadas

El reloj del SLA no se para por poner una orden en pausa: a la pausa se llega también por el cierre de jornada o un descanso. Lo que decide es la causa de la pausa. Hay cuatro causas fijas, porque lo que importa para el contrato es de quién es la responsabilidad:

Cada organización puede cambiar el nombre que ve de cada causa, nunca añadir causas.

• Solo si el cliente lo admite por contrato.
• Solo la resolución: el plazo de respuesta no se para.
• En horas de jornada: el tramo parado se descuenta en minutos de jornada.
• Quién la elige: quien pausa, en la web o en la app. La causa de una pausa registrada se puede corregir, y queda en la auditoría.
• Control por transparencia, sin aprobación: la ficha enseña los tramos, el cliente ve en su portal todas las pausas que paran el plazo con su causa y duración, y la exportación y la API las incluyen.

Las pausas justificadas se aplican solo a órdenes de trabajo.

19.9 Horario laboral del cálculo

El plazo avanza por las franjas del horario semanal (9.8): jornada partida sin contar la comida, franjas nocturnas, horario propio por delegación y sin festivos. Las franjas se cuentan en la zona horaria de la delegación, de modo que la noche del cambio de hora dura lo que dura.

19.10 Avisos de SLA

El sistema mantiene, minuto a minuto, dos avisos sobre las órdenes abiertas:

• «SLA en riesgo sin personal»: la orden está en riesgo, aún no ha vencido y no tiene a nadie asignado. Se cierra solo al asignarle personal, al terminar o al vencer.
• «SLA vencido»: la orden ha superado su plazo de resolución y sigue abierta. Se cierra al terminar o si el plazo se mueve.

Los dos entran en la regla de escalado por defecto y pueden llegar por correo (capítulo 24).

20. Panel de control y analítica

Disponibilidad: núcleo, siempre activo; el alcance depende del nivel de detalle del panel; los costes requieren la capacidad de costes y la flota, su módulo Superficies: Web · Portal cliente (versión reducida, capítulo 22) Para qué sirve: responder con datos a las preguntas de gestión del mantenimiento, con los indicadores que el sector reconoce (MTBF, MTTR, disponibilidad, cumplimiento de preventivo, backlog, cumplimiento de plazos) calculados sobre el histórico real de estados y tramos de trabajo, no sobre campos declarados a mano; y, desde la página de inicio, dirigir el trabajo del día sobre el mapa.

20.1 Indicadores principales

Los indicadores de SLA solo aparecen en organizaciones con SLA. Fechas y días se cuentan en hora local.

Comparativa con el periodo anterior. Con un rango de fechas, las métricas de flujo se comparan con el periodo anterior de la misma duración y con los mismos filtros.

Objetivos y semáforo. Quince indicadores se colorean en verde, amarillo o rojo frente a dos umbrales que la organización configura, cada uno con un texto de ayuda que explica lo que mide.

Nivel básico. MTBF, backlog en semanas o resueltas a la primera son indicadores excelentes, y son a la vez lo que hace que el responsable de mantenimiento de una empresa pequeña concluya que el producto es para otra liga. Con el panel en nivel básico se muestran siete cifras que cualquiera entiende sin explicación —órdenes activas, pendientes, vencidas y completadas, total de activos, incidencias abiertas y artículos bajo mínimo—, con las distribuciones, la tendencia mensual y la comparativa con el periodo anterior.

20.2 Análisis técnico

• Planificado frente a no planificado: la proporción entre preventivo y correctivo, el indicador de madurez de un departamento de mantenimiento.
• Cumplimiento del preventivo.
• Análisis de pausas.
• Recuento de fallos en el periodo.
• Distribuciones de órdenes por estado, prioridad y tipo, e incidencias por criticidad y estado.

20.3 Indicadores de mantenimiento

• MTBF por tipo de activo — tiempo medio entre fallos, sobre los intervalos reales entre incidencias del mismo activo.
• Resolución y MTTR por criticidad, separados como hace la norma UNE-EN 13306:
• Resolución: del alta al cierre de la incidencia, en horas de jornada, con media, mediana (P50) y P90, frente al plazo del SLA y con el % resuelto en plazo.
• MTTR técnico: el tiempo de trabajo efectivo de las órdenes que resuelven la incidencia, sin pausas ni esperas, con media, P50 y P90.
• Dónde se va el tiempo hasta el cierre — gráfico apilado por criticidad: hasta empezar, reparación, pausas por causa (ajena o propia), otras esperas y cierre administrativo.
• Disponibilidad por avería y por mantenimiento, separadas.
• Activos problemáticos (bad actors): ranking de activos por número de incidencias. Es el análisis 80/20 que identifica dónde se concentra el gasto.

20.4 Análisis de peticiones

Incidencias reportadas, resueltas, rechazadas y pendientes, tasa de resolución, tiempo medio de primera respuesta y tiempo medio de resolución.

20.5 Rendimiento del equipo

• Estado de las órdenes por técnico.
• Distribución del trabajo por equipo.
• Productividad por usuario: asignadas frente a completadas.

20.6 Tendencia y listados

• Tendencia mensual de órdenes creadas y completadas, e incidencias creadas y cerradas.
• Últimas órdenes, últimas incidencias y órdenes vencidas con días de retraso.
• Listados de órdenes e incidencias con filtros propios, exportables a CSV y a PDF.

Índice de listados. El botón «Listados» de la barra superior da acceso a los favoritos de cada usuario y a un índice agrupado por categorías (operación, cumplimiento, activos, costes, almacén y flota), con buscador:

Cada listado aparece solo a quien tiene permiso y módulo. Cada cifra del panel abre el listado de lo que cuenta, con el mismo filtro.

Del número al mapa. «Ver en el mapa» aplica el filtro del listado al mapa y al panel operativo: lo que se ve sobre el mapa es exactamente lo del listado.

Los listados se sirven con un tope de 500 filas; cuando se alcanza, la pantalla avisa antes de exportar y propone afinar los filtros: un fichero recortado que se cree completo es peor que un aviso.

20.7 Informes operativos

• Valor de inventario por categoría y almacén.
• Consumo de material por activo en un rango de fechas, neto de devoluciones.
• Coste real de una orden de trabajo en su ficha: mano de obra por persona, materiales y vehículo (5.10).

20.8 Filtros y vistas

Todo el panel admite filtro por rango de fechas, cliente, delegación, sector y clase de trabajo: todo, solo el trabajo sobre activos o solo el trabajo sin activo. Los filtros se aplican a todas las cifras y a los listados que se abren desde ellas.

20.9 Dimensión geográfica y trabajo sin activo

Por zona. Desglose por delegación y por sector de las órdenes activas, vencidas y completadas y de las incidencias abiertas, contando cada orden en su sector responsable (5.22).

Trabajo con y sin activo. Porcentaje de órdenes e incidencias sin activo y zonas con más trabajo sin activo: la lectura del trabajo sobre superficies que no están en el inventario, que señala dónde convendría inventariar.

Mapa de calor. La densidad de órdenes o incidencias de los últimos 90 días se pinta como capa del mapa (21.1).

20.10 Costes reales

Coste incurrido en el periodo —no presupuestado—, agrupable por cliente, tipo de tarea, delegación, sector o mes. Cada importe se fecha cuando se produjo:

Sin tarifa para alguna persona, o sin coste para algún trayecto, el importe se marca incompleto: el total no aparenta ser completo cuando no lo es. Se informa aparte lo gastado en revisiones por «no conforme» y en trabajo no facturable, y los kilómetros de desplazamiento entre la base y las órdenes. Los importes van en la moneda de la organización.

20.11 Capacidad del personal

Por persona y periodo (hasta 93 días):

• Horas de turno, descontando festivos y ausencias.
• Horas asignadas: duración estimada de las órdenes planificadas. Carga = asignadas / turno.
• Horas trabajadas, del parte de horas (con el módulo de campo en tiempo real). Utilización = trabajadas / turno, con objetivo configurable.
• Sin planificar: el trabajo pendiente que aún no ocupa a nadie.

20.12 Flota y seguimiento

Con el módulo de flota o el de campo en tiempo real, para periodos de hasta un año:

• Trayectos: número, kilómetros, horas de conducción y combustible, por persona, por vehículo o por mes.
• Avisos del seguimiento, por persona: visitas detectadas sin registrar, órdenes en curso sin posiciones y días con actividad fuera de turno sin regularizar.

20.13 Informes programados por correo

El resumen del panel se envía por correo, en PDF, de forma periódica y con los filtros que tenía el panel al programarlo:

Va en el idioma, la moneda y el formato de fecha de la organización. Si algún destinatario no podría ver esas cifras en la aplicación, hay que confirmarlo expresamente. El botón «Envíos» reúne las programaciones, su historial y «Enviar ahora».

20.14 Página de inicio operativa

La página de inicio es el mapa a pantalla completa con el panel operativo a la derecha (21.1): el puesto de mando del día —qué hay que atender, dónde está y quién lo hace— sin salir del mapa.

20.14.1 Pulso del día

Una tira de contadores sobre el mapa resume las órdenes que piden atención hoy:

Pulsar un contador filtra a la vez el mapa y el listado con el mismo criterio con que se ha contado, así que el número y lo que se ve siempre cuadran.

20.14.2 Mapa y listado sincronizados

• El listado y el mapa se resaltan mutuamente.
• «Solo lo visible» limita el listado a la zona del mapa en pantalla.
• El listado carga de 50 en 50, con búsqueda, orden y recuentos por estado.
• Cada orden tiene un menú «⋯» con los cambios de estado válidos.

20.14.3 Acciones masivas

Modo de selección múltiple —tarjetas, clic en el mapa o rectángulo sobre el mapa— para asignar, cambiar la prioridad, reprogramar o cancelar hasta 200 órdenes (5.15).

20.14.4 Despacho

Sobre la vista por operario de la pestaña de Planificación:

• Cola «Por despachar»: órdenes pendientes, primero las que no tienen personal.
• Arrastrar una orden a la fila y el día de un operario la asigna y planifica; las ya planificadas se mueven igual.
• «Asignar al más cercano»: los técnicos más próximos por tiempo de conducción, también sin seguimiento GPS, filtrados por su formación obligatoria (10.6).
• Impacto en la jornada: para una orden pendiente, lo que supone meterla en la jornada de cada candidato —hoy o en los tres días siguientes—, con hora de llegada, conducción de más y órdenes que se mueven o dejan de caber. Nada se aplica sin confirmar (10.8).

20.14.5 Menú contextual del mapa

El clic derecho ofrece, según lo que haya bajo el puntero: sobre una orden, ver ficha y asignar al más cercano; sobre un activo, ver su ficha y crear una orden; y en cualquier punto, nueva orden aquí, nueva incidencia aquí, técnicos más cercanos y copiar coordenadas.

La capa de flota colorea los vehículos con una orden en curso y traza la línea del técnico a la orden.

20.14.6 Al día sin recargar

La página se actualiza sola cada 30 segundos mientras está visible: la campana de avisos, el pulso del día y las vistas de órdenes e incidencias reciben solo lo que ha cambiado, y el listado avisa de las órdenes nuevas o actualizadas. Con la pestaña en segundo plano no se consulta.

20.14.7 Vistas acotadas

El Kanban, el calendario, la cola de despacho y el optimizador cargan solo lo que se ve o lo que se busca: ninguna vista descarga la cartera completa.

Todas estas vistas respetan el alcance del técnico (1.13).

20.15 Informes de costes

La administración tiene un bloque Informes con dos pantallas que desarrollan los costes reales del panel con sus mismos criterios (20.10):

Costes de las OT. Lo que ha costado ejecutar las órdenes en un periodo —personal, materiales y combustible—, con filtros y agrupaciones, y orden a orden de mayor a menor coste, con horas, kilómetros, operarios sin tarifa, trayectos sin coste, horas por revisar y si es facturable o una revisión. Exportación CSV en el idioma del usuario.

Costes por cliente. Lo que ha costado atender a cada cliente, por mes, trimestre o año, con gráficas por cliente y por concepto y comparación con el periodo anterior. Es coste, no margen: no hay ingresos.

21. Cartografía e infraestructura GIS

Disponibilidad: núcleo Superficies: Web · Móvil · Portal cliente Para qué sirve: sostener una operación cartográfica seria —cientos de miles de elementos, edición sobre el mapa, capas externas, uso sin cobertura— sin depender de servicios de mapas de terceros ni de sus cuotas para lo esencial.

21.1 El mapa como interfaz principal

La aplicación web es un mapa a pantalla completa con:

• Panel de capas con agrupación por familias, zonificaciones y sectores, selección en bloque y acceso directo al listado y a la edición de cada capa.
• Capa de delegaciones: las sedes desde las que arrancan operarios y equipos.
• Capas de órdenes de trabajo e incidencias, con su punto y, de cerca, el área de las que se sitúan sobre una superficie. Un técnico solo ve las suyas.
• Mapa de calor de órdenes o incidencias de los últimos 90 días (configurable hasta 730), recalculado al mover el mapa.
• Panel operativo con cinco pestañas: Órdenes de trabajo, Incidencias, Lecturas, Planificación y Activos (20.14).
• Filtro por cliente, que acota todo lo que se ve (3.1).
• Buscador de direcciones y buscador global (25.7), que encuentra órdenes, incidencias, activos por código o atributos y clientes.
• Herramienta de información para consultar cualquier elemento con un clic, y menú contextual (20.14.5).
• Filtros avanzados de órdenes e incidencias, que el mapa y el listado aplican igual.
• Temáticos de órdenes e incidencias (por estado, prioridad…) y el temático «Estado del activo» (4.11), con su leyenda.
• Avisos que llevan al mapa: un aviso pulsado abre el elemento en el mapa.
• Street View integrado.
• Edición de geometrías sobre el mapa, para dibujar y modificar activos, zonas y sectores, y el punto o el área de una orden o incidencia. Mover un activo deja rastro en su histórico de posiciones (4.14).

21.2 Capas del mapa

Los activos se sirven al mapa por zona y nivel de zoom, siempre de la propia organización, sin los activos de baja definitiva y sin los campos ocultos de la capa. Hay capas propias de órdenes de trabajo y de incidencias, y capas propias para el móvil y para el portal de cliente, cada una con su alcance de datos. Todas exigen sesión o una credencial temporal.

21.3 Caché del mapa y versionado

Cada capa decide si se sirve desde caché, de modo que una zona ya consultada no se recalcula. Al editar un activo solo se renueva la zona afectada, no la capa entera en todos los niveles de zoom. Cada capa tiene una versión que cambia con sus activos, su definición o sus estilos, y los mapas abiertos la aplican sin recargar.

21.4 Capas WMS externas

Integración de servicios WMS de terceros (catastro, planeamiento, cartografía oficial):

• Descubrimiento automático de las capas que ofrece el servicio, solo hacia servidores públicos de Internet.
• Configuración de dirección, capa, versión, sistema de referencia, transparencia, opacidad, estilo, formato, leyenda y visibilidad por defecto.
• Si el servicio no ofrece la proyección del mapa pero sí otra conocida (geográficas, ETRS89, UTM…), el sistema reproyecta la imagen.
• Las capas WMS también llegan a la app.

21.5 Ortofoto del PNOA/IGN

Generación de un paquete offline con la ortofoto del PNOA que publica el IGN, acotado al ámbito de los activos de la organización, en niveles de zoom 15 a 18, con estimación previa del tamaño, consulta de estado y descarga. Una generación fallida no destruye la anterior. Da al técnico en campo la ortofoto real de su zona, offline.

21.6 Mapa base propio

Generación propia del mapa base a partir de OpenStreetMap para cualquier región del mundo, con catálogo de regiones y recomendación de la adecuada. El mapa base no depende de un proveedor externo ni de una clave con cuota.

21.7 Activos para uso offline

Generación de paquetes cartográficos con los activos de la organización y sus atributos, que la app descarga y usa sin conexión. Se publican de una vez —una descarga nunca ve uno a medias— y se regeneran cada noche. La app puede además pedir solo los activos modificados desde la última generación, y la lista de los que tiene que quitar.

21.8 Cálculo de rutas propio

Cálculo de rutas sobre la red viaria, sin depender de servicios externos:

• Ruta punto a punto con distancia, duración y trazado (tramos de flota, capítulo 13).
• Matrices de tiempos y distancias entre muchos orígenes y destinos, base de la proximidad del personal, del despacho, del planificador y de la ordenación de rutas de lectura.

Solo lo usan los servicios internos de la plataforma, y si deja de responder el sistema lo dice al momento en lugar de hacer esperar; el planificador sigue funcionando con una estimación aproximada. Está pensado para la escala local de una operación de mantenimiento, no para recorridos continentales.

21.9 Rendimiento del mapa

El mapa carga y responde deprisa con cientos de miles de activos: el encuadre del patrimonio está precalculado, el arranque pide en paralelo todo lo que pinta, las capas y sus versiones se piden de una vez, los recursos estáticos se guardan en el navegador, las respuestas van comprimidas, la edición solo renueva la zona afectada y el buscador por atributos tiene un tope de tiempo que avisa en lugar de colgarse.

21.10 Capas alimentadas desde fuera

Además de dibujarse o cargarse desde fichero (4.4), una capa puede mantenerse desde un sistema externo:

• Origen de datos externo (API REST): la capa declara la conexión remota, el campo de geometría y su sistema de referencia, los campos identificativos, el campo de fecha para la sincronización incremental y las horas de ejecución, en la hora local de la capa. Cada sincronización recalcula los códigos, renueva las zonas del mapa afectadas y deja los movimientos en el histórico de posiciones.
• WMS como capa de fondo de solo consulta (21.4).

22. Portal de cliente

Disponibilidad: incluido en el módulo de gestión de clientes, con límite de clientes y de usuarios de portal por cliente; cada cliente tiene además su interruptor de portal Superficies: Web independiente, adaptada al móvil Para qué sirve: dar al cliente final una ventana de transparencia sobre el servicio que recibe, convertir sus avisos en incidencias estructuradas sin pasar por el teléfono y dejarle participar en el cierre de los trabajos.

22.1 Usuarios del portal

Identidad completamente separada de los usuarios internos:

• Email, contraseña propia, nombre, cargo, teléfono, avatar e idioma, que el propio usuario puede cambiar.
• Pertenecen a un cliente concreto.
• Rol del portal y, opcionalmente, zonas del cliente a las que se limita (22.2).
• Activación por email con enlace caducable y reenvío de activación.
• Sesión única, registro del último acceso y recuperación de contraseña propia. Desactivar un usuario corta sus sesiones abiertas.

Los usuarios del portal se dan de alta desde la ficha del cliente o, dentro de su empresa, por su propio administrador del cliente (22.8).

22.2 Roles del portal y ámbito

Cada usuario tiene un rol cuyos permisos se aplican en todo el portal, con todo denegado por defecto:

Zonas. Un usuario con zonas asignadas solo ve los activos, incidencias y órdenes que caen dentro de alguna, y siempre las incidencias que comunicó él. Sin zonas ve todo su cliente. Se aplica en listados, fichas, mapa, panel, preventivo y avisos por correo.

22.3 Qué ve el cliente

Siempre dentro del ámbito de su rol y sus zonas:

• Órdenes de trabajo que le afectan, activas e historial, con filtros de pendientes de conformidad y de revisiones. La ficha incluye fechas, ubicación, formularios, fotos y el estado de la conformidad.
• Plazos del servicio: el estado de los plazos de cada orden e incidencia y, en las órdenes, las pausas que paran el plazo con su causa y duración (19.8).
• Informe PDF de sus órdenes terminadas, en versión para el cliente: sin notas internas y con el DNI del firmante enmascarado.
• Incidencias propias, abiertas e historial, con su ubicación y las órdenes que la atienden.
• Próximos mantenimientos: las órdenes de preventivo y las previsiones de los próximos días (60 por defecto, hasta 180).
• Activos de su ámbito: ficha, fotos e incidencias asociadas.
• Mapa propio limitado a sus activos, con sus estilos, capas y filtros.

Nunca ve las notas internas de una incidencia ni el contacto de quien la reportó.

22.4 Qué puede hacer el cliente

• Crear incidencias, con adjuntos y tipo, situándolas en un punto del mapa, sobre los activos afectados o dibujando una zona afectada. Entran pendientes, vinculadas al usuario, y generan el aviso de incidencia nueva.
• Consultar el estado y el avance de sus trabajos.
• Dar la conformidad a un trabajo terminado (gestor o administrador): «Conforme» o «No conforme», con comentario obligatorio en el segundo caso. Si la orden se reabre y se vuelve a terminar, se pide de nuevo.
• Cada cliente decide si la conformidad es exigida: entonces la orden no se cierra sin ella. Si no, es informativa.
• Puede fijar unos días de conformidad tácita: sin respuesta en ese plazo, se da por conforme.
• «No conforme» abre una orden de revisión urgente, sin operario y no facturable, enlazada con la original, y avisa a la empresa para que elija quién la hace (5.21).

22.5 Panel del portal

Panel con resumen y gráficos: incidencias por tipo y por criticidad, trabajos por estado, evolución mensual, últimas incidencias y últimos trabajos completados. Indicadores: incidencias abiertas y críticas, trabajos en curso y completados en el mes, tiempo medio de resolución e incidencias fuera de SLA. Además:

• Nivel de servicio, con SLA: respuesta y resolución en plazo de incidencias y trabajos, y su evolución mensual.
• Preventivo: cumplimiento y revisiones previstas en los próximos 30 días.

22.6 Avisos por correo

El portal avisa por correo a sus usuarios, sin que tengan que entrar:

• Incidencia recibida, en marcha, resuelta o no tramitada, y trabajo terminado, con el informe PDF adjunto y, si el cliente la tiene, la petición de conformidad.
• Antes de enviar se comprueba que el aviso sigue siendo verdad: si un cierre se ha deshecho, el correo no sale.
• Cada usuario elige en «Mis avisos» qué recibe, y cada correo va en su idioma con un enlace directo a la incidencia o la orden.

22.7 Seguridad del acceso

• Aislamiento: la sesión del portal solo sirve para el portal, y todas las consultas se limitan a su organización, su cliente y el ámbito de su rol y sus zonas.
• Acceso de la empresa: en cada acceso se comprueba que el cliente sigue de alta y con el portal encendido; dar de baja un cliente o apagarle el portal cierra sus sesiones.
• Ficheros: solo se descargan los de su ámbito.
• Intentos de acceso: bloqueos temporales y escalonados tras varios fallos, sin revelar si el email existe.
• Contraseñas: la misma política que los usuarios internos (1.10).
• Los accesos, altas, cambios, respuestas de conformidad y acciones del administrador del cliente quedan en la auditoría.

22.8 Administrador del cliente

Un usuario con el rol Administrador gestiona los usuarios del portal de su propia empresa sin pasar por la empresa de mantenimiento: invitar, editar, reenviar la invitación y eliminar. Solo usuarios de su cliente, nunca a otro administrador, solo con las zonas que tiene él y dentro del máximo de usuarios por cliente del plan.

22.9 Portal en el móvil

El portal web está adaptado a pantallas pequeñas: el mapa arriba y el panel en una hoja plegable, que se pliega al trabajar sobre el mapa y se abre al ver un detalle.

23. Aplicación móvil

Disponibilidad: núcleo; las funciones de flota y de campo en tiempo real dependen de sus módulos Superficies: Móvil (aplicación para iOS y Android) Para qué sirve: que el técnico haga la jornada completa desde el móvil, incluidas las zonas sin cobertura, y que lo que hace vuelva al sistema sin transcripción manual.

23.1 Sesión y arranque

• Login propio, independiente del de la web: entrar en el móvil no cierra la sesión del navegador, y un login nuevo en la app deja sin efecto el anterior.
• Una sesión sin usar durante 60 días caduca, y el usuario puede cerrarla desde su perfil web, por ejemplo tras perder el teléfono. «Salir» la anula también en el servidor.
• El arranque trae ya resuelto lo que la app necesita para decidir qué pantallas monta: permisos, módulos, capacidades, vocabulario, horario laboral semanal e idioma.
• La app responde en el idioma del usuario o del teléfono.
• Un usuario sin ficha de personal no entra (1.3).
• Tras varios intentos fallidos, la app sabe cuántos segundos dura el bloqueo, y el teléfono desde el que ya se entró puede seguir entrando aunque un tercero haya bloqueado la cuenta.

23.2 Trabajo asignado

• Mis asignaciones: las atrasadas, las de hoy, las de los 3 días siguientes y las que no tienen fecha, más las completadas en los últimos 3 días.
• Detalle de la orden con todo lo necesario para ejecutarla, incluida su zona horaria, sus fechas reales, el tiempo en curso, si exige firma, su ubicación propia y su fecha límite.
• Detalle de los lotes de lectura y de las incidencias.

Un técnico solo alcanza las órdenes que tiene asignadas. El estado de una orden solo cambia por la sincronización (23.11), con las mismas reglas que la web: transición válida en el ciclo de la organización, los mismos permisos por cambio de estado (5.1), firma, formularios obligatorios, conformidad del cliente, propagación a la incidencia y consumo de stock.

23.3 Materiales, herramientas y EPIs

• Catálogo de artículos, también los que no tienen stock, con la existencia total como orientación.
• «Mi furgoneta»: el almacén del operario —el del vehículo que lleva hoy, su furgoneta, su almacén o el de su delegación—, con lo que hay de cada artículo, el mínimo y lo comprometido por las órdenes abiertas.
• Cada línea de material de la orden dice de qué almacén sale y cuánto lleva consumido.
• Añadir material e informar lo usado, también sin conexión.

Lo usado consume stock. El stock baja cuando el operario informa lo usado, no al planificar. La app informa el total usado de la línea, y el sistema solo mueve la diferencia: un reenvío no descuenta dos veces y bajar la cantidad devuelve stock. El operario no elige almacén. Con la orden validada, cerrada o firmada, el material ya no cambia.

Requisitos de las tareas. La app recibe los EPIs y las herramientas que piden las tareas de cada orden, y sube los EPIs que el técnico confirma al iniciar, con el motivo si falta alguno (5.23).

23.4 Formularios de campo

Cumplimentación de los formularios de la orden con el diseño adaptado al móvil, guardado en borrador y marcado de completado. Los campos de foto, firma y GPS capturan directamente del dispositivo.

• Las tareas se completan con sus formularios (18.6).
• Completar, validar o cerrar una orden con un formulario obligatorio sin completar no se permite; las respuestas que llegan en la misma sincronización cuentan.
• Los campos y secciones retirados desaparecen de la app, sin perder lo ya respondido.

23.5 Evidencia fotográfica y firma

• Adjuntos de la orden, con miniatura, coordenadas GPS, fecha de captura y marca de posición simulada.
• Firma del cliente sobre la orden, o excepción de firma cuando no puede firmar, con foto de evidencia si el motivo la pide.
• La app sabe ya resuelto si la orden exige firma, y no se puede completar sin ella (5.9).
• Toda firma se sella al recibirse con una fotografía de lo firmado —incluidas las respuestas de los formularios—, por lo que las respuestas tienen que llegar con la firma o antes (25.16).

23.6 Activos en campo

• Ficha del activo con sus propiedades, fotos y documentación.
• Alta de activos nuevos desde campo, que entran pendientes de validar.
• Catálogo de tipos de activo, sus propiedades y sus estados.
• Árbol de capas (también las WMS) y estilos por capa, para pintar el mapa igual que en la web.
• Geometrías de los activos de las órdenes del técnico, y su ubicación propia, para resaltarlos.
• Activos modificados desde la última descarga, para actualizar la copia local sin descargarla entera.

Los activos de baja, de capas desactivadas o de clientes dados de baja no llegan como vivos: la app recibe la lista de los que tiene que quitar.

23.7 Solicitudes de cambio y edición de activos

El técnico puede proponer una corrección de geometría o de datos de un activo en lugar de modificarlo directamente: la propuesta queda pendiente de aprobación por un responsable (25.4), y las pendientes se pintan atenuadas en el mapa.

Quien tiene permiso puede además dar de alta, modificar y dar de baja activos sin conexión, con las mismas reglas que en la web; cada cambio de posición queda en el histórico del activo.

Es un mecanismo de calidad del dato: quien mejor ve el error es quien está delante del activo, pero el inventario no se toca sin control.

23.8 Incidencias y parte rápido

• Alta de incidencias desde campo con tipo, criticidad, ubicación y fotos.
• Incidencias abiertas sobre el mapa, con su área afectada.
• La app no elimina incidencias ni hace retroceder su estado.
• Completar la orden resuelve su incidencia, salvo que el técnico responda que no queda resuelta (5.24).
• Parte rápido: registrar trabajo no planificado ya hecho sin pasar por la oficina, también sin conexión. Nace completado, con la posición GPS como ubicación de la orden, y el sistema le asigna su código definitivo.

23.9 Lecturas de contador

Descarga del lote de lecturas completo, toma de lecturas con fotografía y sincronización de vuelta. Un lote cerrado no admite más lecturas. El sistema decide si una lectura está fuera de rango y, si el punto lo pide, abre la incidencia, y la app recibe lo decidido (17.9).

23.10 Modo offline

Es la pieza diferencial de la app. Tres paquetes que se descargan con cobertura y se usan sin ella:

La descarga es completa o incremental: con la marca de la sincronización anterior solo trae lo cambiado, con un pequeño solape para no perder nada. Trae además el horario laboral, las causas de pausa, los requisitos de las tareas y «Mi furgoneta», y la lista de lo que la app tiene que quitar: órdenes reasignadas, canceladas o borradas, incidencias eliminadas, respuestas sustituidas, campos retirados, artículos borrados y activos retirados.

23.11 Sincronización de vuelta

Un único canal de subida de sincronización recibe todo lo hecho sin conexión: cambios de estado con sus fechas reales y la causa de las pausas, partes rápidos, incidencias nuevas, materiales consumidos, confirmaciones de EPIs, cronómetros por técnico para el parte de horas, respuestas de formularios, adjuntos, firmas, fotos y documentos de activos, activos nuevos y modificados, lecturas y bajas.

Registro a registro. Cada registro se valida y se guarda por separado: lo válido entra y lo que no, vuelve con su motivo, sin perder el resto de la jornada. Cada error lleva un código estable con el que la app decide si reintentar, reenviar como alta o retirar el registro y enseñárselo al técnico: falta el elemento del que cuelga, la orden ya no es suya o se canceló, falta un permiso, el cambio de estado no es posible, la orden ya está cerrada o firmada, falta la firma, los formularios obligatorios o la conformidad del cliente, el lote de lecturas se cerró, el plan no admite más elementos, entre otros.

Permisos por registro. Cada registro se comprueba con los permisos del usuario: el cambio de estado con la regla de la web, el material, los activos y las lecturas con los suyos.

El estado se valida como en la web. Si el técnico pasó sin conexión de pendiente a en curso y a completada, se comprueba que se llega por transiciones válidas. Una cancelación simultánea desde la oficina no acaba en una orden cancelada y completada.

Reenvíos sin duplicados. Una incidencia, un parte rápido, una línea de material o una confirmación de EPIs que se reenvía no se duplica.

Después de guardar, en la misma subida, se recalcula el parte de horas y las tareas, y se comprueban en cada orden que se ha cerrado la firma, los formularios obligatorios y la conformidad del cliente; si falta algo, ese cierre se deshace con sus fechas y sus avisos, y el error va a la orden. Después se propaga el estado a las incidencias, se mueve el stock, se renueva el mapa de los activos subidos y se avisa al supervisor de las posiciones simuladas y de los conflictos detectados.

23.12 Flota y seguimiento desde el móvil

• Check-in de vehículo al empezar la jornada, escaneando su QR o eligiéndolo de una lista.
• Aviso de geolocalización: la app muestra la redacción vigente, registra la aceptación y permite retirarla (14.8).
• Captura de posición por lotes, también con la pantalla apagada, solo dentro de la jornada y con consentimiento (capítulo 14).
• Geovalla: la app detecta la llegada y la salida y pregunta al operario si inicia o termina (capítulo 15).
• Consulta del propio recorrido y de las propias sesiones, y exportación de los propios datos de localización.

23.13 Fechas

Toda fecha que envía la app es un instante con su zona horaria, tomado cuando ocurre el hecho, no al sincronizar. Todas las fechas que recibe la app llegan con zona, y cada orden trae la suya para mostrarlas en la hora del lugar del trabajo, no en la del teléfono.

23.14 Errores y trazabilidad

Todo error tiene un código estable, que la app usa para decidir, y un texto en el idioma del usuario. Cada respuesta lleva un identificador de petición, que permite localizar un error concreto a partir de lo que ve el usuario. Una sincronización larga no retrasa al resto de usuarios.

23.15 Conflictos de sincronización

Cuando la oficina y el móvil cambian lo mismo mientras el técnico está sin conexión, la subida no se limita a «gana el último que envía» sin dejar rastro.

Revisión por registro. Las órdenes de trabajo, incidencias, activos, valores de formulario y líneas de material llevan un número de revisión. La app lo devuelve al subir junto con el valor que tenía cada campo cuando lo descargó.

Fusión campo a campo. Si el registro ha cambiado entretanto, lo que solo cambió el móvil se guarda, lo que solo cambió la oficina se conserva, y lo que cambiaron los dos es un conflicto, que gana el dueño del campo: por defecto manda campo en las fechas reales, la descripción de la incidencia, las propiedades y la posición del activo, los formularios y el material usado; manda la oficina en el título y las notas internas de la incidencia y en el estado, el cliente, el sector, el padre y el código del activo. El administrador puede cambiar el dueño de cada grupo de campos. Cuando gana la oficina, el registro vuelve a bajar al móvil con su valor.

Revisión en la oficina. Administración → Conflictos de sincronización: lista con filtros por operario, tipo de registro, estado y fechas, acotada a la delegación de cada supervisor. Por cada conflicto se puede restaurar lo de la oficina, poner lo del móvil o darlo por bueno. Las decisiones quedan en la auditoría.

Aviso y conservación. Cada operario con conflictos pendientes genera un aviso, que se cierra solo cuando ya no le quedan. Los conflictos revisados se borran a los 180 días y los pendientes a los 365.

23.16 Funciones que dependen de la versión de la app

El servidor mantiene la compatibilidad con las versiones anteriores de la app: todo lo nuevo es opcional. Algunas funciones solo tienen efecto completo con una versión de la app que las incorpore: la fusión de conflictos (23.15), la pregunta «¿Queda resuelto el problema?» (con versiones anteriores, completar resuelve la incidencia), la causa de pausa, «Mi furgoneta» y la confirmación de EPIs, el horario semanal y la fecha límite en la app, y la huella de las respuestas al firmar.

24. Alertas del sistema

Disponibilidad: núcleo; los avisos de módulos no contratados no se generan ni se muestran Superficies: Web (centro de avisos en la barra superior) · Correo y webhook (escalado) Para qué sirve: que lo importante llegue al responsable sin que tenga que ir a buscarlo, que suba de nivel si nadie lo atiende y que desaparezca solo cuando deja de ser importante.

24.1 Catálogo de avisos

24.2 Estructura del aviso

Cada aviso tiene severidad (crítica, alta, media, baja) y estado; título y mensaje, que se muestran en el idioma de quien los mira; el elemento relacionado al que navega al pulsarlo; la delegación a la que afecta; quién lo ha visto, quién se encarga y su nivel de escalado (24.7).

24.3 Centro de avisos

En la barra superior: contador de pendientes, listado ordenado por severidad, navegación directa al elemento, marcar como visto uno o todos, e histórico completo.

Visto es por usuario. Una alerta general solo deja de salirle a quien la marca; los demás la siguen viendo hasta que alguien la resuelve o se resuelve sola.

«Me encargo». Quien recibe un aviso puede hacerse cargo de él: el aviso no se cierra —sigue en la campana de los demás, con quién lo atiende— pero deja de escalar. La campana muestra también el nivel de escalado y por dónde ha pasado el aviso.

24.4 Quién recibe cada aviso

Un aviso dirigido a una persona solo le sale a ella. Uno general le sale a quien cumpla todo esto:

1. La organización tiene el módulo que lo produce.
2. Tiene asignada esa familia de avisos en su rol: incidencias, seguimiento GPS, stock, flota, activos, seguridad, SLA o sincronización (1.7). Por defecto, el administrador y el supervisor las tienen todas y el rol de almacén, la de stock.
3. Es de su delegación, si la organización trabaja con delegaciones. Administradores y usuarios sin delegación los ven todos.
4. No lo ha provocado él: quien crea una incidencia no recibe el aviso de lo que acaba de hacer.

A quien le ha llegado un aviso por escalado le sale siempre.

24.5 Avisos que se cierran solos

• Incidencias: cuando la incidencia deja de estar pendiente o se elimina.
• Stock: un solo aviso por material y almacén, que se pone al día con cada movimiento y se cierra al reponer.
• Falta de material: se pone al día al guardar la orden y se cierra al completarla o cancelarla.
• Orden de trabajo: la pausa al cierre de jornada se cierra al reanudar, y el operario fuera de zona, al dejar de estar en curso; si un cierre desde la app se deshace, vuelven a abrirse.
• SLA: cuando la orden tiene personal, termina o cambia su plazo.
• Cliente no conforme: al asignar personal a la revisión.
• Conflictos de sincronización: cuando están todos revisados.

24.6 Avisos en pantalla

Algunas operaciones devuelven además avisos en la propia respuesta: el alta de una orden o de una programación de preventivo (stock y cualificación), los movimientos de inventario (bajo mínimo o en ruptura) y el planificador (recursos excluidos y órdenes sin cubrir).

24.7 Escalado de avisos

Un aviso que nadie atiende sube de nivel según reglas que el administrador gestiona en Administración → Escalado de avisos:

• Una regla se aplica a unos tipos de aviso, puede estar activa o no y puede usar turnos.
• Cada regla tiene hasta 5 niveles. Cada nivel dice a los cuántos minutos sin atender se sube, a quién —responsable o suplente de la delegación, administradores, un rol, una persona concreta o quien esté de guardia— y por dónde: la campana, el correo o un webhook (25.13).
• Con «usar turnos», a quien no está de turno se le salta y el aviso va a la guardia. Si no queda nadie, va a los administradores: un escalado nunca se pierde.
• El escalado para cuando alguien pulsa «Me encargo» o cuando el aviso se cierra solo.

Cada organización tiene de partida la regla «Avisos críticos»: SLA en riesgo y vencido, incidencias críticas y órdenes urgentes → a los 15 minutos, al responsable de la delegación; 30 minutos después, a los administradores; en la campana y por correo. Los avisos no se envían por SMS ni como notificación en el móvil.

25. API pública, integraciones y gobierno del dato

Disponibilidad: núcleo; la API pública se habilita creando claves de API y los webhooks dando de alta destinos Superficies: API pública · Webhooks salientes · Web (administración) Para qué sirve: que el dato de Maptainer viva en el sistema de información del cliente —su ERP, su GIS corporativo, su cuadro de mando— y que el dato del cliente entre en Maptainer sin exportaciones manuales; y que lo que el sistema guarda sea demostrable, portable y se conserve solo el tiempo debido.

25.1 API pública

API documentada de forma independiente, con su propia especificación OpenAPI y su documentación interactiva accesibles sin clave, que incluye el catálogo de webhooks. Hay guía de integración, un cliente de referencia y, para la integración con un ERP, el manual «Integración con un ERP» con su hoja de correspondencias con los ERP de mantenimiento más habituales.

Es una API de lectura con una única escritura: el alta de incidencias desde otro sistema (25.14).

Autenticación por clave de API, que la organización genera desde la aplicación.

Alcances. Cada clave declara a qué puede acceder: activos, lecturas, órdenes de trabajo, incidencias (lectura y alta), inventario, personal, ficheros y exportación completa. Conceder un alcance no basta: se valida además contra los módulos contratados. Una clave con acceso a lecturas sobre una organización sin módulo de lecturas recibe un error explícito, no una lista vacía. Una clave puede además ir limitada a un cliente, para dar de alta solo sus incidencias.

Cuota de 120 peticiones por minuto y clave (60 altas de incidencia y 10 exportaciones), que la respuesta comunica en cada llamada.

Qué se puede leer:

La lectura pagina por cursor, no por número de página, para que recorrer millones de activos no se vuelva más lento a cada página. Los nombres de recursos y campos forman un contrato público versionado que no expone la estructura interna. Los datos personales del personal y de los usuarios no salen cuando se leen solo como catálogo de apoyo.

25.2 Gestión de claves de API

Autoservicio del administrador, en Administración → API y copias de datos:

• Alta con nombre, alcances (solo los de módulos contratados), caducidad opcional y, si se quiere, un cliente.
• Listado con el prefijo, los alcances, el estado, la caducidad y el último uso; activación, desactivación y borrado.
• Rotación: crea una clave nueva con los mismos alcances y deja viva la anterior unos días, para cambiarla en la integración sin cortar el servicio.
• La clave completa solo se muestra al crearla o rotarla, y cada cambio queda en la auditoría.

25.3 Conexiones remotas (entrada de datos)

Conexiones a APIs REST externas del cliente, con hasta tres direcciones con sus credenciales. Combinadas con el origen de datos externo de una capa (21.10), permiten que Maptainer importe y mantenga actualizado un inventario que vive en otro sistema:

• Sincronización programada a las horas de cada capa, sin solapes con una sincronización manual.
• Incremental: con una sincronización correcta previa, solo se piden los cambios desde entonces, con un pequeño solape; un registro marcado como borrado da de baja su activo.
• Topes de tamaño y tiempo.
• Efectos: se recalculan los códigos, se renueva el mapa de las zonas afectadas y cada cambio de posición queda en el histórico.

Las credenciales de estas conexiones son de sistemas de terceros y se tratan como tales: no se vuelven a mostrar una vez guardadas, se guardan cifradas, solo las gestiona el administrador y la conexión solo sale hacia destinos públicos de Internet, sin seguir redirecciones. Una conexión en uso no se puede borrar.

25.4 Solicitudes de cambio

Flujo de gobierno del dato para las correcciones propuestas desde campo (23.7):

• La solicitud guarda el activo, quién la pidió y cuándo, el tipo de cambio (alta, modificación o eliminación) y lo propuesto: geometría, propiedades, foto o estado.
• Listado y consulta con visualización sobre el mapa y comparación entre el valor actual y el propuesto.
• Aprobar o rechazar es un permiso propio, y nadie resuelve sus propias solicitudes salvo el administrador.
• La decisión se conserva, con quién la revisó, cuándo y sus notas, para poder responder al técnico por qué se rechazó. Cada decisión queda en la auditoría.
• Aprobar un cambio de posición lo anota en el histórico del activo con quien la pidió como autor (25.17).

25.5 Políticas de firma

Catálogo de políticas —firma siempre obligatoria, nunca obligatoria, o según el tipo de mantenimiento—, asignadas por cliente. La política se hace cumplir en el servidor: una orden que la exige no se completa sin firma o excepción, venga el cambio de la web, de las acciones masivas o de la app (5.9). Cada firma se sella (25.16).

25.6 Subida de archivos

Cada subida comprueba lo que recibe y tiene su tope:

El contenido se valida por dentro, no por la extensión: imágenes que se abren como imagen, PDF sin acciones ejecutables, documentos Office modernos sin macros, controles ni objetos incrustados, y rechazo de los formatos antiguos con macros y de las dobles extensiones. El nombre en disco lo pone el sistema. Cada noche se retiran las subidas que ya no usa nadie.

25.7 Búsqueda global

Buscador accesible desde la cabecera que localiza órdenes de trabajo e incidencias (por código, título y descripción), activos (por código y por el valor de sus atributos visibles) y clientes, y navega directamente al resultado. No devuelve lo borrado, y quien solo ve sus órdenes solo encuentra las suyas.

25.8 Seguridad de acceso a ficheros

• Todo fichero y toda la cartografía exigen sesión o clave de API y pertenencia a la organización. Un fichero de otra organización responde como inexistente.
• Lo subido nunca se interpreta en el navegador: lo que no es imagen o PDF se descarga.
• La documentación de las órdenes admite enlaces con caducidad (10 minutos por defecto), para compartir un documento concreto.
• La copia completa de datos se descarga con la sesión del administrador, para que la auditoría diga quién se la llevó.
• Por debajo de todo ello, la base de datos acota cada consulta a su organización (2.14).

25.9 Tareas programadas

25.10 Exportación completa y portabilidad del dato

Para qué sirve: que la organización pueda llevarse toda su información cuando quiera, sin pedirla ni depender de nadie. Responde a «¿y si algún día me quiero ir?», cubre el derecho de portabilidad del art. 20 RGPD y alimenta un almacén de datos o un GIS corporativo sin exportaciones manuales.

25.10.1 Qué se lleva

Los 60 recursos de la API, siempre acotados a lo que la clave puede leer:

Pedir explícitamente un recurso sin permiso da un error: la petición no se recorta en silencio, porque un volcado recortado que el integrador cree completo es peor que un error.

25.10.2 El flujo

Se solicita la copia, se sigue su progreso y, al terminar, se descarga por un enlace firmado de corta duración. Se puede pedir solo lo modificado desde una fecha, incluir o no lo borrado, los ficheros y las hojas de cálculo, y el idioma de los textos. Hay una copia en curso por organización a la vez.

«Backup completo» desde el panel. El administrador la pide en Administración → API y copias de datos sin necesidad de clave, sin opciones que puedan dejarla incompleta: todo lo contratado, con ficheros, con lo borrado y con hojas de cálculo, en el idioma elegido. La petición y la descarga quedan en la auditoría.

25.10.3 El formato del paquete

Un ZIP autodescriptivo: un descriptor del paquete, un fichero de datos por recurso (NDJSON, un registro por línea, que se puede procesar sin cargarlo entero en memoria), las bajas en las copias incrementales, los ficheros con su índice y su huella SHA-256, y una carpeta «Hojas de cálculo» con el mismo contenido pensado para abrirlo en Excel sin saber nada de la API —un CSV por entidad, con cabeceras en el idioma elegido, nombres ya resueltos, los activos de cada capa con sus campos como columnas y cada foto o documento enlazado con su fichero— más un LÉAME.

El descriptor recoge la versión del formato, el momento de la copia (que es el punto de partida de la siguiente sincronización), la moneda de los importes, los filtros aplicados, el número de registros de cada recurso y los ficheros que no se pudieron incluir, que se listan en lugar de abortar la copia.

Todo el volcado se lee de una sola instantánea: un registro que cambie mientras se genera no sale a medias ni con relaciones incoherentes.

25.10.4 Convenciones de los datos

• Geometrías: siempre GeoJSON en longitud y latitud (WGS 84).
• Fechas: ISO 8601. Identificadores: texto. Decimales: numéricos.
• Textos multilingües: en el idioma pedido.
• Nombres: los del contrato público, no los internos.

25.10.5 Los límites, declarados

Cada recurso declara si admite copia incremental y si puede informar de sus bajas, y el descriptor advierte de lo que aplica a cada copia. Publicar estos límites es deliberado: evita que un integrador construya una réplica con huecos creyéndola al día.

25.10.6 Escala

Una copia de 2,2 millones de registros de la organización más grande se genera en unos pocos minutos, y el consumo de memoria no crece con el volumen: se escribe directamente en el paquete, sin cargar nada entero.

25.10.7 Ejecución y ciclo de vida

La copia se genera fuera de la aplicación y arranca en el acto. Una copia interrumpida se da por fallida al cabo de un tiempo, para poder pedir otra, y el paquete se conserva 3 días desde que termina.

25.10.8 Auditoría

Cada copia deja registro permanente: quién la pidió, desde dónde, qué recursos, con qué filtros, cuántos registros de cada uno, el tamaño y la huella del paquete. Una copia completa incluye datos personales, así que la traza no es opcional.

25.11 Errores y trazabilidad de peticiones

Todos los errores siguen una estructura común: un código estable con el que el sistema cliente decide qué hacer, un texto en el idioma del usuario y los datos que lo concretan. Ningún error devuelve detalles internos. Cada respuesta lleva un identificador de petición, que permite localizar un error concreto a partir de lo que ve el usuario.

25.12 Registro de auditoría

Las acciones sensibles quedan en un registro permanente —accesos, usuarios y personal, permisos, datos personales, operación y gobierno del dato, integraciones y organizaciones— que no puede romper la operación que registra, no se pierde si esta se deshace, no guarda secretos y no se puede modificar ni borrar desde la aplicación. La retención es configurable (un año por defecto, nunca menos de 90 días). El administrador lo consulta en Administración → Auditoría (1.12).

25.13 Webhooks salientes

Para qué sirve: que otro sistema —un ERP, un middleware, un cuadro de mando— se entere de los cambios de órdenes de trabajo e incidencias en cuanto ocurren, sin preguntar cada poco. Es la vuelta natural del alta de incidencias por API: el ERP comunica la avería y Maptainer le avisa de la orden, de su cierre y de su resultado.

25.13.1 Eventos

Un cambio de estado produce el evento genérico y el específico: quien solo quiera los cierres se suscribe solo a «orden cerrada».

25.13.2 Cómo se generan

Los eventos se registran en el mismo momento y en la misma operación que el cambio: da igual quién lo haga —la web, la app, una tarea programada o la API—, el evento sale, y si el cambio se deshace, el evento también. Cada evento dice además si el cambio lo hizo una clave de API, para que el receptor reconozca el eco de sus propias altas.

25.13.3 El contenido

Cada evento lleva su identificador (el mismo en todos los reintentos), tipo, versión, instante y organización; la entidad con su código legible, el estado anterior y el nuevo, el cliente y la referencia externa; quién hizo el cambio; el registro completo con el mismo contrato que la API; y lo relacionado: en una orden, sus incidencias con su referencia externa; en una incidencia, sus órdenes.

25.13.4 Firma y seguridad de la entrega

• Firma según el estándar Standard Webhooks, verificable por el receptor con un secreto que se muestra una sola vez y que se puede rotar sin cortes: durante un periodo de gracia valen el secreto anterior y el nuevo.
• Solo https y destinos públicos, sin seguir redirecciones y con tiempos de espera acotados.

25.13.5 Entrega y reintentos

• Las entregas a cada destino van en orden, y un receptor lento no frena a los demás.
• Una respuesta correcta cierra la entrega; cualquier otra cosa se reintenta durante unas 42 horas, con esperas crecientes.
• La entrega es al menos una vez: el receptor descarta repetidos por el identificador del evento.
• Un destino sin una entrega correcta en 3 días se desactiva solo y se avisa por correo a los administradores.
• Los eventos se conservan 30 días.

25.13.6 Configuración

Hasta 10 destinos por organización, con nombre, dirección, eventos (solo los de módulos contratados) y, si se quiere, un único cliente. Desde la misma pantalla se puede probar el destino, ver el historial de entregas con su respuesta y reenviar una entrega concreta.

25.14 Alta de incidencias por la API

Para qué sirve: que un ERP o un sistema de control comunique «hay un problema» y Maptainer se encargue del resto con sus reglas: revisión, orden, planificación, ejecución y cierre.

• Catálogo de tipos de incidencia, criticidades y estados, para montar la tabla de equivalencias con el ERP.
• Alta por el mismo proceso que la web —cliente, delegación, SLA, avisos y código—, en estado pendiente y con origen Integración (API).
• Todo por código: el tipo, la criticidad y los activos (hasta 50) se indican por su código, y un código desconocido o ambiguo da un error explícito. Sin activos, se puede indicar un punto y una dirección.
• Referencia externa (el número de aviso del ERP), única por organización: un segundo alta con la misma referencia devuelve la incidencia que ya existe.
• Protección frente a reenvíos: repetir la misma petición en 24 horas devuelve la misma respuesta sin crear otra incidencia.
• Búsqueda por referencia externa y consulta de una incidencia con su estado.
• Una clave limitada a un cliente solo da de alta y ve las incidencias de su cliente.

Para saber cuándo se resuelve, el integrador se suscribe a los webhooks de incidencias y órdenes, que llevan la referencia externa.

25.15 Derechos de las personas y conservación de los datos personales

Para qué sirve: atender los derechos de acceso, portabilidad y supresión (arts. 15, 17 y 20 RGPD) sin romper la historia del mantenimiento ni sus cifras, y que los rastros de localización y de acceso caduquen solos.

25.15.1 Exportación de los datos de una persona

Un ZIP con todos sus datos en JSON, un CSV por apartado, un LÉAME y los ficheros que subió y sus firmas. Se puede pedir para un usuario, una persona del personal o un usuario del portal, y cada persona puede descargar los suyos desde su perfil. Cada descarga queda registrada.

25.15.2 Supresión por anonimización

Suprimir a un usuario, a una persona del personal o a un usuario del portal anonimiza en lugar de borrar, porque borrar rompería la historia: las órdenes se quedarían sin autor y sin coste. Desaparece lo que identifica a la persona —nombre, correo, teléfono, notas, domicilio, contacto en las incidencias que reportó, DNI de sus firmas— y se borra su localización; se conservan las órdenes, asignaciones, historiales y la prueba del trabajo hecho para el cliente.

La supresión no mueve ninguna cifra de costes: antes de suprimir se fija su parte de horas, y la auditoría guarda la huella económica antes y después como prueba de que nada cambió.

25.15.3 Conservación por plazo

Lo que tiene finalidad propia se conserva; el «por dónde» caduca:

Los usuarios del portal de los clientes dados de baja hace más de 12 meses se anonimizan solos.

25.15.4 Aceptación de los textos legales

Al activar una cuenta, interna o del portal, hay que aceptar la política de privacidad y el aviso legal, y cada aceptación queda registrada con documento, versión, fecha, origen y navegador, sin posibilidad de modificarse. La aplicación no usa servicios de terceros que reciban la visita.

25.16 Sello de integridad y sellado de tiempo de las firmas

Para qué sirve: que la firma del cliente sea prueba de lo que firmó, no solo una imagen.

El sello. Al recibir cada firma o excepción de firma, el sistema guarda una fotografía de lo firmado —la orden, el firmante, la posición, la hora, la imagen de la firma y todas las respuestas de formulario de la orden— junto con su huella SHA-256 y la hora del servidor.

• El firmante va seudonimizado en el sello, de modo que suprimir a la persona (25.15) no invalida el sello.
• Inmutable: el sello no se puede modificar.
• Verificación: la ficha de la orden muestra el estado del sello de cada firma —intacta, modificada (y qué cambió) o sin sellar— y permite descargar lo firmado.

Sellado de tiempo de un tercero. Una vez al día, las huellas de todos los sellos del día anterior se combinan en una sola, que se envía a una autoridad de sellado de tiempo (RFC 3161), que firma «esta huella existía a esta hora». A la autoridad solo le llega la huella, nunca datos. Desde la ficha se descarga una prueba con lo firmado, la prueba de inclusión, la respuesta de la autoridad y un programa que lo verifica fuera de Maptainer.

El sello viaja también en el PDF de la orden, en la API pública y en la copia completa. No es firma electrónica cualificada: lo que aporta es integridad y fecha cierta de lo firmado.

25.17 Histórico de posiciones de los activos

Cada movimiento de un activo deja registro de la posición anterior y la nueva, cuándo, quién y desde dónde (web, móvil, solicitud aprobada o sincronización REST), sea cual sea el camino (4.14). Se consulta en la ficha del activo, por la API pública y en la copia completa, con una hoja de cálculo propia.

A.1 Cómo se gobierna el acceso

Cuatro mecanismos distintos y no intercambiables:

Sobre los dos del medio, un perfil de arranque (2.5) los escribe de una vez. Por debajo de todos, la base de datos acota cada operación a su organización (2.14), y el alcance por asignación limita al técnico a sus órdenes (1.13).

A.2 Matriz completa

Superficies: W = web · M = móvil · P = portal de cliente · A = API pública.

A.3 Permisos por defecto de los roles de sistema

Los roles son de cada organización: lo que su administrador marque o desmarque no afecta a ninguna otra.

Son el punto de partida: una vez creado el rol, sus permisos son decisión de la organización, y las excepciones por usuario prevalecen sobre las del rol.

A.4 Límites de suscripción

Se comprueban al crear, por todas las vías: web, app, sincronización, cargas masivas y sincronización con una API externa. Una carga masiva que no cabe se rechaza entera antes de insertar nada, diciendo cuántos elementos caben: una importación a medias es peor que ninguna. A partir del 80 % del cupo se avisa, y la administración muestra el consumo de cada límite.

El límite acota el crecimiento, no confisca lo existente: una organización por encima de su tope sigue operando todo lo que tiene; solo deja de poder añadir.

A.5 Vigencia de la suscripción

La organización tiene un estado (de alta o de baja) y una fecha de validez, inclusive. Se comprueban al acceder y en cada sesión abierta, en la web, la app, el portal y la API: dar de baja a una organización surte efecto también para quien ya tenía la sesión abierta. El mensaje nombra la organización y, si ha vencido, la fecha.

Treinta días antes del vencimiento, la aplicación muestra un aviso con los días que quedan. Ante un dato dudoso, el sistema deja entrar: dejar fuera a un cliente que ha pagado es mucho peor que dejar entrar un día de más.

Última actualización: 17 OCT 2026