We have a (miserable) group of employees with multipe positions, many whom change positions every month, and sometimes multiple times per month. We are encountering an error "too much pay history for retro processing" when trying to add a position to an individual. KB article refers to needing to run the PA113, but there are NO pending records for this person on PA55. Has anyone ever seen this? I'm not sure if it's referring to the fact that this person has mutliple positions effective with different dates in June? I'm at a loss...

Thanks!!

I had the same problem a couple of years ago with one employee that somehow had 128 records entered on Total Prorate Salary for the same date. Most were duplicates. No idea how this happened.

Anyway, GSC told me at the time that there was a table limit of 100 and that's why I was getting the error. Fortunately, I was able to delete most of my data since it was garbage. To resolve my error I had to delete the bad records from HRHISTORY for Field 729 on the specified date. Once I cleaned up the record everything worked fine.

I'm not sure what your options are since your data is valid but maybe this will give you something to look at.

Thanks, Scott - turns out it was much messier than I had imagined it could get. Time to remove history correction from certain users!!

By the way, I did have a bazillion total prorated salary amounts for the same date, but deleting didn't have an impact on this issue.

Have a great day!

you may also want to check Pay_ rate and prorate A_sal for the same employee.

Not sure what version you are on but we are ISeries 8.03 and there were bugs back in November and we are still trying to clean up messes from the workaround we used for pay changes until Lawson released our fix. Ended up SQL for all those people for prorated and base annual hours as the workaround did not enter those new records. Just recently I had a report that we are now having PA113 problem that we have never encountered that I am just starting to investigate. When I saw your post about the PA113 I wonder if there is some other "problem".

Our problem was strictly user error (thank goodness, I think). Although no one will own up to it, the only thing I can figure they actually did was merge 2 personnel actions with different effective dates - which I wasn't sure was even possible. The only other thing I can think they may have done was enter 1 personnel action, enter 2 more with a different date that they then merged, then tried (and failed) to successfully delete the first one. Spent all day on it - its a sad day when I can't figure out how these users actually created their mess!!