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.
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.
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 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.
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.
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.
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.
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.
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.
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.
Screen captures are meant to be indicative of the concept being presented and may not reflect the current screen design.
If you have any comments or questions please email the Wiki Editor
All content © High Line Corporation