Common use of Validaciones a aplicar Clause in Contracts

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. cve: BOE-A-2022-21130 Verificable en xxxxx://xxx.xxx.xx – Si el registro que se pretende crear es de la prestación Ingreso Xxxxxx Xxxxx (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»).

Validaciones a aplicar. cve: BOE-A-2022-21130 Verificable en xxxxx://xxx.xxx.xx – La obligatoriedad de los campos a aportar en un registro de Alta Cambio de prestación 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 prestación ya persona perceptora no se encuentra dada de alta en el sistema (el identificador antiguo no existe en TSD) se rechazarárechazará la acción. – Si El identificador de persona podrá ser modificado por la FECHA DE SITUACIÓN entidad gestora que dio 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á alta a la persona encontrada la nueva prestación recibida siempre y cuando se detecte o por cualquier otra. – Se comprobará que se trata de la misma persona. Para ello se aplicará el algoritmo de coincidencia del 80% de los datos personales fijos (nombre, apellidos y nombre 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 admitirán movimientos 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 prestación asociados nuevas prestaciones o situaciones subjetivas asociadas a un identificador de persona este identificativo. El error 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 utiliza para marcar esta circunstancia es: 31034 (Referencia al identificativo antiguo en el movimiento) y . Asociado a este error se devolverá a la entidad gestora gestora, a nivel informativo cual es informativo, el identificador actual de persona dada de alta en TSD nuevo identificativo en el campo OTRO IDENTIFICATIVO. – Se modificará • 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 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 nuevo identificativo 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 OTRO IDENTIFICATIVO). Si fuese necesario tramitar su alta se deberá remitir a través de una carga diaria. cve: BOE-A-2022-21130 Verificable en xxxxx://xxx.xxx.xx – Si el registro que se pretende crear es de la prestación Ingreso Xxxxxx Xxxxx (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»).

Validaciones a aplicar. La obligatoriedad de los campos a aportar en un registro de Alta Cambio de prestación identificación de persona vienen detallados en la tabla del apartado 4.2.86.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 prestación ya persona no 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 (el identificador antiguo no existe en más de 3 meses la fecha de carga TSD) se rechazará el altala acción. – Si • El identificador de persona podrá ser modificado por la persona perceptora entidad gestora que dio de la prestación ya se encuentra en el sistema (mismo IDENTIFICADOR) no se le dará de alta. Se asociará alta a la persona encontrada la nueva prestación recibida siempre y cuando se detecte o por cualquier otra. • Se comprobará que se trata de la misma persona. Para ello se aplicará el algoritmo de coincidencia del 80% de los datos personales fijos (nombre, apellidos y nombre 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 admitirán movimientos guardará el identificador antiguo en TSD asociado al identificador actual. • Cuando se produzca un cambio de identificación: o A partir de ese momento no se permitirá el alta de prestación asociados nuevas prestaciones o situaciones subjetivas asociadas a un identificador de persona este identificativo. El error 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 (utiliza para marcar esta circunstancia es: 32034 Referencia al identificativo antiguo en el movimiento) y . Asociado a este error se devolverá a la entidad gestora gestora, a nivel informativo cual es informativo, el identificador actual de persona dada de alta en TSD nuevo identificativo en el campo OTRO IDENTIFICATIVO. – o 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. 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 MOVIL 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. • 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. o Se podrá solicitar la protección de una persona indicando el valor ‘P’ en el indicador de protección. o 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 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 los datos 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, domicilio no se permitirá dentro del mismo fichero modifican se generará el envío código de alta aviso “92040: AVISO: Aceptado el cambio excepto en los datos de prestaciones asociadas al mismo identificativo (IPF) con apellidos y nombres distintos. Esto es debido a DOMICILIO ya que las validaciones que obligan estas situaciones ralentizarían el proceso masivolos datos existentes son más completos”. En caso de detectarse esta situación, tabla 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 (presenta la información obligatoria que tendrán el mismo IDENTIFICATIVO). Si fuese necesario tramitar su alta se deberá remitir a través de una carga diaria. cve: BOE-A-2022-21130 Verificable en xxxxx://xxx.xxx.xx – Si el registro que se pretende crear es de la prestación Ingreso Xxxxxx Xxxxx (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 para cada 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 acción: CÓDIGO DE ACTUACIÓN 21 22 23 25 26 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»).GESTORA S S S S S TIPO DE DOCUMENTO S S S S S

Validaciones a aplicar. La obligatoriedad de los campos a aportar en un registro de Alta Modificación de prestación Situación Subjetiva vienen detallados en la tabla del apartado 4.2.86.2.4. – En este caso, los campos marcados como no obligatorios si se completan no se validarán. • Si la prestación ya 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. 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 (MODIFICACION DE LA SITUACION SUBJETIVA) • 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 se rechazará. – Si para 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 persona asociada, se rechazará el altamovimiento de borrado. – • Si la persona perceptora de asociada a la prestación ya situación subjetiva que se pretende borrar no se encuentra en el sistema (mismo IDENTIFICADOR) 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 le dará eliminaran tanto los datos personales como los de altadomicilio. Se asociará a utilizará para modificar el identificador de una persona previamente enviada al sistema TSD por tener una situación subjetiva asociada. Se aportará por la persona encontrada la nueva prestación recibida siempre entidad el identificador antiguo, el identificador nuevo, compuesto al menos por tipo y cuando se detecte que se trata número de la misma persona. Para ello se aplicará el algoritmo de coincidencia del 80% de documento y también los datos personales (nombre, 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. cve: BOE-A-2022-21130 Verificable en xxxxx://xxx.xxx.xx – Si el registro que se pretende crear es de la prestación Ingreso Xxxxxx Xxxxx (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»)validación.

Validaciones a aplicar. La obligatoriedad de los campos a aportar en un registro de Alta Cambio de prestación identificación de persona vienen detallados en la tabla del apartado 4.2.86.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 prestación ya persona no se encuentra dada de alta en el sistema (el identificador antiguo no existe en TSD) se rechazarárechazará la acción. – Si El identificador de persona podrá ser modificado por la FECHA DE SITUACIÓN entidad gestora que dio 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á alta a la persona encontrada la nueva prestación recibida siempre y cuando se detecte o por cualquier otra. – Se comprobará que se trata de la misma persona. Para ello se aplicará el algoritmo de coincidencia del 80% de los datos personales fijos (nombre, apellidos y nombre y fecha de nacimiento). – No se admitirán movimientos ) coinciden al 80% con los almacenados en la BBDD 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ónno coincidir al 80% o más, se devolverá error con 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 código 11033 (Identificador duplicado con diferente valor en Apellidos y/o nombre en el fichero cambio automático de entradala nacionalidad a «Española». No puede haber personas con DNI y con nacionalidad extranjera. – A efectos de control y validaciones posteriores, se contempla este caso guardará el identificador antiguo en carga inicial)TSD asociado al identificador actual. Esta situación – Cuando 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 produzca un cambio de una carga diaria. identificación: cve: BOE-A-2022-21130 Verificable en xxxxx://xxx.xxx.xx – Si el registro que • A partir de ese momento no se pretende crear es de la prestación Ingreso Xxxxxx Xxxxx (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 permitirá el alta de un beneficiario, 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 caso de que movimiento. Asociado a este error se devolverá a la prestación no exista (necesaria entidad gestora, a nivel informativo, 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 nuevo identificativo en el campo CLAVE PRESTACIÓN, según OTRO IDENTIFICATIVO. • Sin embargo se detalla en el ANEXO 7.4permitirán los códigos de actuación 22 (Modificación de una situación subjetiva) aunque nos lleguen asociados al identificativo antiguo. En el caso de remitir una prestación que no corresponde con la entidadAunque se hayan modificado los datos solicitados, se devolverá este código de aviso (no es un error (código 11282 «El Campo CLAVE PRESTACIÓN no puede ser remitido por esta entidad»)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.