!!!RETROACTIVE PAY
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.


For more information on the necessary set up required to run UPRETRO see the [RETROACTIVE PAY] page.

||Report Parameters||
|__Entity__|__Mandatory, LOV Available__ \\Payroll Mandatory, LOV Available
|__From Date __|__Mandatory, Date, LOV Available__\\Used to qualify the pays to be evaluated. Only ‘closed’ pays with pay start date (on\\the [IPPH]) greater than or equal to this date will be included in the retro evaluation.
|__To Date__|__Mandatory, LOV Available__\\Used to qualify the pays to be evaluated. Only ‘closed’ pays with pay end date (on \\the [IPPH]) less than or equal to this date will be included in the retro evaluation.
|__New Pay Category__|__Mandatory, LOV Available__\\Pays will be created with the category specified in this field. Pay categories are\\defined on the [IPPGU] (U.S. Clients) and/or the [IPPGC] (Cdn. Clients).
|__New Pay Period__|__ Mandatory, LOV Available__\\Enter the pay period in which the retro assessment will be paid to employees, for  \\new retro pays.
|__Triggered Employees Only__|__Optional, Toggle__\\If chosen, only those employees with the [IEAS] field ‘Trigger Retro’ set to ‘on’ will be\\processed.
|__Update Existing Pays__|__Optional, Toggle__\\Defaults to ‘Yes’. Causes UPRETRO to create the ‘new’ retro assessment amounts \\into an existing pay ([IPPH] record, must have been created prior to running\\UPRETRO, and must be in stage ‘To Be Audited’ or ‘Audited’). This option allows \\users to pay retro on the same pay header as their ‘regular’ pay. \\Note: if users would like a separate pay (to control taxation or sundries, or to \\prevent benefits or attendance calculations from occurring), but do not want multiple\\pay stubs to be created:\\1) Choose ‘No’ for this parameter (create retro into a separate pay);\\2) Use the ‘Consolidate Disbursements’ flag on the Pay Category ([IPPGU] or\\[IPPGC]) to force one pay stub for both pays.
|__Batching Method__|__Optional, LOV Available__\\Choose a batching method (the manner in which UPRETRO will group employees \\for batch totals and administration). The same choices exist as for all other ‘batch \\creating’ programs: Authorization Area, Department, Dept. Batch Code, Location, \\Payroll or Work Area.
|__Create as Eligible__|__Optional, Toggle__\\Choose if the new batches should be flagged as ‘eligible to pay’ or not. [UPCALC] \\will ignore batches with this flag ‘off’. This flag may be manually updated on the \\ [IPBE] (Administer Batches) form, and is used to ensure that batches are not\\prematurely picked up by an [UPCALC] run.
|__Store Hours into PC__|__Optional, LOV Available__\\If chosen, all hours that are evaluated (the associated time transaction from all\\earnings pc’s with Retro triggered) may be stored into a ‘time’ PC (should be a \\special pc created for just this purpose). This might be used as a ‘checks and\\balances’ pc to audit all the hours evaluated. Note that all overtime, premium and\\regular hours will store into the one pc entered here.
|__Use IEAS Wages__|__Optional, Toggle__ \\If ON, the assignment wage will always be used during regeneration and not\\necessarily the matching one.
|__Exception Level__|__Mandatory, LOV Available__ \\Defaults to ‘Exceptions Only’, may be changed to allow users to view higher-level\\exception messages (if problems occur, or to assist in set up and testing).
|__Trial__|__Optional, Toggle__ \\If ‘OFF’ then the update is committed. \\If ‘ON’ then the update is not committed and the [UPTL] may be run again.


||Report Filters||
|__People List Code__|__Optional, Multiple Selection, LOV Available__
|__Person Code__|__Optional, Multiple Selection, LOV Available__
|__Department__|__ Optional, Multiple Selection, LOV Available__
|__Unit__|__Optional, Multiple Selection, LOV Available__
|__Group__|__Optional, Multiple Selection, LOV Available__
| |All of the above fields are used to qualify the employees to be evaluated.\\Qualifications work as ‘and’. For example, if both a department and unit are chosen, \\only employees whose records match both the department AND the unit will be \\chosen. Employees in the department, but not in the unit, will be ignored. Users may\\choose by exact matches (i.e. full Unit name “FT-Salary”), or by using ‘match’ (i.e. \\“FT%”).
|__Evaluate Categories__|__Optional, Multiple Selection, LOV Available.__ \\Used to qualify the pays to be evaluated. Only ‘closed’ pays with category matching\\those chosen in this parameter will be included in the retro evaluation. Pays of \\category type ‘Reversal’, ‘Adjustment’, and ‘Retro’ will be ignored by UPRETRO, \\regardless of entry here. (Pays that have been reversed are also ignored, \\regardless of their category).