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