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

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

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
99 26-Nov-2021 10:22 12 KB jlawler to previous
98 26-Nov-2021 10:22 12 KB jlawler to previous | to last
97 26-Nov-2021 10:22 12 KB jlawler to previous | to last
96 26-Nov-2021 10:22 11 KB khiggs to previous | to last
95 26-Nov-2021 10:22 11 KB khiggs to previous | to last
94 26-Nov-2021 10:22 11 KB khiggs to previous | to last
93 26-Nov-2021 10:22 10 KB mhodgins to previous | to last
92 26-Nov-2021 10:22 10 KB mhodgins to previous | to last
91 26-Nov-2021 10:22 10 KB mhodgins to previous | to last
90 26-Nov-2021 10:22 10 KB mhodgins to previous | to last
89 26-Nov-2021 10:22 10 KB mhodgins to previous | to last
88 26-Nov-2021 10:22 12 KB mhodgins to previous | to last
87 26-Nov-2021 10:22 12 KB mhodgins to previous | to last
86 26-Nov-2021 10:22 12 KB mhodgins to previous | to last
85 26-Nov-2021 10:22 11 KB mhodgins to previous | to last
84 26-Nov-2021 10:22 11 KB mhodgins to previous | to last
83 26-Nov-2021 10:22 11 KB mhodgins to previous | to last
82 26-Nov-2021 10:22 11 KB mhodgins to previous | to last
81 26-Nov-2021 10:22 11 KB mhodgins to previous | to last

Page References

Incoming links Outgoing links
UBRETRO
UBRETRO

Version management

Difference between version and

At line 1 changed one line
!!__RETROACTIVE BENEFIT EARNINGS AMOUNTS__
The UBRETRO facility was designed to calculate retro on benefit deductions when an employee receives a pay increase.
At line 3 added 2 lines
;[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.
At line 4 removed 3 lines
!__Features__
The UBRETRO facility was designed to calculate retro amounts on benefit deductions when an employee receives a pay increase. Benefit deductions may need to be recalculated to include the retro earnings.
At line 9 changed one line
!__UPRETRO/UBRETRO key processing differences__
!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
At line 11 changed one line
[UPRETRO] and UBRETRO work differently with regards to pay header requirements.
;[Custom_Functions]
The following custom functions are required - P2K_CF_WAGE_RATE and P2K_CF_PREMIUM. 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';
At line 13 removed 21 lines
In the case of [UPRETRO] the program will include all the old pays that are to have retro calculated. Prior to launching UPRETRO all the pay’s that will be processed will be displayed using the “List” button on [UPRETRO].
[UPRETRO] will create a new pay if there is no applicable pay header or will update an existing pay header if no applicable pay header can be found.
UBRETRO behaves differently in that it does not create a pay header. Instead prior to processing, UBRETRO requires the creation of a single "To Be Audited" pay for the specific pay period in which the retro amounts are to appear.
Therefore the “[Trigger BE Retro|TRIGGER_BE_RETRO]" toggle found on [IEAS] must be enabled on a EASD record that has effective and expiry dates that fall within the specified pay period start and end dates on the pay header selected.
If there are no "To Be Audited" pays that fall in period specified on the EASD records, than UBRETRO will not process.
!!New Custom Functions
Two New Custom Functions
* P2K_CF_WAGE_RATE\\
* 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'.
At line 36 changed one line
These calculations are based on the employee's Prime Assignment only.
Review the lexicon [IMLN] X_UC_FUNCTIONS. These functions may be manually added if not already there.
At line 38 changed 4 lines
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\\
;[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
At line 43 changed 8 lines
!!Sample User Calculation
Global Variables are needed to invoke the new custom function logic available in UserCalcs. They must be named exactly as shown below:\\
* CF WAGE DATE\\
* CF PREMIUM DATE\\
* CF PREMIUM TYPE
Usercalc Example: Capture wage rate and premium rate as of pay issue date\\
Usercalc Example: Capture wage rate and premium rate as of pay issue date
At line 54 changed 19 lines
| 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 |
|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 | | |
At line 75 removed 2 lines
!!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..)
At line 78 removed 7 lines
__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 employee before you can run the UBRETRO process\\
*A report parameter __Post Negative Retro__ controls if negative amounts should be posted to IPPH. If set to __NO__ the negative amounts are not recorded; however, exception messages will still be logged.
*Reversals and pays that have been reversed are ignored
*Unit and Group information is obtained from the assignment, not the from the __old__ pay header being evaluated.
At line 86 changed one line
The following can be done if UBRETRO was run in update mode and needs to be rerun:\\
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
At line 88 removed 3 lines
__Option 1__
*Cancel the Pay Header(s) manually or run UPCBAT and run UPAUDT to delete the Pay Headers. You may then create a new Pay
Header and rerun the UBRETRO process
At line 92 removed 18 lines
__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.
!!Set Up Requirements
;[Pay_Components]
The UBRETRO program will only process for pay components attached to benefit plans that have a 'Retro' PC attached to the 'Retro Pay' tab on [IPPC]. It is important to update the appropriate element if new 'retro' pay components are created.
;__High Line Recommendations:__\\
* Create unique pay components to store the retro amount
* Create unique pay components for adjustments
!Retro Benefit Calculations Based on Earnings\\
When an employee receives a retroactive pay increase, their benefit deductions may need to be re-calculated to include the retro earnings.
The standard retroactive pay program (UPRETRO) will calculate the difference between the old and new wage rates and will insert a pay line into the current period's pay header for each pay line that was evaluated. 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.
The UserCalc example listed below us the Part Time Pension calculation and is associated to B0320 on the PT_PENS plan
At line 118 changed one line
!!Retroactive Benefit Calculation Program
!!Processing Information
At line 120 changed 32 lines
||Report Parameters||
| Entity | Mandatory, LOV Available
| Payroll | Mandatory, LOV Available
| Pay Period | Mandatory, Date LOV Available\\ If there is no pay header available for the employee, the retro amount will not be calculated
| Retro Start Period | Mandatory, LOV Available
| Retro End Period | Mandatory, LOV Available
| Triggered Employees| Mandatory. Yes/No\\Restricts the list of employees to only those who have the 'Trigger BE Retro' toggle 'On' at the assignment level
| Plan Coverages | Mandatory, Lexicon Available
| Benefit Plans | Mandatory, Lexicon Available
| Trial | Optional, Toggle\\If 'Off' then the update is committed\\If 'On' the update is not committed and UBRETRO may be processed again\\
|Post Negative Retro| Optional, Toggle\\If 'Yes' then negative amounts will be posted on the pay header\\If 'No' the negative amounts will not be posted\\In both cases exception messages will appear on the report
| 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).
| User Comment | Allows users to enter a short comment that will be visible on the report
||Report_Filters||
| People List Code | People Lists may be used to select groups of employees based on specific data\\__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 may be selected for processing
| Batch Number | Individual bath numbers may be selected for processing
| Department | Individual departments may 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 may 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 may be selected for processing\\__NOTE: This filters looks at the employee's assignment details based on the pay period end date of the pay period defined in the 'Pay Period' paramater
----
![Notes|Edit:Internal.UBRETRO]
[{InsertPage page='Internal.UBRETRO' default='Click to create a new notes page'}]
;[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-
This page (revision-99) was last changed on 26-Nov-2021 10:22 by jlawlerTop