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 behind those database inconsistencies. In this article I will review some of the most common mistakes that may lead to trouble.
Issue 0
First and foremost don't panic beforehand:
Tools that are used to copy employees' productive data to test and development systems may cause inconsistencies in the target system if the whole context is not copied along with the employee's master data.
Therefore first thing to be checked is whether the issue is happening in a productive system or just in a test or development system.
e.g. Employee master data and payroll results are exported from the productive system to the test system. however posting info (Tables PPOIX, PPDIT...) is not copied.
Issue 1
Symptom: You are analyzing 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 catch but if the exception is of a rare type that cannot be catch, 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.
Issue 6
After an upgrade, payroll cluster is inconsistent in the new system.
Symptom:
1. If you run transaction PC_PAYRESULT you get the following error message:
H99_DP_MESSAGES 011 "Incorrect structure of payroll result &1/&2"
2. When running other reports you get a dump when importing payroll results.
Runtime Errors: CONNE_IMPORT_WRONG_COMP_TYPE
Except.:CX_SY_IMPORT_MISMATCH_ERROR
Error when attempting to IMPORT object "X"
X is a table from payroll cluster. e.g. WPBP, C1, SV...
Cause:
1. You used to have an append structure un PC* structure e.g.
If the dump says X = WPBP, the append structure was in PC205.
2. The append structure was deleted in the new version.
Solution:
Of course the best choice would be always to leave PC205 free of append
structures but as the append structure was customer specific, you have
to build your own conversion program. For that I would recommend you
to base it on a standard one that was created for the same purpose.
What the conversion toll has to do is read the cluster data, remove
the non standard info and write it back to the cluster.
e.g. program RPU600BT_CONV_SINGLE_CL
[...]
CALL FUNCTION 'IMPORT_PCLX_TO_BUFFER'
[...]
PERFORM standard_conversion
[...]
CALL FUNCTION 'EXPORT_PCLX_FROM_BUFFER'
[...]
See note 763880 for additional info.
Issue 7
Symptom: You run RPCIPE* for one pernr. Later on, going to the posting run generated and to the corresponding posting documents you realize thta several other pernrs are included in the posting run.
Cause: Payroll control record (PA03) was repeatedly deleted and newly created with a higher or lower period than before. e.g. payroll data was created, in one case up to period 17/2011, however, it is back now on period 10/2011 for correction. You have generated payroll data far into the future, and later set the record to the starting point.
Info: Never manipulate control record this way in a productive system. If you do so in a test system, you can expect inconsistencies.
Issue 8
Symptom 1:
Upon executing an out-of-sequence reversal, you get an error stating Adjustment of posting index for out-of-sequence has failed. Message no. 3G 447
Symptom 2:
When trying to display an already posted document you get the following error at the bottom of the document:
Caution! Total ( XX,XX EUR ) unequal to amount in output line ( YY,YY- EUR )
Symptom 3:
Enhancement EXIT_RPCIPE00_002 for RPCIPE00 is not processing some WTs for retro periods.
Cause:
RPCIPE00 processes retrocalculated periods from table PPOIX then EXIT_RPCIPE00_002 tries not match PPOIX with table RT. Field PPOIX-RTLINE will match originally with the number of line that PPOIX-LGART occupies in table RT in payroll cluster. This is what happens in the original posting and this is what should happen when a retrocalculation period is processed by RPCIPE00... unless... you deleted an already posted payroll result and calculated again the same payroll period. This new payroll calculation creates a different RT table where Wage types are placed in lines that are not the original ones. PPOIX and RT tables are mismatched.
You may send a break point here:
METHOD CALL_EXIT_TWO => CL_HRPAY99_POSTING_ENGINE_PP
READ TABLE ir_par->inter-rt INTO ls_rt INDEX <is_ppoix>-rtline.
If the WT retrieved from table RT does not correspond to the WT in PPOIX, you have an inconsistency.
Issue 9
The following dump occurs while running payroll:
Runtime Errors SAPSQL_ARRAY_INSERT_DUPREC
Exception CX_SY_OPEN_SQL_DB
Date and Time 30.09.2011 17:32:37
Short text
The ABAP/4 Open SQL array insert results in duplicate database records.
What happened?
Error in the ABAP Application Program
The current ABAP program "SAPLHRPAY99_RGDIR_WPBP" had to be terminated because
it has
come across a statement that unfortunately cannot be executed.
Take a look at SAP Note 393820.
https://service.sap.com/sap/support/notes/393820
In many cases you can solve the problem by running program RPUDIR00.
Issue 10
Mid-month payroll area changes may cause inconsistencies in the future.
Example: an employee belongs to payroll area A until 14.04.2011. Payroll area is changed to B as of 15.04.2011.
Payroll results are split in April:
So far so good. Now, in a future period e.g. 06.2011, retro is forced to date 15.04.2011.
But payroll area A is not released for payroll , unlike payroll area B. Therefore the first split (Payroll area A) will not be retrocalculated:
Leaving the payroll results inconsistent.
If you realize this after payroll for 06.2011 is closed, it will be too late to fix it.
To avoid inconsistencies due to mid-month payroll area changes, try to avoid mid-month payroll area changes. You can changes payroll area at the beginning of the following month.
What is more, if both payroll area are monthly, and the payment and payroll process is done at the same time, you should use just one payroll area. Remember that payroll area is not intended to be taken into account in payroll calculation.
Issue 11
Looking at payroll results for an employee you get the error:
No data exists for sequence number XXXXX
Message no. H99_DP_MESSAGES004
Cause:
Due to lack of authorization, when transaction PU01 was executed to delete payroll results, the entries in cluster RX (or RE, RU etc... it depends on the country) were deleted, however, the entries in the cluster CU (Directory) that correspond to the first screen you see in transaction PC_PAYRESULTS), were not deleted.
When you try to execute the transaction PU01 again you get the error message but when you go to the PC_PAYRESULTS transaction you still see the deleted records.
Solution:
Fix your authorization profile and rebuild cluster CU using program RPUDIR00.