The UBRETRO facility was designed to calculate retro amounts on benefit deductions when an employee receives a pay increase.  

!!Custom Functions
New Custom Functions - P2K_CF_WAGE_RATE and P2K_CF_PREMIUM.  These new custom functions have been created to be used with UserCalcs which allow us to determine an employee's wage rate and premium rate based on dates defined in the UserCalc. These new functions are defined in the lexicon 'X_UC_FUNCTIONS'.  If the functions are not listed in X_UC_FUNCTIONS lexicon, they can be manually added to the lexicon in {IMLN} 

The function 'P2K_CF_WAGE_RATE' will pass the wage rate from the employee's assignment as of the date found in the Global Variable 'CF WAGE DATE';  

The function 'P2K_CF_PREMIUM' will pass the value of an employee's premium from their assignment as of the date found in the Global Variable 'CF PREMIUM DATE' and for the premium type defined in the Global Variable 'CF PREMIUM TYPE'.

These calculations are based on the employee's Prime Assignment only.

The Global Variables must be named and created exactly as shown below:
CF PREMIUM DATE  - this is a 'DATE' type global variable
CF PREMIUM TYPE - this is a 'CHAR' type global variable
CF WAGE DATE - this is a 'DATE' type global variable


!!Sample User Calculation
Global Variables are needed to invoke the new custom function logic available in UserCalcs.  The must be named exactly as shown:  CF WAGE DATE, CF PREMIUM DATE, CF PREMIUM TYPE

Usercalc Example:  Capture wage rate and premium rate as of pay issue date
The following UserCalc was written to capture the employee's wage rate and premium rates as per the Pay Issue Date and return the combined amounts to be used in the benefit calculation.  This is a 'Function' type UserCalc and will return the value of the wage rate plus premium rate to the appropriate benefit component.

||LINE||CMD ||TYPE 1||OPERAND 1      || OPER||TYPE 2||OPERAND 2  || TYPE 3||OPERAND 3||IF GO TO||ELSE GO TO||NOTES        ||
| 100  | LET |  $G    |CF WAGE DATE|  EQ |   DB   |  PPH.PAY_ISSUE_DATE|        |           |   110   |     |              |
| 110  | LET |  V     |BASE WAGE   |  EQ |   CF   |  P2K_CF_WAGE_RATE  |        |           |   200   |     |              |
| 200  | LET |  $G    |CF PREMIUM DATE|EQ|   DB   |  PPH.PAY_ISSUE_DATE|        |           |   210   |     |              |
| 210  | LET |  $G    |CF PREMIUM TYPE|EQ|   A    |  CCR REG           |        |           |   220   |     |            |  
| 220  | LET |  V     |CCR            |EQ|   CF   |  P2K_CF_PREMIUM    |        |           |   300   |     |              |
| 300  | LET |  $G    |CF PREMIUM DATE|EQ|   DB   |  PPH.PAY_ISSUE_DATE|        |           |   310   |     |              |
| 310  | LET |  $G    |CF PREMIUM TYPE|EQ|   A    |  CORR_ASSIGN       |        |           |   320   |     |              |
| 320  | LET |  V     |CORR ASSIGN    |EQ|   CF   |  P2K_CF_PREMIUM    |        |           |   400   |     |              |
| 400  | LET |  $G    |CF PREMIUM DATE|EQ|   DB   |  PPH.PAY_ISSUE_DATE|        |           |   410   |     |              |
| 410  | LET |  $G    |CF PREMIUM TYPE|EQ|   A    |  HPL               |        |           |   420   |     |              |
| 420  | LET |  V     |HPL            |EQ|   CF   |  P2K_CF_PREMIUM    |        |           |   500   |     |              |
| 500  | LET |  $G    |CF PREMIUM DATE|EQ|   DB   |  PPH.PAY_ISSUE_DATE|        |           |   510   |     |              |
| 510  | LET |  $G    |CF PREMIUM TYPE|EQ|   A    |  LPL               |        |           |   520   |     |              |
| 520  | LET |  V     |LPL            |EQ|   CF   |  P2K_CF_PREMIUM    |        |           |   600   |     |              |
| 600  | LET |  V     |BENEFIT WAGE   |ADD|  V    |  BASE WAGE         |   V    |CCR        |   610   |     |              |
| 610  | LET |  V     |BENEFIT WAGE   |ADD|  V    |  BENEFIT WAGE      |   V    |CORR ASSIGN|   620   |     |              |
| 620  | LET |  V     |BENEFIT WAGE   |ADD|  V    |  BENEFIT WAGE      |   V    |HPL        |   630   |     |              |
| 630  | LET |  V     |BENEFIT WAGE   |ADD|  V    |  BENEFIT WAGE      |   V    |LPL        | 99999   |     |              |
|99999 | RET |  V     |BENEFIT WAGE   |


!!Calculate Retro Benefit Amounts
The function UBRETRO was developed to process retro calculation amounts on benefit components.  Benefit amounts requiring a retro calculation must have been generated during the benefit process in UPCALC in order for UBRETRO to process and re-calculate the retro benefit amounts.  Pay components requiring a retro calculation must have a "Retro PC' defined.  These retro pay components may need to be added to elements (i.e. Total Deductions, Pre Tax Elements, etc..)

__Caveats\\__
* UBRETRO will not process pay headers where no benefits have been calculated\\
* UBRETRO will not calculate benefit retro amounts unless the employee is enrolled in a benefit plan\\
* A pay header at a 'To Be Audited' stage must be created for the employees before you can run the UBRETRO process\\

When the UBRETRO process is run in 'Update' mode, a User Defined Field on the IPPH called 'Posted UBRETRO' is updated with a value of 'Y'.

The following can be done if UBRETRO was run in update mode and needs to be rerun:\\

__Option 1__
*Cancel the Pay Header(s) manually or run UPCBAT and run UPAUDT to delete the Pay Headers.  You can then create a new Pay 
   Header and rerun the UBRETRO process

__Option 2__
* Delete the lines created in the Pay Header, remove the 'Y' in the 'Posted UBRETRO' user-defined field on the Pay header and then run UPAUDT.  You will need to make a change in the Pay Header to reset the stage to 'To Be Audited'.  The UBRETRO process may then be rerun.

!!Retroactive Benefit Calculation Program

Report Parameters
;[Entity]
Select the entity for which you wish to run this process for
;[Payroll]
Select the payroll for which you wish to run this process for
;[Pay_Period]
This represents the current pay period for the batch where the Retro Lines will be "inserted".  There should only be one pay header available to be used.\\ __Note: if there is no pay header available for the employee, the retro amount will not be calculated.__
;[Retro_Start_Period]
This represents the starting retro pay period for which the calculations will be processed
;[Retro_End_Period]
This represents the ending retro pay period for which the calculations will be processed
;[Triggered_Employees]
This restricts the list of employees to those who have the 'Trigger BE Retro' toggle 'On' at the assignment.  Once UBRETRO has been run in the Non Trial mode, the toggles will be turned 'Off'
;[Benefit_Plans]
This represents the benefit plans to be processed.  Multiple plans may be selected
;[Plan_Coverages]
This represents the coverages to be processed; the list of coverages will be restricted based on the benefit plans selected above
;[Trial]
If the value of this field is 'Yes', then the process will be run in trial mode and the data will not be saved to the database.  If Trial is set to 'No', then the process will be run in update mode and the changes will be saved to the database.

__NOTE: It is always recommended to run the program in TRIAL first and verify the results before running it in update mode.__

;[Exception_Level]
The program can be run with various levels of exceptions and depends on the level of detail required; the higher the exception level, the greater the amount of detail.
;[User_Comment]
This field allows users to enter a short comment that will be visible on the first page of the report
;[Report_Filters]
The following report filters are used to restrict who in the batch should be reviewed and/or updated\\
* __People List Code__\\
      People lists can be used to select groups of employees based on specific criteria\\__NOTE: This filter looks at the 
      employee's assignment details based on the pay period end date of the pay period defined in the 'Pay Period' 
      parameter__\\
\\
* __Person__\\
      Individual employees can be selected for processing\\
* __Batch Number__\\
      Individual batch numbers can be selected for processing\\
* __Department__\\
      Individual departments can be selected for processing\\
      __NOTE: This filter looks at the employee's assignment details based on the pay period end date of the pay period 
      defined in the 'Pay Period' parameter__\\
* __Unit__\\
      Individual units can be selected for processing\\
      __NOTE: This filter looks at the employee's assignment details based on the pay period end date of the pay period 
      defined in the 'Pay Period' parameter__\\
* __Group__\\
      Individual groups can be selected for processing\\
      __NOTE:  This filter looks at the employee's assignment details based on the pay period end date of the pay period 
      defined in the 'Pay Period' parameter__\\



;[Retro_Benefit_Calculations_Based_On_Earnings]
When an employee receives a retroactive pay increase, their benefit deductions may need to be recalculated to include the retro earnings.

The standard retroactive pay program [UPRETRO] will calculate the difference between the old and new wage rates and insert a pay line into the current period's pay header for each pay line that was evaluated.  

!Set Up Requirements
;[Pay_Component]
The program will only process for pay components attached to benefit plans that have a 'Retro' pay component attached to the 'Retro Pay' tab on [IPPC].  It is important to update the appropriate element if new 'retro' pay components are created



In order to ensure that retro wages are used in the benefit calculation and are picked up in the correct period a UserCalc (as shown below) is required to capture the retro earnings.  This usercalc sample would be associated to the benefit plan [IBPN] as B0320


||LINE||CMD ||TYPE 1||OPERAND 1     ||OPER||TYPE 2||OPERAND 2   ||TYPE 3||OPERAND 3||IF GO TO||ELSE GO TO||NOTES          ||
| 100 | LET | V     | Base Earnings | EQ  | EC    | PT_STD_EARN |       |          |  110    |           | The purpose of this usercalc is to capture the earnings used in part time pension calculations.  Only retro earnings that have dates within the pay period should be processed.  Retro earnings should be used to calculate 'retro' benefits for the pay period they are earned in
| 110 | LET | V     | ELPL.BEGIN_DATE| EQ | $S     | PERIOD_START_DATE|  |          |  120    |           |
| 120 | LET | V     | ELPL.END_DATE  | EQ | $S     | PERIOD_END_DATE  |  |          |  130    |           |
| 130 | LET | V     | RETRO EARNINGS | ELPL|ET     | RETRO EARNINGS   |  |          |  140    |           |
| 140 | LET | V     | TOTAL EARNINGS | ADD |V      | BASE EARNINGS    |V | RETRO EARNINGS| 99999|         |
|99999| RET | V     | TOTAL EARNINGS |     |       |                  |  |          |         |           |

!!Processing Information

;[Entity]:
            This is a required field the user must select the correct entity to process
;[Payroll]:
            This is a required field the user must select the correct payroll to process
;[Pay_Period]:
            This is a required field the user must select the correct pay period to process.  This represesents the pay period for the batch where the retro lines will be inserted.  There should only be one pay header available to be sued.  -NOTE - if there is no pay header available for the employee, the retro amount will not be calculated-