Retroactive Payroll Processing

Processing begins with the creation of a Retro Trigger, the record that contains the identifying information needed for the retroactive batch jobs to perform the appropriate recalculation. Triggers can be generated in three ways:

• Automatically from a change entered online - Changes to ESMT, Personnel Action, Employment Status, FTE %, Override Pay, Override Grade, Step, Pay Progression Start Date, Payroll Number/Pay Class, Title, Sub-Title, Pay Type, Rate code, and Amount/Percent.

Changes to Department Specific Data (DEPTD), Department Action, and Work Cycle.

Changes to Contract/Reserve Pay Options (COPT), Contract Action, Work Cycle, Override Contract Value Amount, Override Contract Period ID, Contract Pay – Requested, Override Days, Override Hours per Day, Reserve Pay – Requested, Override Accrual Period, and Override Payout Period.

Submission of a Check Disposition (CHCK), to update Check Status to Redeposited – Cancelled or Redeposited – Stopped.

Changes to benefits (either enrollment or rate change) via the Benefits Enrollment (BRNL), Miscellaneous Deductions (MISC), or Pension Profile (PENS) transactions.

Prior pay period time adjustments via the Timesheet Adjustment (TADJ), Group Timesheet (TIMEI) or Timesheet (TIMEI) transactions.

Note, Advantage HRM does support the ability to bypass the automatic generation of retroactive triggers if there are any transactions that a site does not wish to have retroactive triggers automatically generated for. When the BYPASS AUTO RTRG CREATION Site Specific Parameter (SPAR) is set to true, all of the transaction codes listed in the Text Value will not have retroactive triggers automatically generated. Additional information on this setting can be found in the CGI Advantage 4 HRM Site Specific Parameters User Guide.

• Manually for an individual employee - using the Retro Trigger (RTRG) transaction or Trigger Management (TRGM) activity folder.

• Enter mass change for a group of affected employees - Enter Mass Change Request for One-Time Transactions (MAS3), Run Mass Change batch process to generate RTRGs, generally used to identify employees affected by a change to the Pay Policy Rate (PPRT) table.

To control “How Far Back” retroactive payroll processing should go, the following setup should be used to set the Earliest Retro Pay Date.

• For the Site

• Use the Site Specific Parameter (SPAR) table.

• The date entered in the Text Value field will be the earliest date for which retroactive pay can be processed by the system.

• By Organization/Unit

• Use the Extended Department (DEPTX) page.

• Set the date for individual departments or department/unit combinations.

• Allows for greater flexibility of retro processing.

The system first attempts to validate trigger information against the Earliest Retro Pay Date field on the appropriate Extended Department entry. If one is not setup, the system utilizes the date in the Site Specific Parameters entry.

After creation, retro triggers reside on the retro trigger table until selection by the first retro batch job, the Select Retro Trigger job. The Select Retro Trigger job compares the parameters entered for the job to the unprocessed retro triggers in the system. All selected triggers are assigned a Retro Run Number, which allows them to be processed by the remaining retro jobs.

In order for retro triggers to be selected for processing by the Select Retro Trigger job the Retro Frequency Selection (RSEL) table must be setup. The Retro Processing Frequency (RETF) table may also be setup to provide the user with a greater level of control over which triggers are selected. The Retro Frequency Selection (RSEL) entries are utilized by selecting retro triggers for processing based on whether or not the corresponding fields on a trigger match those of an RSEL entry.

The following combinations are valid for the Retro Frequency Selection (RSEL) page:

• PYNO PACT PART DOC

• PYNO PACT PART ********

• PYNO PACT *** ********

• PYNO ***** *** ********

• ***** ***** *** ********

Wildcard entries may be used on RSEL in order to select a broader range of triggers at one time.

Retro Processing frequencies are established on RETF. Codes established on this table can then be used on both a Retroactive Frequency Selection (RSEL) entry and as a parameter for the Select Retro Trigger job to select triggers that meet the selection criteria and additionally only that specific frequency.

Utilizing RETF enables the user to have another level at which to control what triggers are and are not selected for processing.

Within the Select Retro Trigger job, the ENVVAR_AMS_UPRM2 parameter is used to enter the Retroactive frequency code for which they would like to pick up triggers. If multiple frequencies are to be selected at once, users would have to add ENVVAR_AMS_UPARM3, and so on.

What is the purpose of the Retroactive Selection Type? Retro triggers have one of three classifications, which are Retro Type IDs:

• F - FLSA Trigger

• P - Non-FLSA Pay Trigger

• O - Pending Pay Trigger

The Retroactive Selection Type parameter selects certain types:

• P – selects both non-FLSA pay and pending pay triggers

• O – selects pending retroactive pay triggers

• F – selects FLSA triggers

• B – selects all triggers

Additionally, this field can contain a Select Date.

The Retro Type ID assigned to the trigger then determines the retroactive batch jobs utilized to process that trigger.

1. Recalculate TTG Pay for Retro

• Processes triggers whose retro run number (assigned by Select Retro Trigger) matches the one entered in the job’s parameters.

• Recalculates all Time-to-Gross records for which a pay change has been retroactively made and writes an adjustment to the retro_ttg_pend_pay table (accounting information is written to the retro_ttg_pp_actg table).  

• Example: Hours are entered for an employee on a timesheet (TIMEI or TADJ). Subsequently a change is made to their pay rate. This job compares the existing pending pay table value to what the employee should have received and writes an adjustment for the difference.

• Required Parameters - The Retro Run Number must be entered to indicate the group of triggers the job may process.

• Additionally, this job can process triggers from multiple locations (either from the table or from a file that can be specified).

• The user may also indicate if historical position data should be used when processing the retro adjustment.

2. Delete/Reset Retro Triggers

• Deletes or resets all retro triggers selected for the current retro run (i.e. for the last retro run number assigned by Select Retro Trigger job).

• Provides users with the option of being able to catch and correct mistakes within the job stream.

• Required Parameters - To run the Delete/Reset Retro Triggers job, simply set the Retro Trigger Reset type parameter to ‘R’ if the triggers are to be reset, and likewise to ‘D’ if the triggers are to be deleted.

3. Extract Pay Data for Retro Calculations & Retro Pay Calculation

• The Extract Pay Data for Retro Calculations job utilizes output from the Select Retro Triggers job to selectively write pending payment, pay detail, and archived pay detail records to a file.

• The Retro Pay Calculation job writes retroactive adjustments for regular (non-FLSA) pay triggers. The recalculated value is output to the retro_pend_pay table.

• Required Parameters - All parameters are self-explanatory for these jobs, with exception of the HAB3150 user parameter, ENVVAR_AMS_UPRM1 which contains 5 columns:

• Column 1: Enter the Retroactive Selection Type: P, O, F, or B (according to what has been used in prior jobs)

• Column 3: Enter the Payment Status

• N – Payment is ready for Processing

• Y – Payment is Held

• Column 5: Enter the Supplemental Type ID to be used in creating Pending Payments:

• T – Payment will be picked up by Retro Supp Run

• R – Payment will be picked up by a replacement Supp Run

• P – Payment will be picked up by a By-Pay-Type or Multi-Pay Supp Run

• ‘ ‘ (blank space) – Payment will be picked up by a regular Gross-to-Net run

• When the multi-state feature is enabled, the state codes for the retroactive non-FLSA pay events are not generated on the RETRO_PEND_PAY table.  The state codes for the retroactive pay events are generated during GTN.

4. Extract Pay Data for Retro FLSA Calculation & Retro FLSA Calculation

• The Extract Pay Data for Retro FLSA Calculations has the same functionality as the regular Extract Pay job, it simply processes FLSA triggers as opposed to non-FLSA triggers.

• The Retro FLSA Pay Calculation job recalculates FLSA pay and compares the results to those of the original FLSA payments, the differences are written to pending payments.

• Required Parameters - The HAB3250 parameter for this job is setup in the same way as the HAB3150 parameter for the Retro Pay Calculation job. The one difference is that instead of using an entry of ‘B’ to select all triggers in the first column, an ‘F’ is utilized to select only FLSA triggers.

• When the multi-state feature is enabled, the state codes for the retroactive FLSA pay events are not generated on the RETRO_PEND_PAY table. The state codes for the retroactive pay events are generated during GTN.

5. Retro Run Cleanup

• The Retro Run Cleanup job first copies records for the current retro run from:

• Retro_Pend_Pay & Retro_TTG_Pend_Pay to Pend_Pay

• Retro_TTG_PP_ACTG  Pend_Pay_Actg

• This job then purges all records on the retro tables associated with the retro run number entered as a job parameter. This includes the tables above for which it has already copied over the selected records. Additionally, this job purges the retro trigger table itself.

• Required Parameters - Users must enter the Retro Run Number as a parameter for this job, indicating which records should be copied and then purged from the retro tables.

• When the multi-state feature is enabled, the state codes for the retroactive non-FLSA and FLSA pay events are not generated on the PEND_PAY table.The state codes for the retroactive pay events are generated during GTN.

Retro adjustments are viewable within the Payroll Management Activity Folder (PAYM) under the Pending Payment tab.

The retroactive sequence number, if greater than zero, indicates that the pending payment was created by retroactive pay processing. For instance, a retroactive sequence number of ’02’ indicates that this is the second time retro was calculated for this pay event.

When the multi-state feature is enabled, the state codes for the retroactive non-FLSA and FLSA pay events are not generated on the Pending Payment tab. The state codes for the retroactive pay events are generated during GTN.

• Out of the Box Retro Reports

• Processing Retroactive Pay Differentials