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