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

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

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
24 26-Nov-2021 10:22 26 KB kparrott to previous
23 26-Nov-2021 10:22 25 KB rforbes to previous | to last
22 26-Nov-2021 10:22 25 KB jmyers to previous | to last
21 26-Nov-2021 10:22 26 KB JMyers to previous | to last

Page References

Incoming links Outgoing links
USING SALARY RATE METHODS
USING SALARY RATE METHODS

Version management

Difference between version and

At line 9 changed one line
Since earnings are generated from the hours which are generated daily, it is likely that generated earnings will be off by pennies from the employee semi monthly or monthly wage. This is handled by ‘Force Balance’ logic, invoked when the transactions are brought into payroll (UPTR).
Since earnings are generated from the hours which are generated daily, it is likely that generated earnings will be off by pennies from the employee semi monthly or monthly wage. This is handled by ‘Force Balance’ logic, invoked when the transactions are brought into payroll ([UPTR]).
At line 13 changed 3 lines
There is also a new ‘Pay Line Based’ premium that can be used in place of the ‘UPTG Period $$$’ premium. The problem with the UPTG premium is that it creates ‘Dollars Only’ into the IPTR screen, which means that the premium dollars from the hours worked in the period are not naturally generated into payroll. If not generated from hours, the UPRETRO would not be able to create the retro in the past. The correct way to handle a ‘Pay Period Premium’ is to use this new type. It will be generated from the hours worked (which may vary), and the dollars assigned to each hour will be computed by P2K correctly so that the total will equal the Period Premium Amount. To account for any penny difference, the premium is ‘Force Balanced’ when the transaction is brought into payroll during the execution of UPTR.
\\
----
There is also a new ‘Pay Line Based’ premium that can be used in place of the ‘UPTG Period $$$’ premium. The problem with the [UPTG] premium is that it creates ‘Dollars Only’ into the [IPTR] screen, which means that the premium dollars from the hours worked in the period are not naturally generated into payroll. If not generated from hours, the [UPRETRO] would not be able to create the retro in the past. The correct way to handle a ‘Pay Period Premium’ is to use this new type. It will be generated from the hours worked (which may vary), and the dollars assigned to each hour will be computed by P2K correctly so that the total will equal the Period Premium Amount. To account for any penny difference, the premium is ‘Force Balanced’ when the transaction is brought into payroll during the execution of [UPTR][.
\\ \\
----
At line 19 changed one line
On the IPPC form, PC Details Rules tab, a new salary rate method is added to point individual pay components to the Variable Rate or Variable Time. This will allow the user to select a different rate calculation for different types of time (i.e. Regular or LWOP).
On the [IPPC] form, PC Details Rules tab, a new salary rate method is added to point individual pay components to the Variable Rate or Variable Time. This will allow the user to select a different rate calculation for different types of time (i.e. Regular or [LWOP]).
At line 27 changed one line
The employees will have their salary calculated based on time, not the current method of generating a SM/MO salary amount in UPTG. Using this method, UPTG will support pay period employee changes such as new hires, terminations, salary changes and leaves.
The employees will have their salary calculated based on time, not the current method of generating a SM/MO salary amount in [UPTG]. Using this method, [UPTG] will support pay period employee changes such as new hires, terminations, salary changes and leaves.
At line 31 changed one line
Since the time will be generated by day and each day will have an associated dollar amount, the standard FLSA calculations will be supported.
Since the time will be generated by day and each day will have an associated dollar amount, the standard [FLSA] calculations will be supported.
At line 34 changed one line
Pay period earnings are force balanced during UPTR to compensate for any earnings variance caused by earnings generation on a daily basis daily.
Pay period earnings are force balanced during [UPTR] to compensate for any earnings variance caused by earnings generation on a daily basis daily.
At line 37 added one line
At line 38 changed 2 lines
\\
----
\\ \\
----
At line 42 changed 2 lines
\\
----
\\ \\
----
At line 50 changed one line
\\
\\ \\
At line 69 changed 2 lines
\\
----
\\ \\
----
At line 72 changed one line
The key to computation of the variable rate is to divide the semi monthly wage by a number of hours. The hours will be determined by the creation of an element which will hold the pay components to be used in determination of the number of hours worked in this pay period. The Variable Hours element may be a simple or compound element, defined on IPPE.
The key to computation of the variable rate is to divide the semi monthly wage by a number of hours. The hours will be determined by the creation of an element which will hold the pay components to be used in determination of the number of hours worked in this pay period. The Variable Hours element may be a simple or compound element, defined on [IPPE].
At line 81 changed one line
The Variable Hours (Element) method requires that an element be set up in IPPE to hold the pay components to be considered when calculating the number of hours worked in a pay period. It can have any element code, but must be one of the ‘group elements’ in IDGR. The Group Element type MUST be set to ‘Variable Rate’.
The Variable Hours (Element) method requires that an element be set up in [IPPE] to hold the pay components to be considered when calculating the number of hours worked in a pay period. It can have any element code, but must be one of the ‘group elements’ in [IDGR][. The Group Element type MUST be set to ‘Variable Rate’.
At line 86 changed one line
\\
\\ \\
At line 96 changed one line
Standard hours (From IEAS) = 8.5
Standard hours (From [IEAS]) = 8.5
At line 99 changed one line
When the employee is hired, terminated, or has a mid-period rate change, this formulae is NOT used and the system reverts to the ‘Variable Rate Hours’ method.
When the employee is hired, terminated, or has a mid-period rate change, this formula is NOT used and the system reverts to the ‘Variable Rate Hours’ method.
At line 108 changed 2 lines
\\
----
\\ \\
----
At line 113 added one line
At line 162 changed one line
Period Earnings($4,420.29) / Sched Hours (184) = Variable Rate($24.0233)
Period Earnings($4,420.29) / Sched Hours (184) = Variable Rate($24.0233)
At line 166 added one line
At line 204 changed one line
\\ \\
----
At line 215 changed 2 lines
\\
----
\\ \\
----
At line 219 changed 2 lines
The audit text output from the variable rate calculation is also stored in a separate user field attached to the pay line, for future reference.
Variable Rate Audit Text Sample
The audit text output from the variable rate calculation is also stored in a separate user field attached to the pay line, for future reference.
At line 225 added 2 lines
!Variable Rate Audit Text Sample
At line 223 changed one line
\\
\\ \\
At line 227 changed 2 lines
\\
----
\\ \\
----
At line 234 changed one line
To deal with this issue, P2K will perform ‘Force Balancing’ for variable rate employees when the transactions are brought into payroll (UPTR). This balancing will occur after the last transaction for an employee has been loaded into IPPH. Please note that all transactions for an employee must be in the same execution of UPTR for force balancing to be invoked. UPTR can not be executed more than once for employees using a variable rate.
To deal with this issue, P2K will perform ‘Force Balancing’ for variable rate employees when the transactions are brought into payroll ([UPTR]). This balancing will occur after the last transaction for an employee has been loaded into [IPPH]. Please note that all transactions for an employee must be in the same execution of [UPTR] for force balancing to be invoked. [UPTR] can not be executed more than once for employees using a variable rate.
At line 237 changed one line
*the pay type (IDGR) must be set to ‘Salary’
*the pay type ([IDGR]) must be set to ‘Salary’
At line 243 changed one line
The Force Balance pay component must point to an element containing the pay components that are part of regular earnings. These earnings should contain anything that is generated from UPTG and as well as anything that may be entered as exceptions in IPTR that would be considered part of the employee’s regular earnings.
The Force Balance pay component must point to an element containing the pay components that are part of regular earnings. These earnings should contain anything that is generated from [UPTG] and as well as anything that may be entered as exceptions in [IPTR] that would be considered part of the employee’s regular earnings.
At line 251 changed one line
Any computed Force Balance amount is recorded into a separate pay line in the current pay (IPPH).
Any computed Force Balance amount is recorded into a separate pay line in the current pay ([IPPH]).
At line 268 changed 2 lines
%%information Note that all transactions making up part of the employee regular earnings are generated from the scheduled hours, and therefore will be handled perfectly by Retroactive Pay (UPRETRO). Any Force Balance earnings will NOT be taken into consideration during UPRETRO, since generation is simply set to ‘Entered Value’.%%
\\
%%information Note that all transactions making up part of the employee regular earnings are generated from the scheduled hours, and therefore will be handled perfectly by Retroactive Pay ([UPRETRO]). Any Force Balance earnings will NOT be taken into consideration during [UPRETRO], since generation is simply set to ‘Entered Value’.%%
\\ \\
At line 276 changed one line
To deal with this issue, P2K will perform force balancing for variable rate employees when the transactions are brought into payroll (UPTR). This balancing will occur after the last transaction for an employee has been loaded into IPPH. Please note that all transactions for an employee must be in the same execution of UPTR for force balancing to be invoked. UPTR can not be executed more than once for employees using a variable rate.
To deal with this issue, P2K will perform force balancing for variable rate employees when the transactions are brought into payroll ([UPTR]). This balancing will occur after the last transaction for an employee has been loaded into [IPPH]. Please note that all transactions for an employee must be in the same execution of [UPTR] for force balancing to be invoked. [UPTR] can not be executed more than once for employees using a variable rate.
At line 278 changed one line
It is important to note that the only place that balancing occurs is when the IPTR batches are brought into payroll during the execution of UPTR.
It is important to note that the only place that balancing occurs is when the [IPTR] batches are brought into payroll during the execution of [UPTR].
At line 290 changed one line
Any computed Force Balance amount is recorded into a separate pay line in the current pay (IPPH). This pay line will have the same pay component as the Cell Point pay component.
Any computed Force Balance amount is recorded into a separate pay line in the current pay ([IPPH]). This pay line will have the same pay component as the Cell Point pay component.
At line 306 changed 2 lines
%%information Note that all transactions making up part of the employee regular earnings are generated from the scheduled hours, and therefore will be handled perfectly by Retroactive Pay (UPRETRO). Any Force Balance earnings will NOT be taken into consideration during UPRETRO, since generation is simply set to ‘Entered Value’.%%
\\
%%information Note that all transactions making up part of the employee regular earnings are generated from the scheduled hours, and therefore will be handled perfectly by Retroactive Pay ([UPRETRO]). Any Force Balance earnings will NOT be taken into consideration during [UPRETRO], since generation is simply set to ‘Entered Value’.%%
\\ \\
At line 310 changed one line
Pay Period premiums are a new feature as of September, 2005 and are designed to replace UPTG premiums. This type of premium is generated naturally from the hours worked in the pay period and is also ‘Force Balanced’ to ensure that the employee gets the exact premium amount when working a full pay period. Pay Period premiums are computed using a variable rate per hour depending on the number of hours that the employee is scheduled to work. If the employee is scheduled to work the entire pay period, the total of premium generated (by day) must equal the value of the Pay Period premium.
Pay Period premiums are a new feature as of September, 2005 and are designed to replace [UPTG] premiums. This type of premium is generated naturally from the hours worked in the pay period and is also ‘Force Balanced’ to ensure that the employee gets the exact premium amount when working a full pay period. Pay Period premiums are computed using a variable rate per hour depending on the number of hours that the employee is scheduled to work. If the employee is scheduled to work the entire pay period, the total of premium generated (by day) must equal the value of the Pay Period premium.
At line 314 changed 2 lines
To deal with this issue, P2K will perform ‘Force Balancing’ when the transactions are brought into payroll (UPTR). This balancing will occur after the last transaction for an employee has been loaded into IPPH.
%%information Please note that all transactions for an employee must be in the same execution of UPTR for force balancing to be invoked.%%
To deal with this issue, P2K will perform ‘Force Balancing’ when the transactions are brought into payroll ([UPTR]). This balancing will occur after the last transaction for an employee has been loaded into [IPPH].
%%information Please note that all transactions for an employee must be in the same execution of [UPTR] for force balancing to be invoked.%%
At line 317 changed one line
It is important to note that the only place that balancing occurs is when the IPTR batches are brought into payroll during the execution of UPTR.
It is important to note that the only place that balancing occurs is when the [IPTR] batches are brought into payroll during the execution of [UPTR].
At line 329 changed one line
Any computed Force Balance amount is recorded into a separate pay line in the current pay (IPPH ). This pay line will have the same pay component as the Pay Period Premium pay component.
Any computed Force Balance amount is recorded into a separate pay line in the current pay ([IPPH]). This pay line will have the same pay component as the Pay Period Premium pay component.
At line 346 changed one line
%%information Note that all transactions making up part of the employee regular earnings are generated from the scheduled hours, and therefore will be handled perfectly by retroactive pay (UPRETRO). Any Force Balance earnings will NOT be taken into consideration during UPRETRO, since generation is simply set to ‘Entered Value’.%%
%%information Note that all transactions making up part of the employee regular earnings are generated from the scheduled hours, and therefore will be handled perfectly by retroactive pay ([UPRETRO]). Any Force Balance earnings will NOT be taken into consideration during [UPRETRO], since generation is simply set to ‘Entered Value’.%%
This page (revision-24) was last changed on 26-Nov-2021 10:22 by kparrottTop