Padrón — Puesta a producción

Para qué sirve este documento

Lista exhaustiva de todo lo que el ayuntamiento debe tener resuelto antes de poner en producción el módulo Padrón de Habitantes. Pensado para un responsable funcional + un técnico de sistemas que preparan el municipio juntos. No es un manual de usuario: es la checklist de prerrequisitos administrativos, legales y técnicos.

Antes de leer

Para conocer las pantallas y procedimientos del módulo, ver Manual Funcional → Padrón de Habitantes. Para los detalles técnicos (modelos, endpoints, crons), ver Manual Técnico → Módulos → Padrón de Habitantes. Para los detalles de cada conexión externa (Catastro, INE, PID, FNMT, DEHú, TSA…), ver el Catálogo común de integraciones externas.

Navegación

Usa el índice lateral derecho para saltar entre secciones. El documento tiene 12 apartados: del resumen ejecutivo a la checklist final ordenada por meses.

1. Resumen ejecutivo

El módulo Padrón funciona técnicamente al 100% en modo desarrollo y demo pero su puesta en producción requiere completar 4 frentes:

Datos: cargar el callejero (Catastro), la cartografía (INE) y los habitantes (migración del sistema anterior).
Trámites administrativos: convenios y altas en MINHAP, INE, DEHú, FNMT, PID/SCSP.
Certificados electrónicos: instalar sello de órgano FNMT y opcionalmente certificados personales de firmantes.
Decisiones funcionales: elegir canal IDA, método de firma, plazos de notificación, umbrales de inspección.

Tiempo realista: 2-4 meses desde "hoy" hasta producción plena, condicionado por la velocidad de los trámites con AAPP externas (especialmente FNMT y PID).

Funcionalidades que NO requieren ninguno de estos trámites (operativas desde el día 1 de instalación): - Gestión interna del padrón: altas, bajas, cambios de domicilio, modificaciones. - Hojas padronales, movimientos con hash-chain. - Volantes de empadronamiento (sin firma, validez interna). - Importación de callejero desde Catastro (servicio público abierto). - Inspección y renovaciones (cron interno, sin envíos externos). - Explorador estadístico, cifras oficiales (en modo "no comunicadas al INE").

Funcionalidades BLOQUEADAS sin trámites: - Comunicación mensual al INE (IDA): necesita alta en intercambio.ine.es. - Certificados de empadronamiento firmados oficialmente: necesita cert FNMT o certificado personal del firmante. - Notificación electrónica al ciudadano (DEHú): necesita alta en DEHú + cert. - Verificación de residencia saliente (consultar a otros municipios via PID): necesita convenio PID + cert FNMT. - Sello PAdES-T con TSA acreditada: ya operativo por defecto (DigiCert público), pero el ayuntamiento puede preferir TSA propia/CCN-CERT.

2. Datos iniciales — carga del padrón al arrancar

El sistema arranca vacío. La primera vez que el ayuntamiento lo use hay que cargar cuatro conjuntos de datos en este orden:

2.1 Configuración del municipio

En Configuración del módulo Padrón → identificar el municipio:

Campo	Dónde sacarlo	Obligatorio para
`codigo_ine_municipio` (5 dígitos)	INE: Códigos de Comunidades, Provincias y Municipios. Ej.: Plasencia = `10148`	IDA al INE
`catastro_provincia_` y `catastro_municipio_`	Autocompletado en la pantalla (consulta web service Catastro público)	Importar callejero

2.2 Cartografía censal (distritos y secciones)

Origen: Instituto Nacional de Estadística — fichero shapefile anual.

URL: https://www.ine.es/prodyser/cartografia/seccionado_actual.zip
Cómo se carga: pantalla "Importar cartografía INE" del módulo. Acepta:
Descarga automática (HTTP GET a la URL anterior, sin auth).
Subida manual del ZIP si la red no permite la descarga directa.
Frecuencia: anual (INE publica un seccionado nuevo cada enero/febrero).
Bloqueante: NO para empadronar; SÍ para mapa de calor y asignación automática de secciones censales a vías.

2.3 Callejero (vías, fincas, viviendas)

Origen: Catastro — servicio público OVCCallejero + OVCCoordenadas.

URL: http://ovc.catastro.meh.es/ovcservweb/OVCSWLocalizacionRC/OVCCallejero.asmx y OVCCoordenadas.asmx.
Autenticación: NINGUNA (servicio abierto).
Cómo se carga: pantalla "Importación masiva Catastro" (2 fases):
Fase 1: descarga todas las vías del municipio + sus fincas con RC14.
Fase 2: coordenadas + viviendas (subdivisiones) por finca.
Tiempo: para un municipio mediano (~40 000 fincas) son ~3-4 horas.
Limitación: Catastro banea por IP si recibe >5 peticiones/s sostenidas. El sistema autolimita a 0,4 s entre peticiones y detecta los 429.
Refresco: la pantalla "Sincronización Catastro" permite refrescar vías individuales sin reimportar todo (recomendado mensualmente para detectar renumeraciones).

2.4 Habitantes (la migración crítica)

Origen: el sistema padronal anterior del ayuntamiento. Esto es lo más delicado: cada ayuntamiento viene con un formato distinto.

Formatos típicos: CSV/Excel exportado del sistema anterior, dump SQL, conector directo a la BD legacy.
Lo que el módulo necesita: por cada habitante,
Documento (DNI/NIE/Pasaporte) con tipo
Nombre, primer apellido, segundo apellido
Fecha y lugar de nacimiento, sexo, nacionalidad
Dirección de empadronamiento (vivienda, fecha alta)
Estado (EMPADRONADO o no)
NO hay importador genérico: se construye un script ad-hoc por ayuntamiento, generalmente partiendo de scripts/seed_padron_demo.py como plantilla.
Validación previa obligatoria:
DNIs con letra correcta (algoritmo módulo 23)
Direcciones cruzadas contra el callejero importado (las que no encajen quedan en una lista de "habitantes huérfanos" para revisión manual)
Coherencia INE: si el INE tiene cifras oficiales del ayuntamiento, deben coincidir en ±2% como mucho
Estimación: 1-2 semanas de un técnico para preparar, validar y ejecutar la carga en un municipio de 20 000 habitantes.

2.5 Hojas padronales

Se crean automáticamente al cargar los habitantes (una hoja por vivienda ocupada). El representante de hoja se asigna automáticamente al primer habitante con relación PROPIETARIO (si no, el primero por orden).

3. Trámites administrativos externos

Todos requieren plazos NO controlables por el ayuntamiento. Iniciarlos en cuanto se decida adoptar la plataforma.

3.1 Alta en intercambio.ine.es (canal CLÁSICO IDA)

Para qué: enviar mensualmente las variaciones del padrón al INE.
Cómo: el secretario/a del ayuntamiento solicita acceso al portal intercambio.ine.es indicando código INE del municipio. INE devuelve un usuario + contraseña para subir manualmente el TXT generado.
Tiempo: 5-15 días hábiles.
Coste: gratis.
Bloquea: la Comunicación INE (sin esto el operario no puede subir el fichero IDA generado por el sistema).

3.2 Alta en eIDA (canal moderno IDA por web service)

Para qué: igual que el anterior pero automático vía SOAP, sin clic humano. Recomendado para municipios grandes.
Cómo: solicitud a s.g.estadisticas.poblacion@ine.es con datos del ayuntamiento + cert FNMT del sello de órgano (ver §4).
Tiempo: 1-3 meses (INE valida la conectividad y firma convenio).
Coste: gratis.
Bloquea: solo el envío automático. El canal CLASICO sigue funcionando.

3.3 Convenio PID/SCSP (Plataforma de Intermediación de Datos)

Para qué: consultar el padrón nacional (Verificación de residencia saliente) y, en general, cualquier servicio interadministrativo del Estado.
Cómo: el ayuntamiento se adhiere al convenio marco de la SGAD (Secretaría General de Administración Digital): https://administracionelectronica.gob.es/ctt/scsp
Documentación: formularios de alta como organismo cedente y cesionario
designación de responsable + relación de servicios solicitados (el que nos interesa: SVDR — Verificación de Datos de Residencia).
Tiempo: 2-6 meses.
Coste: gratis para AAPP.
Bloquea: la consulta saliente al padrón nacional. Hasta que esté, el módulo funciona en modo MOCK (genera respuestas ficticias).

3.4 Alta en DEHú (Dirección Electrónica Habilitada Única)

Para qué: notificar electrónicamente al ciudadano (avisos de renovación, requerimientos, etc.). Sustituye al envío postal en los obligados (personas jurídicas + ciudadanos voluntarios).
Cómo: alta en https://dehu.redsara.es como organismo emisor. Requiere cert FNMT de sello de órgano.
Tiempo: 15-30 días hábiles.
Coste: gratis para AAPP.
Bloquea: solo la notificación electrónica. El envío postal sigue estando como fallback.

3.5 Convenios bilaterales para cesiones SVDR entrantes

Para qué: cuando OTRA AAPP (Diputación, INSS, Universidad...) quiere consultar tu padrón vía API, hace falta convenio.
Cómo: contrato bilateral firmado entre ambas AAPP especificando finalidad, base legal, plazo de retención de datos, responsable LOPD.
Tiempo: variable, semanas a meses.
Coste: gratis.
Cuándo hace falta: solo al dar de alta una API key para ese organismo desde la pantalla "Verificación de residencia". El sistema te pide poner la referencia del convenio firmado.

4. Certificados electrónicos

4.1 Sello de órgano (FNMT — obligatorio)

Qué es: certificado de la persona jurídica "Ayuntamiento de X" que firma electrónicamente sin necesidad de un humano (cron, web service, sello automático en PDFs).
Dónde se pide: FNMT — Cert. Sello Electrónico.
Quién lo pide: la persona titular del órgano (alcalde o secretario) o un funcionario habilitado.
Validez: 4 años. Vigilar caducidad — el sistema avisa con cron diario padron_habitantes.cert_sello.vigilar_caducidad cuando faltan ≤30 días.
Coste: gratis para AAPP.
Dónde se guarda: el archivo .p12 se sube a la pantalla "Configuración Padrón → Certificado de sello" y se cifra en BD con Fernet.
Bloquea: firma de certificados de empadronamiento, eIDA, DEHú, SVDR saliente.

4.2 Certificados personales de firmantes (opcional)

Qué es: cert FNMT/DNIe personal del alcalde / secretario / técnico que vaya a firmar manualmente certificados.
Cuándo hace falta: solo si el ayuntamiento decide habilitar la modalidad de firma con cert personal (alternativa al sello de órgano).
Modalidades soportadas en el módulo (configurables por entidad):
permite_sello_organo (default true)
permite_cert_personal (default false)
permite_autofirma (default false)

4.3 AutoFirma (cliente Java instalado en el funcionario)

Qué es: aplicación oficial del Gobierno para firmar con DNIe/cert personal sin subir el archivo .p12 al servidor.
Cómo se activa: el firmante instala AutoFirma en su PC y el módulo abre el firmador local cuando pulsa "Firmar" si la entidad tiene permite_autofirma=true.
Bloquea: solo si quieres usarlo (es uno de los 3 métodos).

4.4 TSA (Time Stamping Authority) para PAdES-T

Qué es: sello de tiempo cualificado que se añade a los PDFs firmados para que la firma sea válida incluso si el certificado caduca.
Estado actual: ya operativo por defecto contra http://timestamp.digicert.com (TSA pública gratuita).
Alternativas (configurables): TSA propia del ayuntamiento, CCN-CERT, ACCV, FNMT.

5. Conectividades externas

Servicio	Dirección	Autenticación	Frecuencia	Estado actual
Catastro callejero	`http://ovc.catastro.meh.es/ovcservweb/.../OVCCallejero.asmx`	Ninguna	Carga inicial + sincronización mensual	✅ Operativo
Catastro coordenadas	`http://ovc.catastro.meh.es/ovcservweb/.../OVCCoordenadas.asmx`	Ninguna	Carga inicial	✅ Operativo
INE cartografía	`https://www.ine.es/prodyser/cartografia/seccionado_actual.zip`	Ninguna	Anual	✅ Operativo
INE intercambio (CLÁSICO)	`https://intercambio.ine.es`	Usuario+contraseña por portal web	Mensual (variaciones del padrón)	🟠 Requiere alta
INE eIDA (moderno)	A confirmar con INE en alta	Cert FNMT sello de órgano	Mensual auto	🟠 Requiere alta + cert
PID / SCSP — SVDR	`https://intermediacion.administracionelectronica.gob.es/...`	Cert FNMT sello de órgano	Bajo demanda	🟠 Requiere convenio + cert
DEHú	`https://dehu.redsara.es/...`	Cert FNMT sello de órgano	Por cada notificación	🟠 Requiere alta + cert
TSA DigiCert	`http://timestamp.digicert.com`	Ninguna	Por cada firma PAdES-T	✅ Operativo
FNMT (cert sello)	`https://www.sede.fnmt.gob.es/...`	Identificación presencial inicial	Renovación cada 4 años	🟠 Trámite

✅ Operativo: usable hoy sin trámite. 🟠 Requiere trámite: ver §3.

6. Decisiones funcionales del ayuntamiento

Estas decisiones debe tomarlas la corporación municipal antes de activar el módulo en producción. Casi todas se reflejan en "Configuración del módulo Padrón" desde la propia UI.

6.1 Canal de comunicación con el INE

CLASICO (default): el sistema genera el TXT mensual, el operario lo sube manualmente al portal intercambio.ine.es, y luego sube la respuesta cuando llega. Recomendado para municipios <50 000 habitantes.
eIDA: envío y recepción automáticos por web service. Requiere alta específica (§3.2). Recomendado para municipios grandes.

6.2 Modalidades de firma habilitadas

Por cada uno de los 3 métodos, decidir si se permite (true/false):

permite_sello_organo: la entidad firma automáticamente con su cert FNMT. Cómodo, sin clic humano.
permite_cert_personal: alcalde/secretario sube su .p12 y firma cada documento. Mayor trazabilidad legal.
permite_autofirma: el firmante usa AutoFirma local. Más seguro (la clave nunca sale de su PC).

6.3 Rol funcional responsable

rol_funcional_firma_cert_id: rol al que se notifica que hay un certificado pendiente de firma (típicamente "Alcalde" o "Secretario"). Si es NULL, los certificados quedan EMITIDOS sin paso de firma.
rol_funcional_notif_id: rol al que se notifica el resultado del envío mensual al INE.

6.4 Notificación automática por email

notificar_email: si activo, además de la bandeja interna se manda email.
email_notificacion: dirección a notificar (puede ser una lista de distribución del ayuntamiento).

6.5 Umbrales de inspección

(Hardcoded por ahora en código, ver §8.6 para migrarlos a configuración). Por defecto: - Sobrepoblación: >8 residentes activos por vivienda. - Sin renovación: residencia activa >5 años sin movimientos. - Aviso NIE-NC: 60 días antes del vencimiento. - Vivienda vacía: 30 días sin habitantes empadronados.

6.6 Plazos legales del padrón

(Vienen impuestos por norma, no decidibles, pero conviene conocerlos): - Renovación NIE-NC: cada 2 años. - Renovación comunitario sin certificado permanente: cada 5 años. - Snapshot anual: a 1 de enero, aprobado en enero/febrero. - Envío IDA al INE: primeros 10 días de cada mes con variaciones del mes anterior.

7. Roles y personas

7.1 Roles RBAC (técnicos, en el sistema)

El módulo tiene 32 permisos canónicos y 1 rol agregador "Jefe de Padrón" con todos ellos. Roles típicos:

Rol	Permisos clave	Equivalente humano
Jefe de Padrón	Todos (32)	Jefe/a del Negociado de Estadística
Operario Padrón	habitante, vivienda, movimiento (CRUD); volante:emitir	Auxiliar administrativo del padrón
Auditor Padrón	*:ver, inspeccion:ver, svdr:auditar	Interventor / auditor interno
Lector Padrón	*:ver	Concejalía consultora

Se asignan desde el módulo Admin → Roles → asignar permisos. Ver [project_permisos_plan_fases.md] en docs internos para el catálogo completo.

7.2 Roles funcionales (institucionales)

Distintos de los RBAC. Son cargos políticos/funcionales que se mantienen aunque cambie la persona (alcalde, secretario, interventor). Se gestionan en módulo Admin → Roles Funcionales.

Configurar al menos: - "Alcalde/sa" — para firma de Decreto de aprobación del padrón anual. - "Secretario/a" — para firma de certificados oficiales si se elige esa modalidad. - "Responsable LOPD" — para responder peticiones ARCO.

7.3 Responsable LOPD (legal)

Designación obligatoria por RGPD. La persona o departamento al que se remitirán las peticiones de los ciudadanos sobre sus datos. Su nombre debe aparecer en la página de "Sede Electrónica → Política de privacidad" del ayuntamiento.

8. Configuración técnica del sistema

8.1 Variables de entorno (.env del servidor)

Mínimas para producción:

SECRET_KEY=<aleatoria larga, NO la por defecto>
DATABASE_URL=postgresql://usuario:pass@host:5432/gestion_civis
FERNET_KEY=<clave Fernet de 32 bytes base64, generada con cryptography>
STORAGE_PROVIDER=local      # o 'gcs' si usas Google Cloud Storage
STORAGE_LOCAL_PATH=/var/lib/gestion_civis/storage
FRONTEND_URL=https://padron.tuayuntamiento.es
SMTP_HOST=...
SMTP_USER=...
SMTP_PASSWORD=...
SMTP_FROM=padron@tuayuntamiento.es

CRÍTICO: la FERNET_KEY cifra DNI, fecha de nacimiento, lugar de nacimiento de los habitantes en BD. Si se pierde, esos datos quedan inaccesibles para siempre. Backup separado y custodia segura.

8.2 Base de datos PostgreSQL

Versión mínima recomendada: 14.
Extensiones requeridas: ninguna específica (todo SQL estándar).
Tamaño orientativo: ~200 MB por cada 10 000 habitantes en operación durante un año.
Tablespaces separados recomendados para padron_hab_movimiento (crece linealmente con la actividad).

8.3 Storage de PDFs

Volantes, certificados, ficheros IDA y devoluciones se guardan en filesystem o Google Cloud Storage. Tamaño orientativo: ~200 KB por PDF. Un municipio de 30 000 habitantes genera ~10 000 PDFs/año.

8.4 Cifrado en reposo (Fernet)

Aplicado a: documento, fecha_nacimiento, lugar_nacimiento del habitante.

Implementación: app/utils/encrypted_string.py (TypeDecorator). Para búsquedas exactas se usa doc_busqueda (SHA-256 hex no reversible).

8.5 Hash-chain en movimientos

Cada PadronMovimiento lleva hash_anterior (del movimiento previo) y hash_propio (SHA-256 de su propio contenido). Garantiza integridad demostrable: si alguien borra o modifica un movimiento, el siguiente lo detecta. Verificable con utility en scripts/.

8.6 Configuración multi-tenant

Toda configuración del módulo (canales, certs, plazos, métodos firma) está en la tabla padron_hab_configuracion con una fila por entidad. Nunca en variables de entorno, para no contaminar instancias multi-municipio.

8.7 Puerto y reverse proxy

Backend Flask por gunicorn en puerto interno (típicamente 5000).
Frontend servido por Vite build estático tras nginx.
TLS terminado en nginx con cert Let's Encrypt o cert FNMT del ayuntamiento (recomendado).

9. Procesos automáticos (crons MOS)

El sistema tiene un scheduler interno (app/core/mos/scheduler.py) que ejecuta acciones programadas. Vigilar que esté arrancado (típicamente como servicio systemd separado).

Cron	Cuándo	Qué hace	Crítico
`padron_habitantes.inspeccion.detectar`	Diario 04:00	Las 8 reglas de inspección + asignación geo vía→sección	Alta
`padron_habitantes.renovaciones.detectar`	Día 1 de cada mes 05:00	Crea PROGRAMADAS para NIE-NC y comunitarios	Alta
`padron_habitantes.ida.generar_mensual`	Día 1 de cada mes 06:00	Genera fichero IDA del mes anterior	Alta
`padron_habitantes.snapshot.generar_anual`	2 enero 03:00	Snapshot de cifras oficiales	Alta
`padron_habitantes.cert_sello.vigilar_caducidad`	Diario	Avisa si cert FNMT caduca en ≤30d	Media

Si el scheduler cae, ninguno de estos procesos se ejecuta — el ayuntamiento podría dejarse sin avisar incidencias durante semanas. Monitorizar con alerting externo.

10. Cumplimiento legal y seguridad

10.1 Normativa aplicable al padrón

Ley 7/1985 de Bases del Régimen Local — competencia del padrón.
RD 1690/1986 Reglamento de Población y Demarcación Territorial — procedimiento de la revisión anual y aprobación (art. 81).
Resolución INE/DGCAH 17/02/2020 — instrucciones técnicas de comunicación con el INE (sustituye a la de 01/04/1997).
Ley 39/2015 Procedimiento Administrativo Común — notificación electrónica + cesión de datos entre AAPP (art. 28).
Reglamento Población — art. 70-72 — bajas por duplicado y por inscripción indebida.

10.2 Normativa de protección de datos

RGPD (UE 2016/679) — base legal para tratamiento (art. 6.1.c — obligación legal del padrón), derechos del ciudadano (art. 15-22).
LO 3/2018 LOPDGDD — adapta el RGPD en España, audit log de cesiones obligatorio (art. 6).

El sistema cumple en lo técnico: - Audit log de cesiones SVDR (entrantes Y salientes). - Cifrado en reposo de datos sensibles. - Hash-chain para integridad. - Retención: los movimientos son inmutables y permanentes; los volantes emitidos quedan archivados en el habitante.

El ayuntamiento debe cumplir en lo organizativo: - Designar Responsable de tratamiento (suele ser el alcalde) y DPO. - Inscribir el tratamiento en el Registro Público de Actividades de Tratamiento (RAT) de la AEPD. - Política de privacidad publicada en sede electrónica. - Procedimiento para atender peticiones ARCO en ≤30 días.

10.3 Seguridad operativa

Acceso al sistema solo por HTTPS.
Contraseñas hash bcrypt.
JWT con expiración corta + refresh token.
Rate limiting en endpoints (especialmente login).
Logs de acceso retenidos ≥1 año.
Backup cifrado.
Acceso al cert FNMT solo desde el servidor, nunca por email.

11. Backups y continuidad

11.1 Qué hay que respaldar

Elemento	Frecuencia	Retención	Cifrado
BD PostgreSQL	Diario	30 días + 1 mensual al año	Sí
Storage de PDFs	Diario incremental	Indefinida	Sí
Cert FNMT (.p12)	Una vez al instalar + cada renovación	Hasta renovar +5 años	Sí (custodia en caja fuerte)
`FERNET_KEY`	Una vez + custodia separada	Vida del sistema	Imprescindible
`.env` del servidor	En cada cambio	Vida del sistema	Sí

11.2 Plan de continuidad

Servidor secundario en caliente recomendado para municipios >20 000 habitantes (RPO ≤1 día, RTO ≤4 horas).
Probar la restauración trimestralmente (no vale solo hacer backups).
En caso de pérdida total: orden de recuperación = BD → FERNET_KEY → storage → cert FNMT → reanudar.

11.3 Migración a otro proveedor

Toda la información reside en BD + storage. La migración es trivial exportando el dump SQL y copiando los PDFs, siempre que se mantenga la misma FERNET_KEY (o se reemcripte la BD con la nueva).

12. Checklist final ordenada

Ordenada por dependencia: cada paso desbloquea el siguiente.

Mes 1 — Preparación administrativa (en paralelo a desarrollo/despliegue)

Decidir canal IDA (CLASICO o eIDA).
Iniciar solicitud de cert FNMT de sello de órgano.
Iniciar adhesión a PID/SCSP.
Iniciar alta en DEHú.
Decidir modalidades de firma (sello/cert personal/AutoFirma).
Designar Responsable LOPD y DPO.

Mes 1-2 — Despliegue técnico

Provisionar servidor con PostgreSQL 14+, Python 3.11+, Node 18+.
Generar SECRET_KEY y FERNET_KEY y custodiar separadamente.
Configurar .env con credenciales reales.
Aplicar todas las migraciones (flask db upgrade).
Seed inicial: python seed.py (roles, permisos canónicos).
Configurar reverse proxy con TLS.
Configurar scheduler MOS como servicio systemd.
Configurar backups diarios automáticos.
Crear usuarios del ayuntamiento + asignarles roles.

Mes 2 — Carga de datos

En "Configuración del módulo Padrón": código INE + municipio Catastro.
Importar cartografía censal del INE.
Importación masiva Catastro (callejero — 3-4 horas).
Migración del padrón histórico desde sistema anterior.
Validación cruzada con cifras INE oficiales.
Sincronización vía → sección por point-in-polygon (auto al terminar Catastro).

Mes 2-3 — Activación de servicios externos (según vayan llegando)

Recibido cert FNMT → instalar en pantalla Configuración → activar sello de órgano.
Alta CLASICO INE confirmada → primer envío IDA manual de prueba.
(Si aplica) eIDA activo → cambiar canal en configuración.
Convenio PID firmado → cambiar svdr_saliente_modo a PRODUCTION y rellenar URL + cert.
Alta DEHú activa → activar canal electrónico de notificaciones.

Mes 3 — Pruebas en producción con datos reales

Generar fichero IDA del mes en curso y validar contenido.
Emitir 5-10 volantes/certificados de prueba y comprobar firma.
Lanzar inspección y revisar casos detectados.
Generar snapshot anual de cifras y descargar PDF.
Hacer 3 consultas SVDR salientes para verificar conexión PID real.
Ejecutar drill de restauración de backup.

Antes de abrir al público

Política de privacidad publicada.
Inscribir el tratamiento "Padrón Municipal" en el RAT del AEPD.
Procedimiento documentado para peticiones ARCO.
Formación a los operarios en las pantallas.
Manual interno de procedimientos (decreto Alcaldía aprobando uso).

Tras la puesta en marcha (operación continua)

Monitorizar scheduler MOS (alerting externo si no ejecuta).
Monitorizar caducidad cert FNMT (renovar 30 días antes).
Revisar incidencias INE mensualmente.
Sincronizar Catastro mensualmente (sin reimportar todo).
Snapshot anual aprobado por Decreto de Alcaldía en enero/febrero.
Cartografía INE actualizada anualmente cuando publican seccionado nuevo.

Resumen visual de bloqueos

            Sin trámites             Con trámites              En producción
            (instalación)            (semanas-meses)           (todo activo)

Habitantes  ✅ alta/baja              ✅ misma                 ✅ misma
Volantes    ✅ sin firma              ✅ con sello FNMT        ✅ con firma legal
Certif.     ⚠️ sin firma legal        ✅ con sello/cert        ✅ con firma legal
IDA         ⚠️ genera pero no envía   ✅ envío CLASICO         ✅ envío eIDA auto
Cifras      ✅ generables             ✅ aprobables Decreto   ✅ comunicadas INE
SVDR salida ⚠️ modo MOCK             ⚠️ modo MOCK            ✅ contra PID real
DEHú        ❌ no operativo          ⚠️ pendiente              ✅ operativo
Catastro    ✅ funcional              ✅ funcional             ✅ funcional

Anexo — Contactos útiles

INE — Subdirección General Estadísticas Población: s.g.estadisticas.poblacion@ine.es
FNMT — Soporte certificados AAPP: https://www.sede.fnmt.gob.es/soporte-tecnico
PID/SCSP — Soporte Plataforma: https://administracionelectronica.gob.es/ctt/scsp
DEHú — Soporte: dehu@correo.gob.es
Catastro — Webmaster servicios web: https://www.catastro.minhap.es/ovcweb/help/help_oficinavirtual.htm

Documento mantenido por: equipo Gestión Civis. Última revisión: 08/06/2026.