Payroll Processing for Retro Pay

Paysheet Processing for Retro Pay

Here is the suggested order for processing retroactive adjustments:

Create paysheets for all company and paygroup combinations.
Run the Load Paysheets (PYLOAD) process to load data to paysheets for regular payroll if needed.
Run the Retroactive Pay Load Paysheets (PSPRPPSH) COBOL SQL process the load retro pay to paysheets.

This process is necessary because the Load Paysheets process does not load retroactive payments.
Run the Load Time and Labor (PSPLDTL1) COBOL SQL process to load payable time data to paysheets if needed.

For off-cycle retro pay, you can run the Retroactive Pay Load Paysheets (PSPRPPSH) process any time because it invokes the paysheet creation process and loads the selected retro entries based on either Run ID or Company/Pay Group/Pay End Date selection on the Load Retro Pay to Paysheets run control page.

On paysheets, you cannot modify retro pay amounts. If you do not want to pay the loaded amount, your only option is to deselect the OK to Pay check box. If you do this, then the system updates the original retro request as follows:

If an open retro request exists for the same employee and record number, the system cancels the original retro request.

The changes that triggered the cancelled retro request will be processed as part of the open retro request.
If no open retro request exists, the system changes the process flag of the original retro request to Action Required.

Possible actions to take include manually cancelling the request or using the Retroactive Pay Undo (PSPRPUND) COBOL SQL process to change the process flag to Not Processed, Calculated, or Cancelled/Withdrawn. If you change the process flag to Calculated, you can override the retro earnings amount before reloading it to paysheets.

Pay Unsheet and Retro Pay

When you run the Payroll Unsheet (PAYUNSHT) process, it updates the retro request process flag for all retro requests that get unsheeted.

Note:

Remember that the unsheet process is not an option by employee ID; the unsheet is for the entire Run ID.

When the Payroll Unsheet process performs these updates, it must account for the restriction that there can be only one open retro request at a time per employee and job number.

The following table describes how the Payroll Unsheet process updates the retro request process flags in various conditions.

Open Request Exists?	Unsheeting One or Many Requests?	Process Flag Updates
No	One	Set the retro request process flag to Calculated so that it can be reloaded to paysheets.
No	Many	Set all retro requests except the last one to Cancelled/Withdrawn. Requests are cancelled in sequence number order to ensure that each one rolls into the next one. Set the last retro request to Recalculate Request so that it can be recalculated to account for the changes from the requests that were rolled in.
Yes	One or Many	Set all retro requests being unsheeted to Cancelled/Withdrawn. Requests are cancelled in sequence number order to ensure that each one rolls into the next one. Set the existing open retro request to Recalculate Request so that it can be recalculated taking into account the changes from the requests that were rolled in.

Open Request Exists?

Unsheeting One or Many Requests?

Process Flag Updates

No

One

Set the retro request process flag to Calculated so that it can be reloaded to paysheets.

No

Many

Set all retro requests except the last one to Cancelled/Withdrawn. Requests are cancelled in sequence number order to ensure that each one rolls into the next one.

Set the last retro request to Recalculate Request so that it can be recalculated to account for the changes from the requests that were rolled in.

Yes

One or Many

Set all retro requests being unsheeted to Cancelled/Withdrawn. Requests are cancelled in sequence number order to ensure that each one rolls into the next one.

Set the existing open retro request to Recalculate Request so that it can be recalculated taking into account the changes from the requests that were rolled in.

At the end of the process, the Retro Pay Effective Date for the open retro request is adjusted to account for any other requests that have rolled into it. Also, retro requests are rolled up, the system populates the Additional Request Included field in each retro request except the oldest; on each retro request, the Additional Request Included field contains a link to an older retro request that was rolled into it.

Note:

The retro requests being unsheeted normally start out with a retro request process flag of Paysheets Loaded. If, however, someone has changed the status using the Retroactive Pay Undo process, the Payroll Unsheet process does not change the process flag. Instead, it creates a message to alert you to the possibility that the process flags are out of sync.

Pay Calculation and Retro Pay

When the Pay Calculation process processes paysheets with retro earnings, it verifies that the retro request process flag for the corresponding retro request is Loaded to Paysheets. If the process flag is not Loaded to Paysheets, the Pay Calculation process issues a pay error message.

Pay Confirm and Retro Pay

When the Pay Confirmation process successfully processes a retro payment, it updates the retro request process flag to Confirmed Payment. It also adds the check number to the retro request.

Pay Unconfirm and Retro Pay

When a regular paycheck is unconfirmed, the Pay Unconfirm (PSPUNCNF) COBOL SQL process changes the retro request process flag to Loaded to Paysheets.

Paycheck Reversal/Adjustment and Retro Pay

When you use the Paycheck Reversal/Adjustment (PSPPYREV) COBOL SQL process, the system updates both the retro request process flag and the link from the retro request to the paycheck. At all stages of the process, the link goes to the last confirmed paycheck.

This table describes the changes to the retro request at various stages of the paycheck reversal process:

Action	Retro Request Process Flag	Link from Retro Request to Paycheck
The original paycheck is confirmed.	Confirmed	Goes to the original paycheck.
The paycheck is reversed (reversal is confirmed).	Paycheck Reversed	Goes to the reversed paycheck.
Reversal is unconfirmed.	Confirmed	Goes to the original paycheck.
Reversal is deleted.	Confirmed	Goes to the original paycheck.

This table describes the changes to the retro request at various stages of the paycheck reversal/adjustment process:

Action	Retro Request Process Flag	Link from Retro Request to Paycheck
The original paycheck is confirmed.	Confirmed	Goes to the original paycheck.
The paycheck is reversed/adjusted (reversal/adjustment is confirmed).	Paycheck Reversed	Goes to the adjustment paycheck.
Reversal/adjustment is unconfirmed.	Confirmed	Goes to the original paycheck.
Reversal/adjustment is deleted.	Confirmed	Goes to the original paycheck.