PeopleSoft Enterprise Payroll for North America 9.1 PeopleBook

Processing Retro Pay

This chapter provides an overview of retroactive (retro) pay processing and discusses how to:

Work with retro pay mass requests.
Review retro pay requests.
Run and review retro pay calculations.
Load retro pay into paysheets.
Update the retro pay process flag.
(E&G) Generate lump-sum retroactive payments for contractual employees.
(USF) Manage interest calculations on retro pay.
Report on retro pay processing.

Note. Retroactive benefit processing is documented in the PeopleSoft Enterprise Human Resources PeopleBook: Manage Base Benefits.

Understanding Retro Pay Processing

This section lists prerequisites and discusses:

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

Prerequisites

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 Defining Retro Pay Programs, Defining Earnings for a Retro Pay Program.
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 Defining Retro Pay Fields, Defining Trigger Values.
Define trigger programs in the Retro Pay Trigger Program (PY_RETROTRG_DEF) component.

See Defining Retro Pay Trigger Programs.
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 Defining Retro Pay Cancellation Reasons.

Retro Request Creation

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 chapter, 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.

See Also

Setting Up Retro Pay Processing

Retro Pay Processing

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:

Retro pay processing process flow.

Retro Request Process Flags

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 Pay Unsheet and Retro Pay.
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 Cancelling Retro Requests.

Payroll Processing for Retro Pay

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

Paysheet Processing for Retro Pay

The Load Paysheets (PYLOAD) process does not load retro pay; you must load retro pay to paysheets using the Retroactive Pay Load Paysheets process.

You must load on-cycle retro pay into paysheets in conjunction with the regular payroll. So, for on-cycle retro pay, run the Load Retro Pay to Paysheets process after you run the Load Paysheet process for the regular payroll.

Note. You should always load retro requests to paysheets immediately after you create the paysheets, before running any other processes such as the Load Time and Labor (PSPLDTL1) process.

For off-cycle retro pay, you can run the Load Retro Pay to Paysheets 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.

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.

Working With Retro Pay Mass Requests

This section provides an overview of retro pay mass requests and discusses how to:

Specify retro pay mass request criteria.
Create mass retro requests.

Understanding Retro Pay Mass Requests

At times, you might make retroactive payroll changes in volume using an SQR to make Job Data or Additional Pay changes. The SQR bypasses online processing, so the changes do not automatically generate retro requests. Instead, you run the Retroactive Pay Mass Request (PSPRPMSS) COBOL SQL process to create retro requests for employees that meet criteria that you specify. It is up to you to make sure that you define the criteria to catch all employees who were affected by the SQR.

If the mass retro selection criteria creates retro requests for people who did not actually get the raise, retro processing will still include the request, but the retro amount will end up being zero, and the Load Paysheets process will ultimately cancel the request with a ZR reason.

Pages Used to Define and Process Retro Pay Mass Requests

Page Name	Definition Name	Navigation	Usage
Retro Pay Mass Request Criteria	MASS_RETRO_PAY	Set Up HRMS, Product Related, Payroll for North America, Retroactive Payroll, Retro Pay Mass Rqst Criteria, Retro Pay Mass Request Criteria	Specify the criteria that the Retroactive Pay Mass Process uses to select the employees for whom it creates retro requests.
Process Mass Retroactive Pay	RUNCTL_MASS_RETRO	Payroll for North America, Retroactive Payroll, Retro Pay, Process and Review Requests, Process Mass Retroactive Pay, Process Mass Retroactive Pay	Create mass retro requests for employees who meet your selection criteria.

Specifying Retro Pay Mass Request Criteria

Access the Retro Pay Mass Request Criteria page (Set Up HRMS, Product Related, Payroll for North America, Retroactive Payroll, Retro Pay Mass Rqst Criteria, Retro Pay Mass Request Criteria).

Retro Pay Program ID

Select the ID that identifies the earnings that this retroactive process calculates.

Maintain these values in the Retroactive Pay Program table.

Start Date and End Date

The system applies the retro pay mass request to employees with effective dates in their Job records that are both:

Later than, or equal to, this start date.

Earlier than, or equal to, this end date.

If the effective date in an employee's Job record does not fall between these start and end dates, the system selects the latest effective date that is earlier than, or equal to, the start date.

First Hire Date and Service Date

If you specify the hire date or service date, the employees' hire date or service date must be earlier than, or equal to, the effective dates of the data in the Selection Criteria group box. If you leave these fields blank, the system uses the end date.

Process End Date

Define the end of this retro period.

Process Flag

Displays the status of the process.

Delete Request

Select this check box to reverse the mass retro request, but only if you have not yet run the Retroactive Pay Calculations process for your mass retro ID. The mass retro request ID and its associated retro requests are deleted the next time you run the Retro Pay Mass Process.

Note. This process works only if the retro requests for the selected mass retro request ID have not been calculated.

(USF) Eligible for Interest

Select to mark the resulting retro requests as eligible for interest.

Selection Criteria

Use this group box to define the criteria that the system uses to select employees for whom to create retro pay requests. When you leave a field blank, all values are included. For example, if you leave the Company field blank, the process includes employees from all companies.

Job Elig Wk Days (job eligible work days), Un Cd Elig Wk Days (union eligible work days), and Loc Elig Wk Days (location eligible work days)

These fields work with the job code, union code, or location code to enable you to create requests for employees who have been in a job, union, or location for a specified amount of time. The system uses the later of these dates:

The start date of the Retro Pay Mass Request process.
The effective date in the Job record.

See Also

Setting Up Retro Pay Processing

Creating Mass Retro Requests

Access the Process Mass Retroactive Pay page (Payroll for North America, Retroactive Payroll, Retro Pay, Process and Review Requests, Process Mass Retroactive Pay, Process Mass Retroactive Pay).

Mass Retro Request ID

The Retroactive Pay Mass Process creates retro requests for all employees who meet the criteria in the Mass Retro Request ID that you enter here.

Reviewing Retro Pay Requests

This section provides an overview of retro pay request updates and discusses how to review retro pay requests.

See Also

Setting Up Retro Pay Processing

Understanding Retro Pay Request Updates

Use the Retro Pay and Trigger Summary page to review information about the retro requests. Generally, the information you see on the Retro Pay and Trigger Summary page is not editable. However, in certain circumstances, you can make limited updates.

Cancelling Retro Requests

When a retro request's current process flag is Not Processed, Suspended, or Action Required, you can manually change the process flag to Cancelled/Withdrawn to cancel the request.

When you cancel a retro request, it is important that you 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) picks up the original data change.

For example, you cancel a retro request that was triggered by a raise, but you do not remove the raise information from the job data. You later make another change that triggers another retro request. When you review the new request, this second event is the only trigger shown. But when the system calculates retro pay, it will pick up the raise for which retro was never paid and incorporate that into the calculation.

Warning! If you cancel a retro request, you must also back out the data change that triggered the request in the first place.

Marking Retro Requests as Manually Loaded to Paysheets

When the current process flag is Action Required, you can set the process flag to Manually Loaded to Paysheets to indicate that the retro is being paid outside of the standard retro process. This is not a true cancellation, as the retro does, in fact, get paid. But this status change deactivates the request so that it does not get further processed, while retaining data related to the paid retro amount so that the system can use that information in any future retro calculations that affect any of the same pay periods.

See Understanding Retro Pay Calculations.

(USF) Configuring Interest Eligibility

Use the Eligible for Interest check box on the Retro Pay Request and Trigger Summary page to indicate whether the employee is entitled to receive interest on the retro earnings.

If the request was created through the Retroactive Pay Mass Request process, the setting from the Retro Pay Mass Criteria page is applied to all resulting retro requests, and you cannot change the setting manually.

Page Used to Review and Cancel Retro Pay Requests

Page Name	Definition Name	Navigation	Usage
Retro Pay Request and Trigger Summary	RETROPAY_RQST_SUMM	Payroll for North America, Retroactive Payroll, Retro Pay, Process and Review Requests, Request and Trigger Summary, Retro Pay Request and Trigger Summary	Review retro pay requests and the triggers that created the requests. If the process request flag is Not Processed, Action Required, or Suspended, you can also use this page to manually cancel the request.

Reviewing and Cancelling Retro Pay Requests

Access the Retro Pay Request and Trigger Summary page (Payroll for North America, Retroactive Payroll, Retro Pay, Process and Review Requests, Request and Trigger Summary, Retro Pay Request and Trigger Summary).

Retro Request Information

Employment Record Number	If the employee has multiple jobs, the system creates separate retro pay requests for each job.
Retro Pay Sequence Number	Displays a unique identifier for the retro request. The system assigns sequence numbers based on the value in the Last Retro Pay Request Seq Nbr field on the Last ID Assigned page.
Additional Request Included	Displays a link to an earlier retro request that has been rolled into the current retro request. This occurs if because there can only be one open retro request for an employee at a time Retro requests are rolled up when there is an open retro request when retro pay is unsheeted, or the Payroll Unsheet process unsheets pay from multiple retro requests.
Retro Pay Process Flag	Displays the status of the retro request. For example, a newly created retro request is Not Processed, and after the Retroactive Pay Calculations process runs, the process flag changes to Calculated. See Retro Request Process Flags. In certain situations, you can change the process flag: If the current process flag is Not Processed, Suspended, or Action Required, you can change it to Cancelled/Withdrawn. If the current process flag is Action Required, you can change it to Manually Loaded to Paysheet.
Retro Cancellation Reason	When you change the process flag to Cancelled/Withdrawn, you can optionally select a cancellation reason. This field prompts against reasons that you create on the Retro Pay Cancellation Reason page, excluding the delivered cancellation reasons that are reserved for system use. See Defining Retro Pay Cancellation Reasons.
(USF) Eligible for Interest (interest)	Select if the retroactive payment is eligible for interest payment. This check box is unavailable for change if the request was created through the Retroactive Pay Mass Request process.
Process End Date	Displays the date that the system created the retro request. The system uses this date to determine the last pay period to recalculate.
Retro Pay Effective Date	Displays the earliest date that the retro pay is effective. For example, if the retro request incorporates two separate compensation rate increases that are effective on different days, the retro pay effective date is the earlier of the two dates. The system uses this date to determine the earliest pay period to recalculate.
Retro Pay Program ID and Retro Pay Trigger Program ID	These fields identify the retro programs that are associated with the pay group that the employee belonged to at the time the retro request was created.
Mass Retro Request ID	If the request was created by the Retroactive Pay Mass Process, the system displays the mass retro request ID for the process that created it.

Retro Pay Trigger Events

This group box is hidden if there is no trigger data. Requests with no trigger data include those that the Retroactive Pay Mass Process creates and requests that were created in a release prior to PeopleSoft Payroll for North America 9.1.

Trigger Event ID	Identifies an individual trigger event within a retro request. Because employees can have only one open retro request at a time, each retro request has event information for every triggering event that occurs while the request is open. For example, suppose you insert a row of job data with a new compensation rate, then, while the retro request is still open, you correct the compensation rate on that row. Each job data update is a separate triggering event within the retro request.
Sequence	Displays the sequence number of the Job record row or the Additional Pay Data row where the change was triggered. When there are multiple sequence numbers for a trigger event ID, only the last row in the sequence is active; the individual field-level triggers in the earlier rows are superseded by the changes in the last row.
Effective Date and Action Date	The effective date is the date that the retro event became active. This is the effective date of the job data row or the additional pay data row where the change occurs. The action date is the date that the data was saved, triggering the retro request. For example, on June 1 you enter a compensation rate change that was effective on March 1. In the resulting retro request, this event has an effective date of March 1 and an action date of June 1.
Record Name	Displays the record where the triggering event occurred: JOB or ADDL_PAY_DATA.
Updated By User	Displays the user ID of the person who made the change that triggered the retro request.

Retro Pay Trigger Fields

This grid shows the specific field changes that caused the trigger event.

Note. When the retro pay calculation processes a retro request, it uses the actual job and additional pay data. It does not use the trigger details to calculate retro pay. The system saves the trigger data for audit purposes only.

Field Name	Displays the name of the field that changed.
Previous Value and New Value	Displays the field values before and after the change that triggered the retro request. Values are formatted as generically as possible, which means that the formatting does not necessarily match the formatting in the page where the values were originally entered. For example, if the trigger field is a currency field such as a shift rate, the previous and new values appear here as plain numbers. Trailing zeros after the decimal point are dropped. For example, 1.50 is displayed as 1.5.
Value Not on Trigger	If the system creates a trigger because a field changed to a specific value, then a subsequent update to the field changes the value to one that would not normally create a trigger, the system creates a new trigger to show that the original value is no longer applicable. In the new trigger, the new value (the one that would not normally create a trigger) appears in the Value Not on Trigger field.
Trigger Action	Displays the type of data change: Insert, Update, or Delete.
Trigger Status	Displays Active, Cancelled, or Superseded. Triggers are cancelled if the original field change is reversed. Cancelling an individual trigger does not cancel the overall retro request, but if all of the triggers in a retro request are cancelled, the system cancels the overall retro request too. Only triggers from the job record can be superseded. This occurs when the trigger becomes irrelevant because it occurred in 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 trigger for the compensation rate change has a Superseded status. Note. Only active triggers are considered in the determination of the Retro Pay Effective Date.

Running and Reviewing Retro Pay Calculations

This section provides an overview of retro pay calculations and discusses how to:

Run the Retroactive Pay Calculations process.
Review and update retro pay calculations.
Review retro pay summary information for an employee.
Review calculation messages.

Understanding Retro Pay Calculations

This overview describes retro pay calculations.

The Calculation Process

When you run the Retroactive Pay Calculations process, it processes retro requests with a process flag of either Not Processed, Recalculate Request, or Extracted.

The Retroactive Pay Calculations process performs these steps for each retro request:

Extracts the original pay data for the affected pay periods.

If an error occurs during this step, the retro request process flag for the partially processed request is set to Extracted
Performs the retro calculation.

During this step, the process:
1. Performs FLSA calculations, if necessary.
2. Calculates retro pay.
3. Updates the retro pay earnings table with the retro calculation results.
Updates the retro request process flag for each calculated request to Calculated.

Pay Period Retro Amount

Here is the formula for calculating the retro pay amount for a specific earnings code for a pay period:

New Earnings Amount – Orginal Earnings Amount – Prior Retro Paid

In this formula:

The Orginal Earnings Amount is the amount that was paid on the employee's original pay check.

It is not adjusted for any previous retro payments.
The New Earnings Amount is the amount that the employee should have received if the retro changes had been in effect at the time of the original paycheck.

The system uses the changed employee data to determine the new earnings amount. It does not incorporate any pay rate overrides that were entered on the paysheet for the original paycheck.
To determine the Prior Retro Paid, the system looks for retro requests that resulted in retro pay for the same pay period (the pay period dates must match exactly).

Retro requests are assumed to have resulted in retro pay if the process flag is Loaded to Paysheets, Manually Loaded to Paysheets, or Confirmed Payment.

For example, in one pay period, an employee was paid 1,000 USD of regular pay (his original earnings amount). He received a retroactive pay increase resulting in recalculated pay of 1,100 USD (the new earnings amount), which produced 100 USD of retro pay.

The employee then received another increase for the same period, resulting in recalculated pay of 1,300 USD (the new earnings amount in a new retro request). The original earnings amount is still 1,000 USD, but this time there is also a prior retro paid amount of 100 USD. Therefore the retro pay for this second retro request is 1,300 USD – 1,000 USD – 100 USD, or 200 USD.

Note. If you enter an earnings override while reviewing the calculation results, the system substitutes the override amount for the new earnings amount. The system recalculates the current retro pay amount when you save the override.

Pages Used to Run and Review Retro Pay Calculations

Page Name	Definition Name	Navigation	Usage
Calculate Retroactive Pay	RUNCTL_RTROPAYCALC	Payroll for North America, Retroactive Payroll, Retro Pay, Process and Review Requests, Calculate Retroactive Pay, Calculate Retroactive Pay	Run the Retroactive Pay Calculations process.
Retro Pay Calculation Results	RETROPAY_EARNS	Payroll for North America, Retroactive Payroll, Retro Pay, Process and Review Requests, Retro Pay Calculation Results, Retro Pay Calculation Results	Check the results of the Retroactive Pay Calculations process, and override the results if necessary.
Retro Pay Calc Summary	RETROPAY_SUMMARY	Payroll for North America, Retroactive Payroll, Retro Pay, Process and Review Requests, Retro Pay Calc Summary, Retro Pay Calc Summary	Review a summary of the retro pay requests of an individual employee.
Retro Pay Messages	RETROPAY_MESSAGES	Payroll for North America, Retroactive Payroll, Retro Pay, Process and Review Requests, Retro Pay Messages, Retro Pay Messages	Review retro pay messages.

Running the Retroactive Pay Calculations Process

Access the Calculate Retroactive Pay page (Payroll for North America, Retroactive Payroll, Retro Pay, Process and Review Requests, Calculate Retroactive Pay, Calculate Retroactive Pay).

Note. When you run the Retroactive Pay Calculations process, it processes retro requests with a process flag of either Not Processed, Recalculate Request, or Extracted. After it processes these requests, the Retroactive Pay Calculations process changes the retro request process flag for each calculated request to Calculated.

Process Type

Select one of these options to indicate how you will choose which retro requests to process.

Online (All Employees)

Select this option if you want to calculate retro pay for all requests that were created by trigger processing. This includes requests that were generated by online data changes and by changes that came from a component interface.

Online (Selected Employees)

Select this option if you want to calculate retro pay for retro requests that were generated online, but you want to narrow the process to include only selected employees.

When you select this option, the Employees Selected for Processing grid appears so that you can enter the employees to process.

Mass Retro

Select this option if you want to calculate retro pay for requests that were created by the Retroactive Pay Mass Process.

When you select this option, the Mass Request Options grid appears so that you can choose which mass retro request IDs to process.

Online Request Options

This group box appears if the process type is either of the online options.

Job	Select this check box to process retro requests that were triggered by changes to the job record.
Additional Pay (additional pay)	Select this check box to process retro requests that were triggered by changes to the additional pay data record.

Employees Selected for Processing

This group box appears if the process type is Online (Selected Employees).

Employee ID

Enter the employee IDs for one or more employees to process.

Mass Request Options

Use this group box to process retro requests that created by the Retroactive Pay Mass Process.

All Mass Retro Request IDs

Select this option to process all retro requests that were created by the Retroactive Pay Mass Process.

Selected Mass Retro Request ID

Select this option to process the retro requests that were created for a particular mass retro request, and use the Mass Retro Request ID field to identify the mass retro request to process.

Reviewing and Updating Retro Pay Calculations

Access the Retro Pay Calculation Results page (Payroll for North America, Retroactive Payroll, Retro Pay, Process and Review Requests, Retro Pay Calculation Results, Retro Pay Calculation Results).

Note. This page displays retro requests that have a process flag of Calculated, Loaded to Paysheets, Confirmed Payments, Action Required, Paycheck Reversed, and Manually Loaded to Paysheet.

Note. Except for the OK to Pay and Earnings Amount Override fields, which are editable in certain circumstances, all fields on this page are display-only.

Calculation Results

This page displays the results for a single retro request. There are separate rows of data for each earnings code in each pay period.

For example, an employee gets a retroactive pay increase that affects two pay periods. During the first of those pay periods, the employee had only regular earnings. During the other pay period, the employee had both regular and holiday earnings. There will be three rows of data on the Retro Pay Calculation Results page: one row for the first pay period, and two rows for the second pay period.

Retro Request

This group box displays information that identifies and describes the retro request. All rows of data have the same retro request information.

Duplicate Flag

Displays N (no) or Y (yes) to indicate whether this is a duplicate retro request.

Normally, there can only be one open retro request for an employee and job number. However, duplicate requests can occur when changes made online are also processed in batch. Therefore, when the system creates a new online retro request, it checks to see if there is an open mass retro request. If there is, the system selects the Duplicate Flag for both the mass retro request and the online retro request.

Paycheck Number or Paycheque Number

After the retro pay is paid (the retro request process flag is Confirmed Payment or Paycheck Reversed), this field displays the check number of the check that includes the retro pay.

The check number is a link that you click to access the Review Paycheck component, where you can review complete payment details. In the Review Paycheck component, retro earnings appear in the Other Earnings grid. The detail information for the retro earnings codes includes the retro pay sequence number; the sequence number is a link back to the Retro Pay Calculation Results page.

Pay Run

This group box displays information about the pay run that is affected by the retro request.

Exception

The system selects this check box if the retro pay calculation is based on a mid-pay period change. This informs you that the system prorates the retroactive pay amount. Run the Retro Pay Summary report (PAY302RT) to verify the proration calculation.

Exception processing can also generate Retro Pay messages that you should review and validate prior to loading the retro calculations to paysheets.

See Reviewing Calculation Messages.

OK to Pay

The system initially selects this check box for active employees and deselects it for terminated employees. The system also initially deselects this check box if the Duplicate Flag is Y (yes).

You can change this setting only if process flag is Calculated.

Earnings

This group box displays information about an earnings code for which the employee received retro pay during the pay period.

Original Values and New Values

These group boxes show pay-period specific information about a particular retro-eligible earnings code.

Earnings Amount	The original value is the amount that was paid on the employee's original pay check. It is not adjusted for any previous retro payments. The new value is the amount that the employee would have received if the retro changes had been in effect at the time of the original paycheck.
Earnings Amount Override	To override the calculation, enter the desired new earnings amount. The system uses the manually entered override amount rather than the (calculated) new earnings amount to determine the amount of retro pay. The system recalculates the Current Retro Pay amount when you save the page. The calculated new earnings amount is not updated. You can only enter an override while the retro request is open.
Prior Retro Paid	Displays the sum of all prior retro payments for the employee record number, pay period, and earnings code. If this is non-zero, the Prior Retro Paid grid appears so that you can review the supporting details.
Current Retro Pay Amount	Displays the amount of retro earnings to be paid for this employee record number, pay period, and earnings code. The system calculates the amount as follows: New Earnings Amount – Orginal Earnings Amount – Prior Retro Paid If you entered an earnings override, the system substitutes the override amount for the new earnings amount: Earnings Amount Override – Orginal Earnings Amount – Prior Retro Paid

Prior Retro Paid

If the Prior Retro Paid field shows a non-zero amount, this group box appears.

Prior Retro Pay Sequence

Displays the ID of the retro request for the previously paid retro earnings. Click the link to view the calculation details for that retro request.

Reviewing Retro Pay Summary Information for an Employee

Access the Retro Pay Calc Summary page (Payroll for North America, Retroactive Payroll, Retro Pay, Process and Review Requests, Retro Pay Calc Summary, Retro Pay Calc Summary).

Reviewing Calculation Messages

Access the Retro Pay Messages page (Payroll for North America, Retroactive Payroll, Retro Pay, Process and Review Requests, Retro Pay Messages, Retro Pay Messages).

The system deletes calculation messages when:

The retro request is cancelled.

To cancel a retro request after it has been calculated, use the Retroactive Pay Undo (PSPRPUND) COBOL SQL process.

See Updating the Retro Pay Process Flag.
The results of the retro calculation are loaded to paysheets.

Warning messages do not prevent the paysheet load.

When there are errors that do prevent the system from loading retro to paysheets, the retro request pay flag is set to Action Required to indicate that you need to review the messages for more information about why the paysheet load failed.

Note. Although the Retroactive Pay Calculations process is the source of most messages that you see on this page, certain other processes also insert messages occasionally. For example, the Payroll Unsheet process creates a message if it processes a retro request that did not start out with the process flag Loaded to Paysheets.

Loading Retro Pay Into Paysheets

This section provides an overview of the Retroactive Pay Load Paysheets process, lists prerequisites, and discusses how to run the Retroactive Pay Load Paysheets process.

Understanding the Retroactive Pay Load Paysheets Process

To load retro pay into paysheets, run the Retro Pay Load Paysheets process after your on-cycle paysheets have been created.

For off-cycle retro pay, you can run this 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.

When processing retro requests that did not produce any retro pay, the Retroactive Pay Load Paysheets process cancels the retro request with a cancellation reason of ZR (zero retro).

If the employee has changed pay groups since the original paycheck, the system cannot load the retro pay. Instead, it changes the retro request process flag to Action Required and generates an error message explaining the problem. When you get this error, you have these options:

Manually load the retro amount to paysheets to the correct company and pay group so that you can pay the amount outside the retro process, then use the Request and Trigger Summary page to set the retro request process flag to Manually Loaded to Paysheets.

Setting the retro pay process flag to Manually Loaded to Paysheets deactivates the request so that it does not get further processed, while retaining data related to the paid retro amount so that the system can use that information in any future retro calculations that affect any of the same pay periods.
On the Retro Pay Calculation Results page, enter manual overrides to zero out the retro amount on the retro request that won't load, then add that same amount to a retro request for the employee's new pay group.

This option is available only if a retro request for the employee's new pay group exists.

To enter manual overrides in a retro request, its process flag must be Calculated. Change the retro request process flag back to Calculated either by rerunning the calculation process or by running the Retroactive Pay Undo process.
Use the Request and Trigger Summary page or the Retroactive Pay Undo process to cancel the retro request.

Prerequisites

You must run the Retroactive Pay Calculations process before you load retro pay to paysheets.

Also, it is a good practice to run the Retro Pay Messages Report (PAY304RT) before you load retro pay into paysheets. The system deletes error messages for retro requests that it loads to paysheets, and running the report captures the messages before they are deleted and saves them for future review.

Page Used to Load Retro Pay Into Paysheets

Page Name	Definition Name	Navigation	Usage
Load Retro Pay to Paysheets	RUNCTL_RTROPAYPSHT	Payroll for North America, Retroactive Payroll, Retro Pay, Process and Review Requests, Load Retro Pay to Paysheets, Load Retro Pay to Paysheets	Run the Retroactive Pay Load Paysheets process.

Running the Retroactive Pay Load Paysheets Process

Access the Load Retro Pay to Paysheets page (Payroll for North America, Retroactive Payroll, Retro Pay, Process and Review Requests, Load Retro Pay to Paysheets, Load Retro Pay to Paysheets).

Processing Options

Process Terminated Employees

By default, the system doesn't process paysheets for retro pay for terminated employees. However, you can select this check box to include terminated employees for whom retro pay has been calculated. Only employees who terminated on or before the pay end date are included.

If you select this check box, the Retroactive Pay Load Paysheets process sets a flag for terminated employees who are processed. When you run the Retro Pay Terminations report (PAY303RT), only flagged employees are included.

On-Cycle or Off-Cycle Run

Pay Run ID

If you use this field, all fields in the Off-Cycle Run group box become unavailable for entry.

Off-Cycle Run

Company

If you use this field, all fields in the On-Cycle or Off-Cycle Run group box become unavailable for entry.

Updating the Retro Pay Process Flag

This section provides an overview of batch changes to the retro pay process flag and discusses how to update the retro pay process flag.

Understanding Batch Changes to the Retro Pay Process Flag

In some circumstances, you need to update the process flag of a retro request directly rather than letting the system handle the process flag changes. The Retroactive Pay Undo process enables you to change the retro request process flag to Cancelled/Withdrawn, Calculated, or Not Processed. You can run this process for specified retro requests, for mass retro requests (all, or those associated with specific Mass Retro Request IDs), or for the retro pay requests of a pay run.

Important! Use caution when making batch changes to the retro pay process flag.

These are some considerations for making batch changes to the retro pay process flag:

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.
If you change a retro request from Calculated to Not Processed, the system clears any error messages that were associated with the retro request.
If a retro request process flag is Action Required because you deselected the OK to Pay check box on the paysheet, you can use this process to return the retro request to Calculated status.

Once the retro request process flag is Calculated, you can enter an earnings override before reloading the retro request to paysheets.
In general, you should not change the process flag for a retro request that has been loaded to paysheets.

Using the Retroactive Pay Undo process to change the process flag does not affect paysheets in any way.

If you want to completely remove the posted retro adjustment paysheets from the system, you must run the Payroll Unsheet process and unsheet the complete pay run ID.
It is not normally necessary to run the Retroactive Pay Undo process to reset the retro request process flag after you unsheet retro pay; the Payroll Unsheet process handles all process flag updates.

However, if the Payroll Unsheet process does not complete successfully, you may need to change a retro request process flag using the Retroactive Pay Undo process. Change the process flag to Calculated if the calculation is correct and you just need to reload the retro pay to paysheets.

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

Page Used to Update the Retro Pay Process Flag

Page Name	Definition Name	Navigation	Usage
Change Retro Pay Process Flag	RUNCTL_RTROPAYUNDO	Payroll for North America, Retroactive Payroll, Retro Pay, Process and Review Requests, Change Retro Pay Process Flag, Change Retro Pay Process Flag	Change the process flag value in the Retro Pay Request table for retro pay requests.

Updating the Retro Pay Process Flag

Access the Change Retro Pay Process Flag page (Payroll for North America, Retroactive Payroll, Retro Pay, Process and Review Requests, Change Retro Pay Process Flag, Change Retro Pay Process Flag).

Undo Process Flag To

Indicate the new process flag value to apply to the affected retro requests: Calculated, Not Processed, or Cancelled.

Processing Options

Select one of these options to indicate how you will choose which retro requests to update.

Selected Sequence Number	Select this option if you want to select one or more specific retro requests to update. When you select this option, the Retro Pay Sequence Number grid appears so that you can enter the retro pay sequence numbers (the request IDs) for the requests that you want the system to update.
Mass Retro	Select this option if you want to change the process flag for retro requests that were created by the Retroactive Pay Mass Process.
On or Off-Cycle	Select this option if you want to change the process flag for the retro pay requests of a pay run.

Retro Pay Sequence Number

This group box is visible only when the process option is Selected Sequence Number.

Retro Pay Sequence Number

Select the sequence numbers for the retro requests that you want to update. Although you enter the sequence number, you can use the field prompt to search for sequence numbers based on the EmplID, the employee name, or the current value of the retro pay process flag.

You cannot select retro requests with a retro pay process flag of Cancelled/Withdrawn.

Mass Retro Processing Option

This group box is visible only when the selected process option is Mass Retro.

All Mass Retro Request IDs

Select this option to change the process flag for all retro requests that were created by the Retroactive Pay Mass Process.

Selected Mass Retro Request ID and Mass Retro Request ID

Select the Selected Mass Retro Request ID option to update the process flag in the retro requests that are associated with the mass retro request that you identify.

On-Cycle or Off Cycle Parameters

This group box is visible only when the selected process option is On or Of-Cycle. Use the fields in this group box to specify which pay runs to process. The system changes the process flag of any retro request included in the pay run.

Pay Run ID

If you use this field, all fields in the Off-Cycle Run group box become unavailable for entry.

Company

If you use this field, the Pay Run ID and On or Of-Cycle fields become unavailable for entry.

See Also

Payroll Processes

(E&G) Generating Lump-Sum Retroactive Payments for Contractual Employees

This section provides an overview of lump-sum retroactive payments and discusses how to:

Set up lump-sum retroactive payments.
Process additional pay for contractual employees.

Understanding Lump-Sum Retroactive Payments

At times, you might change an employee's contract retroactively. For example, suppose that you have an employee working under a nine-month contract that is paid over a 12-month period. During the contractual period, the employee's compensation rate is increased, and the increase is effective on the first day of the contract. In such instances, you must pay the employee retroactive earnings. With the Lump-Sum Retroactive Payment feature, you can pay the employee's retroactive earnings as a lump sum.

To use this feature, indicate that you want a lump-sum retroactive payment for contract pay by selecting the Lump Sum Retro Payment check box on the Contract Change Proration Option page that appears after you enter a new contract amount in the employee's record. Then, the Contract Additional Pay SQR Report process (CNTPAY01) calculates all the lump-sum retroactive payment data. To deliver the payment in a separate check, select the Separate Check check box on the Contract Additional Pay - Run Parameters page.

The Contract Additional Pay process completes the following tasks:

Determines what you already paid as:
- Paid, but not earned (PNE).
- Earned, but not paid (ENP).
- Contract regular earnings (CRG).
Determines what you should have paid as PNE, ENP, and CRG, had the increase (or decrease) been in effect.
Generates lump-sum entries for each earnings code.
Processes the lump-sum entries from an on or off-cycle payroll.
Automatically adjusts the goal balances to reflect the increased amount.

The goal balance of the contract additional pay represents the actual balance of the contract pay. For example, if an employee has 10,000 CAD of contract pay and 500 CAD of lump-sum retroactive pay, contract additional pay with sequence number of 1 represents the employee's normal contract pay, and additional pay with sequence numbers greater than 1 represents the employee's lump-sum retroactive payment. The final goal balance of the sequence 1 additional pay should be 10,000 CAD, and the goal balance of the lump-sump retroactive additional pay should be 500 CAD.

When producing a lump-sum retroactive payment for contract pay, the system:

Processes the retroactive compensation.
Provides a lump-sum payment of the retroactive amount to the employee.
Tracks the effective date of the retroactive changes to the compensation amount of the contract.
Maintains the integrity of the contract.

This means that the contract begin and end dates, and the payment begin and end dates, do not change to accommodate the retroactive changes.
Maintains the integrity of the assigned grade and step of the employee.
Maintains the integrity of the true value of the contract.

The lump-sum retroactive payment for contract pay is optional. However, this capability enables you to deliver earnings to the employees in a manner that best fits your business practices and your employees' needs.

Note. If the compensation rate is changed in Correction mode (that is, no new effective-dated row is added), no lump-sum retroactive amount is calculated.

Pages Used to Generate Lump-Sum Retroactive Payments for Contractual Employees

Page Name	Definition Name	Navigation	Usage
Contract Change Prorate Options	JOB_CNT_CHG_SEC	Workforce Administration, Job Information, Job Data, Compensation Click the Contract Change Prorate Option link on the Compensation page. Workforce Administration, Job Information, Pay Rate Change, Compensation Click the Contract Change Prorate Option link on the Compensation page.	Select contract proration options and enable the system to process a lump-sum payment of retroactive earnings to the employee.
Create Contract Projected Pay	RUNCTL_PAYINIT3	Payroll for North America, Payroll Processing USA, Create and Load Paysheets, Create Contract Projected Pay, Create Contract Projected Pay Payroll for North America, Payroll Processing CAN, Create and Load Paysheets, Create Contract Projected Pay, Create Contract Projected Pay	Process additional pay for contractual employees. This page executes the CNTPAY01 SQR. The Contract Projected Payment process produces an exception report. The exception report lists corrections that might be required to process contract additional pay.

Setting Up Lump-Sum Retroactive Payments

Access the Contract Change Prorate Options page (Workforce Administration, Job Information, Job Data, Compensation, then click the Contract Change Proration Option link on the Compensation page).

Before running the process to calculate and report on lump-sum retroactive payments for contractual employees, set up the system at the employee level.

Select the Lump Sum Retro Payment check box on the Compensation: Contract Change Proration Option page.

Processing Additional Pay for Contractual Employees

Access the Create Contract Projected Pay page (Payroll for North America, Payroll Processing USA, Create and Load Paysheets, Create Contract Projected Pay, Create Contract Projected Pay; or Payroll for North America, Payroll Processing CAN, Create and Load Paysheets, Create Contract Projected Pay, Create Contract Projected Pay).

Note. You can use the On-Cycle Run group box or the Off-Cycle Pay Calendar group box, but not both.

On-Cycle Run

Pay Run ID

Select a pay run ID that identifies the pay calendars to process. Each pay calendar identifies a company, pay group, and the start and end dates of the pay period. The system uses this information to select employees that have been active during the pay period.

Payroll Cycle

On-Cycle	If you select this option, the system uses the pay run ID that you entered to extract the company, pay group, and pay end date from the pay calendar.
Off-Cycle	If you did not enter a pay run ID, and you select this option, the system accepts the company, pay group, and pay end date that you enter on the page.
Both	The system uses the pay run ID to extract the company, pay group, and pay end date from the pay calendar. If you did not enter a pay run ID, the system accepts the company, pay group, and pay end date that you enter on this page.

Lump Sum Retro Payments

Separate Check

Select this option to distribute all lump-sum retroactive payments in the pay cycle as separate checks.

Important! Run this process before you run the Create Paysheet process. This process creates additional pay records that are referenced during a payroll run.

(USF) Managing Interest Calculations on Retro Pay

This section provides an overview of interest on retro pay and discusses how to enter the current interest rate.

Understanding Interest on Retro Pay

Agencies are required to pay interest on retroactive payments that are over 30 calendar days late. Payments are based on Office of Personnel Management (OPM) interest rates. Following are additional setup and processing details for managing interest calculations.

Additional Setup Steps

Follow these steps in addition to the general retro pay setup and processing steps that are documented earlier in this chapter:

On the Earnings table, define retro earnings interest codes.

Retro interest earnings codes have unique payment requirements. The interest that is paid to employees is classified as income with no federal, Old Age, Survivors and Disability Insurance (OASDI), or Medicare withholdings.
Assign the retro pay interest earning code at the pay group level.

Enter the interest earning code in the Interest field on the Pay Group Table - Calc Parameters (Pay Group table - Calculation Parameters) page.
Enter the current interest rate, as stipulated by the OPM, on the Retro Pay Interest page.
When you define the retro pay mass request on the Retro Pay Mass Request Criteria page, select the Eligible for Interest check box.
For retro pay requests that are not generated by the Retroactive Pay Mass Process, select the Eligible for Interest check box on the Retro Pay Request and Trigger Summary page.

Interest Processing

During the Retroactive Pay Load Paysheets process, the interest is calculated on the sum of the retro payment and inserted into the paysheet using the interest earnings code that you defined for the employee's pay group.

Page Used to Manage Interest Calculations on Retro Pay

Page Name	Definition Name	Navigation	Usage
Retro Pay Interest	GVT_RETRO_INT	Set Up HRMS, Product Related, Payroll for North America, Retroactive Payroll, Retro Pay Interest USF, Retro Pay Interest	Define the retroactive interest rate as mandated by the OPM.

Entering the Current Interest Rate

Access the Retro Pay Interest page (Set Up HRMS, Product Related, Payroll for North America, Retroactive Payroll, Retro Pay Interest USF, Retro Pay Interest).

Interest Rate

Enter the interest rate that is specified by the OPM.

Reporting on Retro Pay Processing

This section lists the pages used to report on retro pay processing and discusses how to:

Generate the Retro Pay Request Summary and Trigger report.
(USF) Generate the Retro Pay Interest report

Common Elements Used to Report on Retro Pay Processing

Retro Request Type

Choose which types of retro requests to include in the report:

Select Additional Pay Request to view the retro pay requests that are generated by an additional pay change.
Select Job Related Requestto view the retro pay requests that are generated by a job change.
Select Mass Retro Pay Request to view a retro pay request that is generated by mass retro.

If you select this option, you must also enter a mass retro ID.
Select All Requests to view all retro pay requests.

Pages Used to Report on Retro Pay Processing

Page Name	Definition Name	Navigation	Usage
Retro Pay Request and Trigger Report	RUN_PAY300RT	Payroll for North America, Retroactive Payroll, Retro Pay, Reports, Retro Pay Request and Trigger, Retro Pay Request and Trigger Report	Run the PAY300RT report, which reports retroactive pay information from the Retro Pay Request table.
Retro Pay Calculations Report	RUN_PAY301RT	Payroll for North America, Retroactive Payroll, Retro Pay, Reports, Retro Pay Calculations, Retro Pay Calculations Report	Generate the PAY301RT report, which provides a detailed listing of the retroactive pay calculations, sorted by employee and by earnings type.
Retro Pay Summary	RUN_PAY302RT	Payroll for North America, Retroactive Payroll, Retro Pay, Reports, Retro Pay Summary, Retro Pay Summary	Run the PAY302RT report, which creates a summary of each request type, with a grand total of both request types.
Retro Pay Terminations Report	RUN_PAY303RT	Payroll for North America, Retroactive Payroll, Retro Pay, Reports, Retro Pay Terminations, Retro Pay Terminations Report	Generate the PAY303RT report, which lists all terminated employees for whom the system has calculated retro pay. Note. Before generating this report, you must run the Retroactive Pay Load Paysheets (PSPRPPSH) COBOL SQL Process with Process Terminated Employees selected on the Load Retro Pay to Paysheets page. This is how the system sets the flag used to identify terminated employees. The Retroactive Pay Load Paysheets process sets the terminated employee flag only for employees who were terminated on or before the pay end date. Therefore, employees who terminated after the pay end date do not appear on the report.
Retro Pay Messages Report	RUN_PAY304RT	Payroll for North America, Retroactive Payroll, Retro Pay, Reports, Retro Pay Messages, Retro Pay Messages Report	Generate the PAY304RT report, which lists messages from the Retro Pay Calculations process.
Retro Pay Interest Limit Report	RUNCTL_PAY306RT	Payroll for North America, Retroactive Payroll, Retro Pay, Reports, Retro Pay Interest Limit, Retro Pay Interest Limit Report	Run the Retro Pay Interest report (PAY306RT), which lists the name, national ID, and interest earnings for employees who have interest earnings over the limit amount in the reporting year.

Generating the Retro Pay Request and Trigger Report

Access the Retro Pay Request and Trigger Report page (Payroll for North America, Retroactive Payroll, Retro Pay, Reports, Retro Pay Request and Trigger, Retro Pay Request and Trigger Report).

Retro Trigger Detail

Select Exclude Details if you want the report to include only the overall request information. Select Include Details to additionally include detailed information about the triggers for the retro request.

(USF) Generating the Retro Pay Interest Report

Access the Retro Pay Interest Limit Report page (Payroll for North America, Retroactive Payroll, Retro Pay, Reports, Retro Pay Interest Limit, Retro Pay Interest Limit Report).

Reporting Year	The year in which the interest earnings are reported.
Limit Amount	The limit amount for the year in which you are reporting.

Retro Pay Program ID	Select the ID that identifies the earnings that this retroactive process calculates. Maintain these values in the Retroactive Pay Program table.
Start Date and End Date	The system applies the retro pay mass request to employees with effective dates in their Job records that are both: Later than, or equal to, this start date. Earlier than, or equal to, this end date. If the effective date in an employee's Job record does not fall between these start and end dates, the system selects the latest effective date that is earlier than, or equal to, the start date.
First Hire Date and Service Date	If you specify the hire date or service date, the employees' hire date or service date must be earlier than, or equal to, the effective dates of the data in the Selection Criteria group box. If you leave these fields blank, the system uses the end date.
Process End Date	Define the end of this retro period.
Process Flag	Displays the status of the process.
Delete Request	Select this check box to reverse the mass retro request, but only if you have not yet run the Retroactive Pay Calculations process for your mass retro ID. The mass retro request ID and its associated retro requests are deleted the next time you run the Retro Pay Mass Process. Note. This process works only if the retro requests for the selected mass retro request ID have not been calculated.
(USF) Eligible for Interest	Select to mark the resulting retro requests as eligible for interest.

All Mass Retro Request IDs	Select this option to process all retro requests that were created by the Retroactive Pay Mass Process.
Selected Mass Retro Request ID	Select this option to process the retro requests that were created for a particular mass retro request, and use the Mass Retro Request ID field to identify the mass retro request to process.

All Mass Retro Request IDs	Select this option to change the process flag for all retro requests that were created by the Retroactive Pay Mass Process.
Selected Mass Retro Request ID and Mass Retro Request ID	Select the Selected Mass Retro Request ID option to update the process flag in the retro requests that are associated with the mass retro request that you identify.