Understanding Retro Pay Processing

This topic lists prerequisites and discusses:

Retro request creation.
Retro pay processing.
Retro request process flags
Payroll processing for retro ray.

These are the steps for setting up retro pay processing:

On the Earnings Table - General page, specify which earnings types are eligible for retro pay and which are used to pay retro pay.
See Establishing Earnings Codes.
Define retro pay programs in the Retroactive Pay Program component (RETROPAY_PGM_TBL).
See Program Table Page, Program Definition Page.
Define retro pay triggers in the Retro Pay Monitored Fields (PY_RETROTBL_DEF) component and the Retro Pay Trigger Values (RETRO_TRG_VALUES) component.
See Retro Pay Monitored Fields Page, Retro Pay Trigger Values Page.
Define trigger programs in the Retro Pay Trigger Program (PY_RETROTRG_DEF) component.
See Retro Pay Trigger Program Page.
Assign retro pay programs and retro pay trigger programs to pay groups in the Pay Group Table component (PAYGROUP_TABLE).
See Defining Pay Groups.
(Optional) Define retro pay cancellations reasons on the Retro Pay Cancellation Reason component (PY_RETROCNL_TBL).
See Retro Pay Cancellation Reason Page.

The retro pay process begins when a change to job data or additional pay data affects pay for a previous pay period. Changes can be updates, inserts, or deletions. These changes generate retro pay requests.

The data changes that generate retro pay requests can occur two ways: online, or through mass retro.

Online Retro

When you set up retro pay processing, you define retro triggers. These are definitions for the specific data changes that generate retro pay requests. When a user makes such a change, the system creates a new retro request or, if there is already an open retro request for the employee and job number, the system adds the new trigger information to the existing request so that it is available for review.

Note: When employees have multiple jobs, the system creates separate retro requests for each job.

Changes made by a component interface (including those made in manager self-service) are treated the same as changes that a user manually enters on a page. Throughout this topic, all discussions of retro requests that are triggered online also apply to retro requests that are triggered through a component interface.

Mass Retro

At times, you might make retroactive payroll changes in volume, for example, in response to union contracts. To do this, you use SQL to make changes to the Job Data or Additional Pay tables. The SQL updates database tables directly, bypassing online processing, so the system does not automatically create corresponding retro requests. Instead, you must configure and run the Retroactive Pay Mass Process (PSPRPMSS) COBOL SQL process to create the retro requests for the affected employees.

When you review a retro request that was created through mass retro processing, only minimal information is available. You do not see detailed information about the actual changes to the job data or the additional pay data.

To process retro pay requests, you run these processes:

The Retroactive Pay Calculations (PSPRPEXT) COBOL SQL process calculates the amount of retro pay to be paid to the employee.
Review and update the calculation results and rerun the calculation as many times as needed.

Note: When calculated, retro pay requests do not always result in a retro pay difference.
The Retroactive Pay Load Paysheets (PSPRPPSH) COBOL SQL process loads the calculation results into paysheets.
Retro pay is loaded into paysheets as other earnings; the earnings code comes from the retro pay earnings program that is associated with the employee's pay group.

This diagram illustrates the retroactive pay process:

As you process retro pay, the system maintains the retro request status in the Retro Request Process Flag field.

Open and Closed Requests

To understand how the system maintains the status, keep in mind that there can be only one open retro request per employee and job number. If there are additional retro changes for the employee and job number, those changes are incorporated into the open request.

Open requests are those that have not yet been loaded to paysheets (or they have been unsheeted). Open requests have statuses of Not Processed, Calculated, Recalculate Request,Action Required, Suspended, or Extracted.

Closed requests have statuses of Loaded to Paysheets, Manually Loaded to Paysheets, Confirmed Payment, Paycheck Reversed, or Cancelled/Withdrawn. If all of an employee's retro requests are closed, then the system creates a new retro request when a triggering event occurs.

Process Flag Descriptions

The following table describes the retro request process flag values that are used in the most basic scenario, where the request is created, calculated, loaded to paysheets, and confirmed by the payroll process.

Process Flag	When Used
Not Processed	The retro request has been created, but has not yet been calculated or otherwise processed. This is the default value for newly created retro requests.
Calculated	You have calculated the amount of retro pay, but you have not yet loaded the retro earnings to paysheets. The Retroactive Pay Calculations process applies this status after calculating retro pay for the retro request.
Loaded to Paysheets	You have loaded the retro earnings to paysheets, but the payroll process has not yet paid the earnings. The Retroactive Pay Load Paysheets process applies this status after successfully loading the retro pay to paysheets.
Confirmed Payment	The retro earnings have been paid. The Pay Confirmation PSJob process (PAYCONF) applies this status after it confirms the employee’s paycheck.

Additional process flags are available for retro requests that do not follow this standard progression. The following table lists additional process flags for open retro requests:

Process Flag	Description
Recalculate Request	Additional retro changes have been made since the Retroactive Pay Calculations process last ran, and it is necessary to rerun the calculation process before you can load the retro pay to paysheets. This occurs when: An additional triggering event occurs after you calculate retro pay but before you load the retro pay to paysheets. The Payroll Unsheet process cancels retro requests for unsheeted pay and rolls older requests into the most recent one (either an existing open request or, if there were no open requests, the most recent of the unsheeted requests); the surviving request must be recalculated because it now incorporates additional retro triggers. See Working With Retro Pay Mass Requests.
Action Required	A problem prevented successful processing, and manual intervention is required. This occurs under these conditions: You deselect the OK to Pay check box on the paysheet. The Retroactive Pay Load Paysheets process cannot load the retro pay to the employee's paysheet because the employee is no longer part of the pay group for which the retro pay was calculated. See Understanding the Retroactive Pay Load Paysheets Process.
Extracted	The Retroactive Pay Calculations process encountered a problem while extracting earnings data. The Retroactive Pay Calculations process starts by extracting the appropriate earnings from any confirmed checks that were issued during the retro pay period. If a problem occurs during this extraction process, the calculation process does not continue to the calculation routines, and the retro request process flag remains in `Extracted` status.
Suspended	The retro request was generated by job data changes that are irrelevant because they were made in correct history mode to a row that does not have the highest sequence number for its effective date—and the change was not carried through to the row with the highest sequence number. For example, an employee has two rows of job data with the same effective date. You use correct history mode to make a compensation rate change on the row with the lower sequence number. The row with the higher sequence number still shows the previous compensation rate. Essentially, it is as if the compensation rate change never occurred because it was not in effect for even a single day. The system still creates a retro request, but its initial process flag is `Suspended.` Note: If you make the changes in the row with the highest sequence number and then later add a row with a higher sequence number to back out the change, the system cancels the retro request rather than suspending it. The retro request remains suspended until you cancel it or until another data change adds active triggers to the request. The addition of active triggers changes the process flag to `Not Processed.`

The following table lists additional process flags for closed retro requests:

Process Flag	Description
Manually Loaded to Paysheet.	The retro pay process was unable to pay the retro earnings because the employee is no longer in the same pay group as when the original earnings were paid. You manually apply this status after the Retroactive Pay Load Paysheets process sets the process flag to `Action Required.` Apply this status only if you manually load the retro pay information into paysheets for regular payroll processing, or if you use any other mechanism to make the retro payment outside of the normal retro process. Note: When you manually load the retro pay to paysheets, the paysheet does not include a link to the original retro request.
Paycheck Reversed	The retro earnings were paid, but the paycheck that included the retro earnings was reversed. The Paycheck Reversal/Adjustment COBOL SQL process (PSPPYREV) applies this status when it reverses the check that paid the retro amount. See Reversing Paychecks.
Cancelled/Withdrawn	The retro request was cancelled without being paid. This system applies this status when you reverse all of the employee data changes that were the triggers for the retro request. You can manually cancel retro requests on the Request and Trigger Summary page. This option is available only for requests where the process flag is `Not Processed,` `Suspended,` or `Action Required.` You can cancel retro requests in batch using the Retroactive Pay Undo process. Warning! If you cancel a retro request, you must also back out the data change that triggered the request in the first place. Otherwise, the next time the system creates a retro request for the employee, the retro pay calculation (which looks at the source data and not the triggers) will pick up the original data change. See Reviewing Retro Pay Requests.

Process Flag

Description

Manually Loaded to Paysheet.

The retro pay process was unable to pay the retro earnings because the employee is no longer in the same pay group as when the original earnings were paid.

You manually apply this status after the Retroactive Pay Load Paysheets process sets the process flag to Action Required. Apply this status only if you manually load the retro pay information into paysheets for regular payroll processing, or if you use any other mechanism to make the retro payment outside of the normal retro process.

Note: When you manually load the retro pay to paysheets, the paysheet does not include a link to the original retro request.

Paycheck Reversed

The retro earnings were paid, but the paycheck that included the retro earnings was reversed.

The Paycheck Reversal/Adjustment COBOL SQL process (PSPPYREV) applies this status when it reverses the check that paid the retro amount.

See Reversing Paychecks.

Cancelled/Withdrawn

The retro request was cancelled without being paid.

This system applies this status when you reverse all of the employee data changes that were the triggers for the retro request.

You can manually cancel retro requests on the Request and Trigger Summary page. This option is available only for requests where the process flag is Not Processed, Suspended, or Action Required.

You can cancel retro requests in batch using the Retroactive Pay Undo process.

Warning! If you cancel a retro request, you must also back out the data change that triggered the request in the first place. Otherwise, the next time the system creates a retro request for the employee, the retro pay calculation (which looks at the source data and not the triggers) will pick up the original data change.

See Reviewing Retro Pay Requests.

As you load retro pay information into paysheets, you begin using the standard PeopleSoft Payroll for North America processes to complete the payment process. This topic describes considerations for completing the retro payment process.

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

One

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

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.

Understanding Retro Pay Processing

Prerequisites

Retro Request Creation