You are here:
I am willing to share my know how gained from 15 years of supporting PeopleSoft payroll and related modules. I do not have access to an installed system at this time, so my knowledge will be from memory and analysis of provided facts
PeopleSoft Payroll -- development and support PeopleSoft Payroll Interface -- development and support PeopleSoft Benefits Administration -- support PeopleSoft COBOL -- Functional expert/programmer
BA Mathematics, PeopleSoft employee 1993 to 2004
| User | Date | K | C | T | P | Comments |
|---|---|---|---|---|---|---|
| Sue | 11/13/09 | 10 | 10 | 10 | 10 | Thanks again - you lead me in ..... |
| Randy | 09/28/09 | 10 | 10 | 10 | 10 | Thank you very much for the quick ..... |
| Jagadeesh | 06/11/09 | 10 | 9 | 10 | 10 | |
| Daisy | 04/17/09 | 10 | 10 | 10 | 10 | Thank You very much |
| Amy | 04/15/09 | 10 | 10 | 10 | 10 |
Yes, paycheck reversal occurs after confirmation. That is its specific role. You cannot reverse a check that has not been confirmed as it will not have a check number assigned. The reversal process
I think those pages should be deleted. Check to see if the corresponding entries in PS_PAY_LINE are deleted for the 'old' page numbers. I think I reported this bug at one time. On a recalc all the 'C'
The Single Check feature is certainly a factor. Each combined check is creating a new page number. To get a high level picture of what is happening look at the results of the following SQL both before
I have never found it to be a true issue of needing a larger maximum. The error is triggered because of an undetected processing problem or manual entry of page numbers near the maximum. During the
Vishal Not my area of expertise, but I offer a line of thought. The creation of PERSON_DATA is valid for more that just employees, so it should not require creation of a position. If that is happening
Answers by Expert:

©2009 About.com, a part of The New York Times Company. All rights reserved.