Client and Business Case - A global manufacturing company wanted to automate the retrospective pay calculation in Oracle Payroll for critical payroll processes like retrospective pay awards, temporary promotions, secondments, retro pay for part timers etc.
Solution - Oracle Payroll allows you to make back pay adjustments through the RetroPay process. Key points include:
–Inputs to pay that were originally correct have now changed retroactively.
–You receive late notifications of promotions.
–You can run the RetroPay process from the submit Requests window.
How Retro Pay Works - Oracle Payroll now rolls back and reprocesses all the payrolls for the assignment set from the date you specified. The system compares the old balance values with the new ones and creates entry values for the RetroPay elements based on the difference. These entries are processed for the assignments in the subsequent payroll run for your current period.
No changes are made to your audited payroll data.
Configuration - All payroll elements configured during the implementation are assessed for whether they are “retropay’able” or not. Usually all regular payments and allowances are considered eligible for retropay. Voluntary deductions and some non-recurring payments are not normally eligible but can be made so if required.
For each eligible element a corresponding “Retropay Element” is also configured. These elements will hold the results of any pay adjustments calculated by the “Retropay” process.
A number of Retropay element “Groups” may also be configured. I.e. There will almost certainly be a group which includes all eligible elements but there could be another group which is just for bonus related adjustments. This gives flexibility when running retropay to restrict the process to just those items where you are notified that a change is due.
Operational steps - Immediately prior to every payroll calculation the “Retropay Notifications” report should be run. This lists any system changes that indicate a retrospective adjustment may be due. E.g. One or more employees may have had a late or corrected entry of a new allowance, change of Grade, change of Grade Step placement etc.
Using the “Retropay Notifications” report you can establish the assignments, period and elements for which retrospection is needed.
If a retrospective calculation is needed, then run the standard “Retropay by Element” process.
Input parameters are :-
Assignment set – if you want to restrict the run to selected assignments
Retropay element group – if you want to restrict the run to selected elements
Start date – this is the earliest date you want the system to recalculate from
End date – this is the latest date you want the system to recalculate up to
The process recalculates for the assignments, period and elements indicated. Any resulting adjustments are attributed to each relevant retropay element and entered into the current pay period for processing in the full payroll gross to nett run. In this way the results of the previous period(s) payrolls are not amended. The adjustments will only affect values and be costed in the current payroll period.
How the notification process works - During the implementation “Dynamic Triggers” will be configured. These identify when a change has occurred in the database which could mean an adjustment to pay is needed. E.g. There will be dynamic triggers to detect changes in Grade, Spinal Point, Standard Hours, Contract Type, FTE, Allowances etc. The “Retrospective Notifications” process uses these triggers to notify you of the items which need retrospective calculation.
How the calculation process works - Assume a retropay run is for March and April with the adjustments to be paid in May. The system retrieves all balances for the assignment as at end of February payroll and notionally recalculates all eligible elements for March and April. These notional element results are compared by the system with the original actual results in March and April for the same elements. Any differences are automatically entered onto the relevant retropay element in May. The end result will be exactly the same as if a payroll clerk had manually calculated the adjustments needed and manually keyed them onto adjustment elements in the current pay period.
Optimising use of the Retropay functionality - It can be seen that as the exact same system process is used to recalculate as was used in the original payroll calculation, then elements which have derived values will automatically be correctly recalculated by the retropay process.
e.g.
Allowance X has a formula attached which specifies that the allowance value is 10% of basic salary plus 2% of all contractual allowances. If basic salary and all contractual allowances are part of the retropay set then Allowance X will also be recalculated.
If the allowance has no formula and is populated by a user keying in an arbitrary amount then it will not be affected by retropay on other elements. The only way this would generate a retropay adjustment would be if the original allowance entry were changed, i.e. different start/end date or value.
During the implementation, due consideration should be given to how elements are configured to enable maximum use of the retropay functionality.
Pay Awards - When revising the values on a pay scale due to a pay award it will be essential to datetrack to the correct effective date when the new values come/came into force. You can apply the pay award in advance of the effective date or after it. If it is applied late then restrospective calculations will be due and the operational steps outlined above will need to be followed. If you have applied the pay award in advance then the old rates will be applied until the effective date of the pay award when the new rates will automatically be applied. If this occurs mid-period then the calculated values will be pro-rated accordingly.
Temporary Promotions, Secondments etc. - Any employee who is in a role which is not their usual substantive assignment will still be eligible for retropay adjustments on their substantive assignment for the period before their Temporary Promotion or Secondment started, and also on their extra assignment for the Promotion or Secondment.
Part Timers - It can be seen that as the exact same system process is used to recalculate as was used in the original payroll calculation, then elements which are pro-rated according to a part-timers FTE will still be pro-rated in exactly the same way.
Overlapping Retrospective Runs - It is possible that having run Retropay in June to recalculate March-May, you then have reason to run it in September for April-August. This is perfectly legitimate and the system will correctly process the second retropay run which overlaps the time period covered by the first run.
Solution - Oracle Payroll allows you to make back pay adjustments through the RetroPay process. Key points include:
–Inputs to pay that were originally correct have now changed retroactively.
–You receive late notifications of promotions.
–You can run the RetroPay process from the submit Requests window.
How Retro Pay Works - Oracle Payroll now rolls back and reprocesses all the payrolls for the assignment set from the date you specified. The system compares the old balance values with the new ones and creates entry values for the RetroPay elements based on the difference. These entries are processed for the assignments in the subsequent payroll run for your current period.
No changes are made to your audited payroll data.
Configuration - All payroll elements configured during the implementation are assessed for whether they are “retropay’able” or not. Usually all regular payments and allowances are considered eligible for retropay. Voluntary deductions and some non-recurring payments are not normally eligible but can be made so if required.
For each eligible element a corresponding “Retropay Element” is also configured. These elements will hold the results of any pay adjustments calculated by the “Retropay” process.
A number of Retropay element “Groups” may also be configured. I.e. There will almost certainly be a group which includes all eligible elements but there could be another group which is just for bonus related adjustments. This gives flexibility when running retropay to restrict the process to just those items where you are notified that a change is due.
Operational steps - Immediately prior to every payroll calculation the “Retropay Notifications” report should be run. This lists any system changes that indicate a retrospective adjustment may be due. E.g. One or more employees may have had a late or corrected entry of a new allowance, change of Grade, change of Grade Step placement etc.
Using the “Retropay Notifications” report you can establish the assignments, period and elements for which retrospection is needed.
If a retrospective calculation is needed, then run the standard “Retropay by Element” process.
Input parameters are :-
Assignment set – if you want to restrict the run to selected assignments
Retropay element group – if you want to restrict the run to selected elements
Start date – this is the earliest date you want the system to recalculate from
End date – this is the latest date you want the system to recalculate up to
The process recalculates for the assignments, period and elements indicated. Any resulting adjustments are attributed to each relevant retropay element and entered into the current pay period for processing in the full payroll gross to nett run. In this way the results of the previous period(s) payrolls are not amended. The adjustments will only affect values and be costed in the current payroll period.
How the notification process works - During the implementation “Dynamic Triggers” will be configured. These identify when a change has occurred in the database which could mean an adjustment to pay is needed. E.g. There will be dynamic triggers to detect changes in Grade, Spinal Point, Standard Hours, Contract Type, FTE, Allowances etc. The “Retrospective Notifications” process uses these triggers to notify you of the items which need retrospective calculation.
How the calculation process works - Assume a retropay run is for March and April with the adjustments to be paid in May. The system retrieves all balances for the assignment as at end of February payroll and notionally recalculates all eligible elements for March and April. These notional element results are compared by the system with the original actual results in March and April for the same elements. Any differences are automatically entered onto the relevant retropay element in May. The end result will be exactly the same as if a payroll clerk had manually calculated the adjustments needed and manually keyed them onto adjustment elements in the current pay period.
Optimising use of the Retropay functionality - It can be seen that as the exact same system process is used to recalculate as was used in the original payroll calculation, then elements which have derived values will automatically be correctly recalculated by the retropay process.
e.g.
Allowance X has a formula attached which specifies that the allowance value is 10% of basic salary plus 2% of all contractual allowances. If basic salary and all contractual allowances are part of the retropay set then Allowance X will also be recalculated.
If the allowance has no formula and is populated by a user keying in an arbitrary amount then it will not be affected by retropay on other elements. The only way this would generate a retropay adjustment would be if the original allowance entry were changed, i.e. different start/end date or value.
During the implementation, due consideration should be given to how elements are configured to enable maximum use of the retropay functionality.
Pay Awards - When revising the values on a pay scale due to a pay award it will be essential to datetrack to the correct effective date when the new values come/came into force. You can apply the pay award in advance of the effective date or after it. If it is applied late then restrospective calculations will be due and the operational steps outlined above will need to be followed. If you have applied the pay award in advance then the old rates will be applied until the effective date of the pay award when the new rates will automatically be applied. If this occurs mid-period then the calculated values will be pro-rated accordingly.
Temporary Promotions, Secondments etc. - Any employee who is in a role which is not their usual substantive assignment will still be eligible for retropay adjustments on their substantive assignment for the period before their Temporary Promotion or Secondment started, and also on their extra assignment for the Promotion or Secondment.
Part Timers - It can be seen that as the exact same system process is used to recalculate as was used in the original payroll calculation, then elements which are pro-rated according to a part-timers FTE will still be pro-rated in exactly the same way.
Overlapping Retrospective Runs - It is possible that having run Retropay in June to recalculate March-May, you then have reason to run it in September for April-August. This is perfectly legitimate and the system will correctly process the second retropay run which overlaps the time period covered by the first run.
No comments:
Post a Comment