This page (revision-21) was last changed on 26-Nov-2021 10:22 by jmyers

This page was created on 26-Nov-2021 10:22 by JEscott

Only authorized users are allowed to rename pages.

Only authorized users are allowed to delete pages.

Page revision history

Version Date Modified Size Author Changes ... Change note
21 26-Nov-2021 10:22 11 KB jmyers to previous

Page References

Incoming links Outgoing links

Version management

Difference between version and

At line 68 changed one line
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.
In all cases it is the ‘Output’ (Earnings) [pay component|PAY COMPONENTS] 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 [{$applicationname}].
----
!PAY COMPONENTS
The ‘Retro Pay’ tab is populated ONLY for the earnings [pay components|PAY COMPONENTS] and NOT for the time [pay components|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|PAY COMPONENTS].
;:The ‘Retro Pay’ Tab is populated ONLY for the earnings [pay components|PAY COMPONENTS] (NOT for the time [pay components|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|PAY COMPONENTS] 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|PAY COMPONENTS] 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|USERCALC] that will be used to calculate the retro amount for this pay component. See the ‘Features’ section for more notes on [UserCalcs|USERCALC].
----
!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’.
[{$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 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.