Categoría: Normativas

oducción (TRSC), que contiene Prestaciones (PR), es una carga diaria (D), enviado por una entidad (P), el día 24/08/2020.
IFI.TRSCPRDR.D200824.N001: Fichero de respuesta en el entorno de producción (TRSC). Sería el fichero de respuesta del ejemplo anterior. Contiene Prestaciones (PR), es una carga diaria (D), enviado por el INSS como respuesta (R), el día 24/08/2020.
IFI.FOTSSSMP.D200825.N001: Fichero enviado al entorno de formación (FOTS), que contiene situaciones subjetivas (SS), es una carga inicial (M), enviado por una entidad (P), el día 25/08/2020.
IFI.FOTSSSMR.D200825.N001: Fichero de respuesta en el entorno de formación (FOTS). Sería el fichero de respuesta del ejemplo anterior. Contiene situaciones subjetivas (SS), es una carga inicial (M), enviado por el INSS como respuesta (R), el día 25/08/2020.
Puede encontrar más detalle de la operativa de envío/recepción de ficheros con IFI en el Manual de usuario IFI publicado en la Sede de la Seguridad Social.
Operativa con IFIWEB.
Esta aplicación es accesible a través de la Sede Electrónica de la Seguridad Social, dentro de las gestiones que pueden realizar Administraciones y Mutuas. La aplicación consta de tres servicios diferenciados:
– Envío de ficheros: Con este servicio podrán enviar los ficheros a intercambiar con la Seguridad Social. Dado que se requiere que el fichero a enviar esté firmado, el servicio obligará a ello forzando la firma con el certificado digital del usuario o con Cl@ve, en función del método de entrada utilizado. El certificado con el que se firme el fichero deberá pertenecer al mismo usuario que ha entrado en el Sistema.
– Descarga de ficheros: Con este servicio el usuario podrá descargar ficheros de respuesta a sus peticiones, así como ficheros de respuesta para peticiones de otros usuarios de su mismo organismo.
– Consulta de ficheros: Con este servicio el usuario podrá consultar el estado de ficheros de respuesta a sus peticiones, así como ficheros de respuesta para peticiones de otros usuarios de su mismo organismo. La consulta se podrá hacer por identificador de petición o bien por fechas.
El acceso a cualquiera de los tres servicios requiere de la identificación del usuario, con certificado digital o con Cl@ve, y una validación de permisos.
Tras identificarse, IFIWEB le mostrará las opciones de menú correspondientes y que tiene autorizadas.
En el caso de TSD las opciones de menú que el usuario puede disponer para el envío de ficheros al entorno de Formación son:
– FTSD-ENVÍO PRESTACIONES CARGA INICIAL.
– FTSD-ENVÍO PRESTACIONES CARGA PERIÓDICA.
– FTSD-ENVÍO PAGOS CARGA INICIAL.
– FTSD-ENVÍO PAGOS CARGA PERIÓDICA.
– FTSD-ENVÍO DE SITUACIONES SUBJETIVAS INICIAL.
– FTSD-ENVÍO DE SITUACIONES SUBJETIVAS PERIÓDICA.
Y las opciones de menú que el usuario puede disponer para el envío de ficheros al entorno de Producción son:
– TSD-ENVÍO DATOS PRESTACIONES CARGA INICIAL.
– TSD-ENVÍO DATOS PRESTACIONES CARGA PERIÓDICA.
– TSD-ENVÍO DATOS DE PAGOS CARGA INICIAL.
– TSD-ENVÍO DATOS PAGOS CARGA PERIÓDICA.
– TSD-ENVÍO DE SITUACIONES SUBJETIVAS INICIAL.
– TSD-ENVÍO DE SITUACIONES SUBJETIVAS PERIÓDICA.
Para el envío de ficheros por IFIWEB, no se requiere una nomenclatura especial en los nombres de los ficheros. Es IFIWEB quien en función de la opción de menú/servicio que el usuario elija para el envío del fichero quien pone la nomenclatura correspondiente. Una vez procesados y validados, se devolverá una respuesta al Organismo, y no solo al usuario que realizó el envío del fichero de datos.
Las opciones de menú que el usuario dispone para la recepción de ficheros del entorno de Formación son:
– FTSD-RECEPCIÓN PRESTACIONES CARGA INICIAL.
– FTSD-RECEPCIÓN PRESTACIONES CARGA PERIÓDICA.
– FTSD-RECEPCIÓN PAGOS CARGA INICIAL.
– FTSD-RECEPCIÓN PAGOS CARGA PERIÓDICA.
– FTSD-ENVÍO DE SITUACIONES SUBJETIVAS INICIAL.
– FTSD-ENVÍO DE SITUACIONES SUBJETIVAS PERIÓDICA.
Las opciones de menú que el usuario dispone para la recepción de ficheros del entorno de Producción son:
– TSD-RECEPCIÓN DATOS PRESTACIONES CARGA INICIAL.
– TSD-RECEPCIÓN DATOS PRESTACIONES CARGA PERIÓDICA.
– TSD-RECEPCIÓN DATOS DE PAGOS CARGA INICIAL.
– TSD-RECEPCIÓN DATOS PAGOS CARGA PERIÓDICA.
– TSD-ENVÍO DE SITUACIONES SUBJETIVAS INICIAL.
– TSD-ENVÍO DE SITUACIONES SUBJETIVAS PERIÓDICA.
Para facilitar esta tarea, IFIWEB dispone de un Servicio de Consulta de Datos, en el que te informa de la situación de todos los intercambios de información, y de si en alguno de ellos se dispone de una respuesta. «CONSULTA DE ESTADO».
Puede encontrar más detalle de la operativa de envío/recepción de ficheros con IFI en el Manual de usuario IFIWEB publicado en la Sede de la Seguridad Social.
Operativa con EDITRAN.
El envío y recepción de ficheros se realizan por las Sesiones establecidas a este efecto según se indican en el apartado 3.4.3 de este capítulo.
Peculiaridades de los ficheros de intercambio para el entorno de formación.
Como se ha ido explicando a lo largo de este apartado, existen dos entornos para TSD: Producción y Formación (o entorno de prácticas).
Para evitar posibles errores y cargas de datos en entornos incorrectos, exclusivamente para los ficheros que se envían al entorno de Formación se espera un nuevo campo en el contenido del fichero (en el registro cabecera) llamado «IDENTIFICADOR CIRCUITO DE FORMACIÓN» según se detalla a continuación:
Este campo solo se informará en los ficheros que se envíen al entorno de Formación, en el resto de casos no deberá tener contenido.
Todos los ficheros que se remitan para este entorno deberán contener en este campo de la cabecera el literal «PRUEBAS». Si un fichero remitido a formación (ya sea con el nombre correcto –IFI– o por la opción adecuada –IFIWEB, EDITRAN–) no contiene dicho campo se rechazarán todos los registros con el error 10008 (datos de carga no corresponden al entorno de ejecución). De la misma forma si este campo tuviera contenido en ficheros que se deseen cargar el Producción se rechazarían de la misma forma.
Gestión de incidencias.
Para una mejor gestión y control, toda incidencia y/o consulta que pueda surgir con la puesta en marcha de estos Intercambios de Información, debe dirigirse al Equipo de Soporte TSD (tsd.soporte@seg-social.es).
Observar que, en el caso de que estas incidencias o consultas sean de carácter técnico, y referentes a la instalación y/o uso de los mecanismos de intercambio de información que se ofrecen, deben aportar la siguiente información:
– Código DIR3 de la Entidad Autorizada.
– Herramienta utilizada (IFI/IFIWEB/Editran).
– Tipo de Certificado electrónico, y DNI del responsable o titular del mismo.
– Sistema operativo, versión y tipo (32 o 64 bits).
– Copia de los mensajes de error que se produzcan.
– Contenido de la consola JAVA en el momento en que se produce el error. La consola Java se abre, en las versiones 1.7.0_xx, desde el Panel de Control de Windows: Icono Java > Avanzado > Consola de Java > Ver consola.
– Si utiliza IFIWEB: Navegador utilizado y versión./Versión del JRE.
– Si utiliza IFI: Fichero «ClienteIFI.log» de la carpeta «log» de su instalación.
Enlaces y recursos.
Fichero de prestaciones.
A continuación de detallará el formato del fichero de PRESTACIONES. Según se ha explicado anteriormente, la estructura de este fichero contendrá 1 registro de cabecera, N registros de datos y 1 registro de pie.
Es importante destacar que este formato será el que se utilice tanto para cargas iniciales como para cargas diarias.
Los volúmenes máximos que se podrán utilizar son los siguientes:
Registro de cabecera.
Registro de datos (prestación).
Registro de pie.
Validaciones generales.
Campos numéricos.
Todos los campos numéricos (representados con una N en la columna Tipo de la tabla anterior) deberán ir ajustados a la derecha.
En el caso de no llegar a la longitud definida se deberán rellenar con ceros por la izquierda.
Si un campo numérico no tiene contenido se deberá rellenar a ceros.
Para el caso de campos numéricos que representan un importe, se enviarán en céntimos de euro (sin decimales) y siempre deberá ser positivo.
Campos alfanuméricos.
Todos los campos alfanuméricos (representados con una A en la columna Tipo de la tabla anterior) deberán ir ajustados a la izquierda.
En el caso de no llegar a la longitud definida se deberán rellenar con espacios por la derecha.
Campos fecha.
Los campos fecha se consideran siempre numéricos (aparecen con tipo N en la tabla anterior) de 8 posiciones.
Todos los campos fecha requieren el formato AAAAMMDD.
Apartado datos identificativos de la persona.
Este apartado es clave para identificar unívocamente a la persona que percibe o es beneficiaria de la prestación.
Para ello se utilizará el campo IDENTIFICATIVO, que representa el Indicador de Persona Física (IPF), según se detalla a continuación:
– La primera posición del campo identifica el tipo de IPF, siendo válidos los valores siguientes:
• 1: DNI.
• 6: NIE.
• 9: IPF ficticio. Solo para españoles menores de 14 años.
– Las posiciones dos a once se formatearán según el tipo de IPF:
• 1: DNI: Las primeras diez contendrán el número de DNI con ceros a la izquierda y la última contendrá la letra del DNI.
• 6: NIE: Las primeras diez contendrán el número de NIE (normalmente empezará por 0X, 0Y o 0Z) y la última contendrá la letra del NIE.
• 9: IPF ficticio:
○ Las posiciones dos a tres contendrán las dos primeras letras del primer apellido (sin partículas).
○ Las posiciones cuatro a cinco contendrán las dos primeras letras del segundo apellido (sin partículas). Si no existiera segundo apellido se remitirán tres guiones medios «—».
○ Las posiciones seis a siete contendrán los dos últimos caracteres del año de nacimiento.
○ Las posiciones ocho a nueve contendrán el mes de nacimiento.
○ Las posiciones diez a once contendrán el día de nacimiento.
○ Las posiciones doce a quince vendrán a ceros (salvo que se conozcan la duplicidad y el desdoblamiento de Afiliación).
○ En el anexo 40.1 se explica con mayor detalle la forma de crear estos IPFs.
– Las posiciones doce a quince representan la duplicidad de ese identificador y su desdoblamiento, conceptos manejados en Afiliación para IPFs repetidos.
• Para los tipos 1, 6 y 9 se completarán si se conocen. En caso de no conocerse, se enviarán a ceros.
– Para los IPF de tipo 9 se validará que su nacionalidad (campo NACIONALIDAD) sea española.
El campo OTRO IDENTIFICATIVO tiene el mismo formato que el campo IDENTIFICATIVO. Representa un IPF y solo se utilizará para los casos en los que se desee informar de un cambio de un IPF previamente informado, código de actuación 05 en cuyo caso será obligatorio (típico uso de extranjeros que tienen IPF de tipo 6 y al conseguir nacionalidad española cambian su IPF a uno de tipo 1).
El APELLIDO SEGUNDO si no se conoce deberá contener «—».
La FECHA DE NACIMIENTO es obligatoria y no aceptará valores menores a 19000101.
Apartado otros datos personales.
El campo NACIONALIDAD se completará en base a la codificación ISO 3166 numérica. Además se aceptarán los valores:
– 952-APÁTRIDAS.
– 953-PAÍS DESCONOCIDO.
El campo INDICADOR DE DATOS PROTEGIDOS hace referencia a una especial protección para aquellos ciudadanos que la hayan solicitado expresamente ante la administración correspondiente. Sus valores podrán ser:
– P-PROTEGIDOS.
– D-Desproteger. (NO REQUIERE PROTECCIÓN) Solo permitido para código de actuación 06.
– Vacío-NO REQUIERE PROTECCIÓN.
Apartado datos de residencia.
En este bloque se remitirá la dirección de la persona que tiene asociada la prestación. El tratamiento es diferente en función de si es un domicilio nacional o extranjero.
El campo PAÍS DE RESIDENCIA determinará si el domicilio es nacional o extranjero. Se introducirá el código 953 si se desconoce.
Para DOMICILIO NACIONAL (código país 724) se validarán los siguientes campos:
– PROVINCIA DE RESIDENCIA. Será siempre obligatorio. Si se desconoce existe el valor 99 PROVINCIA DESCONOCID.
– CÓDIGO MUNICIPIO DE RESIDENCIA. Código del municipio de residencia de la persona perceptora/beneficiaria de la prestación. Los valores permitidos serán los del Código INE, los códigos admitidos se encuentran en esta dirección: http://www.ine.es/nomen2/index.do (página nomenclátor del INE).
– NOMBRE DEL MUNICIPIO DE RESIDENCIA. Si se desconoce el código anterior, será obligatorio introducir aquí en texto la localidad de residencia. Si no se conoce, el nombre del municipio podría contener «DESCONOCIDO».
– El resto de campos no son obligatorios pero, en caso de que alguno tenga contenido se deberá cumplir la siguiente obligatoriedad:
• CÓDIGO DE VÍA (obligatorio).
• NOMBRE DE LA VÍA (obligatorio).
• NUMERO DE LA VÍA (no obligatorio).
• ESCALERA (no obligatorio).
• PUERTA (no obligatorio).
• PISO (no obligatorio).
• BLOQUE (no obligatorio).
• CÓDIGO POSTAL (obligatorio).
Para DOMICILIO EXTRANJERO (código país distinto de 724 y 953), se enviará en modo texto la dirección extranjera a través de los siguientes campos:
– DIRECCIÓN DE RESIDENCIA 1. Datos de la dirección.
– DIRECCIÓN DE RESIDENCIA 2. Datos adicionales por si no fuese suficiente el campo anterior.
– LOCALIDAD DE RESIDENCIA EXTRANJERA. Nombre de la localidad extranjera. Si se desconoce deberá contener «DESCONOCIDO».
Apartado datos específicos IMV o RIS.
Este conjunto de datos únicamente se deberá completar si el registro que se está enviando es una prestación de Ingreso Mínimo Vital (IMV, código 1230102) o una Renta de Integración Social (RIS, código 560202). En cualquier otro caso estos datos irán rellenos a espacios en blanco.
Tipos de acciones disponibles en prestaciones.
Una vez descrito el formato del fichero de prestaciones y validaciones básicas, procedemos a explicar las acciones disponibles que, a través del fichero, las entidades podrán remitir al INSS.
El campo CÓDIGO DE ACTUACIÓN indicará qué operación se pretende aplicar con el registro (prestación) remitido. Sus posibles valores son:
– 01: Alta de prestación. Alta de prestación en el sistema de tarjeta social digital.
– 02: Modificación de prestación. Modificación de datos de una prestación existente (previamente cargada) en el sistema de tarjeta social digital.
– 03: Borrado de prestación. Borrado físico de una prestación. Se utilizará esta acción para corregir errores y borrar prestaciones previamente remitidas al sistema de tarjeta social digital.
– 04: Cambio de situación de prestación. Se utilizará para modificar el estado de una prestación previamente enviada (campo ESTADO ACTUAL). Un uso típico podría ser una prestación que ha estado de Alta durante un periodo de tiempo y en un momento dado pasa a Baja.
– 05: Cambio de identificación de persona. Cambio en el identificador de una persona existente en el sistema de tarjeta social digital. Uso típico de campo de tipo de IPF de 6 (NIE-extranjero) a 1 (DNI-nacional).
– 06: Variación de datos personales. Variación de datos personales de persona existente en el sistema de tarjeta social digital.
– 07: Traspaso de prestación. Asocia una prestación existente en el sistema de tarjeta social digital a otra persona.
Dado que la carga inicial (o masiva) de prestaciones es un proceso muy costoso que pretende agilizar la carga de una gran cantidad de información en el sistema, únicamente permitirá acciones de tipo Alta prestación (01).
Por el contrario, el proceso de carga diaria permite utilizar todas las acciones que aquí se detallan.
Alta de prestación (código de actuación 01).
Se utilizará para dar de alta una nueva prestación en el sistema por parte de una entidad. Se aportará por la entidad la información referente a los datos personales (incluyendo como opcional el indicador de protección), el domicilio de residencia y los datos de la prestación.
Si la prestación que quiere enviar no se encuentra en el catálogo (ver anexo 7.4), por favor solicite su creación a incidencias.tsd@seg-social.es, anexando la normativa reguladora de la misma.
Validaciones a aplicar.
– La obligatoriedad de los campos a aportar en un registro de Alta de prestación vienen detallados en la tabla del apartado 4.2.8.
– Si la prestación ya se encuentra dada de alta en el sistema se rechazará.
– Si la FECHA DE SITUACIÓN de la prestación es anterior al 01/01/1900 o supera en más de 3 meses la fecha de carga se rechazará el alta.
– Si la persona perceptora de la prestación ya se encuentra en el sistema (mismo IDENTIFICADOR) no se le dará de alta. Se asociará a la persona encontrada la nueva prestación recibida siempre y cuando se detecte que se trata de la misma persona. Para ello se aplicará el algoritmo de coincidencia del 80 % de los datos personales (apellidos y nombre y fecha de nacimiento).
– No se admitirán movimientos de alta de prestación asociados a un identificador de persona que previamente haya sido modificado a través de un movimiento de CAMBIO DE IDENTIFICACIÓN DE PERSONA (05). En estos casos, en el fichero de respuesta se indicará el error 31034 (Referencia al identificativo antiguo en el movimiento) y se devolverá a la entidad gestora a nivel informativo cual es el identificador actual de persona dada de alta en TSD en el campo OTRO IDENTIFICATIVO.
– Se modificará el domicilio siempre que se consideren los nuevos datos suministrados igual o más completos que los ya cargados en TSD. Teniendo en cuenta los campos «País», «Nombre localidad» y «Nombre vía».
– El alta de prestaciones que no sean de TIPO DE PAGO único («U») siempre deberán llevar en el campo SITUACIÓN ACTUAL el valor «A» (alta), es decir, la prestación a cargar debe estar de alta. Si fuese necesario cargar una prestación de baja deberá realizarse a través del procedimiento de carga de histórico (anexo 30).
– Si el en el campo TIPO DE PAGO se introduce el valor U (pago único), el campo SITUACIÓN ACTUAL debe ser «B» (baja) y la FECHA SITUACIÓN debe ser la fecha de efectos de la prestación. Solo en el caso de las prestaciones que su pago único haga referencia a un periodo de tiempo se comunicará «A» (alta) y «B» de la prestación. Caso de uso típico de capitalizaciones (CLASE DE PAGO 23).
– Solo para el proceso de carga inicial o masiva, no se permitirá dentro del mismo fichero el envío de alta de prestaciones asociadas al mismo identificativo (IPF) con apellidos y nombres distintos. Esto es debido a que las validaciones que obligan estas situaciones ralentizarían el proceso masivo. En caso de detectarse esta situación, se devolverá error con el código 11033 (Identificador duplicado con diferente valor en Apellidos y/o nombre en el fichero de entrada. No se contempla este caso en carga inicial). Esta situación se puede dar especialmente en hermanos con IPF's ficticios nacidos el mismo día (que tendrán el mismo IDENTIFICATIVO). Si fuese necesario tramitar su alta se deberá remitir a través de una carga diaria.
– Si el registro que se pretende crear es de la prestación Ingreso Mínimo Vital (IMV, código 1230102) o una Renta de Integración Social (RIS, código 560202), se deberán aportar obligatoriamente los campos NUMERO CONVIVIENTES, PERCEPTOR y ESTADO PERCEPTOR.
– En el caso de prestaciones IMV o RIS, se mandará un primer registro de alta de la prestación con los datos del titular, indicando como tipo de perceptor T. Si la unidad de convivencia está formada por más miembros se tendrán que recibir tantos registros como beneficiarios (a excepción del titular), indicando como tipo de perceptor B. Se deberá enviar la misma CLAVE PROPIA ENTIDAD tanto en el registro del titular como en los del resto de beneficiarios. La diferenciación vendrá por el tipo de Perceptor (T o B).
– Para prestaciones IMV o RIS, se rechaza el alta de un beneficiario, en el caso de que la prestación no exista (necesaria el alta previamente de la prestación con el titular).
– En función del tipo de entidad que remite la información (local, autonómica, estatal o Mutuas) existirá un conjunto concreto de prestaciones que podrá enviar en el campo CLAVE PRESTACIÓN, según se detalla en el ANEXO 7.4. En el caso de remitir una prestación que no corresponde con la entidad, se devolverá un error (código 11282 «El Campo CLAVE PRESTACIÓN no puede ser remitido por esta entidad»).
Modificación de prestación (código de actuación 02).
Con este código la entidad remitirá los datos del apartado DATOS DE LA PRESTACIÓN que desea modificar, identificándose la prestación por la CLAVE PROPIA ENTIDAD.
Se podrán modificar los campos CLAVE PRESTACIÓN, FECHA DE SITUACIÓN, TIPO DE PAGO, y en el «Bloque importes» CÓDIGO e IMPORTE.
A través de esta acción también se podrán modificar los datos específicos de las prestaciones Ingreso Mínimo Vital (IMV-1230102) o Renta de Integración Social (RIS-560202).
Validaciones a aplicar.
– La obligatoriedad de los campos a aportar en un registro de Modificación de prestación vienen detallados en la tabla del apartado 4.2.8. En este caso, los campos marcados como no obligatorios si se completan no se validarán. La identificación de la prestación se realizará a través de la CLAVE PROPIA ENTIDAD.
– Si la prestación no se localiza en el sistema, se rechazará la operación.
– La prestación solo podrá ser modificada por la entidad gestora que la dio de alta.
– Si la prestación que se pretende modificar es un Ingreso Mínimo Vital (IMV, código 1230102) o una Renta de Integración Social (RIS, código 560202), los datos personales que acompañarán al registro deben ser los del titular de la prestación.
– Si lo que se pretende modificar es la fecha de alta o baja de un beneficiario de la prestación se deberán mandar los datos personales del beneficiario.
Borrado de prestación (código de actuación 03).
Se utilizará para BORRAR una prestación. Su sentido será el eliminar registros que se remitieron por error. Conlleva un borrado físico de la prestación. Puesto que el borrado de una prestación implica que dicha prestación ya está almacenada en nuestro sistema, la entidad aportará únicamente la CLAVE PROPIA ENTIDAD que identifica la prestación.
Validaciones a aplicar.
– La obligatoriedad de los campos a aportar en un registro de Borrado de prestación vienen detallados en la tabla del apartado 4.2.8. En este caso, los campos marcados como no obligatorios si se completan no se validarán, ya que la única información necesaria para realizar el borrado es la entidad y la CLAVE PROPIA ENTIDAD.
– Si la prestación no se localiza en el sistema, se rechazará la operación.
– La prestación solo podrá ser borrada por la entidad gestora que la dio de alta en el sistema.
– Si la prestación ya tuviera asociado un histórico de pagos, este sería borrado en el mismo proceso del borrado de la prestación.
– Si la prestación con objeto de ser eliminada es la única que tenía asociada la persona perceptora de la prestación, se eliminaran tanto los datos personales como los de domicilio siempre y cuando no tengan situaciones subjetivas asociadas.
Cambio de situación de una prestación (código de actuación 04).
Esta acción únicamente está pensada para comunicar los cambios de situación que se produzcan en una prestación previamente enviada al sistema. Se utilizará para suspender (S), extinguir (B) o activar (A) una prestación. Los datos a aportar por la entidad se reducirán a identificar la prestación que se quiere modificar, el nuevo estado y su fecha. También se usará para extinguir (B) o activar (A) los miembros de la unidad de convivencia en las prestaciones IMV y RIS (Caso de uso para nacimientos, fallecimientos o miembros que se independizan).
Validaciones a aplicar.
– La obligatoriedad de los campos a aportar en un registro de Cambio de situación de una prestación vienen detallados en la tabla del apartado 4.2.8. En este caso, los campos marcados como no obligatorios si se completan no se validarán, ya que la única información necesaria para realizar el cambio de situación es la identificación de la prestación y el nuevo estado y fecha. La identificación de la prestación se realizará a través de la CLAVE PROPIA ENTIDAD.
– Si la prestación no se localiza en el sistema, se rechazará la operación.
– La situación de la prestación solo podrá ser modificada por la entidad gestora que la dio de alta en origen.
– Si no coincidiese el IPF remitido (por haberse producido una vez remitida la prestación un cambió de identificador a través de un código de actuación 05) se procesará el movimiento advirtiendo en el fichero de respuesta de esta situación e incluyendo el identificador actual asociado a la prestación. Se devolverá el código de aviso 91030 «AVISO: aceptado con observaciones referentes al identificativo». Asociado a este aviso se devolverá a la entidad gestora, a nivel informativo, el nuevo identificativo en el campo OTRO IDENTIFICATIVO.
– Si lo que se pretende modificar es la situación de una prestación de Ingreso Mínimo Vital (IMV, código 1230102) o Renta de Integración Social (RIS, código 560202) se deberán enviar los datos personales del titular de la prestación y, para el cambio, se tendrá en cuenta el campo SITUACIÓN ACTUAL.
– Si lo que se pretende modificar es el estado de un beneficiario de una prestación de Ingreso Mínimo Vital (IMV, código 1230102) o Renta de Integración Social (RIS, código 560202) se deberán enviar los datos personales del beneficiario. Se utilizará el campo ESTADO PERCEPTOR para su modificación. Si se comunica una variación de la situación de un miembro de la unidad de convivencia deberá actualizarse el número de miembros de la unidad de convivencia en el campo NÚMERO DE CONVIVIENTES.
Cambio de identificación de persona (código de actuación 05).
Se utilizará para modificar el identificador de una persona perceptora de prestación que se encuentre dada de alta en la BBDD de TSD.
Se aportará por la entidad el identificador antiguo, el identificador nuevo, compuesto al menos por tipo y número de documento y también los datos personales (nombre y apellidos) a efectos de validación.
Validaciones a aplicar.
– La obligatoriedad de los campos a aportar en un registro de Cambio de identificación de persona vienen detallados en la tabla del apartado 4.2.8. En este caso, los campos marcados como no obligatorios si se completan no se validarán, ya que la única información necesaria será es la identificación del perceptor de la prestación y su nuevo identificador.
– Si la persona perceptora no se encuentra dada de alta en el sistema (el identificador antiguo no existe en TSD) se rechazará la acción.
– El identificador de persona podrá ser modificado por la entidad gestora que dio de alta a la persona o por cualquier otra.
– Se comprobará que los datos personales fijos (nombre, apellidos y fecha de nacimiento) coinciden al 80 % con los almacenados en la BBDD de TSD. En caso de no coincidir al 80 % o más, se rechazará la acción.
– Solo se permiten los cambios de identificador de tipo 9 (ficticio) a tipo 6 (NIE) o 1 (DNI) y de tipo 6 (NIE) a tipo 1 (DNI).
– El cambio de identificador de tipo NIE a DNI implica el cambio automático de la nacionalidad a «Española». No puede haber personas con DNI y con nacionalidad extranjera.
– A efectos de control y validaciones posteriores, se guardará el identificador antiguo en TSD asociado al identificador actual.
– Cuando se produzca un cambio de identificación:
• A partir de ese momento no se permitirá el alta de nuevas prestaciones o situaciones subjetivas asociadas a este identificativo. El error que se utiliza para marcar esta circunstancia es: 31034 Referencia al identificativo antiguo en el movimiento. Asociado a este error se devolverá a la entidad gestora, a nivel informativo, el nuevo identificativo en el campo OTRO IDENTIFICATIVO.
• Sin embargo se permitirán los códigos de actuación 02 (Modificación de prestación) y 04 (Cambio de situación de prestación) aunque nos lleguen asociados al identificativo antiguo. Aunque se hayan modificado los datos solicitados, se devolverá este código de aviso (no es un error): 91030 AVISO: aceptado con observaciones referentes al identificativo. Asociado a este aviso se devolverá a la entidad gestora, a nivel informativo, el nuevo identificativo en el campo OTRO IDENTIFICATIVO.
Variación de datos personales (código de actuación 06).
Se utilizará para modificar los datos personales de una persona que se encuentre dada de alta en TSD a instancias de una entidad gestora. Se podrán modificar los campos ESTADO CIVIL, TELÉFONO MÓVIL e INDICADOR DATOS PROTEGIDOS y todos los campos de «datos de residencia».
Esta operación también podrá ser utilizada para proteger (P) o desproteger (D) personas atendiendo a su INDICADOR DE DATOS PROTEGIDOS.
Validaciones a aplicar.
– La obligatoriedad de los campos a aportar en un registro de variación de datos personas vienen detallados en la tabla del apartado 4.2.8. En este caso, los campos marcados como no obligatorios si se completan no se validarán.
– Si la persona perceptora no se encuentra dada de alta en el sistema (el identificador no existe en TSD) se rechazará la acción.
– Los datos personales podrán ser modificados por la entidad gestora que dio de alta a la persona o por cualquier otra.
– Si los datos de la persona que se remiten en este registro no coinciden con los que se indicaron en el alta previa de la prestación, se rechazará la operación. Para ello, debe coincidir su identificador y los datos personales (nombre, apellidos y fecha de nacimiento) al menos en un 80 % con los almacenados en el sistema TSD.
– El indicador de protección podrá variarse por una entidad teniendo en cuenta las siguientes circunstancias.
• Se podrá solicitar la protección de una persona indicando el valor «P» en el indicador de protección.
• Se podrá solicitar la desprotección de una persona indicando el valor «D» en el indicador de protección. Si en las bases de datos de la Seguridad Social constara como protegido, se mantendría la protección.
– Se modificará el domicilio siempre que se consideren los datos igual o más completos que los ya cargados en TSD. Teniendo en cuenta los campos «País», «Nombre municipio» y «Nombre vía». Si los datos de domicilio no se modifican se generará el código de aviso «91040: AVISO: Aceptado el cambio excepto en los datos de DOMICILIO ya que los datos existentes son más completos».
Traspaso de prestación (código de actuación 07).
Este movimiento estará destinado a realizar traspasos de prestaciones entre personas distintas siempre dentro de una misma entidad gestora. Básicamente se deberán enviar los datos para identificar la prestación y los datos de la persona que asume la prestación. AVISO: Si lo que se pretende es modificar el IPF de una persona se deberá usar el código 05 (cambio de identificador)
Validaciones a aplicar.
– La obligatoriedad de los campos a aportar en un registro de traspaso de prestación vienen detallados en la tabla del apartado 4.2.8. En este caso, los campos marcados como no obligatorios si se completan no se validarán, ya que la única información necesaria para realizar la operación es la CLAVE PROPIA ENTIDAD y los datos del nuevo perceptor (se validará que el nombre y apellidos del nuevo perceptor no coinciden al 100 % con los del anterior)
– Si la prestación no se localiza en el sistema, se rechazará la operación.
– El traspaso de la prestación solo podrá ser realizado por la entidad gestora que la dio de alta en origen.
– Si la persona con objeto de asumir la prestación traspasada NO se encuentra en TSD, se dará de alta con los datos personales recibidos y se le asociará la prestación traspasada. Si por el contrario ya se encuentra dada de alta (utilizando el módulo de 80 %) en TSD, no se dará de alta de nuevo ni se modificará ningún dato personal y se le asociará la prestación recibida.
– No se permitirá el traspaso si la persona que va a asumir la prestación viene asociada a un identificativo antiguo que ha sido modificado a través del «Cambio de identificación de persona». El error que se utiliza para marcar esta circunstancia es: 31034 Referencia al identificativo antiguo en el movimiento. Asociado a este error se devolverá a la entidad gestora, a nivel informativo, el nuevo identificativo en el campo OTRO IDENTIFICATIVO.
– Si la persona originalmente asociada a la prestación no posee otras prestaciones ni situaciones subjetivas tras el traspaso, se eliminará de TSD.
– No se podrán traspasar prestaciones de carácter contributivo.
Obligatoriedad de campos.
En esta tabla se presenta la información obligatoria que se deberá remitir para cada tipo de acción:
Fichero de pagos.
A continuación se detallará el formato del fichero de PAGOS. Según se ha explicado anteriormente, la estructura de este fichero contendrá 1 registro de cabecera, N registros de datos y 1 registro de pie.
Es importante destacar que este formato será el que se utilice tanto para cargas iniciales como para cargas diarias.
Los volúmenes máximos que se podrán utilizar son los siguientes:
Registro de cabecera.
Registro de datos (Pago).
Registro de pie.
Validaciones generales.
Campos numéricos.
Todos los campos numéricos (representados con una N en la columna Tipo de la tabla anterior) deberán ir ajustados a la derecha.
En el caso de no llegar a la longitud definida se deberán rellenar con ceros por la izquierda.
Si un campo numérico no tiene contenido se deberá rellenar a ceros.
Para el caso de campos numéricos que representan un importe, se enviarán en céntimos de euro (sin decimales) y siempre deberá ser positivo.
Campos alfanuméricos.
Todos los campos alfanuméricos (representados con una A en la columna Tipo de la tabla anterior) deberán ir ajustados a la izquierda.
En el caso de no llegar a la longitud definida se deberán rellenar con espacios por la derecha.
Campos fecha.
Los campos fecha se consideran siempre numéricos (aparecen con tipo N en la tabla anterior) de 8 posiciones.
Todos los campos fecha requieren el formato AAAAMMDD.
Campo Clave Propia Entidad.
Este campo es el que se utiliza para vincular un pago con la prestación asociada (no puede haber pagos sin una prestación). Para ello, se deberá incorporar en este campo el mismo valor que se introdujo en el campo Clave Propia Entidad de la PRESTACIÓN previamente remitida.
Tipos de acciones disponibles en pagos.
Una vez descrito y formato del fichero de pagos y validaciones básicas, procedemos a explicar las acciones disponibles que, a través del fichero, las entidades podrán remitir al INSS.
El campo CÓDIGO DE ACTUACIÓN indicará qué operación se pretende aplicar con el registro (pago) remitido. Sus posibles valores son:
– 11: Alta de pago. Alta de pago asociado a una prestación existente en el sistema.
– 12: Borrado de pago. Borrado físico de un pago. Se utilizará esta acción para corregir errores y borrar pagos previamente remitidos al sistema de tarjeta social digital.
– 13: Cambio de situación de pago. Se utilizará para modificar el estado de un pago previamente enviado (campo SITUACIÓN PAGO).
Dado que la carga inicial (o masiva) de pagos es un proceso muy costoso que pretende agilizar la carga de una gran cantidad de información en el sistema, únicamente permitirá acciones de tipo Alta de pago (11).
Por el contrario, el proceso de carga diaria permite utilizar todas las acciones que aquí se detallan.
Alta de pago (código de actuación 11).
Se utilizará para dar de alta un nuevo pago para una prestación existente en el sistema. La entidad deberá aportar los datos referentes al pago.
Se remitirán todos los pagos individuales realizados por la entidad gestora de la prestación. La fecha de inicio y fin del pago corresponderán a las fechas de devengo de ese pago. Si la prestación tiene carácter mensual se enviará un registro de pago por cada nómina.
Validaciones a aplicar.
– La obligatoriedad de los campos a aportar en un registro de Alta de pago vienen detallados en la tabla del apartado 5.2.2.
– Si la prestación referenciada en el alta del pago (por el campo CLAVE PROPIA ENTIDAD) no existe en el sistema se rechazará la operación.
– Solo la entidad que dio de alta la prestación podrá asociar pagos a la misma.
– El campo IDENTIFICADOR PAGO SUCESIVO solo será obligatorio para CLASE DE PAGO «06» (Liquidación por revisión de la prestación), «12» (Atrasos) o «21» (Devolución). Se deberá utilizar para identificar los pagos sucesivos que debe realizar la propia entidad gestora de forma secuencial cuando envía un segundo, tercer pago o sucesivos pagos con la misma clave propia entidad, mismo tipo de pago y mismo periodo.
Borrado de pago (código de actuación 12).
Se utilizará para borrar un pago. Esta acción está destinada a eliminar registros de pagos erróneos. Por tanto, conllevará el borrado físico del pago.
Validaciones a aplicar.
– La obligatoriedad de los campos a aportar en un registro de borrado de pago vienen detallados en la tabla del apartado 5.2.2.
– Si la prestación referenciada en el borrado del pago (por el campo CLAVE PROPIA ENTIDAD) no existe en el sistema se rechazará la operación.
– Solo la entidad que dio de alta el pago podrá borrar dicho pago.
– Para identificar el pago que se desea borrar se utilizarán todos los datos obligatorios. Es decir, si no se especifican en el movimiento de borrado los mismos datos que se encuentran en el sistema no se eliminará el pago.
Cambio de situación de pago (código de actuación 13).
Esta acción tiene como objeto el cambio de situación de un pago que se estaba percibiendo y por alguna razón se desea cambiar su situación. Esta acción se utilizará generalmente para indicar si un pago está «Pagado» o «No pagado».
Validaciones a aplicar.
– La obligatoriedad de los campos a aportar en un registro de cambio de situación de pago vienen detallados en la tabla del apartado 5.2.2.
– Si la prestación referenciada en el cambio de situación del pago (por el campo clave propia entidad) no existe en el sistema se rechazará la operación.
– Solo la entidad que dio de alta el pago podrá cambiar la situación de dicho pago.
– Para identificar el pago que se desea modificar se utilizarán todos los datos obligatorios. Es decir, si no se especifican en el movimiento de cambio de estado los mismos datos que se encuentran en el sistema (excepto situación de pago que es el valor que se pretende cambiar) no se modificara el estado pago.
Obligatoriedad de campos.
En esta tabla se presenta la información obligatoria que se deberá remitir para cada tipo de acción:
Fichero de situaciones subjetivas.
A continuación de detallará el formato del fichero de SITUACIONES SUBJETIVAS. Según se ha explicado anteriormente, la estructura de este fichero contendrá 1 registro de cabecera, N registros de datos y 1 registro de pie.
Es importante destacar que este formato será el que se utilice tanto para cargas iniciales como para cargas diarias.
Los volúmenes máximos que se podrán utilizar son los siguientes:
Registro de cabecera.
Registro de datos (situación subjetiva).
Tipo situación subjetiva 01: Familia numerosa.
Tipo situación subjetiva 02: Grado de discapacidad reconocido.
Tipo situación subjetiva 03: Grado de dependencia reconocido.
Tipo situación subjetiva 04: Demandante de empleo.
Tipo situación subjetiva 05: Garantía juvenil.
Tipo situación subjetiva 07: Autónomos.
Registro de pie.
Validaciones generales.
Campos numéricos.
Todos los campos numéricos (representados con una N en la columna Tipo de la tabla anterior) deberán ir ajustados a la derecha.
En el caso de no llegar a la longitud definida se deberán rellenar con ceros por la izquierda.
Si un campo numérico no tiene contenido se deberá rellenar a ceros.
Campos alfanuméricos.
Todos los campos alfanuméricos (representados con una A en la columna Tipo de la tabla anterior) deberán ir ajustados a la izquierda.
En el caso de no llegar a la longitud definida se deberán rellenar con espacios por la derecha.
Campos fecha.
Los campos fecha se consideran siempre numéricos (aparecen con tipo N en la tabla anterior) de 8 posiciones.
Todos los campos fecha requieren el formato AAAAMMDD.
Apartado datos identificativos de la persona.
Este apartado es clave para identificar unívocamente a la persona de la situación subjetiva. Para ello se utilizará el campo IDENTIFICATIVO, que representa el Indicador de Persona Física (IPF), según se detalla a continuación:
– La primera posición del campo identifica el tipo de IPF, siendo válidos los valores siguientes:
• 1: DNI.
• 6: NIE.
• 9: IPF ficticio. Solo para españoles menores de 14 años.
– Las posiciones dos a once se formatearán según el tipo de IPF:
• 1: DNI: Las primeras diez contendrán el número de DNI con ceros a la izquierda y la última contendrá la letra del DNI.
• 6: NIE: Las primeras diez contendrán el número de NIE (normalmente empezará por 0X, 0Y o 0Z) y la última contendrá la letra del NIE.
• 9: IPF ficticio:
○ Las posiciones dos a tres contendrán las dos primeras letras del primer apellido (sin partículas)
○ Las posiciones cuatro a cinco contendrán las dos primeras letras del segundo apellido (sin partículas). Si no existiera segundo apellido se remitirán tres guiones medios «—».
○ Las posiciones seis a siete contendrán los dos últimos caracteres del año de nacimiento.
○ Las posiciones ocho a nueve contendrán el mes de nacimiento
○ Las posiciones diez a once contendrán el día de nacimiento
○ Las posiciones doce a quince vendrán a ceros (salvo que se conozcan la duplicidad y el desdoblamiento de Afiliación).
○ En el anexo 40.1 se explica con mayor detalle la forma de crear estos IPFs.
– Las posiciones doce a quince representan la duplicidad de ese identificador y su desdoblamiento, conceptos manejados en Afiliación para IPFs repetidos.
• Para los tipos 1, 6 y 9 se completarán si se conocen. En caso de no conocerse, se enviarán a ceros.
– Para los IPF de tipo 9 se validará que su nacionalidad (campo NACIONALIDAD) sea española.
El campo OTRO IDENTIFICATIVO tiene el mismo formato que el campo IDENTIFICATIVO. Representa un IPF y solo se utilizará para los casos en los que se desee informar de un cambio de un IPF previamente informado (típico uso de extranjeros que tienen IPF de tipo 6 y al conseguir nacionalidad española cambian su IPF a uno de tipo 1).
El APELLIDO SEGUNDO si no se conoce deberá contener «—».
La FECHA DE NACIMIENTO es obligatoria y no aceptará valores menores a 19000101.
Apartado otros datos personales.
El campo NACIONALIDAD se completará en base a la codificación ISO 3166 numérica. Además se aceptarán los valores:
– 952-APÁTRIDAS.
– 953-PAÍS DESCONOCIDO.
El campo INDICADOR DE DATOS PROTEGIDOS hace referencia a una especial protección para aquellos ciudadanos que la hayan solicitado expresamente ante la administración correspondiente. Sus valores podrán ser:
– P-PROTEGIDOS.
– D-Desproteger. (NO REQUIERE PROTECCIÓN).
– Vacío-NO REQUIERE PROTECCIÓN.
Apartado datos de residencia.
En este bloque se remitirá la dirección de la persona que tiene asociada la situación subjetiva. El tratamiento es diferente en función de si es un domicilio nacional o extranjero.
El campo PAÍS DE RESIDENCIA determinará si el domicilio es nacional o extranjero. Se introducirá el código 953 si se desconoce.
Para DOMICILIO NACIONAL (código país 724) se validarán los siguientes campos:
– PROVINCIA DE RESIDENCIA. Será siempre obligatorio. Si se desconoce existe el valor 99 PROVINCIA DESCONOCIDA.
– CÓDIGO MUNICIPIO DE RESIDENCIA. Código del municipio de residencia de la persona perceptora/beneficiaria de la prestación. Los valores permitidos serán los del Código INE, los códigos admitidos se encuentran en esta dirección: http://www.ine.es/nomen2/index.do (página nomenclátor del INE).
– NOMBRE DEL MUNICIPIO DE RESIDENCIA. Si se desconoce el código anterior, será obligatorio introducir aquí en texto la localidad de residencia. Si no se conoce, el nombre del municipio podría contener «DESCONOCIDO».
– El resto de campos no son obligatorios pero, en caso de que alguno tenga contenido se deberá cumplir la siguiente obligatoriedad:
• CÓDIGO DE VÍA (obligatorio).
• NOMBRE DE LA VÍA (obligatorio).
• NUMERO DE LA VÍA (no obligatorio).
• ESCALERA (no obligatorio).
• PUERTA (no obligatorio).
• PISO (no obligatorio).
• BLOQUE (no obligatorio).
• CÓDIGO POSTAL (obligatorio).
Para DOMICILIO EXTRANJERO (código país distinto de 724 y 953), se enviará en modo texto la dirección extranjera a través de los siguientes campos:
– DIRECCIÓN DE RESIDENCIA 1. Datos de la dirección.
– DIRECCIÓN DE RESIDENCIA 2. Datos adicionales por si no fuese suficiente el campo anterior.
– LOCALIDAD DE RESIDENCIA EXTRANJERA. Nombre de la localidad extranjera. Si se desconoce deberá contener «DESCONOCIDO».
Tipo de situación subjetiva 02: Grado de discapacidad reconocido.
Si la persona está afectada por más de un tipo de discapacidad de las enumeradas en los códigos del anexo 10 del protocolo (02 Discapacidad física, 03 Discapacidad mental, 04 Discapacidad intelectual, y 05 Discapacidad sensorial), se enviará en el campo tipo de discapacidad el código 06 Plurideficiencia.
El campo DIFICULTADES DE MOVILIDAD que este tipo de situación subjetiva lleva asociado, hace referencia a la valoración regulada en el anexo 2, capítulo I del Real Decreto 1971/1999, de 23 de diciembre, de procedimiento para el reconocimiento, declaración y calificación del grado de minusvalía, con la información contenida en el primer cuadro del citado anexo 2.
Igualmente, el campo LIMITACIÓN DE MOVILIDAD se cumplimentará con el valor obtenido de acuerdo al segundo cuadro del anexo 2, capítulo 1 del citado Real Decreto 1971/1999.
Tipo de situación subjetiva 03: Grado de dependencia reconocido.
Una vez introducido el valor S en el campo indicador de dependencia, en el campo grado de dependencia reconocido se deberá introducir alguno de los valores del anexo 11 del protocolo (01 Moderada, 02 Severa o 03 Gran Dependencia). Estos grados vienen recogidos en el artículo 27 de la Ley 39/2006, de 14 de diciembre, de Promoción de la Autonomía Personal y Atención a las personas en situación de dependencia.
Tipos de acciones disponibles en situaciones subjetivas.
Una vez descrito y formato del fichero de situaciones subjetivas y validaciones básicas, procedemos a explicar las acciones disponibles que, a través del fichero, las entidades podrán remitir al INSS.
El campo CÓDIGO DE ACTUACIÓN indicará qué operación se pretende aplicar con el registro (situación subjetiva) remitido. Sus posibles valores son:
– 21: Alta de situación subjetiva. Alta de una nueva situación subjetiva para una persona, dentro del sistema de Tarjeta Social Digital
– 22: Modificación de situación subjetiva. Modificación de datos de una situación subjetiva existente (previamente cargada) en el sistema de Tarjeta Social Digital. Un uso típico podría ser una situación subjetiva que ha estado vigente durante un periodo de tiempo y en un momento dado deja de estar vigente.
– 23: Borrado de situación subjetiva. Borrado físico de una situación subjetiva. Se utilizará esta acción para borrar situaciones subjetivas previamente remitidas al sistema de Tarjeta Social Digital.
– 25: Cambio de identificador de persona. Cambio en el identificador de una persona existente en el sistema de tarjeta social digital. Uso típico de campo de tipo de IPF de 6 (extranjero) a 1 (nacional).
– 26: Variación de datos personales. Variación de datos personales de una persona existente en el sistema de Tarjeta Social Digital.
Dado que la carga inicial (o masiva) de situaciones subjetivas es un proceso muy costoso que pretende agilizar la carga de una gran cantidad de información en el sistema, únicamente permitirá acciones de tipo Alta de situación subjetiva (21).
Por el contrario, el proceso de carga diaria permite utilizar todas las acciones que aquí se detallan.
Alta de situación subjetiva (código de actuación 21).
Se utilizará para dar de alta una nueva situación subjetiva a una persona. Se aportará la información referente a los datos personales, el domicilio de residencia, el tipo de situación subjetiva y todos los valores de los atributos asociados a dicha situación.
Validaciones a aplicar.
– La obligatoriedad de los campos a aportar en un registro de Alta de Situación Subjetiva vienen detallados en la tabla del apartado 6.2.4.
– Si la persona que se recibe asociada a la situación subjetiva no se encuentra en TSD, se procederá con su alta.
– Si la persona asociada ya se encuentra en el sistema (mismo IDENTIFICADOR) no se le dará de alta. Se asociará a la persona encontrada la nueva situación subjetiva siempre y cuando se detecte que se trata de la misma persona. Para ello se aplicará el algoritmo de coincidencia del 80 % de los datos personales (nombre, apellidos y fecha de nacimiento). En el caso de que, aun siendo un identificador encontrado, no coincidan los datos personales (menos del 80 % de similitud) se devolverá error de identificación.
– La situación subjetiva se identificará en el sistema en base al tipo de situación y al identificador de la persona perceptora y la clave propia entidad. En caso de que esa persona ya tuviese la misma situación subjetiva vigente se rechazará la carga.
– No se admitirán movimientos de alta de prestación asociados a un identificador de persona que previamente haya sido modificado a través de un movimiento de CAMBIO DE IDENTIFICACIÓN DE PERSONA (05). En estos casos, en el fichero de respuesta se indicará el error 31034 (Referencia al identificativo antiguo en el movimiento) y se devolverá a la entidad gestora a nivel informativo cual es el identificador actual de persona dada de alta en TSD en el campo OTRO IDENTIFICATIVO.
– Se modificará el domicilio siempre que se consideren los datos igual o más completos que los ya cargados en TSD. Teniendo en cuenta los campos «País», «Nombre municipio» y «Nombre vía».
– Solo para el proceso de carga inicial o masiva, no se permitirá dentro del mismo fichero el envío de alta de situaciones subjetivas asociadas al mismo identificativo (IPF) con apellidos y nombres distintos. Esto es debido a que las validaciones que obligan estas situaciones ralentizarían el proceso masivo. En caso de detectarse esta situación, se devolverá error con el código 12033 (Identificador duplic