Enterprise Resource Planning Blogs by SAP
Get insights and updates about cloud ERP and RISE with SAP, SAP S/4HANA and SAP S/4HANA Cloud, and more enterprise management capabilities with SAP blog posts.
cancel
Showing results for 
Search instead for 
Did you mean: 
former_member183497
Active Participant
(Scroll down for the English version)

 

Hola todos,

En el último blog post, hablamos acerca del reporte Mensaje FIE, cómo ejecutarlo y tratar los absentismos de los empleados y la configuración necesaria para utilizar sus funcionalidades. Por lo tanto, en este blog post usted encuentra ejemplos de los siguientes escenarios:

  • Creación de un absentismo

  • Cuándo un absentismo es cerrado

  • Colisión de absentismos

  • Absentismo con diferente tipología

  • Anulación de un parte en un absentismo guardado

  • Recaída de un absentismo

  • Absentismo existente con diferente fecha de fin

  • Absentismo de pago directo

  • Utilización de la BAdI para ajuste de valores relacionados con entradas de infotipo


 

Prerrequisitos

Usted ha implementado la siguientes SAP Notes:

 

Creación de un nuevo absentismo

Al ejecutar el reporte, se nota que el fichero contiene un absentismo que todavía no existe en el sistema. Entonces, se sugiere la creación de un nuevo absentismo a través del ícono de adición.


Al ejecutar el script generado, se creará el absentismo en el infotipo Absentismos (IT2001).


 

Un absentismo es cerrado

Hay un absentismo guardado en el sistema sin fecha de fin, pero al ejecutar el reporte para el fichero, el sistema indica una fecha. Por lo tanto, es necesario que se cierre el absentismo con la fecha indicada en el fichero y el sistema lo sugiere a través de ícono de edición.


Al ejecutar el script generado, se modificará el absentismo en el infotipo Absentismos (IT2001) poniendo la nueva fecha de fin.


 

Colisión de absentismos

La colisión de absentismos ocurre cuando hay un absentismo guardado en el sistema, al mismo tiempo que el fichero reporta otra entrada cuyas fechas se colisionan. En el ejemplo abajo, hay un absentismo guardado con la fecha de 1 hasta 11 de febrero, pero el fichero contiene una entrada diferente con las fechas de 10 hasta 21 de febrero.


El sistema verifica si el absentismo guardado puede coexistir con el reportado en el fichero. Caso no sea posible, el log del reporte lo exhibe como un absentismo ya existente y con diferencias.


 

Absentismo con diferente tipología

Al ejecutar el reporte Mensaje FIE (RPU_PADES_FIE), el sistema le retorna un absentismo con una tipología diferente. O sea, el fichero reporta los datos de absentismo como accidente laboral, por ejemplo, mientras el absentismo esta guardado como una enfermedad común. El absentismo es lo mismo, pero su subtipo es diferente.


Es posible elegir si el sistema deberá considerar la colisión, bloquear o borrar la entrada original. Por lo tanto, usted define cómo el sistema tratará la colisión de información a través de la actividad de customización Cálculo de la nómina > Cálculo de nómina: España > Evaluaciones para la Seguridad Social > Mensaje FIE > Indicar tratamiento de cambio de contingencia para el FIE.

Suponga que usted elige la opción 0, el sistema mantendrá el absentismo como coexistente con diferencias.


Si usted elige la opción 1, el sistema le sugiere el bloqueo del absentismo existente y la creación de un nuevo con el misto subtipo reportado en el fichero.


Entonces, al ejecutar el script, el sistema bloquea el absentismo original y crea un nuevo para sustituirlo.


Si usted elige la opción 2, el sistema le sugiere que usted borre el absentismo existente para entonces crear un otro nuevo con el misto subtipo reportado en el fichero.


Entonces, al ejecutar el script, el sistema borra el absentismo original y crea un nuevo para sustituirlo.


 

Anulación de un parte en un absentismo guardado

Al ejecutar el reporte Mensaje FIE (RPU_PADES_FIE) para un empleado con absentismo, un parte ha sido anulado por la Seguridad Social, necesitando, por lo tanto, anular la entrada del absentismo o actualizarla en el sistema. Además, el fichero reporta un parte de baja anulado para el absentismo.


Es posible elegir si el sistema deberá considerar la colisión, bloquear o borrar la entrada original. Por lo tanto, usted define cómo el sistema tratará la colisión de información a través de la actividad de customización Cálculo de la nómina > Cálculo de nómina: España > Evaluaciones para la Seguridad Social > Mensaje FIE > Indicar tratamiento de partes anulados para el FIE.

Suponga que usted elige la opción 0, el sistema mantendrá el absentismo como coexistente con diferencias.


Si usted elige la opción 1, el sistema le sugiere el bloqueo del absentismo existente y la creación de un nuevo con el misto subtipo reportado en el fichero.


Entonces, al ejecutar el script, el sistema bloquea el absentismo original y crea un nuevo para sustituirlo.


Si usted elige la opción 2, el sistema le sugiere que usted borre el absentismo existente para entonces crear un otro nuevo con el misto subtipo reportado en el fichero.


Entonces, al ejecutar el script, el sistema borra el absentismo original y crea un nuevo para sustituirlo.

 

Recaída de un absentismo

Al ejecutar el reporte Mensaje FIE (RPU_PADES_FIE), el sistema le retorna un absentismo ya guardado en el sistema, por lo tanto, el fichero le reporta una recaída del absentismo.


El sistema le sugiere la creación del absentismo, vinculándolo al original.


Si el absentismo original no tiene el valor KENN1 asignado, el sistema le sugiere que se inicie un valor valido. Pero si el absentismo original no existe en el sistema, la recaída se reporta como un error. Por lo tanto, al ejecutar el script generado, el sistema sigue con los cambios indicados.


 

Absentismo existente con diferente fecha de fin

Al ejecutar el reporte Mensaje FIE (RPU_PADES_FIE), el sistema le retorna la información el absentismo con la misma fecha de inicio, pero una fecha diferente del fin.


Para este escenario, el sistema le retorna como existente con diferencias.


 

Absentismo de pago directo

Al ejecutar el reporte Mensaje FIE (RPU_PADES_FIE), el sistema le retorna un absentismo de pago delegado guardado y el fichero reporta que se ha modificado a pago directo.


Por lo tanto,  el sistema le sugiere la creación de un nuevo absentismo de pago directo, con la misma fecha de fin del absentismo original.


Al ejecutar el script generado, el sistema guarda apenas el absentismo de pago directo.


 

Utilización de la BAdI para ajuste de valores relacionados con entradas de infotipo

Mediante la BAdI para ajuste de valores relacionados con entradas de infotipo (HRPADES_FIE_BATCH_INPUT), usted puede cambiar las instrucciones de batch input que el reporte Mensaje FIE (RPU_PADES_FIE) genera cuando hace la comparación de los ficheros FIE con los datos maestros de los empleados.

La BAdI contiene métodos para implementación obligatoria y opcional.

Métodos para implementación obligatoria:

  • CHANGE_SUBTY: este método le permite definir el tipo de absentismo, una vez que recibe como parámetro el seguimiento referente a la información utilizada en la generación de absentismo.


Nota:

Usted puede verificar los tipos de seguimiento en el manual MENSAJE DE I.N.S.S. EMPRESA (FIE).

  • SET_DELEGATED_ABSENCE_SUBTY: este método le permite cambiar el subtipo de un absentismo en lo cual se reporta un cambio para pago directo, o sea, su compañía empieza a pagar un valor diferente de contribución, mientras el empleado sigue incapacitado.


Métodos para implementación opcional:

  • UPDATE_ABSENCE: este método recibe la información del absentismo que usted creará y le permite modificarlo de acuerdo con su necesidad, como las fechas del campo Inicio certificado de enfermedad de los absentismos, o algún otro campo nuevo en el infotipo Absentismos (IT2001).

  • UPDATE_BI_SCRIPT: este método recibe el script de batch input y le permite cambiar las instrucciones generadas, de acuerdo con su necesidad. A partir de este método, es posible integrar la funcionalidad con otros programas o soluciones.

  • UPDATE_COLISION_ABSTY: este método le permite definir cuáles son los tipos de absentismo que no se pueden colisionar con los subtipos creados internamente, a través del tipo relacionado (ABSTY) a cada absentismo.

  • UPDATE_COLISION_ABSTP: este método le permite definir cuáles son los tipos de absentismo que no se pueden colisionar con los subtipos creados internamente, a través del tipo relacionado (ABSTP) a cada absentismo.

  • APPEND_ABSENCE_TABLE: este método le permite cambiar las entradas de absentismos, a partir del recibimiento de la tabla de ausencias. La ejecución del método apenas puede ser realizada después de todos los anteriores relacionados con el seguimiento procesado.


Usted puede llamar la BAdI a través de la actividad de customización Cálculo de la nómina > Cálculo de nómina: España > Evaluaciones para la Seguridad Social > Mensaje FIE > Business Add-In (BAdI) > BAdI para ajuste de valores relacionados con entradas de infotipo.

 

Referencias

 

¿Te gusta este blog post? Da un Like y comparte el contenido con tus compañeros.

También podéis dejar un feedback, comentario o pregunta abajo. Y no olviden de seguir el tag HCM Payroll Spain en SAP Community para saber las últimas noticias de Nómina España.

Un abrazo,

Janaína Ferreira

 

----

 

Hi everyone,

In the last blog post, we talked about the Mensaje FIE report, how to run it and handle employee absences, and the configuration required to use its functionalities. Therefore, in this blog post you find examples of the following scenarios:

  • Creating an absence

  • When an absence is closed

  • Absence collision

  • Absence with different typology

  • Cancellation of a certificate in a absence previously saved

  • Relapse of an absence

  • Existing absence with a different ending date

  • Direct pay absence

  • Use of BAdI for the adjustment of values related to infotype entries


 

Prerequisites

You have implemented the following SAP Notes:

 

Creating a New Absence

When you run the report, you see that the file contains an absence that does not exist in the system yet. The, the system suggests the creation of a new absence through the icon of addition.


When you execute the script generated, the absence is created in the Absences (IT2001) infotype.


 

An absence is closed

There is an absence saved in the system without an ending date, but when you run the report for the file, the system indicates a date for it. Therefore, the absence needs to be closed with the date entered in the file, as the system suggests through the icon of editing.


When you execute the script generated, the absence will be changed in the Absences (IT2001) infotype by setting the new ending date.


 

Absence collision

The collision of absences occurs when there is an absence stored in the system, while the file reports another entry whose dates collide. In the example below, there is an absence saved with the date of February 1 to February 11, but the file contains a different entry with dates from February 10 to February 21.


The system checks whether the saved absence can coexist with the one reported in the file. If this is not possible, the report log shows it as an existing absence with differences.


 

Absence with different typology

When you run the Mensaje FIE (RPU_PADES_FIE) report, the system returns an absence with a different type. In other words, the file reports the absence data as an industrial accident, for example, while the absence is stored as a non-industrial disease. The absence is the same, but its subtype is different.


You can choose whether the system should consider the collision, lock, or delete the original entry. Therefore, you define how the system will handle the information collision through the customizing activity Payroll > Payroll: Spain > Evaluations for Social Insurance > FIE message > Indicate processing of contingency change for FIE.

Assume that you choose option 0, the system will keep the absence as coexisting with differences.


If you choose option 1, the system suggests blocking the existing absence and creating a new one with the same subtype reported in the file.


Then, when you run the script, the system locks the original absence and creates a new one to replace it.


If you choose option 2, the system suggests that you delete the existing absence by then creating a new one with the same subtype reported in the file.


Then, when you run the script, the system deletes the original absence and creates a new one to replace it.


 

Cancellation of a certificate in an absence previously saved

When you run the Mensaje FIE (RPU_PADES_FIE) report for an employee with an absence, a part has been cancelled by the Social Insurance, therefore needing to cancel the absence entry or update it in the system. In addition, the file reports a reversed leave certificate for the absence.


You can choose whether the system should consider the collision, lock, or delete the original entry. Therefore, you define how the system will handle the information collision through the customizing activity Payroll > Payroll: Spain > Valuations for Social Insurance > FIE Message > Indicate processing of cancelled report for the FIE.

Assume that you choose option 0, the system will keep the absence as coexisting with differences.


If you choose option 1, the system suggests blocking the existing absence and creating a new one with the same subtype reported in the file.


Then, when you run the script, the system locks the original absence and creates a new one to replace it.


If you choose option 2, the system suggests that you delete the existing absence by then creating a new one with the same subtype reported in the file.


Then, when you run the script, the system deletes the original absence and creates a new one to replace it.

 

Relapse of an absence

When you run the Mensaje FIE (RPU_PADES_FIE) report, the system returns an absence that has already been saved in the system. Therefore, the file reports a relapse of the absence.


The system suggests that you create the absence by linking it to the original.


If the original absence does not have the KENN1 value assigned, the system suggests that you start with a valid value. But if the original absence does not exist in the system, the relapse is reported as an error. Therefore, when executing the generated script, the system follows the given changes.


 

Existing absence with different ending date

When you run the Mensaje FIE (RPU_PADES_FIE) report, the system returns the absence information with the same starting date, but a different date from the ending date.


For this scenario, the system returns you as existing with differences.


 

Direct Payment Absence

When you run the Mensaje FIE (RPU_PADES_FIE) report, the system returns a saved delegated payment absence and the file reports that it has been changed to direct payment.


Therefore, the system suggests the creation of a new direct pay absence, with the same ending date of the original absence.


When you execute the script generated, the system saves the direct pay absence as soon as possible.


 

Using the BAdI for the adjustment of values related to infotype entries

Using the BAdI for the adjustment of values related to infotype entries (HRPADES_FIE_BATCH_INPUT), you can change the batch input instructions that the Mensaje FIE (RPU_PADES_FIE) report generates when you compare FIE files with employee master data.

The BAdI contains methods for mandatory and optional implementation.

Methods for Mandatory Implementation:

  • CHANGE_SUBTY - This method allows you to define the type of absence once you receive as a parameter the tracking regarding the information used in the absence generation.


Note:

You can check the tracking types in the manual MENSAJE DE I.N.S.S. EMPRESA (FIE).

  • SET_DELEGATED_ABSENCE_SUBTY: This method allows you to change the subtype of an absence in which a change is reported for direct pay, that is, your company starts paying a different contribution value, while the employee is still incapacitated.


Methods for optional implementation:

  • UPDATE_ABSENCE: this method receives the absence information that you will create and allows you to change it according to your needs, such as the dates in the Start of Illness Certificate field of the absences, or some other new field in the Absences (IT2001) infotype.

  • UPDATE_BI_SCRIPT: this method receives the batch input script and allows you to change the generated instructions, according to your need. From this method, it is possible to integrate the functionality with other programs or solutions.

  • UPDATE_COLISION_ABSTY: this method allows you to define which absence types cannot be collided with internally created subtypes, via the related type (ABSTY) to each absence.

  • UPDATE_COLISION_ABSTP: this method allows you to define which absence types cannot be collided with internally created subtypes, via the related type (ABSTP) to each absence.

  • APPEND_ABSENCE_TABLE - This method allows you to change absence entries, based on the receipt of the absence table. The execution of the method can hardly be performed after all of the above related to the processed follow-up.


You can call the BAdI through the Customizing activity Payroll > Payroll: Spain > Valuations for Social Insurance > FIE Message > Business Add-In (BAdI) > BAdI for the adjustment of values related to infotype entries.

 

Referencies

 

Did you enjoy this post? Choose “Like” and share the content with your colleagues.

Feel free to leave your feedback, comment or question in the space provided below. And don’t forget to follow the tag HCM Payroll Spain in SAP Community to stay tuned on latest news of Payroll Spain.

All the best,

Janaína Ferreira