Categoría: Normativas

gador utilizado y versión./Versión del JRE.
– Si utiliza IFI: Fichero «ClienteIFI.log» de la carpeta «log» de su instalación
3.8 Enlaces y recursos.
4.1 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:
4.1.1 Registro de cabecera.
4.1.2 Registro de datos (prestación).
4.1.3 Registro de pie.
4.1.4 Validaciones generales.
4.1.4.1 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.
4.1.4.2 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.
4.1.4.3 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.
4.1.4.4 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.
4.1.4.5 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.
4.1.4.6 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».
4.1.4.7 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.
4.2 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.
4.2.1 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.
4.2.1.1 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»).
4.2.2 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).
4.2.2.1 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.
4.2.3 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.
4.2.3.1 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.
4.2.4 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).
4.2.4.1 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.
4.2.5 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.
4.2.5.1 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.
4.2.6 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.
4.2.6.1 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».
4.2.7 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)
4.2.7.1 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.
4.2.8 Obligatoriedad de campos.
En esta tabla se presenta la información obligatoria que se deberá remitir para cada tipo de acción:
5.1 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:
5.1.1 Registro de cabecera.
5.1.2 Registro de datos (Pago).
5.1.3 Registro de pie.
5.1.4 Validaciones generales.
5.1.4.1 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.
5.1.4.2 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.
5.1.4.3 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.
5.1.4.4 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.
5.2 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.
5.2.1 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.
5.2.1.1 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.
5.2.2 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.
5.2.2.1 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.
5.2.3 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».
5.2.3.1 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.
5.2.4 Obligatoriedad de campos.
En esta tabla se presenta la información obligatoria que se deberá remitir para cada tipo de acción:
6.1 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:
6.1.1 Registro de cabecera.
6.1.2 Registro de datos (situación subjetiva).
6.1.2.1 Tipo situación subjetiva 01: Familia numerosa.
6.1.2.2 Tipo situación subjetiva 02: Grado de discapacidad reconocido.
6.1.2.3 Tipo situación subjetiva 03: Grado de dependencia reconocido.
6.1.2.4 Tipo situación subjetiva 04: Demandante de empleo.
6.1.2.5 Tipo situación subjetiva 05: Garantía juvenil.
6.1.2.6 Tipo situación subjetiva 07: Autónomos.
6.1.3 Registro de pie.
6.1.4 Validaciones generales.
6.1.4.1 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.
6.1.4.2 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.
6.1.4.3 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.
6.1.4.4 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.
6.1.4.5 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.
6.1.4.6 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».
6.1.4.7. 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.
6.1.4.8 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.
6.2 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.
6.2.1 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.
6.2.1.1 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 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.
6.2.2 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.).
6.2.2.1 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.
6.2.3 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).
6.2.3.1 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.
6.2.4 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.
6.2.4.1 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 re