Categoría: Normativas

a 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 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 (código de actuación 22).
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 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.
– 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.
– 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, apellidos y fecha de nacimiento) 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 (código de actuación 23).
Se utilizará para borrar una situación subjetiva. Su sentido será eliminar altas que se remitieron por error. Conlleva un borrado físico de la situación. AVISO: Si lo que pretende es modificar la vigencia de la situación subjetiva deberá realizarse a través de un código de actuación 22 (MODIFICACIÓN DE LA SITUACIÓN SUBJETIVA).
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á.
– 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 (código de actuación 25).
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 el identificador antiguo, el identificador nuevo, compuesto al menos por tipo y número de documento y también los datos personales (nombre, apellidos y fecha de nacimiento) 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 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: 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 (código de actuación 26).
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 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, 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 localidad» y «Nombre vía». Si los datos de domicilio no se modifican 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:
Anexo 1. Códigos de actuación.
Anexo 2. Estado civil.
Anexo 3. Código de vía.
Anexo 4. Prestaciones.
Si la prestación que quiere enviar no se encuentra en el catálogo, por favor solicite su creación a incidencias.tsd@seg-social.es, anexando la normativa reguladora de la misma.
Prestaciones de entidades de ámbito estatal.
Prestaciones de entidades de ámbito autonómico.
Prestaciones de entidades de ámbito local.
Prestaciones de las mutuas colaboradoras con la Seguridad Social.
Anexo 5. Tipos de importe.
Anexo 6. Clase de pago.
Anexo 7. Situación de pago.
Anexo 8. Tipo de situación subjetiva.
Anexo 9. Tipo de familia numerosa.
Anexo 10. Tipo de discapacidad reconocida.
Anexo 11. Tipo de dependencia reconocida.
Anexo 12. Tipo de demanda de empleo.
Anexo 13. Tipo de complemento.
Anexo 14. Subtipo de prestación.
El subtipo de prestación siempre irá siempre estará relacionado con un tipo de prestación según se muestra en la siguiente tabla:
Anexo 15. Tipo de deducción.
Anexo 20. Errores.
Anexo 20.1 Errores de formato.
Anexo 20.1.1 Errores formato en Prestaciones y Pagos.
Anexo 20.1.2 Errores formato en Situaciones Subjetivas.
Anexo 20.2 Errores en la carga de datos.
Anexo 20.2.1 Errores carga de datos en Prestaciones y Pagos.
Anexo 20.2.2 Errores carga de datos en Situaciones Subjetivas.
Anexo 30. Carga de históricos.
Con la finalidad de que las entidades gestoras puedan consultar las prestaciones que ya no están de alta, bien por haber causado baja una vez incorporadas a TSD o bien porque ya no estaban de alta en el momento de realizar la carga inicial de prestaciones en TSD, se ha previsto la creación de un histórico de prestaciones y pagos.
Las prestaciones que se cargaron en alta en TSD y han pasado a la situación de baja se integran en el Histórico de TSD de forma automática. Sin embargo, para completar este histórico está previsto que se reciban las prestaciones reconocidas a partir de 1 de enero de 2020 que no se incorporaron a TSD porque cuando se recibió la carga inicial ya se encontraban de baja.
Para completar el histórico de prestaciones y pagos se podrán enviar a TSD los datos de las prestaciones citadas en el párrafo anterior (reconocidas a partir de 2020 que no se enviaron en la carga inicial por estar en esa fecha ya de baja) y sus correspondientes pagos.
El envío de la información del histórico se realizará en el siguiente orden:
1.º Envío inicial de las prestaciones.
Se podrá realizar, dependiendo del volumen, con una carga inicial (que permite el envío de hasta 9.500.000 registros) o una carga diaria (100.000 registros).
Las prestaciones se comunicarán con el código de actuación 01 «Alta de prestación». Se realizarán las mismas validaciones que las establecidas para las altas recogidas en el punto 4.2.1 Alta de prestaciones.
En la cabecera del fichero de envío se deberá marcar «H» en el campo «Identificación información histórico».
Deberá remitirse con la siguiente información:
– Campo «Situación actual»: A (alta).
– Campo «Fecha de situación»: fecha del reconocimiento inicial de la prestación, es decir, su fecha de efectos.
2.º Modificación del estado de las prestaciones a baja.
Se deberá realizar con ficheros de carga diarios (100.000 registros).
Se remitirán con el código de actuación 04 «Cambio de situación de prestación» las bajas de las prestaciones antes comunicadas. Se realizarán las mismas validaciones que las establecidas para los cambio de situación de una prestación las recogidas en el punto 4.2.4 Cambio de situación de una prestación.
En la cabecera del fichero de envío se deberá marcar «H» en el campo «Identificación información histórico».
Deberá remitirse con la siguiente información:
– Campo «Situación actual»: B (baja).
– Campo «Fecha de situación»: fecha en la que se produjo la extinción de la prestación.
3.º Envío de los pagos asociados a las prestaciones.
Se podrá realizar, dependiendo del volumen, con una carga inicial (22.500.000 registros) o con una carga diaria (250.000 registros).
En la cabecera del fichero de envío se deberá marcar «H» en el campo «Identificación información histórico».
Se remitirán con el código de actuación 11 «alta de pago» los pagos asociados a las prestaciones anteriores. Se realizarán las mismas validaciones que las las establecidas para el alta de pagos, recogidas en el punto 5.2.1 alta de pago.
Anexo 40. Otras validaciones.
Anexo 40.1 Formación IPF ficticio (tipo 9).
Este tipo de IPF solo se utilizará para españoles menores de catorce años que carezcan de DNI o NIE. Se creará de la siguiente forma:
– Primera posición, «9».
– 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).
Es importante destacar que los dos apellidos que se utilizarán para la creación de este valor deben desestimar partículas, vocales con diéresis (se sustituyen por la vocal correspondiente) y tildes.
El juego de caracteres válidos que pueden aparecer en el IPF ficticio son: A, B, C, D, E, F, G, H, I, J, K, L, M, N, Ñ, O, P, Q, R, S, T, U, V, W, X, Y, Z, Ç y –.
Las partículas que deben eliminarse serán: «DA», «DAS», «DE», «DEL», «DES», «DELA», «DELS», «DES», «DI», «DO», «DOS», «DU», « Y», «LA», «LE», «LES», «LAS», «LOS», «SA».
Ejemplo: Primer apellido: De Miguel; Segundo apellido: Fernández: Fecha nacimiento: 1990-06-12.
IPF ficticio: 9-MIFE900612.
Don/doña .........................................., en representación de la Entidad Local de XXXX, nombrado por ................................... y en ejercicio de sus competencias recogidas en ............................................
Manifiesta:
Que con fecha ....... de .................................... de 2022, el INSS y la FEMP suscribieron el «Convenio entre el Instituto Nacional de la Seguridad Social y la Federación Española de Municipios y Provincias en materia de intercambio de información y colaboración de las Entidades Locales, para el impulso y consolidación del sistema Tarjeta Social Digital.»
Que mediante la suscripción del presente acto de adhesión, la Entidad Local ........................................, expresa su voluntad de adherirse a dicho Convenio, y acepta de forma incondicionada la totalidad de sus cláusulas en cuanto le sea de aplicación.
La adhesión tiene efectos desde la fecha de inscripción del presente acto de adhesión en el Registro Electrónico estatal de Órganos e Instrumentos de Cooperación del sector público estatal, previa firma, y perdurará durante el periodo de vigencia del citado convenio.
Asimismo, la Entidad Local que se adhiere declara bajo su responsabilidad que su política de seguridad de la información se rige por lo dispuesto en el Real Decreto 3/2010, de 8 de enero, por el que se regula el Esquema Nacional de Seguridad en el ámbito de la Administración Electrónica, el Reglamento (UE) 2016/679 del Parlamento Europeo y del Consejo de 27 de abril de 2016 y la Ley Orgánica 3/2018, de 5 de diciembre, de Protección de Datos Personales y garantía de los derechos digitales