Table of Contents

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 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. The Retro PC can also point to a different PC, in which case any wage adjustments are recorded into the separate PC. The advantages/disadvantages of storing retro results into the original or a new pay component should be discussed with a Consultant.

The IPPC ‘Retro Evaluation Method’ allows you to define if the pay component 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) would be evaluated and assessed with a 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. 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 must be created to calculate the retro amount. This UserCalc must be added to the originating pay component 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 must be of type ‘Calculation’. The UserCalc will be performed each time the triggered pay component is found on the selected pays.

UserCalcs used for retro have all employee demographics and pay header information available to them (as if they were executed from within UPCALC). The UserCalc also has access to any pay component (Pay Amount) values from the pay selected (by reading or using PC or Element information).

UserCalcs 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 amount that updated/ created the statistic.

Output from the 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, 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).

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

RETROACTIVE PAY SET UP#

The following outlines the required set up to implement Retroactive Payroll in Wiki.

PAY COMPONENTS - IPPC#

The ‘Retro Pay’ tab is populated ONLY for the earnings pay components and NOT for the time pay components.
Retro PC (mandatory to trigger retro, otherwise optional)
Triggers the Retro process. Only PC’s with this field populated will be assessed.
If the ‘Retro Evaluation Method’ = By Pay Line, the pay component will be used to store the Retro Assessment for this originating pay component.
The ‘Retro Pay’ Tab is populated ONLY for the earnings pay components (NOT for the time pay components).
  • For example, PC 1100 is the ‘Earnings’ associated with Time PC 100.
  • In this example, the Retro Assessment will be processed into a different pay component from the original earnings (PC 1101).
Abbreviation (defaults)
This filed holds the abbreviation of the ‘Retro PC’. This information cannot be updated here.
Retro Evaluation Method (mandatory for retro, otherwise optional)
The example above depicts the set up required for the ‘By Pay Line’ method. See the ‘Features’ section for detailed notes on this method. If chosen, UPRETRO will process all pay lines with pay component matching the originating PC (in this example, PC 200) and store the results in the ‘Retro PC’ entered (also PC 200).
If ‘Retro Evaluation Method’ = By Pay Component, a UserCalc MUST be created and entered in the ‘User Calc’ field. The output of UPRETRO for this triggering PC will not store in the ‘Retro PC’ entered. The output stores into whichever PC (or PC’s) are used in the UserCalc line(s) ‘Let PC xxxx = nnnn’. The ‘Retro PC’ is used only to trigger the UPRETRO process for this PC.
Retro User Calc (optional)
If method = ‘By Pay Component’, enter the name of the UserCalc that will be used to calculate the retro amount for this pay component. See the ‘Features’ section for more notes on UserCalcs.

ASSIGNMENT - IEAS (EMPLOYEE TRIGGERS)#

Employee assignments can be marked as ‘X Trigger Retro’.

UPRETRO can be executed for only ‘Triggered Employees’ for explicit employee selection.

When UPRETRO is executed, it will remove the trigger for those employees selected.

RETROACTIVE PAY PROCESS#

Retroactive pays are generated by running UPRETRO.

Retro handles any number of employees in one execution.

Selection is available by entity, payroll, unit, group, department, employee and pay category.

Retro monies can update existing pays or be inserted into new pays.

New pays are inserted into batches as determined by the ‘Batching Method’ provided report selection.

For example, batches can be created by ‘Department’ if desired.
When evaluation 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.

The newly created batch will be assigned a ‘Batch Source’ of ‘UPRETRO - Retroactive Pay’.

Wiki 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 you choose to use the original pay components and pick up retro in the next regular pay, there will be no way to tax it differently.

Notes #

Click to create a new notes page
This particular version was published on 26-Nov-2021 10:22 by JAiken.Top