Reviewing Retro Pay Requests

If the employee has multiple jobs, the system creates separate retro pay requests for each job.

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.

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.

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.

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 Retro Pay Cancellation Reason Page.

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.

Displays the date that the system created the retro request.

The system uses this date to determine the last pay period to recalculate.

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.

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.

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.

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.

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.

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.

Displays the record where the triggering event occurred: JOB or ADDL_PAY_DATA.

Displays the user ID of the person who made the change that triggered the retro request.

Displays the name of the field that changed.

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.

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.

Displays the type of data change: Insert, Update, or Delete.

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.