Introduction
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 http://wiki.sdn.sap.com/wiki/display/ERPHCM/Debugging+the+Payroll+Schema 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
message:
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:
http://wiki.sdn.sap.com/wiki/display/ERPHCM/Inconsistencies+in+Payroll
- SAP Managed Tags:
2 Comments
