Archivo de la categoría: Errores / Incidencias INE

Incidencias debidas al lugar de nacimiento, nacionalidad y procedencia o destino (57, 58, 66, 67 y 68)

Lugnaci

Simultaneando artículos de opinión con otros más objetivos que pretenden profundizar en el tratamiento y gestión del padrón de habitantes, hoy voy a tratar sobre aquellas incidencias que se producen a consecuencia de informar incorrectamente el lugar de nacimiento, la nacionalidad, así como las que se derivan de informar datos erróneos en la procedencia o destino de las Altas o Bajas por Cambio de Residencia  de los habitantes inscritos en el padrón de habitantes.

Incidencias 57 y 58 - Provincia y/o municipio de nacimiento inválido o desconocido:

Cualquier ciudadano que haya nacido en territorio español lo ha hecho en una de sus 50 provincias, codificadas alfabéticamente desde el código 01 (Alaba) hasta el 50 (Zaragoza),  o en Ceuta y Melilla (51 y 52 respectivamente),  así como en uno de sus 8.124 municipios existentes que, así mismo, van codificados dentro de cada provincia con su respectivo código.

Aunque se desconociese la regla anterior, en cuanto a codificaciones, las aplicaciones actuales facilitan tablas asociadas a estos datos para no inducir a errores al mecanizar esta información, y aunque en general las dudas acostumbran a surgir cuando el lugar de nacimiento es un país extranjero, en este caso debe informarse el código de provincia 66, complementado con el país de nacimiento en el municipio. Es decir y por ejemplo, un ciudadano nacido en Francia, quedaría reflejado como 66 en su provincia y 110 en el municipio, siendo 110 el código de Francia.

A veces surgen dudas en cuanto al país extranjero de nacimiento, en aquellos casos en que dicho país no existe actualmente. En este caso y si consultamos la página de Ida_Consul, observaremos que en la lista de países y para estos casos, figura una fecha de baja o bien una fecha de alta, de forma que en función de la fecha de nacimiento del ciudadano SI podremos inscribirle en un país de nacimiento inexistente en la actualidad, caso que también sería aplicable a los municipios españoles en cuanto pueden haberse agregado o disgregado de otro municipio.

Incidencia 66: Código Nacionalidad inválido;

En cuanto a la nacionalidad de un habitante, también estaremos supeditados a informar cualquiera de las nacionalidades actuales, incluida la 555 para los apátridas. Solo se podrá utilizar el 999 – Desconocido para los casos de Altas por nacimiento de padres extranjeros y cuando ésta se desconozca (debiendo recabarse la nacionalidad en un plazo no superior a 2 años).

Otros casos devueltos con este error, aún observando que la nacionalidad es correcta, son los que se producen por presentar una inconsistencia entre el tipo de documento y la nacionalidad, por ejemplo, informar un DNI y una nacionalidad diferente de España, o también haber enviado un MCO o MRN para un español o  un movimiento de renovación (MRN) para ciudadanos a los que no les corresponde por no ser ENCSARPS.

Hasta aquí, los errores mencionados pueden afectar a las cifras, ya que en la mayoría de los casos son INVÁLIDOS y por tanto es necesario revisar el error y remitir nuevamente el mismo movimiento habiendo subsanado la anomalía.

Incidencia 67 – Provincia de destino/procedencia inválida o 68 - Municipio/País de destino/procedencia inválido.

Y para concluir y con menor importancia que los anteriores errores, están las incidencias que se producen al informar incorrectamente los datos de procedencia o destino en las altas o bajas por cambios de residencia respectivamente, que deberán cumplir las normas descritas anteriormente, añadiendo que solo serán aceptados valores en los campos destino o procedencia, en los casos de Altas o Bajas por Cambio de residencia o bajas por duplicado.

 

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

Tipos de hoja: Colectiva y Familiar

Familiar

Cada día es más frecuente la petición, por parte de los ciudadanos, de certificados o justificantes históricos “familiares” para la gestión de trámites como aceptación de herencias, divorcios, adjudicaciones de ayudas por motivos diversos, etc…

En el acta de la sesión celebrada el 3 de noviembre de 2016 se anunciaba que “con objeto de avanzar en la prestación de servicios horizontales al ciudadano, se estaba trabajando en la posibilidad de utilizar la Plataforma de Intermediación para que no tengan que pedirse al ciudadano certificados padronales de históricos de residencia, a una fecha concreta y de convivencia”

No dudo que es importante avanzar en esta línea ya que en la dinámica de no aportar documentación que obra en poder de otras administraciones y no debiendo requerirse este tipo de información al ciudadano, se hace necesario buscar alternativas que faciliten el compromiso.

En muchas ocasiones al requerir justificantes “familiares”, se traslada al Ayuntamiento una petición incorrecta y en muchos casos fuera del alcance del Padrón de Habitantes, ya que en éste únicamente constan personas y domicilios, y por ello solo podrían deducirse certificaciones que acreditasen que una o varias personas habitan en un domicilio o que lo habitaron en el pasado.

La normativa vigente, igual que la anterior, clasifica las hojas padronales en dos tipos:  Colectivas o Familiares, por lo cual y si nos dejáramos llevar por la intuición, parecería que en este último tipo de hojas, solo podríamos empadronar a personas que tuvieran algún vínculo de parentesco y en consecuencia usaríamos el tipo “Colectivo” para el resto de empadronamientos, pero esto no es así, ya que en la actual normativa se hace mención a estos dos tipos de hojas en la siguiente forma y dentro del apartado  “3. Casos especiales de empadronamiento”

Empadronamiento en establecimientos colectivos. Cuando el alta se produzca en un establecimiento colectivo (residencias, conventos, etc.) la autorización deberá ser suscrita por la persona que ostente la dirección del mismo. En estos casos se hará constar en el apartado «tipo de vivienda» de la hoja padronal la mención «colectiva». En los demás casos, el tipo de vivienda es «familiar».

Además y en alusión al tipo de hoja, se especifica que “Los certificados y volantes de empadronamiento expedidos a personas inscritas en establecimientos colectivos deberán tener siempre carácter individual”, aunque quizá deberíamos dudar de cómo habría que actuar en el caso de parejas que estuvieran conviviendo en una misma habitación o apartamento dentro de ese tipo de establecimientos (caso complicado de contemplar en la actual estructura de hojas).

Si retrocedemos en el tiempo y damos un vistazo a los formularios sobre el Censo de Población y Viviendas del año 2001, encontraremos esta definición sobre los establecimientos colectivos: “Son viviendas o edificios destinados a ser habitados por un grupo de personas que no constituyen familia, sometidas a una autoridad o régimen común, o unidas por objetivos o intereses personales comunes”

En el caso de las casas de huéspedes o arrendamiento de habitaciones en un mismo domicilio o familias que alquilan una o varias habitaciones y atendiendo a las diferentes circunstancias que pueden confluir en una misma dirección, podríamos estar ante el dilema de si considerarlas de tipo familiar o colectiva ¿o bien compaginar varias hojas en un mismo domicilio que atiendan a dichas distribuciones?

Por tanto y retomando el análisis de la propuesta relativa a la utilización de la Plataforma de Intermediación para emitir justificantes históricos de residencia, se intuye que la única forma en que podrían obtenerse dichos justificantes sería a partir del contraste de todos los campos que identifican la dirección o bien por el número de vivienda, de manera que se relacionasen todas aquellas personas inscritas a una fecha en esa vivienda, considerando adicionalmente el carácter de la hoja (familiar o colectiva).

Entendiendo las diferentes fórmulas aplicadas por los Ayuntamientos para inscribir a los vecinos en relación al concepto “Hoja Padronal”,  sería de vital importancia garantizar que la información proporcionada siguiese unos criterios objetivos fuera cual fuese el canal por el que se solicitase y se pudiera asegurar que todas las direcciones tienen un identificador único y que no hayan viviendas en una misma dirección con identificadores diferentes.

¿Para cuándo la puesta en marcha de las anunciadas incidencias 133 – NHOP correspondiente a varias direcciones y 134 – NHOP distinto en una misma dirección, en sesión del Pleno del Consejo de Empadronamiento de 13 de noviembre de 2012?

Sinceramente, creo que la pretensión de prestar el servicio anunciado es acertada pero, a corto plazo, lo considero un reto complicado.

Compártelo

¿Qué es el NIA?

NIA3

El NIA es el acrónimo de “Número de Identificación del Ayuntamiento” y es un distintivo que deben tener asignadas todas las personas que figuren inscritas en el padrón de habitantes y que en el documento “Diseños de registro de intercambio de información” se define de la siguiente forma:

El campo NIA deberá ser asignado por el Ayuntamiento y deberá identificar sin ambigüedades al habitante con la única premisa de no reasignar un NIA antiguo a una persona diferente. Sin embargo, al tratarse de un número de identificación de personas sería conveniente que se recuperaran los asignados con anterioridad. No deberá existir ningún habitante que no tenga asignado su correspondiente NIA.

Para alertar a los Ayuntamientos de las anomalías que puedan detectarse en este dato y en el caso de no ceñirse a estas recomendaciones, el INE devuelve 2 tipos de errores:

  • Error 48 – NIA inválido (cuando no figura valor alguno o bien incluye caracteres inválidos)
  • Error 107 – Cuando se ha remitido una variación de Alta o modificación de un habitante cuyo NIA ya figura en otra inscripción padronal del municipio.

Del análisis de estas recomendaciones y la devolución de las incidencias anteriores, se intuía que el NIA nacía con el propósito de permitir identificar inequívocamente a cada inscrito durante el proceso de traslado de información entre los Ayuntamientos y el INE mediante los ficheros de intercambio y así evitar la dificultad que podía suponer identificarlo por el resto de datos teniendo en cuenta que todos ellos pueden variar. Tengamos en cuenta, y como ejemplo, el caso de los menores que se inscriben sin documento o los extranjeros con tarjeta de residencia y que posteriormente pueden obtener un DNI, así como otros casos en los que pueden cambiar sus apellidos o cualquier otro de sus datos identificados, incluidos aquellos producidos por errores tipográficos en los mismos.

Actualmente no se utiliza de forma exclusiva este identificador  y ante cualquier modificación remitida al INE, éste contrasta al habitante mediante un conjunto de datos que se encuentran en el bloque de los datos de identificación o antes de variación y tras ese contraste incorpora los datos tras variación y en el caso de que estos datos iniciales NO sean coincidentes con los que obran en el INE, el registro es devuelto al Ayuntamiento con diferentes errores como el 78 – Modificación no encontrada  o el 75 – Baja no encontrada.

En relación a la recomendación “sería conveniente que se recuperaran los NIAS asignados con anterioridad”, refiriéndose a los casos en que el ciudadano vuelve a inscribirse en el mismo municipio,  es conveniente utilizar los mecanismos que pueda ofrecerle su aplicación para recuperar ese dato, teniendo en cuenta que en estos casos no estamos simplemente recuperando el NIA sino que estamos enlazando los movimientos del habitante y por tanto unificando todo el histórico del habitante de forma que sea tratado como un mismo habitante a todos los efectos y frente a cualquier certificación que pueda expedirse del mismo.

Es cierto que en ocasiones, por los motivos explicados anteriormente en cuanto a la variación que han podido surgir en los datos,  puede resultar difícil la “repesca” pero, aún y así, si posteriormente al alta y tras alguna comprobación o alerta se aprecia este defecto, es importante proceder a una unificación. Lógicamente en estos casos será complicado mantener el mismo NIA para todos los movimientos ya que los movimientos anteriores no podrán ser modificados porque ya fueron incorporados por el INE y aunque para la nueva alta pudiésemos aplicar una modificación de datos personales, tampoco conseguiríamos que el NIA del movimiento de alta enviado tomase ese nuevo valor en la base de datos del INE.

Aunque la mayoría de aplicaciones de Padrón de Habitantes gestionan el NIA de forma automática mediante el uso de un contador incremental y dinámico y por ello no debe preocuparnos su asignación, es importante tener en cuenta los aspectos detallados anteriormente.

Que paséis un buen verano!!  Nos vemos en septiembre!!

Compártelo

Error 105 – Procesadas varias modificaciones a la misma fecha

Error_105Hoy detallaremos los motivos y precauciones a tomar para minimizar la devolución de la incidencia 105, remitida a los Ayuntamientos por el INE a través de los ficheros mensuales.

Tal como se describe en el documento “Normas para el tratamiento de las incidencias resultantes de la incorporación de las variaciones mensuales a los ficheros padronales del INE”,  esta incidencia se devuelve cuando se envían dos movimientos con la misma fecha de variación para un mismo habitante, ya sea en el mismo fichero de intercambio o bien cuando se remite posteriormente otro movimiento a la misma fecha que otro ya enviado.

El motivo por el cual el INE genera esta incidencia se debe a una restricción de su sistema, que no permite repercutir más de dos modificaciones con la misma fecha de variación para un mismo habitante.  Recordemos que en el diseño de los ficheros de intercambio no se contempla expresar la fecha con inclusión de la hora, minutos y segundos en los que se registraron los movimientos en el padrón, por lo cual no podemos, dentro de la misma fecha, trasladar al INE, la cronología en la que se han producido.

Partiendo de un ejemplo práctico y bajo el supuesto que aplicásemos, a un inscrito, un movimiento de cambio de domicilio y seguidamente, en la misma fecha, un movimiento de datos personales, al remitir ambos movimientos al INE, si éste procediese a realizar primeramente la carga del movimiento de datos personales, probablemente no podría ejecutar el cambio de domicilio ya que no reconocería al habitante puesto que los datos obrantes en el INE, tras la carga del movimiento anterior, no condirían con los datos de partida del movimiento por cambio de domicilio, lo cual en algunos casos produciría el error 78 – Modificación no encontrada.

Para evitar estos casos y cuando un ciudadano comunica su nuevo domicilio y datos personales, ademas de renovar su inscripción padronal, en el caso de los ciudadanos extranjeros, se deberá enviar un SOLO movimiento al INE, con el código de variación MCD o MRN cuando confluyan diferentes movimientos.

Frente a estas restricciones del sistema destino, las aplicaciones sobre gestión padronal no deben permitir realizar dos o más movimientos a la misma fecha entendidos como dos o más registros o variaciones diferentes y ante la necesidad de abordar varios movimientos deberán remitirse como un MRN (para los casos de renovación de extranjeros) o un MCD para los casos en que se incluya un cambio de domicilio sin renovación.

¿Qué debe hacerse cuando en el padrón de habitantes no se han mecanizado correctamente los datos de alta de un habitante?

La forma de proceder dependerá de si el error se detecta antes o después de haber remitido el movimiento al INE, de forma que si el Ayuntamiento no ha remitido el Alta, se deberá realizar una corrección de los datos sin generar movimiento al INE, es decir, corrigiendo directamente el movimiento de alta. En el caso de que el Ayuntamiento ya haya remitido el alta al INE, se procederá a realizar un movimiento de modificación de datos personales a una fecha real posterior, que para estos casos es aconsejable que sea el día después de la fecha del alta.

Si por cualquier circunstancia, ya sea la remisión del mismo movimiento del habitante en un fichero posterior o a partir de alguna maniobra en el histórico del ciudadano, se ha generado y ha sido devuelto por el INE el error 105, el  Ayuntamiento  deberá comprobar si los datos del habitante en la base de datos del INE coinciden con los que constan en su Padrón y de ser así, no será preciso realizar más acciones.  En otro caso, se deberá comunicar al INE una nueva modificación en la que los datos de identificación sean los que constan en la base del INE y en los datos tras variación los que consten actualmente en el Padrón del Ayuntamiento.

Aprovecho el artículo para remarcar, en alusión a las consultas que se producen en los casos de generar un solo movimiento con varias modificaciones y sobre todo en los que existe una modificación por renovación de extranjero (MRN) y sea devuelto por el INE con un error 78, por no corresponder el tipo de movimiento a las características del extranjero, que será necesario deshacer el MRN pero enviar de nuevo el resto de movimientos que se comunicaban al INE en el registro, también en un solo registro si fuera el caso de coexistir una modificación de datos personales y cambio de domicilio.

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

Extranjeros comunitarios o con Residencia Permanente (No_ENCSARP)

NO_ENCSARPSi en una entrada anterior hablábamos de los Extranjeros No Comunitarios Sin Residencia Permanente (ENCSARP), en esta ocasión hablaremos del procedimiento a seguir para el resto de extranjeros, es decir, los ciudadanos de la Unión Europea y de los Estados que forman parte del Acuerdo Económico Europeo y los que sin pertenecer a estos países, tienen tarjeta de residencia de régimen comunitario por ser familiares de comunitarios y aquellos que tienen autorización de residencia de larga duración.

Aunque este tipo de extranjeros NO están obligados a renovar, si que en determinadas circunstancias han de confirmar que siguen residiendo en el municipio, para lo cual el INE comunica mensualmente a los Ayuntamientos, mediante las incidencias 141,142 y 143, la obligación de confirmar la residencia según los siguientes casos:

Su última inscripción padronal tiene más de dos años de antigüedad y no están inscritos en el Registro Central de Extranjeros (RCE), o hace más de cinco años y tienen una autorización de residencia caducada o el certificado de inscripción en el RCE ha sido expedido hace más de cinco años.

Para confirmar su domicilio, los Ayuntamientos deberán enviar al INE un movimiento de “confirmación de domicilio (M CO)”, pero si durante las gestiones llevadas a cabo para obtener esta confirmación, el extranjero ha cambiado de domicilio en el municipio o ha variado alguno de sus datos personales, NO será necesario remitir al INE un movimiento de “Confirmación de domicilio” ya que la propia modificación por cambio de domicilio (M CD) o la de datos personales (M PE) darán por resuelta la incidencia y a todos los efectos confirmada su residencia.

Por tanto, a diferencia de los ENCSARP en los que SI es necesario enviar un movimiento explicito de renovación (M RN) que podrá contener además nuevos datos de domicilio o personales, en este caso SOLO será preciso enviar un cambio de domicilio o una modificación de datos personales.

En este sentido es importante que todos aquellos movimientos que se aborden en relación a modificaciones en los datos personales de estos extranjeros sin intervención de los mismos (ya sea cambios en la titulación académica u otras modificaciones en sus datos) sean notificados a los mismos con la intención de constatar que el ciudadano sigue residiendo en el municipio y no distorsionar la realidad.

Para las modificaciones en los datos de ubicación del territorio sin intervención del ciudadano,  es importante realizar Movimientos de Rectificación de Domicilio (M RD) ya que estos no serán tenidas en cuenta por el INE a los efectos de confirmación de domicilio y, por tanto y lógicamente si no existe algunos de los movimientos descritos anteriormente, no se contabilizarán para las cifras anuales.

En las sucesivas reuniones del consejo de empadronamiento y desde la puesta en marcha de las incidencias para la consecución de la confirmación de residencia de los NO_ENCSARP, se ha ido trasladando a los Ayuntamientos un criterio progresivo en la contabilización de los mismos en relación a la obtención de cifras, siendo las cifras a 1 de enero de 2016 las últimas en las que se han aplicado estos criterios, ya que a partir de 1 de enero de 2017 no se contabilizará ninguna de las inscripciones para las que el INE haya comunicado alguna incidencia 141, 142 y 143 antes del 1 de octubre del año anterior y que continúen pendientes de gestión en el mes de marzo del año de referencia.

Otra de las consultas dentro del protocolo de gestión de este tipo de modificaciones es la relacionada con el modelo a cumplimentar para llevar a cabo la confirmación de residencia. Ni en la resolución anterior ni en la actual se ha publicado formulario orientativo, tal como se ha facilitado para la renovación de los ENCSARP, por lo cual cada Administración debe confeccionar la plantilla que considere más oportuna a dichos efectos.

A diferencia del tipo de Baja que se aplica a los ENCARP (por caducidad), la baja para este tipo de extranjeros se regirá por el procedimiento indicado en el trámite “Baja por inscripción indebida” y en el caso de que el interesado manifieste vivir habitualmente en otro país, se dará de baja por cambio de residencia sin más trámite.

Aprovecho las fechas en las que estamos para desearos un FELIZ 2017!!

Compártelo

Extranjeros No Comunitarios Sin Autorización de Residencia Permanente. (ENCSARP)

extranjerosAunque creo que después de años practicando, la mayoría de Ayuntamientos tienen bastante claras las actuaciones a seguir en relación a la gestión de los Extranjeros No Comunitarios Sin Autorización de Residencia Permanente, comúnmente reconocidos con el acrónimo de ENCSARP, voy a incidir en algunos puntos que me parece interesante destacar.  

En primer lugar, recordar que mediante acuerdos del Consejo de Empadronamiento en sesión de 7 de noviembre de 2011, se aprobó la creación de la nueva incidencia 146.- Indicador de permanencia,  mediante la cual y a través de los ficheros de devolución mensuales, el INE informa de las adquisiciones y pérdidas de residencia permanente para este colectivo y que durante el mes de mayo de 2012, se remitió un primer fichero, con extensión 146, que permitía realizar la carga inicial de esta información.

Si la aplicación de padrón permite la carga de este dato y además es bien visible, cuando un extranjero de estas características acuda al Ayuntamiento para cualquier otro trámite, sea o no de padrón, se le podrá invitar a renovar su residencia, derivándose de esta práctica las siguientes ventajas:

  • Reduciremos el volumen de preavisos remitidos por el INE en los ficheros mensuales (111 – Comunicación de la fecha de caducidad de la inscripción de los ENCSARP,  (preavisos que se produce con 3 meses de antelación a la caducidad)
  • Aumentaremos la calidad del servicio al ciudadano al evitar al ciudadano posteriores comparecencias para realizar una expresa renovación de su residencia.
  • Ganaremos en eficiencia al evitar gestiones y costes.

La renovación de la residencia para los ENCSARP ha de producirse cómo mínimo cada dos años desde su última renovación o desde su ultima fecha de alta,  pero en ningún caso la normativa hace mención a que no pueda llevarse a cabo en periodos inferiores a los 2 años, computándose un nuevo plazo de dos años a partir del momento en que se genera el nuevo movimiento de Renovación.

Además, en base a la carga periódica de la incidencia 146, que actualizaría sistemáticamente esa circunstancia, permitiría disminuir los errores que se producen al generar una renovación o una baja por caducidad para un habitante que ya NO es ENCSARP y que en consecuencia generaría los errores 78 – Modificación no encontrada, o bien 75 – Baja no encontrada, movimiento que deberá eliminarse ya que la acción que la motivó carecería de efectos desde el momento en que se ha adquirido la residencia permanente.

Es importante tener en cuenta que para los casos en que se remite una Modificación por Renovación que además incluye un cambio en los datos personales o en el domicilio y ha sido devuelta por el INE por los errores citados en el anterior párrafo, deberá eliminarse la modificación por Renovación y VOLVER a remitir el resto de modificaciones que iban incluidas en el movimiento que se envió al INE.

En relación a otras cuestiones planteadas en este mismo ámbito, destacaría las siguientes:

  • Para declarar la caducidad de la inscripción y acordar la baja se precisa de una resolución motivada del Alcalde (Decreto de o resolución de Alcaldía), que deberá ser notificada por los procedimientos previstos en la Ley 39/2015, siendo la fecha de la baja la correspondiente a la notificación.  Si la notificación no puede ser practicada deberá recogerse la fecha de publicación en el BOP (fecha que siempre será posterior a la fecha de caducidad)
  • Mientras no se tenga constancia del resultado de la notificación o se haya realizado la publicación en el BOP, se puede producir la renovación. 
  • Si la renovación se produjese antes de que se mecanice la baja pero no disponemos del acuse de recibo o no ha llegado en su tiempo límite, se puede optar por no mecanizar la baja y hacer la renovación, aunque esto implicaría que si ha habido una resolución motivada por el Alcalde, deba hacerse una Anulación del acuerdo de caducidad por hechos sobrevenidos. 
  • Si el habitante quiere hacer la renovación cuando ya se ha hecho la resolución de alcaldía, pero aun no se ha notificado al habitante se deberá hacer una anulación del acuerdo de caducidad por hechos sobrevenidos. Esto deshará la resolución de baja de este habitante y permitirá que renueve su empadronamiento. 
  • Si el ENCSARP se presenta en el Ayuntamiento una vez ha estado dado de baja por caducidad, se deberá realizar un Alta por Omisión. El alta y la baja en ningún caso podrán tener la misma fecha.

Si alguien considera que puede matizar o aportar otras experiencias que promuevan buenas prácticas, que ¡no dude en añadir comentarios a esta entrada!

Compártelo