Saltar a contenido

Notificaciones (DEHú) — Puesta a producción

Para qué sirve este documento

Lista de todo lo que el ayuntamiento debe tener resuelto antes de enviar notificaciones electrónicas reales a la ciudadanía mediante el módulo común de Notificaciones. Pensado para responsable funcional + técnico de sistemas. Las conexiones a servicios externos (DEHú, FNMT, DIR3) están descritas con detalle en el catálogo común de integraciones externas; aquí solo se referencian.

Antes de leer

Para conocer la operativa de la bandeja, ver Manual Funcional → Notificaciones. Para los detalles técnicos, ver Manual Técnico → Módulos → Notificaciones.

1. Resumen ejecutivo

El módulo de Notificaciones funciona en modo MOCK desde la instalación — permite ejercitar el flujo completo de extremo a extremo (emisión desde Padrón o Registro, vigilancia, comparecencia simulada, descarga de PDF y acuse) sin valor legal real. Útil para formación interna y validación de flujos antes del alta.

Para ponerlo en producción real hay que resolver 3 frentes:

  1. Trámites administrativos: alta del ayuntamiento como organismo emisor en MINHAP + designación de DIR3 + obtención del certificado FNMT de sello de órgano.
  2. Configuración técnica: URL del servicio DEHú, ruta del .p12 en el servidor, código DIR3 emisor.
  3. Desarrollo pendiente: implementación del cliente SOAP/REST PRODUCTION (hoy es un stub).

Tiempo realista: 15-30 días para los trámites + 2-3 días de desarrollo cuando se reciban las credenciales y la URL.

Lo que funciona sin trámites (operativo desde el día 1, modo MOCK):

  • Bandeja unificada con filtros y paginación.
  • Detalle de notificación con todas las fechas del ciclo de vida.
  • Acciones manuales: consultar estado, reenviar (corrigiendo email), cancelar.
  • Cron diario de vigilancia (auto-rechazo por silencio art. 43.2 LPAC).
  • Configuración multi-tenant: cada entidad activa/apaga DEHú por su cuenta.
  • Emisión automática desde Padrón (renovaciones NIE-NC y comunitarios) y Registro (salidas con interesado de canal electrónico).
  • Auditoría MOS de todos los actos.

Bloqueado sin trámites:

  • Envío real al buzón DEHú del ciudadano (modo PRODUCTION).
  • Acuse firmado real por el canal.
  • Validez legal de las notificaciones emitidas.

2. Trámites administrativos

2.1 Certificado FNMT de sello de órgano

Es el certificado electrónico de la persona jurídica "Ayuntamiento de X" que firma cada llamada a DEHú sin intervención humana.

  • Dónde se pide: sede.fnmt.gob.es — Sello electrónico.
  • Quién lo solicita: la persona titular del órgano (alcalde o secretario) o un funcionario habilitado, presencialmente.
  • Validez: 4 años. La plataforma vigila la caducidad con cron diario.
  • Coste: gratis para AAPP.
  • Tiempo: 1-2 semanas desde la solicitud.
  • Resultado: archivo .p12 con clave privada.

Custodia del certificado

El .p12 da capacidad de firmar como el ayuntamiento. Custodiarlo con el mismo nivel que un sello físico: acceso restringido al administrador del sistema, copia de seguridad cifrada, no enviar por email.

Detalle: Catálogo de integraciones → FNMT.

2.2 Alta como organismo emisor en DEHú

  • Dónde: dehu.redsara.es → alta como organismo emisor.
  • Quién la pide: el técnico/secretario del ayuntamiento aportando el código DIR3 del organismo.
  • Tiempo: 15-30 días hábiles.
  • Coste: gratis para AAPP.
  • Resultado: URL del servicio DEHú asignada al ayuntamiento + confirmación del alta. A partir de aquí el cert FNMT vale como autenticación.

2.3 Código DIR3 del organismo emisor

Es el código común del directorio de unidades administrativas del Estado (formato L01XXXXXX para ayuntamientos). Generalmente ya está asignado al ayuntamiento — si no, se solicita en el alta MINHAP. Sin él no es posible activar PRODUCTION.

3. Configuración técnica

Una vez completados los tres trámites:

3.1 Subir el .p12 al servidor

# Linux (ejemplo)
sudo mkdir -p /srv/civis/certs
sudo chown civis:civis /srv/civis/certs
sudo chmod 700 /srv/civis/certs
# copiar el .p12 a /srv/civis/certs/dehu-<entidad>.p12
sudo chmod 600 /srv/civis/certs/dehu-<entidad>.p12

# Windows
New-Item -ItemType Directory -Path C:\civis\certs -Force
# copiar el .p12 a C:\civis\certs\dehu-<entidad>.p12
icacls C:\civis\certs\dehu-<entidad>.p12 /inheritance:r /grant:r "civis:R"

Permisos

El proceso que arranca el backend Flask (gunicorn, python run.py, etc.) debe poder leer el archivo. Nadie más.

3.2 Activar PRODUCTION desde la UI

  1. Acceder con un usuario que tenga el permiso notificaciones:dehu:admin.
  2. Ir a /notificaciones-dehu/configuracion (botón Configuración DEHú desde la bandeja).
  3. Rellenar:
    • Modo = PRODUCTION.
    • URL del servicio = la que devolvió MINHAP en el alta.
    • Código DIR3 emisor = el del ayuntamiento.
    • Ruta del certificado = ruta absoluta del .p12 en el servidor.
  4. Subir el interruptor "Activado".
  5. Guardar.

El sistema valida que estén las cuatro piezas antes de permitir activar PRODUCTION; si falta alguna, devuelve un mensaje claro.

3.3 Comprobar el cron de vigilancia

El cron notificaciones.vigilar_vencimientos (0 5 * * *) viene sembrado de fábrica. Comprobar en Sistema → Tareas programadas que está activo y que next_run apunta a las 05:00 del día siguiente.

Para que el cron se ejecute realmente hay que tener el scheduler MOS arrancado como servicio (python run_scheduler.py). Ver MOS — Arranque del scheduler y Puesta en marcha → Tareas programadas.

4. Desarrollo pendiente (cliente PRODUCTION)

El módulo trae el cliente DEHú con dos modos:

  • MOCK — implementación completa, deterministas, lista para usar.
  • PRODUCTION — stub que devuelve siempre ERROR PRODUCTION_NO_IMPL. Hay que sustituirlo por la implementación SOAP/REST real cuando exista alta MINHAP.

Punto de inserción: app/modules/notificaciones/servicios/cliente_dehu.py. Las tres funciones a implementar tienen la interfaz fijada:

Función Entrada Salida
poner_a_disposicion(notif) NotificacionElectronica objeto con ok, identificador_externo, fecha_puesta_disposicion, modo, error_codigo, error_mensaje.
consultar_estado(entidad_id, identificador) identificador externo objeto con ok, estado (PUESTA_A_DISPOSICION/COMPARECIDA/RECHAZADA/VENCIDA), fecha_evento, error_codigo, error_mensaje.
descargar_acuse(entidad_id, identificador) identificador externo bytes del PDF o None.

La implementación real:

  1. Carga el .p12 desde NotificacionesConfiguracion.dehu_cert_path de la entidad.
  2. Construye el cliente SOAP (zeep o equivalente) contra NotificacionesConfiguracion.dehu_url.
  3. Aplica firma XML-DSig con el cert.
  4. Mapea respuestas DEHú al formato interno.

Estimación realista

2-3 días de desarrollo + 1-2 días de pruebas en pre-producción contra el entorno SANDBOX de DEHú que MINHAP suele proporcionar tras el alta.

5. Checklist de paso a producción

Estado de cada pieza:

  • FNMT: cert de sello de órgano obtenido y subido al servidor.
  • MINHAP: alta como organismo emisor en DEHú confirmada.
  • DIR3: código del ayuntamiento conocido y verificado.
  • URL DEHú: la real del entorno PRODUCTION proporcionada por MINHAP.
  • Cliente PRODUCTION: implementado, validado en SANDBOX.
  • Configuración UI: rellenada y dehu_activo=true.
  • Cron scheduler: run_scheduler.py arrancado como servicio.
  • Cron vigilancia: notificaciones.vigilar_vencimientos activo.
  • Backup: del .p12 y de la BD (Fernet key incluida).
  • Permisos: notificaciones:dehu:admin asignado solo al admin.
  • Formación: operadores entrenados con la bandeja en MOCK.

6. Pruebas en pre-producción

Antes de habilitar PRODUCTION para los usuarios finales, recomendamos esta secuencia de pruebas en SANDBOX:

  1. Emisión desde Padrón: forzar una renovación bianual NIE-NC sobre un habitante de prueba con email controlado → comprobar que la notificación aparece en la bandeja con estado PUESTA_A_DISPOSICION.
  2. Emisión desde Registro: crear un Registro de Salida con interesado canal ELECTRÓNICO + email → comprobar entrega.
  3. Consultar estado: desde el detalle → comprobar que la consulta a DEHú devuelve el estado real (con un buzón de prueba el ciclo se completa rápido).
  4. Comparecencia simulada: abrir el buzón DEHú con el ciudadano de prueba, firmar la comparecencia → consultar estado → debe pasar a COMPARECIDA. Descargar el acuse y verificarlo.
  5. Vencimiento: dejar caducar una notificación 11 días → ejecutar el cron manualmente desde Sistema → Tareas programadas → Ejecutar ahora → debe pasar a RECHAZADA con motivo "Vencido plazo art. 43.2 LPAC".
  6. Error y reenvío: forzar un email inválido → cancelar → reemitir con email corregido → comprobar segundo intento.
  7. Cancelación: emitir → cancelar con motivo → comprobar trazabilidad.

Si los 7 pasos pasan, la entidad está lista para abrir DEHú a la ciudadanía.

7. Operación diaria

  • Vigilancia: el cron diario hace el grueso del trabajo. No requiere intervención humana.
  • Reenvíos manuales: filtrar bandeja por estado = ERROR → reenviar con email corregido cuando proceda.
  • Caducidad del cert FNMT: el cron de Padrón padron_cert_sello_caducidad ya avisa con 30 días de margen. Renovar el cert y subir el nuevo .p12 reusando la misma ruta evita downtime.
  • Cambio de URL DEHú: en caso de migración del servicio MINHAP, basta actualizar dehu_url desde la pantalla de configuración.

8. Coexistencia con el envío postal

Activar DEHú no desactiva el canal postal. Lo que ocurre es:

  • En Registro: el interesado con canal POSTAL sigue por correo. El interesado ELECTRÓNICO con email pasa a DEHú. AMBOS sin email permanece postal.
  • En Padrón: las renovaciones con email pasan por DEHú; las que no tienen email siguen por el flujo postal habitual.

Por tanto el ayuntamiento puede convivir con ambos canales durante una transición larga sin complicaciones.

Listo

Cuando el checklist de la sección 5 esté todo marcado, las notificaciones electrónicas del ayuntamiento tienen plena validez legal art. 43 LPAC y la trazabilidad queda dentro de Gestión Civis.