Time attendance master data sync fails due to duplicate personnel numbers after HR upload in SAP S/4HANA 1809

ERP SAP S/4HANA
, , , , , , , ,
1

We’re experiencing critical issues after uploading new HR master data through LSMW. Time attendance system won’t sync properly and we’re getting HRPA 326 errors for duplicate personnel numbers.

The PA0001 table validation seems to be failing for about 150 employee records. When we check the entries:


SELECT pernr, begda, endda FROM pa0001
WHERE pernr = '00012345'
ORDER BY begda DESC

We see overlapping date ranges for the same personnel number. This blocks time entry and payroll processing for affected employees. We tried running standard checks in PA30 but the system doesn’t flag these duplicates during data entry. Need guidance on proper PA0001 validation logic and how to use LSMW for mass correction without creating more duplicates.

2

Manual processing through PA30 for 147 records is tedious but safest. However, you can create a correction LSMW. The key is proper configuration addressing all three critical areas.

For PA0001 table validation, your LSMW must include these fields in exact order: PERNR, INFTY (0001), SUBTY (blank for PA0001), BEGDA, ENDDA, and the DELIMIT flag. Set DELIMIT = ‘X’ to automatically close previous records.

For HRPA 326 error handling, add error handling in LSMW step 10. Map the RETURN structure to capture error messages. Configure the batch input to process in background mode with error session creation. This way, any remaining validation failures get logged without stopping the entire batch.

For mass data correction with LSMW, create a new project using transaction code PA30 with recording mode. Critical steps:


1. Record PA30 transaction
2. Enter PERNR and INFTY 0001
3. Click Change (not Create)
4. Set DELIMIT checkbox
5. Enter new BEGDA (one day after old ENDDA)
6. Save and complete recording

In your source file, include: PERNR, new BEGDA (current date), ENDDA (99991231), and all required organizational assignment fields (BUKRS, WERKS, PERSG, PERSK, etc.). The delimiter function will automatically set the old record’s ENDDA to new BEGDA minus one day.

Before running production correction, test with 5-10 records in development. Verify using SE16 that old records get properly delimited (ENDDA changed from 99991231 to specific date) and new records are created without overlaps. Check time attendance sync after test correction.

One additional consideration: if these employees have time entries during the overlap period, you may need to reassign those entries to the correct organizational structure after delimiting. Run report RPTIME00 to identify affected time records and use transaction CAT2 for corrections if needed.

After mass correction, run program RHCHECKV to validate all infotype consistency. This catches any remaining date conflicts across all infotypes, not just PA0001.

3

When you recorded your LSMW initially, did you use transaction PA40 (personnel actions) or direct PA30? PA40 handles delimitation automatically while PA30 requires explicit settings. Also check your LSMW step 8 - in the field mapping, there should be a delimiter indicator field. If that’s blank or set incorrectly, you get exactly this behavior.

4

We used direct PA30 recording, which explains part of the issue. I checked and we have 147 personnel numbers with overlapping records. Most have two active records with ENDDA = 99991231. What’s the safest approach to clean this up? Can we create an LSMW to delimit the older records automatically, or do we need to process each one manually through PA30?

5

I’ve seen this before. Your LSMW mapping probably doesn’t include proper date delimiters. When uploading PA0001 records, you need to ensure BEGDA and ENDDA don’t overlap for the same PERNR. Check your LSMW recording - did you set the ‘Delimit’ flag during initial recording? Without it, the system creates new records without properly closing old ones. Also verify your data source has unique date ranges per employee before upload.