!!FEATURES
The Retroactive Pay facility is designed to provide a means to use historical pay information and create earnings and deductions ‘differences’ for the employee in a new pay. It is usually invoked after a change in a contract (union agreement) and can affect wages, premiums, benefits, or any other pay component.
Typically changes are ‘backdated’ to the date they should have been made.
You will select the employees, types of historical pays, and the [pay components|PAY COMPONENTS] to be processed to produce the required retro pay.
----
!Choosing Employees to Process
Employees to be processed may be selected individually, with a people list, by entity, payroll,department, unit, or group.
Employees to be processed may be further qualified by selecting ‘triggered employees only’. If selected, only those employees with the Assignment ([IEAS]) ‘Trigger Retro’ flag set to ‘On’ will be included. This is an optional feature.
----
!Choosing Historical Pays to Process
* Pays to be included may be qualified by category.
* Pays that have been reversed are not included.
* Pays with type ‘Reversal’ or ‘Adjustment’ are not included.
* Previous ‘Retro’ pays are also not assessed (although the earnings paid in them are used if a retro ‘overlaps’ a previous retro – see more on this feature below).
* Pays to be included are selected based on ‘From’ and ‘To’ dates provided on the selection screen.
----
!Choosing Historical Pay Amounts to Update
If a retro amount is to be assessed, the original pay component that stored the earnings or deduction amount must include a ‘retro’ pay component. This is done by completing the Retro PC field, on the Retro Pay tab of the Pay Component Definition ([IPPC]) form.
The Retro PC can point to itself, in which case any assessed wage adjustments are made into the original [PC|PAY COMPONENTS]. The Retro PC can also point to a different [PC|PAY COMPONENTS], in which case any wage adjustments are recorded into the separate [PC|PAY COMPONENTS]. The advantages/disadvantages of storing retro results into the original or a new [pay component|PAY COMPONENTS] should be discussed with a High Line Consultant.
The [IPPC] ‘Retro Evaluation Method’ allows you to define if the [pay component|PAY COMPONENTS] is to be evaluated based on Pay Line information (‘By Pay Line’), or based on Pay Amounts information (‘By Pay Component’). Generally, pay or premium increases would be assessed using the ‘Pay Line’ method and changes in benefits or deductions (or amounts originally calculated with a [UserCalc|USERCALC]) would be evaluated and assessed with a [UserCalc|USERCALC].
Retroactive pay assessed by PC does NOT handle the ‘Retro on Retro’ capability since retro money paid is not stored anywhere.
Pay Lines are transactions for time, earnings, and premiums that were keyed by users, loaded, or generated by programs such as [UPTG]/[UPTR]. If the ‘By Pay Line’ method is chosen, the original pay lines are temporarily regenerated and the difference between the ‘new’ rate and the rate paid is calculated. These differences (in earnings, including premiums) become new pay lines, using the ‘Retro PC’ specified on the originating PC. This method is the easiest, from a users point of view, since no other intervention is necessary to create the retro amounts.
When the evaluation is done by Pay Line, the evaluation process will respect all ‘Wage’ related information. Accuracy will be as good as the maintenance done to the supporting files such as assignment, position, job, user variables, premiums, etc. Changes to this ‘wage sensitive’ data must be backdated properly before using the retro feature.
Pay amounts are the values stored in the [P2K_PR_PAY_PC_AMOUNTS] table (they can be viewed on the [IPPH] Pay Amounts tab). These amounts come from a variety of sources; pay lines, benefits and attendance output, or [UserCalcs|USERCALC]. If the original pay amount was calculated by any other source than pay lines, then the ‘By Pay Component’ method must be used and a [UserCalc|USERCALC] must be created to calculate the retro amount. This [UserCalc|USERCALC] must be added to the originating [pay component|PAY COMPONENTS] in the ‘Retro User Calc’ field.
Retro is based solely on a difference in a generated value, therefore will only work if the money is generated and NOT if it is configured to be an ‘Entered Value’.
----
!UserCalcs for Retro (only used for method ‘By Pay Component’)
[UserCalcs|USERCALC] must be of type ‘Calculation’. The [UserCalc|USERCALC] will be performed each time the triggered [pay component|PAY COMPONENTS] is found on the selected pays.
[UserCalcs|USERCALC] used for retro have all employee demographics and pay header information available to them (as if they were executed from within [UPCALC]). The [UserCalc|USERCALC] also has access to any [pay component|PAY COMPONENTS] (Pay Amount) values from the pay selected (by reading or using PC or Element information).
[UserCalcs|USERCALC] used for retro do not have access to old statistic amounts from the statistic file (the statistic file only holds its value as of the most recent closed pay and does not hold historical information). They do, however, have access to the [pay component|PAY COMPONENTS] amount that updated/ created the statistic.
Output from the [Usercalc|USERCALC] (Via ‘Let PC =’) is recorded as the Retro Assessment. These results may be accessed using the ‘transaction to date’ operand (PT or ET).
Note that when using a [UserCalc|USERCALC], the ‘Let PC = ‘UserCalc line determines where (which Pay Component) the assessment is to be recorded. The ‘Retro PC’ from the PC definition is only used as output when the Pay Component Retro Method is ‘Pay Line’ method.
----
!Paying the Retro Amounts
Values generated by the retro process can update existing open Pay Headers ([IPPH] Timesheets) or the program can create new pay headers and insert the retro assessment lines into them.
If the retro assessment is to be stored into new pays, the pays are created in batches, as determined by the ‘Batching Method’ provided in the report selection.
;:For example, batches can be created ‘by Department’, if desired.
Batches created by the program are given a ‘Batch Source’ of ‘[UPRETRO] - Retroactive Pay’. This can be used to identify batches created manually (on [IPBE]) from batches created by the [UPRETRO] program.
As each Pay Line is evaluated, the Retro money assessed for that line is recorded on that original pay line. Therefore, if Retro is given twice, only the difference between the original Retro and the new Retro will be awarded.
;:Example:
;:1997 Wage Rate = $10/hr
;:In 1999, the contract is updated with 2 retro increases: 1998 Wage Rate = $11/hr 1999 Wage Rate = $11.75/hr
;:If [UPRETRO] was run on these 2 increases (after updating the [IEAS] with appropriate backdated records), the 1st [UPRETRO] run would record $1.00 in Retro paid. The 2nd [UPRETRO] run would recognize that $1.00 has previously been awarded, and create a transaction for the difference ($0.75). A warning message “Retro amounts of $1.00 previously awarded on period 2000-05” will appear on the exception report in this case.
;:Note that both [UPRETRO] runs could be processed into the same pay or separate pays, as required by the client (using [UPRETRO] parameters).
[{$applicationname}] must be able to identify Retro Pay in some manner to be able to tax the income separately. This can be accomplished either by creating a new pay in a different ‘Pay Category’, or by choosing a different pay component for retro. Either way, the income can be identified. If the original pay components are used and stored into a ‘Regular’ pay, there will be no way to tax it differently.
The output report prints exception messages only. If the exception level is increased to ‘User’ level, then exceptions are produced for all retro pays generated.
In all cases it is the ‘Output’ (Earnings) pay component that is evaluated and NOT the ‘Input’ (Time) pay component. Be careful to apply Retro set up to the correct IPPC entries.