Archivo de la categoría: Cifras

Errores 144 y 60 (Españoles mayores de 16 años sin DNI / Tipo de identificador inválido)

anonimo

A puertas del proceso que se lleva cabo anualmente para el recuento de habitantes en cada municipio, ahora referenciadas  a 1 de enero de 2019, trataré dos de los errores que, de existir, motivan diferencias en el recuento de habitantes entre el INE y el Ayuntamiento, y lo haré refiriéndome a ambos errores de forma conjunta porque, aunque se originan de diferente forma, el conflicto por el que se producen es común: la falta de identificación en las inscripciones.

Recordemos que el error 144 se devuelve con el literal “Habitante español, mayor de 16 años, que NO figura en la base de datos de DNIs”, y que el error 66 se remite con la consigna  “Tipo de identificador, TIDEN, inválido”.

El error 144 se genera cuando un habitante español, nacido después de 1920, sobrepasa la edad de 16 años y no se ha generado en el Padrón de Habitantes un movimiento cumplimentando el DNI adquirido y/o no se remitido al INE esta operación en los ficheros de intercambio mensuales. Aunque no existe una edad mínima para obtener el DNI, si que existe una edad máxima , fijada a partir de los 14 años y sobre la cual el INE incrementa en 2 años, es decir a partir de los 16 años, para proceder a la generación de este error que se remitirá a los Ayuntamientos en el caso de no informar este dato.

Para estos casos es conveniente revisar que no exista una comunicación pendiente de gestionar marcada con el error 135, a través del cual el INE hubiese informado al Ayuntamiento del DNI facilitado por el Ministerio del Interior  o revisar que no se haya cometido un error en la fecha de nacimiento u otros datos personales del habitante que puedan haber producido la no localización del mismo en la base de datos de DNI’S. Si no concurriese ninguna de las dos situaciones descritas, el Ayuntamiento deberá iniciar un expediente de baja de oficio (BII – Inscripción indebida) con el fin de obtener esta información.

Mientras que, el error 60, que es invalidante, se origina en el momento de enviar una operación al INE, en general un alta, sin especificar un tipo de documento y documento válido, entre cuyas posibles causas figura el ser mayor de 16 años, español sin DNI o Pasaporte, o bien extranjero sin Pasaporte o Tarjeta de Residencia.  En este caso, la operación no se cargará en la base de datos del INE y deberá subsanarse remitiendo de nuevo la misma variación con los datos correctamente cumplimentados.

Aunque en un grado muy inferior a otro tipo de consultas, puntualmente, nos llegan algunas dudas al respecto de cómo gestionar estos casos y sobre todo cuando dichos ciudadanos, mayores de 16 años, residen en el municipio y no presentan o poseen documento de identidad (ya sea porque son españoles que residieron siempre en el extranjero y al regresar no gestionan la obtención del DNI, u otros casos “sobrevenidos” y relacionados con los programas de acogida humanitaria en los que los que solicitan la inscripción no presentan ningún tipo de documentación acreditativa, en cuyo caso y remitiéndonos al Reglamento sobre instrucciones técnicas a los Ayuntamientos sobre gestión del padrón municipal, se estipula que serán válidos los documentos provisionales de identidad que se facilitan a los solicitantes de asilo y que se expiden una vez se ha admitido a trámite la solicitud, no resultando válidos los documentos provisionales de solicitud de asilo en los que se especifica que es un documento provisional en espera de ser o no admitida a trámite su petición.

En relación a este último caso, el consejo de empadronamiento resolvía, en sesión de 21 de noviembre de 2017, en su punto 4.- Identificación de extranjeros indocumentados incluidos en programas de acogida humanitaria, lo siguiente:

En primer lugar, la documentación remitida suscita dudas sobre la procedencia del empadronamiento de las personas en cuestión, ya que de los mismos se deduce una estancia temporal, por lo que no se cumpliría la condición de “vivir” en España que establece el art. 15 de la Ley 7/1985, de 2 de abril, Reguladora de las Bases del Régimen Local.

En consecuencia, no es posible admitir documentos diferentes a los contemplados en la Resolución de 30 de enero de 2015, y, a lo sumo, el Ayuntamiento podría orientar a los ciudadanos extranjeros indocumentados que solicitan el alta en su Padrón porque van a permanecer en España para que tramiten la solicitud de alguno de los documentos que se relacionan en la mencionada Resolución como, por ejemplo, la cédula de inscripción (para aquellos cuyo país no les documenta o que carecen de nacionalidad), los documentos provisionales de identidad que se facilitan a los solicitantes de asilo y que se expiden una vez que se ha admitido a trámite su solicitud, etc.

Recordemos que para el error  144, si revisamos las instrucciones que se facilitan en el documento de Normas para el tratamiento de las incidencias resultantes de la incorporación de las variaciones mensuales, no se contempla como tratar los casos de habitantes español sin documento:

“El Ayuntamiento realizará las comprobaciones oportunas para verificar si existe algún error en la inscripción y comunicará al INE el resultado de las mismas, ya sea mediante el envío de una modificación corrigiendo aquellos datos personales que pudieran ser erróneos, ya sea mediante el envío de una BII en el caso de que se trate de un habitante inexistente. En aquellos casos en que los datos sean correctos y no proceda la BII, el Ayuntamiento debe proporcionar a la correspondiente Delegación Provincial del INE copia justificativa del DNI, acreditativo de la identidad del habitante”

Por lo cual, se nos presenta un dilema, ya que la baja por Inscripción Indebida solo deberá realizarse si el habitante no existe, y en otro caso la única alternativa que nos ofrece la anterior redacción es “proporcionar copia justificativa del DNI”. Pero ¿y si el habitante existe y reside en el municipio y no tiene DNI? En este caso, NO deberá darse de baja al habitante.

Al ser errores que inciden directamente en el cómputo que se obtendrá a través del proceso de cifras, apareciendo en los ficheros de “Reparos” como habitantes que restan para el Ayuntamiento y que además no podrán alegarse en las circunstancias expresadas en el anterior párrafo, solo quedará esperar que, para el siguiente ejercicio, el ciudadano aporte la documentación necesaria para subsanar los errores y consecuentemente contabilice en las próximas cifras.

 

Compártelo

Alegaciones a las cifras 2018

AlegacionA poco más de una semana de haber finalizado el plazo para que los Ayuntamientos presentasen alegaciones a los reparos presentados por el INE durante el proceso de cifras, y después de haber compartido, con muchos de nuestros clientes, dudas sobre cómo proceder en casos puntuales, me atrevo a afirmar que en la mayoría de ocasiones en que la diferencia era significativa,  ésta se concentra en el colectivo de extranjeros, coincidiendo con el error 112 (extranjeros pendientes de renovar) y los errores 141, 142, 143 (extranjeros pendientes de confirmar su residencia). En segundo lugar, aunque en menor grado, nos encontraríamos el colectivo de habitantes españoles, mayores de 16 años, que NO figuran en la base de datos de DNIs (error 144).

Se da la circunstancia de que la mayoría de los anteriores errores no pueden ser resueltos por el Ayuntamiento en el plazo habilitado para gestionar las alegaciones ya que no se corresponden a omisiones en la incorporación automática de movimientos requeridos por el INE durante el ejercicio, ni a errores que puedan subsanarse sin audiencia del interesado y tras los cuales, en general, se advierte una falta de recursos en la unidad de estadística para gestionar este tipo de situaciones que requieren la tramitación de expedientes y que sería preciso no subestimar para no caer repetidamente, y año tras año, en este tipo de discrepancias.

Descartando los casos anteriores el resto de registros que se descuentan, acostumbran a coincidir con acciones puntuales que se nos han “escapado” a lo largo del año, ya sea por no haber tratado adecuadamente algún Alta por nacimiento con error 72, algún error invalidante o algunos errores pendientes de gestionar (78, 79, 99, 135, 137 entre los más habituales), y casi todos ellos subsanables en el periodo de cifras.

En pro de aportar mejoras al proceso de alegaciones destacaría la necesidad de poder alegar en los registros con error 72 y para los casos en que se precisa subsanar un error en la transcripción del tipo de alta, y que en lugar de un Alta por Nacimiento hubiera tenido que ser de otro tipo.

Aunque en el caso del error 77  (Baja por defunción no encontrada en el Registro Civil) sí es posible alegar, sería deseable, cuando en la alegación se pretende subsanar un error del Ayuntamiento al haber producido una baja errónea, que no fuese necesario adjuntar documentación, justificación que podría ser expresada en las propias observaciones de la alegación.

Sería interesante poder gestionar de una forma más ágil las alegaciones para los errores de tipo 99. Actualmente no es posible hacer una consulta sencilla para buscar el origen del error, debiendo acudir a la descarga de cada uno de los ficheros en los que se generó inicialmente el error.

Y para concluir, creo que sería de interés general para los responsables de esta gestión, disponer del documento “Aclaraciones para la generación de los ficheros de Alegaciones” en el apartado  correspondiente a  “Diseños de Registro” en el que ya se encuentra el documento “Normas para el tratamiento de las incidencias resultantes de la incorporación de variaciones mensuales”.

Entendiendo que las propuestas de mejora nunca tienen límite, y lo puedo afirmar en la línea de peticiones que recibimos en los productos que dan servicio a nuestros usuarios,  es cierto que cada vez son menores las necesidades que se presentan porque también es menor el volumen de diferencias que presentan los Ayuntamientos.

Compártelo

Error 78 – Modificación no encontrada

Error_78En octubre de 2014 ya hice alusión, entre líneas, a esta incidencia al hablar del error 75 (Baja no encontrada) y dadas las variantes que se derivan de esta incidencia y las dudas que plantea, he creído interesante detallaros un posible guión que permita abordar, de forma sistemática, su resolución. Tengamos en cuenta que en la mayoría de casos en los que no quede resuelta, aparece como discrepancia, en el fichero de reparos, durante el proceso de cifras.

Según el documento “Normas para el tratamiento de las incidencias resultantes de la incorporación de las variaciones mensuales a los ficheros padronales del INE”, la causa que lo produce es la siguiente:

El INE no ha localizado una versión activa del habitante en su base, en ese municipio, con los mismos datos de identificación, o se refiere a un ENCSARP para el que se está remitiendo una MCO o a un NO_ENCSARP para el que se está remitiendo una MRN. El registro NO ha sido incorporado a la base del INE.

Por tanto, y descrito de otra forma, el INE está comunicando al Ayuntamiento que NO EXISTE, en su base de datos, ningún ciudadano inscrito al que repercutir esa modificación, o que, para un extranjero,  se está enviando un movimiento de confirmación o renovación (M-RN o M-CO) que no se corresponde con las circunstancias actuales de esa inscripción.

Frente a las diferentes casuísticas, deberíamos partir de la observación de diferentes factores, que podrían abordarse en base a las siguientes cuestiones:

¿Es extranjero y se ha enviado al INE un movimiento de Confirmación (CO) o Renovación (RN)?

Probablemente las circunstancias del extranjero han variado y el Ayuntamiento no era conocedor de este cambio cuando acometió el movimiento y/o pudo haberse cometido un error al enviar un tipo de modificación que no se correspondía a su situación.

Habrá que verificar, consultando en IDA_Consul,  si el extranjero es o no comunitario o ha adquirido la nacionalidad española y:

  • En el caso de haber remitido un MRN y poseer la residencia permanente, podría modificarse el movimiento a MCO y remitirlo al INE o simplemente eliminar el movimiento (deberá revisarse si en ese mismo movimiento de MRN que se remitió, se incluyó una modificación por cambio de domicilio o datos personales, en cuyo caso deberían volverse a enviar al INE).
  • En el caso de haber remitido un MCO y no corresponderse a este tipo de extranjero y si hace 2 años o más de su inscripción en el padrón, deshacer el movimiento y pedir su comparecencia para efectuar la renovación y realizar la correspondiente modificación a la fecha de la comparecencia.
  • En el caso de que el extranjero se haya nacionalizado, deberá deshacerse el movimiento y proceder a realizar la modificación de datos personales.

¿El habitante no existe en la base del INE o figura de baja en IDA_Consul?

Probablemente nunca se envió el Alta o se envió con un error invalidante que no se trató o se resolvió indebidamente mediante una modificación.

  • En el caso que la modificación se hubiese hecho para subsanar el error invalidante, deberá deshacerse el movimiento y reenviar de nuevo el alta con los datos correctos, en el próximo fichero de intercambio.
  • En el caso de que ambos movimientos fueran correctos (el alta y la modificación), remitir ambos movimientos al INE (preferiblemente en diferentes ficheros mensuales).

¿Si existe el habitante en IDA_Consul?

Probablemente los datos iniciales enviados no coinciden con los datos del último movimiento activo en IDA_Consul, quizá por existir un movimiento intermedio anterior y no remitido al INE o bien porque se corrigió algunos de los datos del habitante en el padrón municipal sin enviar la correspondiente modificación al INE,

  • En el caso de que el movimiento anterior o anteriores al último (que ha causado el error 78), no hubiesen sido enviados, remitirlos nuevamente, y remitir de nuevo el ultimo movimiento (preferiblemente en sucesivos ficheros).
  • En el caso de que el movimiento remitido no tuviera los datos iniciales coincidentes con los que figuran en IDA_Consul, proceder a igualarlos y remitir nuevamente el movimiento al INE en el próximo fichero de intercambio mensual.

En el  periodo de cifras también se pueden solucionar las incidencias de este tipo que hubiesen podido quedar en el tintero. En este proceso, el error 78, y siempre que no figure en IDA_Consul el habitante, puede alegarse informando la fecha de alta y el motivo del alta, de forma que el INE cargaría el movimiento en la situación actual pero con la antigüedad que se informe en la fecha del alta.

Compártelo

Proceso de cifras – Fichero C

FicheroC

Tras 4 años escribiendo en este blog y habiendo compartido con vosotros otros artículos relacionados con el proceso de cifras, aprovecho el momento, ya que nuevamente nos encontramos en el inicio del mismo, para destacar las particularidades que conlleva el primer objetivo del proceso: la generación y remisión del “fichero C” al INE, que ha de contener el conjunto de habitantes sobre los que se basará el razonamiento del Ayuntamiento para poder alegar las diferencias que resulten en el fichero de reparos que nos devolverá el INE.

El fichero C debe contener todos los habitantes inscritos hasta el último día del ejercicio, en este caso a 31 de diciembre de 2016, debiendo reflejar los datos personales y los domicilios que en esa fecha estuvieran asociados a los mismos, así como incluir los habitantes que, estando actualmente de baja, estuviesen empadronados, es decir, se trata de obtener la “foto” de ese momento.

Probablemente el proceso de generación del fichero C es la funcionalidad de mayor complejidad algorítmica que existe en el padrón de habitantes por las variadas casuísticas que ha de contemplar, tanto generadas a causa de una operatoria incorrecta, por inconsistencias en el histórico del habitante u otros errores de la propia funcionalidad, lo que provoca que durante su validación puedan generarse errores que harán necesario, en la mayoría de casos, superar más de una vez el proceso de validación del fichero.

Entre los errores que puede presentar el fichero C se destacan, por ejemplo, que éste no tenga el formato correcto o que el número de registros no se corresponda con la cifra que se ha manifestado o que existan registros defectuosos (que tienen una fecha de variación anterior a 1 de Mayo de 1996 o posterior a la fecha de referencia o posean claves o causas de variación diferentes a las establecidas), aunque, superados los errores de formato o contenido, la mayoría de errores que se producen actualmente son los tipificados como invalidantes.

Los errores invalidantes son aquellos que tienen datos nulos en campos de obligada cumplimentación o bien aquellos que presentan errores de inconsistencia en el conjunto de los mismos (ser español y no tener segundo apellido, ser extranjero y tener un DNI, ser mayor de 16 años y no poseer documento de identidad, contener caracteres inválidos en el nombre o apellidos,  etc..)

Aunque cada año son menos los errores que se generan, entre otras cosas porque la calidad de los datos es mejor, es necesario revisarlos con el objetivo de detectar, como mínimo, los errores sistemáticos y proceder a su corrección en esta fase inicial del proceso de cifras.

Es importante tener en cuenta que los registros con errores invalidantes, si se producen sobre habitantes que ya constan en la base del INE, no serán descontados en el proceso de cifras por lo que, en estos casos, no será imprescindible, aunque sí recomendable, proceder a su subsanación. Es decir, si un habitante ya figura cargado y contabilizado en la base de datos del INE y mediante el fichero C es remitido con un error invalidante, este NO será descontado por el INE, simplemente no procederán a su contraste y será un registro que aparecerá como que SUMA en el fichero de reparos y sobre el cual el Ayuntamiento no deberá alegar, siendo necesario subsanar el error para prevenir errores en futuros ficheros.

Al contrario y cuando se trate de registros que NO consten en la base del INE, será imprescindible que se proceda a la subsanación del error para que en la fase de alegaciones puedan tratarse con la pretensión de que contabilicen en cifras.

Recordar que a partir del fichero de cifras, y para aquellos ayuntamientos que han incorporado caracteres de la fase 2 (por ejemplo acentos en la denominación de los elementos territoriales), podrán indicarlo durante la subida del fichero C a la web del INE, con la pretensión de que se repercutan masivamente dichos cambios mediante la devolución y tratamientos específico del fichero O.

Así mismo y aunque se haya especificado el total de habitantes en la subida del fichero C, será necesario remitir un oficio a la correspondiente delegación, haciendo constar el número de habitantes obtenido, teniendo en cuenta que cada cual evaluará el momento en que debe remitir este oficio, por lo que entiendo que hasta la generación y remisión del último fichero C no se estará en disposición de comunicar la “ultima” cifra que va a defender cada Ayuntamiento.

Para poder abordar el proceso sin contratiempos es importante no demorarse ni superar la primera fecha de 10 de abril para la remisión del fichero al INE,  con lo cual podrán subsanarse las incidencias y volver a remitirlo tantas veces como sea preciso hasta el 25 de abril.

Compártelo

Error 102 – La fecha de variación no corresponde al movimiento

Cambiofecha

El código de error 102, que periódicamente encontramos en los ficheros de cola de errores devueltos por el INE, señala una incidencia en relación a la fecha real del movimiento (ya sea de alta o de baja), y se informa al Ayuntamiento de la nueva fecha de variación.

En los casos de alta por nacimiento y baja por defunción, el error se trasladaría al Ayuntamiento por una diferencia en la fecha de nacimiento o defunción al contrastarse ésta con la que les ha sido comunicada por el Registro Civil. En general, en estos casos, acostumbra a ser un baile de números en los que la fecha no se ha transcrito bien en el padrón y de forma habitual no caben dudas de la necesidad y ventajas de incorporarla al padrón. 

En otros casos, y a estos me voy a referir tras las consultas que nos llegan a nuestro servicio de atención al cliente, se producen dudas razonables de si es necesario incorporarlas o no, sobre todo cuando se traslada el error a consecuencia de una baja en la que, en ocasiones, la fecha comunicada por el INE es muy anterior o posterior en relación a la fecha que consta en el movimiento del padrón de habitantes.

Esta diferencia en las fechas se puede producir, a mi entender, por diferentes motivos:

  • El Ayuntamiento de Brances recibió, en su momento, un comunicado de alta “en papel” por parte del Ayuntamiento de Calvín y procedió a mecanizarla en su padrón pero Calvín no envió el alta o bien generó un error invalidante que no permitió que el alta entrase en el sistema. A fecha muy posterior, el ciudadano se empadronó en un tercer Ayuntamiento y por tanto el INE, cuando recibe esta última Alta, comunica al Ayuntamiento de Brances la nueva fecha de baja y destino, que en este supuesto, puede variar en años.
  • El Ayuntamiento de Brances omitió realizar una baja por cambio de residencia comunicada por el INE y que se acabó consolidando mediante el error 101. Cuando posteriormente, este Ayuntamiento, tramita una baja de oficio, cometiendo una negligencia, al remitir la baja al INE éste comunica el municipio y fecha donde se encontraba empadronado. Aunque en estos casos y no puedo precisarlo en detalle, se podría producir un error 75 – Baja no encontrada en el mismo municipio.
  • El Ayuntamiento de Brances ha trasladado una baja de oficio al INE y trascurrido un tiempo, se produce un alta en el Ayuntamiento de Calvín. El INE traslada esa fecha y procedencia al Ayuntamiento de Brances.
  • El  Ayuntamiento de Calvín ha hecho una modificación de datos personales sobre un habitante y ha producido la coincidencia con los datos del Ayuntamiento de Brances que lo tenía de baja de oficio o por cambio de residencia al extranjero y por tanto el INE comunica a Brances una nueva fecha y destino de la baja.

Entendería que las altas que han sido enviadas con mucha demora al INE no encajarían en esta problemática ya que para el municipio de alta y en el caso de haber un alta posterior y consolidada en otro municipio, se produciría un error “99 – Existe un movimiento posterior al comunicado”. El Ayuntamiento, en este caso, debería generar la baja a través de la revisión del fichero  Hppmmm99.maa en el que recabaría la información de la fecha y el movimiento del otro municipio sin remitir movimiento de baja al INE.

Probablemente es costoso para los Ayuntamientos rastrear el origen de dichas comunicaciones y su incorporación no debería producirse de forma automática, debiendo evaluarse de forma individualizada ciertas casuísticas o aplicar una revisión manual en función del tiempo transcurrido entre la fecha que figura en el padrón y la comunicada por el INE.

Por ejemplo, si tenemos una baja por Inscripción indebida de un ciudadano en el año 2013 y se recibe un error 102 para modificar la fecha de baja al 2016, así como el motivo y destino, no debería modificarse esa fecha ya que, probablemente, estaríamos modificando la realidad y comprometiendo las certificaciones que hayan podido expedirse sobre el ciudadano.

Tal y como se deduce del documento “Normas para el tratamiento de las incidencias resultantes de la incorporación de las variaciones mensuales a los ficheros padronales del INE” la decisión de incorporar estas modificaciones en el padrón la gestiona cada Ayuntamiento:

Actuación del INE: El registro ha sido incorporado a la base del INE modificando la fecha de variación en el sentido indicado.

Actuación del Ayuntamiento: Corregir, si procede, la fecha en su propio Padrón y no realizar comunicación alguna.

Recordar que este tipo de incidencia, tal como se indica en el citado documento, puede afectar a las cifras en los casos en que la baja se esté repercutiendo en el ejercicio actual por parte del Ayuntamiento y el INE la esté contabilizando en un ejercicio anterior, con lo que nos encontraríamos con un registro que resta en el fichero de reparos. En este caso, y también en los que pueda suceder a la inversa, es importante ver el esfuerzo que puede comportar gestionar la pertinente alegación teniendo en cuenta que la cifra se conciliará, de forma natural, en el próximo ejercicio.

No estaría de más tener más información por parte del INE del procedimiento que se aplica en el traslado de este error y otros errores a los Ayuntamientos ya que los expuestos en este artículo no son más que el fruto de supuestos y deducciones y como tal pueden ser imprecisas o matizables.

¿Pensáis que existen otras causas en las que se produce esta incidencia? ¿Incorporáis estas correcciones en el padrón cuando se trata de fechas muy anteriores?

Compártelo

Discrepancias en las cifras de población

abacoEste pasado 23 de marzo, casualmente  y a raíz de una búsqueda por Internet, me topé con un artículo de prensa que me llamó sumamente la atención, ya no por el hecho que describía sino por el poco detalle que ofrecía al lector respecto al motivo que probablemente producía tales efectos.

El titular del mismo anunciaba: “el  Ayuntamiento de Calatayud presenta un contencioso contra el INE por una discrepancia de 2.500 habitantes:” http://www.heraldo.es/noticias/aragon/zaragoza-provincia/2016/03/23/el-ayuntamiento-calatayud-presenta-contencioso-contra-ine-por-una-discrepancia-500-habitantes-833070-1101025.html

Como ya he manifestado en mi introducción, en el citado artículo, en ningún momento se hacía referencia a las circunstancias o particularidades que podían estar provocando dicha discrepancia,  de forma que, a mi juicio,  se predisponía al lector a intuir o suponer que probablemente al INE le mueva un especial interés o empeño en descontar habitantes.

Quiero explicar, para los profanos en el tema, que durante el proceso de conciliación de cifras, el INE informa a los ayuntamientos de cuáles son los habitantes que no va a contabilizar, así como de los motivos. Además, según normativa, existen procedimientos regulados que permiten a los ayuntamientos, durante ese periodo, realizar reclamaciones / alegaciones a favor de los registros descontados.

Desde el año 2005, para la mayoría de ayuntamientos, el peso de estas diferencias ha recaído fundamentalmente en el colectivo extranjero, ya que según sean o no comunitarios o posean la autorización de residencia permanente, es necesario que los ayuntamientos realicen unas comprobaciones de su permanencia en el municipio y se lo comuniquen al INE mediante los ficheros de variaciones mensuales.

Tengamos presente que el INE comunica a los ayuntamientos, mediante los ficheros de intercambio y con tres meses de antelación a su caducidad, las “circunstancias” de cada tipo de extranjero, con el fin de que se realicen las gestiones pertinentes. En el caso de que el ayuntamiento no remita, en los plazos señalados, la correspondiente respuesta informática al INE, éste entenderá que no residen en el municipio y por tanto durante el proceso de cifras, los “propondrá” como NO contabilizados.

No dudo que para los ayuntamientos que cuentan con un gran volumen de extranjeros, la gestión que conlleva ese seguimiento es laboriosa,  pero también es una gestión necesaria para garantizar la credibilidad de las cifras que se elevarán al gobierno, teniendo en cuenta que cuando los extranjeros regresan a sus países, actualmente,  no existe un mecanismo que permita dar conocimiento a los ayuntamientos de dichas circunstancias.

Ahora que nuevamente nos encontramos inmersos en el proceso de cifras y para el caso de los ayuntamientos que tengan constancia de que estos ciudadanos siguen residiendo en el municipio, todavía es posible realizar un último sprint para igualar las cifras. Me consta, por el resultado de la gestión de alegaciones de  ejercicios anteriores,  que si durante ese periodo y proceso se consigue la renovación o confirmación de residencia de esos extranjeros, aunque sea fuera del plazo establecido, el INE los contabiliza (debiendo complementar la alegación con las correspondientes pruebas documentales), constatando que la finalidad del INE no es otra que dar credibilidad y confirmar que las cifras oficiales coinciden con la realidad.

Recordemos que para minimizar esta gestión reactiva, se considera una buena práctica el informar a los extranjeros, durante la gestión de cualquier trámite padronal con su administración, de la obligación de ratificar o renovar su residencia.

 

Compártelo

Devolución fichero de casados (N)

Casados2Durante estos días, en que algunos Ayuntamientos están tratando el fichero de devolución de casados,  surgen dudas en la interpretación de su contenido, por lo que aprovecho la ocasión para detallar las diferentes casuísticas que podemos encontrar en los mismos.

Primeramente, y para entender mejor el proceso, recordemos que mediante el fichero de CASADOS podemos resolver, de una forma sencilla, las posibles diferencias que existen entre los datos que figuran en el padrón del Ayuntamiento respecto a los figuran en la base padronal del INE, sin tener que generar modificaciones de datos personales.  Solo se requiere, por parte del Ayuntamiento, responder al INE a través del envío del mismo fichero,  incluyendo exclusivamente  los  registros que el Ayuntamiento considera correctos para la equiparación de los datos entre ambos orígenes de datos.

Este proceso es realmente cómodo, aunque presenta un hándicap importante: Cuanto más tiempo transcurre desde la fecha de referencia del fichero C y la resolución de las diferencias por parte del ayuntamiento, menos vigencia tiene el proceso.  Me explico:

Referido por ejemplo a las últimas cifras que cierran el ejercicio 2014. Durante el año 2015 se han ido produciendo movimientos en el padrón en los datos de los habitantes, de forma que al tratar algunos registros de casados, ya existen movimientos posteriores que han variado sus circunstancias y que al remitirlos al INE, lógicamente,  éste no podrá repercutir por no revertir la situación actual.

Por tanto, mi primer consejo es que las discrepancias del fichero de casados se resuelvan, por parte del Ayuntamiento, a la mayor brevedad posible, incidiendo en el hecho de que después de los años que lleva en vigor este proceso, acostumbra a contener pocos registros.

El fichero de devolución de casados es un fichero en el que el INE nos informa de los registros de Casados que NO ha podido cargar y  al ser un fichero con cola de errores,  debe importarse como el resto de ficheros de errores mensuales.

En este fichero encontramos:

  • Registros que NO tienen cola de errores: Son registros que NO tienen un error en sí mismos, sino que el INE no ha podido cargar por los siguientes motivos: O bien porque el habitante tiene un movimiento posterior o porque ya están de baja en la base padronal del INE y lógicamente no los ha podido incorporar.  Para estos casos es muy probable que no debamos hacer nada más que comprobar  que los datos que figuran en el padrón y los del INE son coincidentes, que lo serán en la mayoría de casos.  En otro caso, esperar al próximo fichero de casados, donde ya no aparecerán. 
  • Registros marcados en la cola de errores con los siguientes: 23-34, 36-39, 47-66, 70: a partir de los cuales habrá que analizar cuál ha sido el problema que originó el error y proceder a realizar la correspondiente modificación en los datos del habitante para subsanar las deficiencias. Aquí es importante determinar a qué fecha se hace la modificación, ya que si la hacemos en el ejercicio en curso (en este caso 2016), volverá a aparecer mal en el próximo fichero de cifras ya que el próximo fichero C se generará con los movimientos hasta final del 2015. 
  • Registros con error en el nivel de estudios: Bien porque éste sea inferior al que figura en la base padronal del INE o cuyo código sea 99 (Título desconocido). Para estos casos se exceptúan a los menores de 16 años con títulos equivalentes a 00 (no aplicable por ser menor de 16 años), o bien cuando el valor de la titulación de la base padronal del INE sea 21 (Sin estudios) y el del registro remitido por el ayuntamiento sea 20 (Titulación inferior a graduado escolar)

Dado que tras la descarga del fichero, y al ser un proceso anual que lógicamente no crea el mismo hábito que otros procesos con periodicidad menor,  los usuarios del padrón nos trasladan  no haber encontrado documentación al respecto y aprovecho para sugerir que, en el apartado “Diseños de Registro de intercambio de información padronal” de la Web de IdaPadron, se añadiesen ésta y otras circulares explicativas del tratamiento específico de estos ficheros y otros.

Compártelo

Novedades en la gestión de alegaciones

EncajarYa estamos a las puertas del proceso de conciliación de cifras, y cada vez es menor el esfuerzo para gestionarlo, primero porque ya son muchos los años de entrenamiento y segundo porque cada vez son menores las diferencias que existen con el INE. Probablemente si se implantase un objetivo en la evaluación del desempeño que valorase la diferencia de habitantes respecto a las del INE, la mayoría lo superaría.

Por tanto, aprovecho el momento para destacar un importante cambio en la gestión de algunos reparos, acordado en la última sesión celebrada el 6 de noviembre de 2014 por el consejo de empadronamiento en relación a la forma de alegar ciertos reparos.

Para entender mejor el propósito de esta novedad, recordemos que el fichero de cifras que remitimos al INE, para que posteriormente nos devuelva los reparos obtenidos de ese contraste, contiene el último movimiento de cada  habitante activo a la fecha de referencia, en este caso a 31 de diciembre de 2014.

En general, al  tener que alegar sobre registros que restan y que no figuran en la base de datos del INE, nos encontrábamos frente al dilema de si además de alegar, debíamos remitir el alta al INE en el próximo fichero de variaciones mensual para poder reflejar correctamente el motivo de alta, la fecha real de la misma y movimientos posteriores sobre el  mismo.

En el acta de dichos acuerdos, se detalla cual era el procedimiento que se estaba llevando a cabo desde el INE hasta el momento:  Al cargar los registros alegados en su base, debía transformar el código de variación de modificación a ALTA y repercutirlas con la fecha de variación del registro (que no era la del alta, sino la de la modificación) y generar, en su caso, la baja a esa fecha en el otro municipio, lo cual, exceptuando los casos ya contemplados de que el Alta ya estuviera contabilizada en otro municipio y por tanto la alegación no pudiera aceptarse, se producía una inconsistencia al generarse la baja en una fecha incorrecta en el otro municipio.

Pues bien, ahora nos quedará más claro cómo actuar en estos casos, que exclusivamente afectarán cuando el reparo se refiera a un habitante cuyo último movimiento a esa fecha fuese una modificación, de forma que:

En el caso de que ese último movimiento exista en reparos con CDEV (código de devolución) = NE, GE ó IN y si debe alegarse mediante uno de los siguientes códigos:  CINEX, INVAL, GEST o ERR99,  motivos utilizados por los Ayuntamientos con la pretensión de que el INE proceda a la incorporación de esos habitantes en su base o bien para que procedan a contabilizar al habitante si la incidencia que impedía su contabilización ha desaparecido, será obligatorio remitir en la alegación, la causa y código de variación (A OM  – A CR –  A NA), así como la fecha real del alta.

Advirtiéndose por parte del INE que en caso de no cumplimentarse esta información, estas alegaciones no podrán tratarse y serán desestimadas.

Aunque siempre pretendo que mis artículos no estén asociados a ninguna plataforma concreta y por tanto sean de interés general, en este caso me permito hacer una excepción para recordar a los usuarios de la aplicación de Padrón de Habitantes de ABSIS, que ya se ha contemplado en la última versión distribuida de la aplicación, la lógica que permite tratar esta casuística.

Suerte con las cifras!

Compártelo

Ficheros relacionados con las CIFRAS

Tipos_archivoAprovechando que estamos en período de cifras y dado el tráfico de ficheros que intercambiaremos con el INE, he pensado que a todos, y a mí la primera, nos irá bien tener esta recopilación como una referencia para identificarlos, conocer su contenido y propósito.

Si me he dejado alguno, no dudéis en comunicármelo, que lo incluyo!

 

CppmmmAI.año:

Fichero anual de cifras, relativo a 1 de enero de cada año, que genera  el  Ayuntamiento a consecuencia de la propuesta de Cifras que realiza el INE a los Ayuntamientos, con el propósito de informarle de los habitantes que le constan en su padrón a esa fecha.

CppmmmIA.año:

Fichero que devuelve el INE a los Ayuntamientos conteniendo los errores del fichero de Cifras, mediante el cual ofrece la oportunidad a los Ayuntamientos para que arreglen todos aquellos registros que generan inconsistencias en la carga, y que no superando la fecha límite, estos puedan volver a remitir un nuevo fichero C.

RppmmmIA.año:

Fichero de reparos devuelto por el INE a los Ayuntamientos tras realizar la comparación del fichero C con su base a la misma fecha, conteniendo los registros que el INE les suma, resta o descarta en relación al fichero C y que ofrece la oportunidad a los Ayuntamientos de justificar y alegar dichas diferencias para conciliar cifras.

DppmmmIA.año:

Fichero de reparos  remitido por el INE a aquellos Ayuntamientos que no tienen diferencia numérica en las cifras, pero que durante el contraste ha generado discrepancias que han compensado las cifras. El propósito es revisar esas discrepancias y en todo caso, solucionarlas fuera del proceso de cifras.

AppmmmAI.año:

Fichero de alegaciones que remite el Ayuntamiento al INE, como contestación al fichero de reparos, que permite comunicar al INE de todos aquellos desacuerdos, con la pretensión de que sean considerados en las cifras finales.

FppmmmIA.año:

Fichero que devuelve el INE a los ayuntamientos con la información y resultado final de las alegaciones efectuadas, para que los Ayuntamientos conozcan qué alegaciones han sido consideradas y cuáles no.

EppmmmIA.año

Fichero de casados, remitido por el INE tras realizar la comparación del fichero C con su base a la misma fecha, que contiene diferencias encontradas en los datos personales de los habitantes y que ofrece al Ayuntamiento la posibilidad de arreglar las diferencias, de una forma rápida y sencilla, sin remitir variaciones al INE.

EppmmmAI.año:

Fichero de casados que remite el Ayuntamiento al INe, en contestación al fichero E anterior, con las correcciones que desea que se carguen en su base de datos (del INE) sin generar movimientos.

NppmmmIA.año

Fichero que devuelve el INE en contestación del fichero de casados con los registros que no han podido cargarse para que estos conozcan qué registros del fichero de casados no han podido ser cargados, expresados los motivos, en algunos casos, en la cola de errores, con la correspondiente incidencia.

OppmmmIA.año:

Fichero de casados O, remitido por el INE tras realizar la comparación del fichero C con su base a la misma fecha, que contiene diferencias en los datos postales de los habitantes, así como otros campos como la titulación académica, la nacionalidad y otros, con el mismo propósito que el anterior. Este fichero, por sí sólo, al contener solo los datos del Ayuntamiento, dificulta la resolución y es aconsejable requerir el fichero OBis.

OppmmmAI.año:

Fichero de casados O, que remite, en contestación al fichero O anterior,  el Ayuntamiento al INE, con los registros que desea que se carguen en su base de datos (del INE) sin generar movimientos.

OBppmmmI.año:

Fichero OBIS, complementario al fichero O, con un formato diferente al de intercambio y que contiene, además, los datos que figuran en el INE para ofrecer una mayor agilidad en la gestión del fichero O. Este fichero no se resuelve. Se devuelve al INE el fichero O en formato de intercambio.

PppmmmI.año:

Fichero que devuelve el INE en contestación del fichero O con los registros que no han podido cargarse para que estos conozcan qué registros del fichero O no han podido ser cargados, expresados los motivos, en algunos casos, en la cola de errores, con la correspondiente incidencia.

Aunque así de entrada pudiera asustar el volumen de ficheros que se gestionan entorno a las cifras, puedo constatar que, de forma general, cada año contienen menos registros y el tiempo dedicado a su gestión va disminuyendo, señal inequívoca de que el esfuerzo continuado en gestionar correctamente los ficheros mensuales da sus frutos.

Compártelo

Nivel de estudios – Error 131 (Parte II)

caminos

La mayoría de lectores de este blog, que ya cuenta con mas de 100 suscriptores, supongo que sois clientes de nuestra aplicación, pero seguramente éste no es ni el único ni el principal motivo por el cual coincidimos en este espacio, ya que entre otros, probablemente, tenemos la necesidad de constatar que nuestras inquietudes son comunes.

Desde mi perspectiva, como consultora y “comunicadora”,  intento que cada artículo sea un fiel reflejo de las conversaciones, dudas y conclusiones que ponemos sobre la mesa día a día, por lo cual, aún rompiendo con la periodicidad prevista de publicación, tengo la viva necesidad de dedicar este artículo al último comunicado del INE en relación a la ampliación del plazo de envío de los ficheros E y O de Cifras hasta el 28 de febrero de 2014 en relación al error 131 – Inconsistencia entre edad y nivel de estudios.

En primer lugar, me resulta sorprendente que estando a las puertas del próximo proceso de cifras y tras la acertada y reiterada recomendación de no agotar, en la medida de lo posible, el plazo a 31 de diciembre para su remisión (para evitar que se incorporen movimientos mensuales producidos en el año en los ficheros de intercambio, que impedirían la carga de estos), ahora se comunique esta prórroga.

En segundo lugar, encuentro a faltar que no se describa cómo o en qué medida vamos a poder corregir los errores 131 mediante esos ficheros (E y O) ya que ni de entrada están todos los registros con esa incidencia ni todos los registros que figuran en esos ficheros tienen  esta incidencia, por tanto este medio comportará, en la mayoría de los casos, una sistemática laboriosa y totalmente parcial para normalizar este dato, cuando la solución debería haber pasado por una recomendación o instrucciones precisas que permitiesen repercutirlo de forma global al conjunto de habitantes con edad menor a los 16 años.

Si leemos la nota aclaratoria para la puesta en marcha del error 131, se dice, exclusivamente y sin dar pie a otras posibles opciones que “Para el tratamiento de estos errores, el Ayuntamiento deberá remitir una MPE, modificando el CNES o la FNAC, según corresponda”.

Tal como comenté en mi artículo de diciembre de 2013, relativo al error 131, y habiendo constatado que aquellos Ayuntamientos que tenían un gran volumen de registros con esta incidencia, se  concentraban en los menores de 16 años,  durante este mes y medio, hemos estado desarrollado diferentes estrategias, con algunos de vosotros, para resolverlos en el menor plazo de tiempo posible, entendiendo que para edades superiores, la gestión se verá dilatada en función de lo que cueste requerir esa información en el Padrón de Habitantes.

A partir de las dudas y consultas surgidas a raíz de esta incidencia, me cuestiono si algunas de ellas no se podrían haber evitado, entendiendo que si el valor del nivel de estudios pasa a ser un dato implícito para los menores de 16 años y por tanto deducible a partir de esa edad ¿Por qué desde el INE no se han previsto o propuesto medidas más sencillas, claras y eficientes para resolver esta incidencia?

De la misma forma que el INE incorpora en su base, de forma automática y sin espera de confirmación, otros datos como por ejemplo la procedencia en las altas por cambio de residencia, la fecha de variación, etc ..),  ¿no se podría haber aplicado un sistema parecido para los menores y posteriormente haberlo comunicado a los Ayuntamientos? Y no me digan que la fecha de nacimiento podría ser el obstáculo para cuyo contraste se podrían aplicar otros recursos.

Por tanto, mi recomendación es que, exceptuando aquellos casos en los que ya se han llevado a cabo las Modificaciones de Datos Personales, esperemos al próximo proceso de cifras para normalizar dichos datos, y asegurarnos que en el próximo fichero “C” ya esté informado el nivel de estudios correcto para los menores de 16 años, evitando generar futuras modificaciones de datos personales, ya sea de forma masiva o asistida.

En este caso ¿nos devolverán en el fichero de “casados” a todos los menores que hayamos normalizado y que no coincidan con “su” CNES para que lo constatemos y remitamos en su caso una nueva confirmación?. Me temo que si.

 

Compártelo