Archivo de la categoría: Errores / Incidencias INE

Error 77 – Baja por defunción no encontrada en el Registro Civil

DefuncionEn esta ocasión trataremos el error 77 que, análogamente al error 72 descrito como ”Alta por nacimiento no encontrada en el Registro Civil”, se produce cuando al enviar al INE una baja por defunción a través de los ficheros mensuales, este no la esperaba al no tener constancia de esa comunicación a través del Registro Civil.

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”, el error se produce por los siguientes motivos:

No se ha localizado una inscripción de defunción en la información procedente de Registro Civil, disponible en el INE, coincidente con la inscripción padronal. El motivo puede ser la diferencia en algún dato de identificación, desfases en la recepción de la información, que se trate de una defunción no inscrita en el Registro Civil por haberse producido en el extranjero, o un error en la generación de la variación.

Por tanto, matizando la descripción anterior, se produciría en los siguientes supuestos:

  • Haber practicado una baja por defunción sobre un habitante equivocado.
  • Haber practicado este tipo de baja cuando realmente se habría producido y registrado en otro municipio o en el extranjero.
  • Cuando los datos de inscripción en el padrón no coincidan con los de la baja que figura en el padrón del INE o Registro Civil.
  • Cuando el Ayuntamiento se adelante y envía una baja que aún no se ha sido mecanizada en el Registro Civil.

En todos los casos, el INE incorporará el registro en su base a la espera de confirmación por parte del Ayuntamiento.

En el supuesto de que el Ayuntamiento compruebe que realmente se trata de una defunción producida en su municipio, y así mismo compruebe que no existe un error 82 – “Baja por defunción pendiente de confirmación” para ese habitante, cotejando si hay diferencias en los datos personales de ambos registros de error (77 y 82), se lo comunicará a su correspondiente delegación y/o remitirá a ésta la correspondiente partida de defunción.

Hay que tener en cuenta que, en ocasiones, los Ayuntamientos pueden necesitar mecanizar las inscripciones de nacimiento o defunción antes de que lo haga el Registro Civil, en cuyo caso y al remitir el fichero de variaciones, el INE devolverá este error como consecuencia de la  falta de sincronización entre ambas mecanizaciones.  En este supuesto, si el Ayuntamiento tiene la certeza de haber consolidado correctamente la inscripción, podrá esperar unas semanas y consultar en la página de Ida Cónsul para constatar que ya no exista el error y, por tanto, dar por resuelta la incidencia.

Si el Ayuntamiento tuviese pruebas de que realmente se trata de una defunción producida en otro municipio español, deberá rechazar el error y posteriormente realizar una baja por cambio de residencia con una fecha anterior a la de la defunción (aspecto que en ocasiones deberá ser consultado con el INE o con el Ayuntamiento en el que le consta que se ha producido la baja). En este caso, es aconsejable enviar el rechazo y la baja en dos ficheros de intercambio diferentes.

Si el Ayuntamiento tuviese pruebas de que el habitante, siendo español, ha fallecido en el extranjero y probablemente no se inscribió en el Registro de Matricula de la Oficina o Sección Consular en el país de destino, (en cuyo caso hubiese sido comunicado al Ayuntamiento mediante la incidencia 76 “Baja por Cambio de residencia por alta en PERE”) y que tampoco se hubiera comunicado la defunción al consulado español, lo pondrá en conocimiento del INE a la espera de la confirmación por parte de estos.

Si el Ayuntamiento tuviese constancia que el habitante, siendo extranjero, ha fallecido en otro país, podrá rechazar el error y posteriormente modificar el motivo de la baja a “Cambio de residencia” indicando el destino a ese país. En este caso, si no se tiene constancia de la fecha real de la baja, podría informarse la que le consta como fecha de defunción.

Desde hace ya varios años, este error, juntamente con el error 83,  figura entre los únicos sobre los que se puede practicar un rechazo y en este caso, como hemos dicho, con la finalidad de que el INE deshaga el movimiento o coloquialmente y de forma distendida como solemos decir, que “nos lo resuciten” :-)

Compártelo

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

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