Database inconsistencies are often difficult to fix once they occur, therefore it's worth being well informed about their causes in order to prevent them. Harmful Abap code is often being those database inconsistencies. In this article I will review some of the most common mistakes that may lead to trouble.

Issue 1

Symptom: You are analysing a posting run / document at transaction PCP0. When you drill down for a G/L Account to see the details (1) by pernr you get the error message: “Data inconsistency”.



Cause: Inconsistent payroll results deletion. using programs RPUDEL20 or RPUP2D* can be quick and useful in a test client but harmful of used in a productive system. Transaction PU01 should be used to delete payroll results if needed. If PU01 does not allow to delete payroll results, in most of the cases there is a good reason behind it: Payroll results are not standalone. Here are some dependencies:

Payroll results are already posted. You'll notice because there is an entry in table PCALAC linking seqnr + pernr + posting run is. But also, there are entries in table PPOIX for the same seqnr + pernr + posting run id. PPOIX table contains the details mentioned above (1). By the way, don't delete PCALAC or PPOIX entries out of the standard procedures.

Solution: A posting reversal will allow deleting payroll results.

Issue 2

Symptom: Payroll cluster is unreadable. You get a dump when trying to import payroll results:CONNE_IMPORT_ILL_OBJECT_TYPE /  CX_SY_IMPORT_FORMAT_ERROR.

Cause: Customer developed ABAP program has updated payroll results in an inconsistent way. e.g. the program fills / changes tables RT, BT, WPBP... then sends them back to PCL2 . But some seqnrs do not correspond to just one entry in PCL2 but of to two or more entries that are differentiated by SRTF2 = 0, 1.... You'll notice it easily displaying table PCL2 in transaction SE16. For the same seqnr the different records have different update times and programs. Of course, not only payroll driver can update payroll cluster but pre DME RPCDTA*0 and others but those post payroll programs will update cluster records in a consistent manner.


Issue 3

Symptom: Same payment is done several times.

Cause: Payroll results already transferred to bank accounts. PU01 will not allow you deleting them but if you manage to do so, you may pay twice to the employee.

Issue 4

Symptom: Cluster directory “CU” at PCL2 is corrupted. A program tries to read payroll results but you get a dump.

Solution: Normally program RPUDIR00 will rebuild cluster directory, but RPUDIR00 itself tries to read cluster “CU” before rebuilding it. If the cluster “CU” is corrupted, normally the dump exception will be catched but if the exception is of a rare type that cannot be catched, RPUDIR00 will end up in dump before being able to rebuild the directory.

A trick: During RPUDIR00 run skip import RGDIR avoiding the dump, then cluster “CU” will be newly and consistently created. You have to use the debugger to skip a piece of code. See under section “Skipping blocks of code” as to how to do it.


Issue 5

Symptom: When running the FI posting for payroll we receive the following

Inconsistence in payroll results (tables  C0/RT)
Message no. 3G101

Cause: In your payroll schema you imported last payroll results with split indicators pointing out to WPBP, C0, C1 etc.

Solution: WT's split indicators should be removed when the WTs come from another payroll results. It may happen that last payroll results have 2 WPBPs with APZNR = 01 and 02. You have a WT XXXX with APZNR that is imported to the current payroll period but the current payroll just has 1 WPBP.

I have added the following document to the wiki where I will maintain with new info in case I find new interesting items:

I just read an interesting blog called "Creating Effective Customer Messages (OSS Notes)":


Creating Effective Customer Messages (OSS Notes)


Now, from my experience in SAP Support I would like to add something that is essential and yet not everyone realizes it: Choosing the right application component will speed up the message processing. Or the other way round: choosing the wrong component will delay the message delivery to the relevant team at SAP Support.


Why is the application component important?


- I will reply with another question: If one writes a letter (Let's say a traditional one), why should one write the correct address. The answer is obvious: "So that the letter reaches its destination". Application component would be like the ZIP code.


Ok, but how do I know which is the right application component for my message?


It seems that choosing the right component is often a difficult task.  Here are some hints:


Method 1


As a rule, if the issue occurs with transaction "X" or program "Y", ABAP program RSSTATUS will tell the correct component to post the customer message:



Program RSSTATUS checks the package that is linked to the object (Program, transaction, table. Let's find out the component of transaction PCP0 from SE80:



Of course sometimes the component is not so clear or the may be changed during the message "life" because:


  • Some transactions from an application component, call transactions from a different component. E.g. program RPCIPE00 / RPCIPE01 (Posting payroll to accounting) belongs to component PY-XX-DT but an issue with RPCIPE* might be due to:


  • Issues with the connection. The message would be forwarded temporarily to XX-SER-NET-HTL.
  • The component of the program "X" or transaction "Y" is not accurately maintained at SAP side.

Method 2


Another way to find out the right component for a message, as opposed to the RSSTATUS way is to perform a note search for the transaction or program where the problem is occurring. The right component will most likely be the one for which you get most of the notes.


Application components are useful when searching for notes too (As a filter)


By the way, this does not only apply to message creation but may also help in note search. Filtering by component(s) may be necessary to avoid getting irrelevant notes.

Right now I am participating in a project that consists of a technical note search as described in the blog:


Automated Note Search and Customer Code Detection


The tool is based on a technical search based on objects as described in the blog "Finding SAP notes using ABAP coding as keywords"


Finding SAP notes using ABAP coding as keywords


During the design of the first prototype of our "Automated Note Search and Customer code detection tool" we noticed:


1. There were objects from several different components (e.g. BC* is always involved) in a single transaction, which means many heterogenous notes from different components were found and mixed up.

===> This was solved by collecting all the objects found in the trace in components, then the user who is searching for notes will decide for which of the suitable components the note search has to be done.


2. When a component X is selected for note searching, it may happen that you get notes from component Y. The reason is that the component assigned to the note does not correspond to the component of the objects in the correction instructions attached to the note.

We really wanted to get rid of the component (I mean, to make it transparent to our users) but in the end it was not possible. The idea of using as a default component the application component of the program / transaction entered in the tool selection-screen turned out to be unfeasable for the reasons explained above.




I would also highlight the "connection" issue. Sometimes an example in the customer's system is requested by the support consultant. To enable SAP accessing those examples I recommend.

  • Make sure the user account has the necessary authorizations to debug: Profile S_A.DEVELOP as opposed to SAP_ALL is recommended.
  • Create variants whenever possible.
  • When the message is created, chose the right customer number / installation / system. If the issue is reproduced in the development DHR system but the message was created for PHR and nothing else is said, we'll always try to connect to PHR. Therefore, if the issue is reproduced in system DHR, state DHR when creating the message will save time and effort.
  • Opening the system for short periods, leads to "message ping-pong": (I ask you open the system and you open it for let's say 1 hour, unfortunately I was busy when the connection was opened and when I try to connect, the connection is closed again). This can be an endless loop... Take into account that sometimes SAP needs to connect more than once if the issue is complex. Moreover, if the ticket is forwarded to development, the developers may want take a look too.

           =====> Solution (Line opener program).

Have you heard about the - Line Opener Program (LOP)?

Installation of the LOP (Line Opener Program) and Service Connector is highly recommended, because it enables the members of SAP Support and Development to access a system whenever it becomes necessary.         

More Information you can find in note 797124.                         

In order to help you opening, installing and customizing the Line Opener Program, I enclose the following video available in youtube:   

Hi Guys,

I'd like to share with the HCM community some hints on how to customize the HRFORMS payslip so that the settings in Infotype P0655 are taken into account. In the case of PE51 based forms, this is not necessary as the standard deals with infotype P0655. Users can record at infotype P0655 whether the employee uses ESS remuneration statement, therefore the payslip must not be printed when the remuneration statement program is run at the backend.





However if you run your HRFORMS pasylip program you’ll notice that the settings in P0655 are ignored.


Here you are a hint to make your HRFORMS payslip check P0655:

Check Infotype P0655 in Badi HRFORM_HRF02 at method CHECK_PERNR.

here is the code I implemented in my test system:


method IF_EX_HRFORM_HRF02~CHECK_PERNR.<br /><br />  data: subrc like sy-subrc,<br />        l_essonly type essonly,<br />        i0655    TYPE STANDARD TABLE OF p0655.<br /><br />  FIELD-SYMBOLS:  <iwa> LIKE LINE OF i0655.<br /><br />* Read the infotype 0655<br />  CALL FUNCTION 'HR_READ_INFOTYPE'<br />    EXPORTING<br />      pernr           = im_pernr<br />      infty           = '0655'<br />      begda           = im_begda<br />      endda           = im_endda<br />    IMPORTING<br />      subrc           = subrc<br />    TABLES<br />      infty_tab       = i0655<br />    EXCEPTIONS<br />      infty_not_found = 1<br />      OTHERS          = 2.<br /><br /><br />  if subrc = 0.<br />    LOOP AT i0655 ASSIGNING <iwa> WHERE begda LE im_endda<br />                                AND endda GE im_begda.<br />      l_essonly = <iwa>-essonly.<br />      EXIT.<br />    ENDLOOP.<br /><br />    if l_essonly = 'X'.<br />      If sy-dbnam = 'PNPCE'. "Call directly from R/3 <<<<<<<<<<<<<br />        raise reject.<br />      endif.<br />    endif.<br />  endif.<br /><br />endmethod.





How to implement the Badi




Go to transaction SE18 -> Choose form HRFORM_HRF02 -> Overview -> Create implementation -> e.g. ZCARLOS.




Filters ->Set the FORM for which you want to implement the Badi, e.g. SAP_PAYSLIP_US.


Then go to the section “Interface” where you can find all the methods available.



Go to method check_pernr by double clicking over it.


Here you can insert your own code.


Warning: The information contained in this blog is obsolete!

(Hay una versión en español debajo).

In case of illness (or other absences relevant for Social Security), function EPRO1 does not reduce the amount of prorrata WT /34C because it does not take into account the absence days. Here’s a workaround if you want WT /34C to be calculated proportionally to the active days of the payroll period (Taking out the sickness days). E.g. Amount for /34C should be 300 EUR for a normal month of 30 days . If there is a maternity beginning on the 15th, the amount calculated for /34C must be 300 x 15 / 30 = 150 EUR. EPRO1 calculates WT /34C based on WT /3AC “Active days for Social Security”, therefore you can substract the absence days in WT /3BC “Abs. days – contributions” to /3AC just before EPRO1 is run, and later on, just after EPRO1 add again /3BC to /3AC to restore the original number of days.Here is an example of the rules that would make EPRO1 work on real worked days basis: 


Besides absences, other situations as Public Sector administrative acts can be considerer as long as they are quantified in payroll results through a WT with field ANZHL filled.  

Here you are a sample as to how to implement this solution:















En caso de enfermedad (o otros absentismos relevantes para Seguridad Social), al función EPRO1 no alicuota el importe calculado de la prorrata /34C porque no tiene en cuenta los días de absentismo. En lo que sigue, describiré un workaround para alicuotar /34C en función de los días activos del período de nómina (Quitando los días de ausencia). E.g. El importe del concepto /3AC debería ser 300 EUR en un mes normal de 30 días. Si existiese una maternidad empezando el día 15, el importe de /34C debería ser 300 x 15 / 30 = 150 EUR. EPRO1 calcula /34C en base a los días activos para la seguridad social /3AC, por tanto pueden restar los días de ausencia /3BC al concepto /3AC antes de entrar en la función EPRO1 y volverlos a sumar al salir de dicha función.


Además de las ausencias, otra situaciones como los Actos Administrativos de Sector Públicose pueden considerar como no computables para la prorrata, siempre que los mismos sean cuantificables a través de un concepto de nómina.











Maintaining Wage Types


When maintaining  Wage Types (coyping or deleting) using transaction PU30 or OH11, you expect that all the tables in which the WT exist are taken into account. e.g. if you want to copy WT M101 for molga = 04 into a new WT, you'll notice that although WT M101 exists in table T5E37, after copying the Wage Type, the target WT does not exist in table T5E37 as you expected. This causes the target WT is not an exact copy of the original one.


Transaction PU30 / OH11 makes a copy (or deletion) of the original WT into the target WT of all the entries in international tables, such as T512W and T511. Other tables such as T5E37 may be ignored.


Tuning-up transactions PU30 / OH11


In order to include in the WT Maintenance Country-Specific, Add-on and Customer-Owned Wage-types an Abap include named RPUWMT*0 or H**UWMT0 (where * / ** is the letter(s) for your country) must be created in case it does not exist yet. e.g. RPUWMTE0 should be created for Spain and HARUWMT0 should be created for Argentina. For some countries like Germany, the report RPUWMTD0 is provided in the standard but of course it will not take into account Customer-Owned tables. You can use RPUWMTD0 as a template to create your own Country Version. Details on how to create it can be found in the on-line documentation of program RPUWMTX0. It is not necessary to create the report from scratch as you can use for example program RPUWMTD0 as a template.



  • How to know if a table is Country-Specific, Customer-Owned or Add-on specific:

By the package they belong to. Go to transaction SE11, type the name of the table in the field "Database table". Go to "Attributes" and you'll see the package. In the Package Attributes you'll see the component, e.g. PY-XX and Software component e.g. SAP_HRRXX.


  • How to know which tables in your system may contain Wage Types:

Go to transaction SE11, type "LGART" in the Data Type field and click on the "Where-used list" icon. You'll get a list of tables that may contain Wage Types. There can be other tables that contain WTs.


Additional notes:


PY-XX-TL 639536 Wage type copier: More than one wage type in request
PY-XX-TL 777542 Table T549V is not copied
PY-XX-TL 682144 Tables for new averages are not copied
PY-XX-TL 860295 PU30: Table T558A results in the dump

(Hay una version en español debajo).


In case of illness (or other absences relevant for Social Security) during a full payroll period, overtime payments could lead to a rejection of the FAN file by the social security.




In order to avoid FAN file rejection by Social Security it's necessary to avoid paying overtime during absence periods.


Note: The standard does not prevent from paying overtime during illness periods, therefore each client should implement a solution its own.


As a hint here is an example of rule that would prevent from paying overtime during illness periods.


Subschema ESV0


Rule ZCZC:


Another choice would be a user-exit or Badi to check that when creating a I0015 for overtime WTs there is not an illness absence. The advantage of this solution is that it would prevent directly to record overtime. The disadvantage is that this solution only works in case overtime is recorded in I0015 or any other infotype like I2010) but not in case overtime comes from the time evaluation.


Versión en español


En caso de enfermedad (o otro absentismo relevante para la Seguridad Social) durante un período de nómina completo, el pago de horas extraordinarias puede llevar a un rechazo del fichero FAN por parte de la seguridad social .


Para evitar el rechazo del fichero FAN por parte de la Seguridad Social se debe evitar el pago de horas extra en período de IT.


Nota: El estándar no pone ningún impedimento al pago de horas extra en período de IT por lo que cada cliente se hará cargo de implementar esta solución por su cuenta.


A modo de ejemplo, la siguiente regla de nómina impediría el pago de horas extra durante períodos de IT.


Subschema ESV0


Rule ZCZC:


Otra posibilidad es comprobar mediante una user-exit o Badi que al meter las horas extra en el I0015 no exista IT durante todo el mes. La ventaja es que impediría directamente que se grabasen horas extra. La desventaja es que esto solo funciona en el caso de que las horas extra se introduzcan por el I0015 (Podría ser el I2010 u otro)., pero no en el caso de que las horas extra provengan de la evaluación de tiempos.


Filter Blog

By date:
By tag: