Categoría: Normativas

ó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 dos 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).
– 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 y 6 se completarán si se conocen. En caso de no conocerse, se enviarán a ceros.
• Para los tipos 9, al ser un identificador autogenerado, se completarán siempre a ceros.
– 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 - APATRIDAS.
– 953 - PAIS 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 PAIS 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.
– CODIGO 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 VIA (obligatorio)
• NÚMERO DE LA VIA (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 externas 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 (extranjero) a 1 (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:
Se utilizará para dar de alta una nueva prestación en el sistema por parte de una entidad externa. Se aportará por la entidad externa 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.
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 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 (nombre y apellidos). 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.
– 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 IDENTIFICACION 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.
– Si el domicilio contiene campos con valor ‘desconocido’ y existe para esa misma persona en TSD un domicilio válido, éste no será modificado.
– Si el en el campo TIPO DE PAGO se introduce el valor U (pago único), el campo SITUACION ACTUAL debe ser ‘B’ (baja) y la FECHA SITUACION debe ser el día que se concede la prestación.
– 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.
– Para prestaciones IMV o RIS, se usará el mismo movimiento para el alta de la prestación y alta de beneficiario. El campo CLAVE PROPIA ENTIDAD será igual para titulares y beneficiarios, la diferenciación vendrá por el tipo de Perceptor (T o B). Solo se dará alta de la prestación si es titular. Si es beneficiario se dará de alta una asociación entre la prestación (que ya deberá existir por un alta previa de titular) y la persona (beneficiario). Si el campo obligatorio «número de convivientes» es superior a 1 se tendrán que recibir como datos identificativos obligatorios los de los miembros de la unidad de convivencia o familiar. (Ejemplo: si se hace constar 3 miembros, deberán enviar datos identificativos de 2 miembros además de los datos del titular).
– 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).
Modificación de prestación:
Se utilizará para modificar algún dato de una prestación almacenada en el sistema. La entidad externa identificará la prestación que quiere modificar (con el identificador de la persona y el código de prestación) y remitirá los datos del apartado de DATOS DE PRESTACION que desea modificar.
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. A nivel de importes, se podrán modificar (tanto el código como el importe) a través de este tipo de registro.
– 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 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 y apellidos) al menos en un 80 % con los almacenados en el sistema TSD. Si la no coincidencia está motivada por un cambio de identificador (la persona cambió de identificador) 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 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), se deberán aportar obligatoriamente los campos NUMERO CONVIVIENTES, PERCEPTOR y ESTADO PERCEPTOR. Esto se realizará siempre a la prestación IMV o RIS del perceptor titular (no de los beneficiarios). Es decir, los datos personales que acompañarán al registro deben ser los del titular de la prestación.
Borrado de prestación:
Se utilizará para BORRAR una prestación. Su sentido será el corregir altas 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 externa aportará únicamente la clave de entidad que identifica la prestación unido a los datos identificativos del envío, de la entidad gestora y del perceptor de 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 de la prestación.
– 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:
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 externa se reducirán a identificar la prestación que se quiere modificar, el nuevo estado y su fecha.
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.
– 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 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 y apellidos) al menos en un 80% con los almacenados en el sistema TSD. Si la no coincidencia está motivada por un cambio de identificador (la persona cambió de identificador) 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. El campo PERCEPTOR en este caso tendrá valor B (Beneficiario) y se utilizará el campo ESTADO PERCEPTOR para su modificación.
Cambio de identificación de persona:
Se utilizará para modificar el identificador de persona perceptora de prestación que se encuentre dada de alta en la BBDD de TSD.
Se aportará por la entidad externa 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) 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.
– Se admiten cambios de identificador de tipo NIE a NIF, pero no de tipo NIF a NIE. También se permite cambio de tipos distintos a 1 y 6 a NIE o a NIF.
– El cambio de identificador de tipo NIE a NIF implica el cambio automático de la nacionalidad a «Española». No puede haber personas con NIF 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:
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 aportará por la entidad la información referente a los datos personales y domicilio de residencia.
Esta operación también podrá ser utilizara para proteger (P) o desproteger (D) personas atendiendo a su INDICADOR DE CONFIDENCIALIDAD.
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 y apellidos) 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.
– Si el domicilio contiene campos con valor «desconocido» y existe en TSD un domicilio válido, éste no será modificado. 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:
Este movimiento estará destinado a realizar traspasos de prestaciones entre personas 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.
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 identificación de la prestación y los datos del nuevo perceptor.
– 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 eliminara de TSD.
– Si la prestación que se pretende traspasar es Ingreso Mínimo Vital (IMV, código 1230102) o Renta de Integración Social (RIS, código 560202), se rechazará directamente el movimiento.
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 externas 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 SITUACION 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.
Se utilizará para dar de alta un nuevo pago para una prestación existente en el sistema. La entidad externa deberá aportar los datos referentes al pago.
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.
– La limitación en el periodo del pago que se va a informar se establece en 5 años.
Borrado de pago.
Se utilizará para borrar un pago. Esta acción está destinada a corregir altas de pago erróneas. Por tanto una baja de un pago 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.
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.
– Teniendo en cuenta que solo se van a almacenar los pagos referentes al año en curso y a los 5 años anteriores, solo se podrán cambiar el estado de los pagos contenidos en este periodo.
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 06: Nivel de rentas.
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 dos 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).
– 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 y 6 se completarán si se conocen. En caso de no conocerse, se enviarán a ceros.
• Para los tipos 9, al ser un identificador autogenerado, se completarán siempre a ceros.
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 - APATRIDAS
– 953 - PAIS 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 PAIS 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.
– CODIGO 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:
• CODIGO DE VÍA (obligatorio).
• NOMBRE DE LA VIA (obligatorio).
• NUMERO DE LA VIA (no obligatorio).
• ESCALERA (no obligatorio).
• PUERTA (no obligatorio).
• PISO (no obligatorio).
• BLOQUE (no obligatorio).
• CODIGO 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:
– DIRECCION DE RESIDENCIA 1. Datos de la dirección.
– DIRECCION 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’.
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 externas podrán remitir al INSS.
El campo CODIGO DE ACTUACION 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
– 23: Borrado de situación subjetiva. Borrado físico de una situación subjetiva. Se utilizará esta acción para corregir errores y 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 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.
Se utilizará para dar de alta una nueva situación subjetiva a una persona. Se aportará por el proveedor 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 y apellidos). 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. En el caso de que la situación subjetiva que se pretende dar de alta ya se encontrase asociada a esa misma persona se devolverá un error (una misma persona no puede estar asociada varias veces la misma situación subjetiva).
– 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 IDENTIFICACION 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.
– Si el domicilio remitido contiene campos con valor ‘desconocido’ y existe para esa misma persona en TSD un domicilio válido, éste no será modificado.
– 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 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.
Modificación de situación subjetiva.
Se utilizará para modificar el estado de vigencia de una situación subjetiva almacenada en TSD así como los atributos de dicha situación subjetiva. Se aportará por la entidad la información referente a los datos personales, el tipo de situación subjetiva y:
– Si se quiere establecer a «no-vigente» una situación subjetiva, se remitirá ‘N’ como valor para el indicador de vigencia ignorando el contenido de los demás atributos recibidos.
– Si se quiere establecer a «si-vigente» una situación subjetiva, se remitirá ‘S’ como valor para el indicador de vigencia además de todos los valores de los demás atributos que reemplazarán a los existentes.
– Si se quiere alterar el valor de alguno de los atributos de una situación subjetiva, se remitirá ‘S’ como valor para el indicador de vigencia además de todos los valores de los demás atributos que reemplazarán a los existentes.
Toda situación subjetiva (salvo NIVEL DERENTAS) tiene un indicador de vigencia propio que se completa siempre con posibles valores S o N. Se corresponde con el primer campo de la situación (INDICADOR DE FAMILIA NUMEROSA, INDICADOR DE GRADO DE DISCAPACIDAD RECONOCIDO, INDICADOR DE GRADO DE DEPENDENCIA RECONOCIDO, etc).
Validaciones a aplicar.
– La obligatoriedad de los campos a aportar en un registro de Modificación de Situación Subjetiva vienen detallados en la tabla del apartado 6.2.4. En este caso, los campos marcados como no obligatorios si se completan no se validarán. A nivel de importes, se podrán modificar (tanto el código como el importe) a través de este tipo de registro.
– Si la situación subjetiva no se localiza en el sistema, se rechazará la operación.
– La situación subjetiva podrá ser modificada por la entidad gestora que la dio de alta 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 situación subjetiva, se rechazará la operación. Para ello, debe coincidir su identificador y los datos personales (nombre y apellidos) al menos en un 80 % con los almacenados en el sistema TSD. Si la no coincidencia está motivada por un cambio de identificador (la persona cambió de identificador) se procesará el movimiento advirtiendo en el fichero de respuesta de esta situación e incluyendo el identificador actual asociado a la persona. Se devolverá el código de aviso 92030 «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.
Borrado de situación subjetiva.
Se utilizará para borrar una situación subjetiva. Su sentido será el corregir altas que se remitieron por error. Conlleva un borrado físico de la situación.
Validaciones a aplicar.
– La obligatoriedad de los campos a aportar en un registro de Borrado de Situación Subjetiva vienen detallados en la tabla del apartado 6.4.4. En este caso, los campos marcados como no obligatorios si se completan no se validarán.
– Si la situación subjetiva no se encuentra dada de alta en el sistema para la persona asociada, se rechazará el movimiento de borrado.
– Si la persona asociada a la situación subjetiva que se pretende borrar no se encuentra en el sistema, se rechazará. Para que no se rechace, debe coincidir su identificador y los datos personales (nombre y apellidos) al menos en un 80% con los almacenados en la BBDD de TSD.
– Solo se podrá borrar una situación subjetiva por la última entidad que la modificó.
– Si la situación subjetiva con objeto de ser eliminada es la única que tenía asociada la persona y además no tenía prestaciones registradas en el sistema, se eliminaran tanto los datos personales como los de domicilio.
Cambio de identificación de persona.
Se utilizará para modificar el identificador de una persona previamente enviada al sistema TSD por tener una situación subjetiva asociada.
Se aportará por la entidad externa 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 6.2.6. 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 de la persona y su nuevo identificador.
– Si la persona 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) 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.
– Se admiten cambios de identificador de tipo NIE a NIF, pero no de tipo NIF a NIE. También se permite cambio de tipos distintos a 1 y 6 a NIE o a NIF.
– El cambio de identificador de tipo NIE a NIF implica el cambio automático de la nacionalidad a «Española». No puede haber personas con NIF 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: 32034 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 22 (Modificación de una situación subjetiva) 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): 92030 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.
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 aportará por la entidad la información referente a los datos personales y domicilio de residencia.
Esta operación también podrá ser utilizara para proteger (P) o desproteger (D) personas atendiendo a su INDICADOR DE CONFIDENCIALIDAD.
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 6.2.6. En este caso, los campos marcados como no obligatorios si se completan no se validarán.
– Si la persona 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 persona, se rechazará la operación. Para ello, debe coincidir su identificador y los datos personales (nombre y apellidos) 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.
– Si el domicilio contiene campos con valor ‘desconocido’ y existe en TSD un domicilio válido, éste no será modificado. Se generará el código de aviso 92040: AVISO: Aceptado el cambio excepto en los datos de DOMICILIO ya que los datos existentes son más completos.
Obligatoriedad de campos.
En esta tabla se presenta la información obligatoria que se deberá remitir para cada tipo de acción:
Glosario de términos.