ANEJO

Resolución de la Presidenta del Instituto Nacional de Estadística y del Director General de Cooperación Local por la que se dictan instrucciones técnicas a los Ayuntamientos sobre la revisión anual del Padrón municipal y sobre el procedimiento de obtención de la propuesta de cifras oficiales de población

La Ley 4/1996, de 10 de enero, que modifica los artículos relativos al Padrón municipal de la Ley 7/1985, de 2 de abril, Reguladora de las Bases del Régimen Local, establece la informatización de todos los Padrones municipales y su coordinación por parte del Instituto Nacional de Estadística, posibilitando que las cifras resultantes de las revisiones anuales puedan ser declaradas oficiales.

En desarrollo de esta previsión, en el Real Decreto 2612/1996, de 20 de diciembre, se da una nueva redacción a los artículos 81 y 82 del Reglamento de Población y Demarcación Territorial de las Entidades Locales, aprobado por el Real Decreto 1690/1986, de 11 de julio.

Tras varios años aplicando un procedimiento ad hoc que permitiera conocer a nivel de registro individual las diferencias entre las cifras propuestas por el Ayuntamiento y las deducidas por el Instituto Nacional de Estadística en su función de coordinación que, sin embargo, no se encontraba explicitado en las Resoluciones con instrucciones de carácter técnico publicadas hasta el momento (Resolución de 1 de abril de 1997, de la Presidenta del Instituto Nacional de Estadística y del Director General de Cooperación Territorial por la que se dictan instrucciones técnicas a los Ayuntamientos sobre la gestión y revisión del Padrón municipal y Resolución de 4 de julio de 1997 de la Presidenta del Instituto Nacional de Estadística y del Director General de Cooperación Territorial por la que se dictan instrucciones técnicas a los Ayuntamientos sobre actualización del Padrón municipal), las cuales únicamente preveían la elaboración de resúmenes numéricos, en enero del año 2004 se publicó la Resolución de 16 de diciembre de 2003 de la Presidenta del Instituto Nacional de Estadística y de la Dirección General para la Administración Local por la que se dictan instrucciones técnicas a los Ayuntamientos sobre la revisión anual del Padrón municipal y sobre el procedimiento de obtención de la propuesta de cifras oficiales de población que ha sistematizado y normalizado el intercambio de información relativa al procedimiento de obtención de las cifras oficiales de población.

Sin embargo, a finales del año 2003, la Ley Orgánica 14/2003, de 20 de noviembre, de Reforma de la Ley Orgánica 4/2000, de 11 de enero, sobre derechos y libertades de los extranjeros en España y su integración social, modificada por la Ley Orgánica 8/2000, de 22 de diciembre; de la Ley 7/1985, de 2 de abril, Reguladora de las Bases del Régimen Local; de la Ley 30/1992, de 26 de noviembre, de Régimen Jurídico de las Administraciones Públicas y del Procedimiento Administrativo Común, y de la Ley 3/1991, de 10 de enero, de Competencia Desleal introdujo una modificación en el artículo 16 de la Ley 7/ 1985 estableciendo la renovación periódica cada dos años de las inscripciones en el Padrón de los extranjeros no comunitarios sin autorización de residencia permanente (ENCSARP) y la caducidad de dichas inscripciones en caso de no llevarse a cabo tal renovación.

Este cambio en la gestión del Padrón cuya aplicación, en lo que a la caducidad de las inscripciones se refiere, se inicia a partir de diciembre de 2005, se ha desarrollado en la Resolución de 28 de abril de 2005 de la Presidenta del Instituto Nacional de Estadística y del Director General de Cooperación Local por la que se dictan instrucciones técnicas a los Ayuntamientos sobre el procedimiento para acordar la caducidad de las inscripciones padronales de los extranjeros no comunitarios sin autorización de residencia permanente que no sean renovadas cada dos años, dando lugar a nuevas claves y causas de variación y la consiguiente incidencia en el procedimiento de obtención de las cifras de población, haciendo necesario actualizar la Resolución de 16 de diciembre de 2003.

Por otro lado, en las dos revisiones en las que se ha aplicado el nuevo procedimiento, se ha puesto de manifiesto la necesidad de realizar algunas validaciones adicionales que permitan asegurar la calidad de los ficheros facilitados por los Ayuntamientos de modo que las alegaciones no sean desestimadas únicamente por deficiencias en la formación de los ficheros.

Finalmente la experiencia de estos años también aconseja realizar ajustes en los plazos previstos en las distintas fases del procedimiento, fijando las fechas de inicio de los procedimientos que el INE ha de realizar de forma conjunta para todos los municipios, lo que permitirá un mayor aprovechamiento del tiempo y la disponibilidad con mayor antelación de las cifras oficiales de población a 1 de enero de cada año.

Por todo ello, a propuesta del Consejo de Empadronamiento, se han elaborado por el Instituto Nacional de Estadística y la Dirección General de Cooperación Local las siguientes instrucciones para la revisión anual del Padrón municipal.

I

Aprobación de la revisión anual del Padrón municipal

De acuerdo con lo dispuesto en el artículo 81 del Reglamento de Población y Demarcación Territorial de las Entidades Locales, los Ayuntamientos aprobarán la revisión de sus Padrones municipales con referencia a 1 de enero de cada año, formalizando las actuaciones llevadas a cabo durante el ejercicio anterior.

Para ello considerarán las variaciones producidas en el Padrón de su municipio que hayan sido remitidas al Instituto Nacional de Estadística en los ficheros de intercambio mensuales, así como el resultado de la coordinación comunicada por éste en los distintos ficheros mensuales hasta el mes de marzo, ficheros HppmmmIA.3aa.

II

Información tenida en cuenta por el INE para obtener la propuesta de cifra de población

La información que se tendrá en cuenta para obtener la propuesta de cifra de población serán todos los registros vivos y activos en la fecha de referencia, 1 de enero del año de la revisión, que:

• Hayan sido enviados por los Ayuntamientos al INE, antes del 10 de marzo.
• Hayan sido incorporados en la base del INE.
• No se vean afectados por alguna incidencia derivada de la coordinación del INE, pendiente de confirmación o resolución en caso de haber originado discrepancia.

Estas incidencias son las siguientes:

• Altas por nacimiento no confirmadas por Registro Civil (error 72).
• Bajas por cambio de residencia pendientes de confirmación (errores 76, 80 y 106).
• Bajas por defunción comunicadas por Registro Civil, pendientes de confirmación (error 82).
• Bajas por duplicado pendientes de resolver para el municipio que no tiene asignada la gestión (error 84 X) o la inscripción marcada con el error 83 X, en el caso de duplicados intramunicipales.
• Bajas acordadas con informe del Consejo de Empadronamiento (error 101).
• Inscripciones caducadas de extranjeros no comunitarios sin autorización de residencia permanente (comunicaciones BBC 111 para las que no se ha recibido renovación MRN).
• Baja por cambio de residencia por expulsión de extranjero ejecutada (error 115).
• Baja por duplicado gestionada por la OCE (error 114).

Se entiende por registro vivo y activo en la fecha de referencia la variación del habitante de alta o modificación vigente en la fecha de referencia (puede ser el registro de la carga inicial si no ha sufrido variaciones desde el 1 de mayo de 1996). No puede ser una variación de baja.

III

Comunicación por parte del INE de la finalización de la coordinación del año anterior

Una vez incorporada por parte del INE la información contenida en los ficheros mensuales de variaciones HppmmmAI, remitidos por los Ayuntamientos antes del 10 de marzo, se dará por finalizada la coordinación de las variaciones del año anterior mediante el envío de los ficheros de devolución del mes de marzo, HppmmmIA.3aa, la información relativa a nacimientos y defunciones recibida de los Registros Civiles en el mes de enero y la comunicación al Ayuntamiento de la cifra de población resultante en ese momento del fichero del INE.

La información de los Registros Civiles relativa a nacimientos y defunciones recibidos en el mes de enero se remitirá antes del 24 de febrero.

La comunicación de la cifra de población se realizará con posterioridad al envío de los ficheros HppmmmIA.3aa y, en todo caso, antes del 1 de abril.

IV

Remisión al INE de la información necesaria para el contraste de la cifra de población

IV.1 Resultados numéricos de la revisión.

Los resultados numéricos de la revisión anual se comunicarán al INE mediante oficio en el que se especifique únicamente la población resultante para el municipio referida al 1 de enero.

IV.2 Fichero CppmmmAI.aaa justificativo de la cifra remitida.

Junto con la cifra de población, y para que los posibles reparos que hubiera de formular el INE, en virtud de lo previsto en el artículo 82 del Reglamento de Población, puedan detallarse a nivel de registro, se enviará el fichero, copia del Padrón completo a 1 de enero, del que se haya deducido la cifra de población comunicada.

El fichero cuya denominación será CppmmmAI.aaa, se remitirá ajustado a las especificaciones que se detallan en el Anexo I.

IV.3 Plazo de envío de la información.

La cifra de la revisión junto con el fichero CppmmmAI.aaa se remitirán a la correspondiente Delegación Provincial del INE antes del 10 de abril.

El INE pondrá a disposición de los Ayuntamientos la posibilidad de transmisión inmediata del fichero por IDA_Padrón.

V

Validación del fichero CppmmmAI.aaa y causas de devolución

Una vez recibido el fichero CppmmmAI.aaa, las Delegaciones provinciales del INE dispondrán hasta el día 17 de abril para validar el fichero y, en caso de no superar la validación, comunicarlo por un medio urgente al Ayuntamiento y proceder a su devolución. Éste dispondrá de un nuevo plazo, hasta el 25 de abril, para que la correspondiente Delegación del INE reciba un nuevo fichero. Este procedimiento de validación-devolución-nuevo envío sólo podrá reiterarse mientras no se supere el plazo del 25 de abril.

Será motivo de devolución íntegra del fichero CppmmmAI.aaa alguna de las siguientes causas:

• El número de registros no coincide con la cifra comunicada por el Ayuntamiento.
• La longitud de alguno de los registros no es la del formato de intercambio.
• El código de municipio (CPRO-CMUN) de alguno de los registros no se corresponde con el fichero del municipio.
• El número de registros erróneos supera el 10% del total, entendiendo por tales las bajas, los registros con FVAR fuera de rango (<1-5-96 o >1 enero año revisión) o con CVAR+CAUV con valores distintos de los admitidos (ver Anexo I).
• Si el número de registros en esta última situación es inferior (menor o igual) al 10% el fichero no será devuelto, pero los registros en esas condiciones no se compararán y se devolverán como reparos, con TIPOINF=D.

También se realizará un contraste de errores invalidantes, de cuyo resultado se informará al Ayuntamiento, pero que no invalidará el fichero para la posible comparación.

VI

Comparación con el fichero del INE y formulación de reparos mediante el fichero RppmmmIA.aaa

La comparación entre el fichero CppmmmAI.aaa remitido por el Ayuntamiento y la información que consta en poder del INE, a partir de la cual se ha obtenido la cifra comunicada, se realizará sólo con los ficheros que hayan superado la validación anterior, y sin los registros marcados con TIPOINF=D.

El INE iniciará el 26 de abril la comparación de los ficheros CppmmmAI.aaa de forma simultánea para todos los ficheros recibidos. Por tanto, no se considerará ningún fichero recibido con posterioridad al 25 de abril en la correspondiente Delegación provincial del INE.

El contraste se realizará por coincidencia de los campos CPRO, CMUN y los siguientes campos tras variación: NOMB, APE1, APE2, IDEN, NDOCU, NIA, CPRON, CMUNN y FNAC.

La comparación dará lugar a registros S, contabilizados por el INE y no encontrados en el fichero del Ayuntamiento, y registros R, contabilizados por el Ayuntamiento y no por el INE, que este último intentará casar entre sí (pues puede haber registros R y S que se refieran al mismo habitante pero que no se identifiquen por los campos de contraste del párrafo anterior).

De este modo se generarán dos ficheros:

• El fichero RppmmmIA.aaa, específico de reparos, que contendrá los registros R y S no casados entre sí y los registros D que no han superado la validación.
• Un fichero EppmmmIA.aaa, en el que se incluirán los registros R y S casados entre sí, que supuestamente se refieren al mismo habitante.

Los diseños de registro y contenido de estos ficheros se incluyen en los Anexos II y III, respectivamente.

El fichero de reparos, RppmmmIA.aaa, se remitirá a los Ayuntamientos antes del día 10 de mayo, junto con un resumen de su contenido, que cumplirá la siguiente fórmula:

Con el envío de este fichero, cuando el INE no esté de acuerdo con la cifra remitida por el Ayuntamiento, se dará cumplimiento a la formulación de los reparos según lo previsto en el artículo 82.1 del Reglamento de Población y Demarcación Territorial de las Entidades Locales.

Asimismo y con el fin de corregir las diferencias de identificación que pudieran existir entre la base de datos que mantiene el INE y el Padrón de cada municipio, se facilitará al Ayuntamiento el fichero EppmmmIA.aaa, con formato de intercambio de modificación. Este fichero se cumplimentará en la parte de inicio con los datos de identificación correspondientes al registro marcado con S y en los datos tras variación con los correspondientes al registro marcado con R en el fichero de comprobación.

Desligado del procedimiento de la revisión, el Ayuntamiento podrá enviar al INE este fichero, o los registros del mismo que estime conveniente, en un único fichero con la denominación EppmmmAI.aaa (AI), a la mayor brevedad y, en todo caso, antes de que acabe el año. El INE incorporará a su base de datos las modificaciones sin generar variación y sin comunicar error o incidencia alguna a los Ayuntamientos.

Por otro lado puede ocurrir que, aún cuando las cifras del INE y del Ayuntamiento sean coincidentes, al realizar la comparación también se generen registros R y registros S. En estos casos, no se formularán reparos pero, con el fin de que puedan subsanarse las diferencias existentes, se facilitará al Ayuntamiento un fichero denominado DppmmmIA.aaa, con el mismo contenido y estructura que el fichero RppmmmIA.aaa, e igualmente, en su caso, facilitará un fichero EppmmmIA.aaa, con el mismo contenido y tratamiento especificado en los párrafos anteriores.

Cuando se remita al Ayuntamiento un fichero DppmmmIA.aaa, las posibles correcciones que se deriven del mismo se desligarán del procedimiento de aprobación de cifras y se remitirán al INE en los ficheros de variaciones mensuales.

Todos estos ficheros podrán asimismo descargarse por el Ayuntamiento por IDA_Padrón.

VII

Presentación de alegaciones a los reparos formulados por el INE

Una vez recibida la comunicación de los reparos junto con el fichero RppmmmIA.aaa, los Ayuntamientos dispondrán hasta el 1 de junio para presentar en la respectiva Delegación del INE las correspondientes alegaciones a los reparos formulados por el INE.

Estas alegaciones se presentarán en un único fichero específico, cuya denominación será AppmmmAI.aaa y cuyo formato de registro figura en el anexo IV

El INE pondrá a disposición de los Ayuntamientos la posibilidad de transmisión inmediata del fichero por IDA_Padrón.

Las alegaciones se presentarán sólo sobre los registros que hayan sido devueltos por el INE en el fichero RppmmmIA.aaa, teniendo en cuenta que, en ningún caso, de la estimación de las alegaciones podrá resultar una cifra superior a la mayor de las cifras propuestas por el Ayuntamiento o el INE.

Para cada registro sobre el que se presenten alegaciones se consignará en el campo específico habilitado para ello la causa de la alegación según la relación codificada que figura en el Anexo IV. Esta relación podrá modificarse en el transcurso de las distintas revisiones anuales, procediéndose a su actualización en la página web de IDA_Padrón.

Los Ayuntamientos podrán justificar sus alegaciones con cualquier medio de prueba admitido en derecho, aportándolo junto con el fichero anterior.

El INE validará los ficheros de alegaciones para detectar errores sistemáticos que invaliden el fichero, alegaciones en las que se haya modificado de forma indebida el contenido del fichero de reparos, la utilización de claves de alegación no válidas o inconsistentes, alegaciones duplicadas, etc. que permitirán la subsanación de los mismos siempre que no se agote el plazo del 1 de junio.

El INE iniciará el 2 de junio los procesos de estimación/ desestimación automática de alegaciones de forma conjunta para todos los ficheros, por lo que los ficheros recibidos en la correspondiente Delegación del INE con posterioridad al 1 de junio no serán considerados.

VIII

Estudio y estimación de alegaciones por parte del INE

El INE aceptará, sin mas trámites, aquellas alegaciones relativas a nacimientos que hayan sido remitidos por el Ayuntamiento en fichero mensual de variaciones (o de alegaciones) para los que se aporte la partida de nacimiento o fotocopia del libro de familia, las fés de vida que afecten a defunciones y los rechazos a las bajas por cambio de residencia con destino al extranjero o falsos duplicados que se justifiquen documentalmente.

Las alegaciones relativas a inscripciones caducadas de extranjeros no comunitarios sin autorización de residencia permanente serán aceptadas cuando se justifique documentalmente la renovación de la inscripción mediante declaración del propio interesado (o representante en el caso de menores) o el error en la calificación de extranjeros (comunitario o con residencia permanente) mediante aportación de fotocopia del documento de identificación acreditativa del error.

Asimismo, incorporará a su base y, en su caso contabilizará, siempre que no se generen errores invalidantes o de gestión, los registros enviados con claves de alegación CINEX, INVAL, GEST, ERR99, OTRAS y BAJA. Sin embargo, no se contabilizarán los registros que se incorporen como altas por cambio de residencia generando una baja por cambio de residencia en otro municipio, salvo que esta última estuviera o haya sido confirmada por el otro municipio. No obstante, estas altas se contabilizarán en la revisión del año siguiente.

Para los municipios que no hubieran enviado el fichero justificativo, CppmmmAI.aaa, y cuya cifra no coincida con la del INE, o que habiéndolo remitido haya resultado devuelto, sin que hayan llegado a subsanar las causas de devolución contempladas en el apartado V, el INE no estimará ningún tipo de alegación y someterá a informe del Consejo de Empadronamiento la cifra comunicada en el apartado III.

IX

Discrepancias sometidas a informe del Consejo de Empadronamiento

Cualquier alegación fundamentada en argumentaciones distintas a las contempladas en el apartado anterior que no sea aceptada por el INE será sometida como discrepancia al Consejo de Empadronamiento para su informe.

X

Comunicación a los Ayuntamientos del resultado de la estimación/desestimación de las alegaciones y de la propuesta de población que se elevará al Gobierno

Una vez informadas las discrepancias por el Consejo de Empadronamiento, así como la propuesta de cifra de población que el Presidente del INE elevará al Gobierno, esta última será comunicada a cada Ayuntamiento acompañada, en su caso, del fichero FppmmmIA.aaa, cuyo diseño de registro se incluye en el Anexo V, con el resultado de la estimación/desestimación de las alegaciones.

ANEXO I

Especificaciones del fichero CppmmmAI.aaa

El fichero CppmmmAI.aaa, donde pp es el código de provincia, mmm es el código de municipio y aaa son las tres últimas cifras del año correspondiente a la revisión, se ajustará al diseño de intercambio de Padrón completo según se establece en las Normas Generales del Anexo I de la Resolución de 1 de abril de 1997. Es decir, con los datos de inicio y tras variación cumplimentados, con los datos iguales en los campos coincidentes.

También estarán cumplimentados los campos FVAR, CVAR y CAUV con los datos correspondientes a la última variación (de alta o modificación), vigente a la fecha de referencia (1 de enero) y enviada por el Ayuntamiento al INE.

No se incluirán bajas.

Los valores válidos para los campos CVAR y CAUV son los siguientes:

CVAR+CAUV

Blanco (para las altas iniciales de la renovación a 1-5-96).

AOM.

ACR.

ANA.

MPE.

MRD.

MCD.

MRN.

El fichero se remitirá al INE en disquetes, CD-ROM o cintas de carrete abierto y se obtendrá de acuerdo a las siguientes características:

Para ficheros obtenidos con MS-DOS / Windows.

Longitud de registro: Fija con 554 posiciones para los datos.

Caracteres de control de fin de línea: Cada registro debe terminar en los caracteres de control CR y LF (en este orden), sus equivalentes en Hexadecimal y en Decimal son 0D, 0A y 13,10, respectivamente.

Carácter de fin de fichero: Ninguno.

Para ficheros obtenidos con UNIX.

Longitud de registro: Fija con 554 posiciones para los datos.

Caracteres de control de fin de línea: Cada registro debe terminar con el carácter de control LF, sus equivalentes en Hexadecimal y en Decimal es 0A y 10, respectivamente.

Carácter de fin de fichero: Ninguno.

ANEXO II

Diseño de registro y contenido del fichero de reparos RppmmmIA.aaa

El fichero RppmmmIA.aaa tendrá estructura de fichero de intercambio con cola de errores de 150 posiciones y un campo adicional para una denominación de fichero, que se añade al final de la cola de errores, con una longitud de 45 posiciones.

Este fichero contendrá tres tipos de registros que se distinguirán por el valor de TIPOINF=D, R o S.

Registros D.

Son los registros que no han pasado la validación del apartado V. Estarán cumplimentados del siguiente modo:

TIPOINF: D.

Resto de datos: Los que consten en el fichero CppmmmAI.aaa.

Cola de errores: En blanco.

Nombre del fichero: En blanco.

Registros S.

Son los registros contabilizados por el INE que no se han encontrado en el fichero CppmmmAI.aaa.

Datos de identificación: Los que figuren en el fichero del INE.

CVAR+CAUV: Los que figuren en el fichero del INE.

TIPOINF: S.

CDEV: En blanco.

FVAR: La que conste en el fichero del INE.

Datos tras variación: Los que consten en fichero del INE.

Cola de errores: En blanco.

Nombre del fichero: En blanco.

Registros R.

Registros que figuran en el fichero del Ayuntamiento y que el INE no ha contabilizado.

Datos de identificación: Los que consten en el fichero CppmmmAI.aaa.

CVAR+CAUV: Los que figuren en el fichero CppmmmAI.aaa.

TIPOINF: R.

CDEV: NO, registro que consta en base INE con alguna incidencia pendiente (1) .

GE, registro devuelto por error de gestión (2) .

IN, registro devuelto por error invalidante.

NE, registros no encontrados en la base del INE.

FVAR: La que conste en el fichero justificativo CppmmmAI.aaa.

Datos tras variación: Los que consten en el fichero CppmmmAI.aaa.

Cola de errores: Cumplimentada con el último error/ incidencia de esa variación comunicado al Ayuntamiento que impide su contabilización.

Nombre el fichero: Fichero en el que fue remitido al Ayuntamiento la comunicación del último error/incidencia de esa variación que impide su contabilización.

ANEXO III

Diseño de registro y contenido del fichero EppmmmIA.aaa, de registros R-S casados entre sí

El fichero EppmmmIA.aaa tendrá el diseño de registro habitual de formato de intercambio mensual, sin cola de errores, y estará cumplimentado como para las modificaciones, del siguiente modo:

La parte de inicio se cumplimentará con los datos de identificación correspondientes al registro marcado con S (registro fichero INE) y en los datos tras variación se incluirán los datos correspondientes al registro marcado con R (registro fichero CppmmmAI.aaa de Ayuntamiento).

Los campos de control FVAR-CVAR-CAUV estarán cumplimentados con los datos del fichero INE.

ANEXO IV

Diseño de registro y contenido del fichero de alegaciones AppmmmAI.aaa

El diseño de registro del fichero AppmmmAI.aaa tendrá la misma estructura y contenido que el fichero de reparos, RppmmmIA.aaa, con dos campos finales adicionales:

• CALEG, Clave de Alegación (A5).
• OBSVR, Observaciones (A200).

En el campo CALEG se especificará la clave de alegación según la tabla anexa y en el campo OBSVR, el Ayuntamiento podrá especificar lo que considere conveniente, en relación con el registro sobre el que presenta la alegación.

Para cada registro sobre el que se alegue deberá venir cumplimentado el valor TIPOINF=D, R o S remitido por el INE en el fichero de reparos. Asimismo, en el resto de campos coincidentes con el fichero de reparos, se mantendrá el mismo contenido enviado, pues en caso de modificar alguno de los campos previos la alegación no podrá ser atendida, con las siguientes salvedades:

Registros devueltos en el fichero de reparos con CDEV=IN.-Se podrán modificar exclusivamente los campos afectados por el error invalidante marcado en la cola de errores.

Registros devueltos con TIPOINF=D.-Deberá rectificarse el valor de CVAR, CAUV o FVAR en el caso de que los enviados en el fichero CppmmmAI fueran valores no admitidos o fuera de rango, respectivamente.

Registros devueltos con TIPOINF=S. Sólo pueden alegarse de BAJA.-En FVAR se consignará la fecha con la que ha sido dado de baja en el Padrón del Ayuntamiento y en CVAR+CAUV la causa de variación de la baja. En caso de no modificarse estos campos la baja se repercutirá en la base del INE como B II con fecha 31 de diciembre del año anterior a la fecha de referencia.

Registros alegados con CALEG=EXTRJ. Cuando se alegue por renovación de la inscripción de un ENCSARP en FVAR deberá consignarse la fecha de la renovación.

Valores posibles del campo Clave de Alegación para reparos devueltos con TIPOINF=R o S

TIPOINF	CVAR+CAUV+ERROR	PRETENSION AY.	CALEG
R	* * 72	Contar en cifras.	ANA72
R	* * 82	Contar en cifras.	BDE82
R	* * 76	Contar en cifras.	BCR76
R	* * 77	Contar en cifras.	BDE77
R	* *	Contar en cifras.	CINEX
R	* * IN (=CDEV)	Contar en cifras.	INVAL
R	* * GE (=CDEV)	Contar en cifras.	GEST
R	* * 83 X	Contar en cifras.	FBDU
R	* * 84 X	Contar en cifras.	FBDU
R	* * 80	Contar en cifras.	FBCR
R	* * 106	Contar en cifras.	FBCR
R	* * 99	Contar en cifras.	ERR99
R	* *	Contar en cifras.	OTRAS
R	* * 112	Contar en cifras.	EXTRJ
R	* * 115	Contar en cifras.	CR115
R	*.* 114	Contar en cifras.	DU114
S	* *	No contar en cifras.	BAJA

* El/Los asteriscos significan que puede ser cualquier CVAR o CAUV (aunque siempre deberá ser coincidente con lo que había en el fichero de reparos).

CALEG válidas para reparos con TIPOINF=D

TIPOINF	CVAR+CAUV+ERROR	PRETENSION AY.	CALEG	Situación registro en IDA-Padrón a 1-enero
D	**	Contar en cifras.	ANA72	A NA 72
D	**	Contar en cifras.	BDE82	B DE 82
D	**	Contar en cifras.	BCR76	B CR 76
D	**	Contar en cifras.	BDE77	B DE 77
D	**	Contar en cifras.	CINEX	INEXISTENTE (3)
D	**	Contar en cifras.	CINEX	B * 101
D	**	Contar en cifras.	CINEX	B *, Sin error
D	**	Contar en cifras.	FBDU	B DU 83 X (4)
D	**	Contar en cifras.	FBDU	B DU 84 X (5)
D	**	Contar en cifras.	FBCR	B CR 80
D	**	Contar en cifras.	FBCR	B CR 106
D	**	Contar en cifras.	CINEX	B * Resto de errores.
D	**	Contar en cifras.	OTRAS	A *
D	**	Contar en cifras.	OTRAS	M *
D	* *	Contar en cifras.	EXTRJ	Inscripción de extranjero caducada.
D	* *	Contar en cifras.	CR115	B CR 115
D	*.*	Contar en cifras.	DU114	B DU 114

* El/Los asteriscos significan que puede ser cualquier valor de CVAR, CAUV válido.

Descripción de claves:

• ANA72.-Alta por nacimiento no existente en Registro Civil, requiere documentación.
• BDE82.-Defunción errónea, generada por Registro Civil, requiere documentación.
• BCR76.-Rechazo de baja por cambio de residencia con destino al extranjero, requiere documentación.
• BDE77.-Defunción errónea, no encontrada en Registro Civil, enviada erróneamente por el Ayuntamiento.
• CINEX.-Ciudadano inexistente en base del INE.
• INVAL.-Ciudadano devuelto con error invalidante.
• GEST.-Ciudadano devuelto con error de gestión.
• FBDU.-Falso duplicado, se acompaña documentación justificativa.
• FBCR.-Falso duplicado, se acompaña documentación justificativa.
• ERR99.-Habitante devuelto con error 99.
• EXTRJ.-Inscripción de extranjero no caducada, requiere documentación.
• CR115.-Expulsión de extranjero errónea, requiere documentación.
• DU114.-Duplicado erróneo, requiere documentación.
• OTRAS.-Otra causa de alegación no contemplada en las anteriores.
• BAJA.-Habitante baja en Padrón del Ayuntamiento.

ANEXO V

Diseño de registro del fichero FppmmmAI.aaa, con el resultado de la estimación/desestimación de alegaciones

El diseño de registro del fichero FppmmmAI.aaa tendrá la misma estructura y contenido que el fichero de alegaciones, AppmmmIA.aaa, con tres campos finales adicionales:

• RESALEGINI (A2).
• RESALEG (A2).
• OBSVINE (A200).

Donde se incluirán las claves y observaciones con el resultado de la estimación/desestimación de las alegaciones, incluyendo en RESALEGINI el resultado inicial tras el tratamiento automático del INE y en RESALEG el resultado final coincidente con RESALEGINI, salvo cuando haya sido preciso revisión manual.

Valores posibles RESALEGINI

RESALEG-INI	Descripción
NR	No en Reparos.
AI	Alegación inconsistente.
DM	Depuración manual.
AC	Aceptada.
RA	Caso raro.
GB	Genera baja.
MA	Alegación en tabla de manuales.
NV	No válida.
BA	Baja (Sólo para alegaciones de baja. Implica baja aceptada).
DS	Desestimada.
N.º de error	Invalidante o de gestión. Generado por la alegación al intentar la carga en la base

Valores posibles RESALEG

RESALEG	Descripción
NR	No en Reparos.
AI	Alegación inconsistente.
AC	Aceptada .
GB	Genera baja.
NV	No válida.
DS	Desestimada.
N.º de error	Invalidante o de gestión. Generado por la alegación al intentar la carga en la base.