Correcting or Reversing Finalized Results
With its built-in retroactive processing capabilities, Global Payroll generally handles corrections as a basic part of regular on cycle payrolls. With off cycle processing, you can quickly address the more critical exceptions.
Page Name |
Definition Name |
Usage |
---|---|---|
GP_OFFCYCLE_C_SEC |
Enter instructions for processing payroll corrections. |
|
Positive Input Page |
GP_PI_MNL_ERNDED |
Enter positive input for the calendar with the corrections that are needed. Enter positive input for the target calendar. For a Reversal, regardless of the Retro mode, you normally would never use these PI links, because all you are doing is reversing out the entries that were already there. This page is also used to enter additional and advance payment instructions. |
Absence Event Entry Page |
GP_ABS_EVENT |
Enter absence events that need correcting. This link is available only if PeopleSoft Absence Management is installed. |
Payee Calendar SOVR Page |
GP_PYE_CAL_SOVR |
Enter or review supporting information for the element override. This page is also used to enter additional payment instructions. |
Retro Page |
GP_TRIGGER_RTO |
Enter or review retroactive trigger information. |
Two types of corrections are available that can be processed. They are:
Replacement
Forced Reversal
Two types of retroactive methods can be processed. They are:
Use Existing Retro Rules.
Forced Corrective.
Example of a Normal Retroactive Correction and a Replacement Correction
After the April Payroll was complete, the payee recognized that their payment was incorrect. There was supposed to be a retro active pay increase, in January. The increase for SALARY was increased from 10,000.00 to 11,000.00. Instead of waiting until the end of May to be compensated, an off cycle correction payment will be made.
For a replacement correction using existing retro rules, the system handles the adjustment using the normal retroactive processing mode and processing set, as dictated by the existing triggers. Standard use and validation of retroactive rules apply (as if running on-cycle). This includes:
The retroactive mode.
The forwarding of elements.
The recalculation of elements.
For a forwarding mode client, this example would develop like this:
Calendar Processed |
Version / Revision |
Salary – Old |
Year-to-Date Old |
Salary – New |
Delta to be Forwarded |
Year-to-Date New |
---|---|---|---|---|---|---|
January (1st Trigger) |
V1R2 |
10,000 |
10,000 |
11,000 |
1,000 |
10,000 |
February |
V1R2 |
10,000 |
20,000 |
11,000 |
1,000 |
20,000 |
March |
V1R2 |
10,000 |
30,000 |
11,000 |
1,000 |
30,000 |
April |
V1R2 |
10,000 |
40,000 |
11,000 |
1,000 |
40,000 |
Off Cycle Target Calendar |
4,000 |
44,000 |
For a replacement correction using forced corrective retro, the normal retroactive processing behavior is overruled from the calendar to correct forward. While the system still performs cross-validation of retroactive triggers (no method conflict among triggers is allowed), other rules are abandoned. With normal retroactive corrections:
The retroactive mode is corrective (the system ignores for processing the retroactive events of the trigger).
No elements are forwarded (the system ignores the retroactive processing set).
All elements are recalculated (the system ignores the retroactive recalculate setting).
For a forwarding mode client, the example would develop like this (note the shift in retroactive mode):
Calendar Processed |
Version / Revision |
Salary – Old |
Year-to-Date Old |
Salary – New |
Delta not to be Forwarded |
Year-to-Date New |
---|---|---|---|---|---|---|
January (1st Trigger) |
V1R2 |
10,000 |
10,000 |
11,000 |
1,000 |
11,000 |
February |
V2R1 |
10,000 |
20,000 |
11,000 |
1,000 |
22,000 |
March |
V2R1 |
10,000 |
30,000 |
11,000 |
1,000 |
33,000 |
April |
V2R1 |
10,000 |
40,000 |
11,000 |
1,000 |
44,000 |
Off Cycle Target Calendar |
Example of a Reversal – Both Modes
For example, the payee was processed with a status of Leave of Absence With Pay during the month of February. The status should have been Leave of Absence Without Pay. This time assume, that no changes occurred in January (despite the trigger on January 1st).
Original Check |
February |
Reversing Entry |
Off-Cycle |
---|---|---|---|
Salary (E1) |
10000 |
Salary |
–10000 |
401K |
1000 |
401K |
–1000 |
FWT |
2000 |
FWT |
–2000 |
Union Dues |
100 |
Union Dues |
–100 |
Net Pay |
6900 |
Net Pay |
–6900 |
The Forced Reversal option will reverse the payment out element-by-element (or item-by-item) as illustrated in the example, and it will do so even if the payee status had not yet been updated in the HR database. If the necessary data corrections are not made, a subsequent retroactive process will reidentify and recalculate the reversed payment.
If the necessary corrections have been made — the payee status has been corrected in the HR database — the request for Replacement will also cause a reversal, but element-by-element the results may differ, because the system will apply the normal retro processing rules
For a forced reversal using existing retro rules, the retroactive processing mode that is dictated by the underlying triggers is respected, but the other rules are abandoned. All elements are recalculated (the system ignores the retroactive recalculate setting). For a forwarding client, this would result numbers like these (in terms of balances and target calendar calculations).
1st Trigger |
Target Calendar |
||||
---|---|---|---|---|---|
January |
February |
March |
April |
Off-Cycle |
|
v1r2 |
v1r2 |
v1r2 |
v1r2 |
||
E1 Old |
10000 |
10000 |
10000 |
10000 |
|
Year-to-Date Old |
10000 |
20000 |
30000 |
40000 |
|
E1 New |
10000 |
0 |
10000 |
10000 |
–10000 |
Year-to-Date New |
10000 |
20000 |
30000 |
40000 |
30000 |
Difference |
10000 |
For a corrective client, this would develop like this (regarding balances and target calendar calculations):
No elements are forwarded (the system ignores the retroactive processing set).
All elements are recalculated (the system ignores the retroactive recalculate setting).
1st Trigger |
Target Calendar |
||||
---|---|---|---|---|---|
January |
February |
March |
April |
Off-Cycle |
|
v2r1 |
v2r1 |
v2r1 |
v2r1 |
||
E1 Old |
10000 |
10000 |
10000 |
10000 |
|
Year-to-Date Old |
10000 |
20000 |
30000 |
40000 |
|
E1 New |
10000 |
0 |
10000 |
10000 |
0 |
Year-to-Date New |
10000 |
10000 |
20000 |
30000 |
|
Difference |
10000 |
Forced reversals using forced corrective retro are similar to the standard replacement in that the normal retroactive behavior is overruled from the calendar to correct and forward. While the cross-validation of retroactive triggers still occurs (no method conflict among triggers is allowed), other rules are abandoned. With replacement reversal corrections:
The retroactive mode is corrective (the system ignores the retroactive events of the trigger for processing).
No elements are forwarded (the system ignores the retroactive processing set).
All elements are recalculated (the system ignores the retroactive recalculate setting).
For a forwarding client, this would develop like this (regarding balances and target calendar calculations):
1st Trigger |
Target Calendar |
||||
---|---|---|---|---|---|
January |
February |
March |
April |
Off-Cycle |
|
v2r1 |
v2r1 |
v2r1 |
v2r1 |
||
E1 Old |
10000 |
10000 |
10000 |
10000 |
|
Year-to-Date Old |
10000 |
20000 |
30000 |
40000 |
|
E1 New |
10000 |
0 |
10000 |
10000 |
0 |
Year-to-Date New |
10000 |
10000 |
20000 |
30000 |
30000 |
Difference |
10000 |
For a corrective client, no principal difference exists between a forced reversal using existing retro rules and a forced reversal using forced corrective retro.
Note: The preceding examples include March and April as closed payrolls that have taken place between the corrected payroll and the actual correction taking place to illustrate the difference between the nature of the normal retroactive process and the forced replacement process (particularly for normally forwarding clients). The majority of the cases are likely to be corrections to the very last period paid, in this case April, and the difference in the behavior is generally negligible.
Use the Correction Request Detail page (GP_OFFCYCLE_C_SEC) to enter instructions for processing payroll corrections.
Navigation:
Click the Correction Details icon in the Calendars to Correct section of the Off Cycle Request page.
Note: The fields that are available for entry on this page depend on the configuration settings that were created for this type of off cycle transaction.
This page shot displays the page as it will be presented when no configuration exists.
See Understanding Off Cycle Configurations.
Field or Control |
Description |
---|---|
Calendar ID |
Select the calendar that needs a correction made to it. |
Look up advances where the calendar itself is not yet finalized |
Select this field in order to select and correct a calendar where the on cycle calendar itself has not yet been finalized, but the calendar has been processed for this payee already as an advance. |
P.I. Calendar to Correct |
Click to access the Positive Input page. |
Absence Event Entry |
Click to access the Absence Event Entry page. |
Type of Correction |
Enter the type of correction. Values are Replacement and Forced Reversal. Note: When processing reversals, you need to void the payment, which you can do using the Review Payments by Cal Group component after banking has been finalized; or for reconciliation purposes on the Manual Payment Reconciliation page. This is not an automatic process. See Understanding Banking, Manual Payment Reconciliation Page. |
Retro Method |
Enter the retro method to use for this correction type. Values are Use Existing Retro Rules and Forced Corrective. |
Payment Date |
The default value comes from the Off Cycle Request page if a value was entered on that page. This date drives the selection of date-effective rules and the allocation of results to the appropriate time period (month-to-date, quarter-to-date and year-to-date balances). |
Payment Method |
Select the payment method for the correction. |
Element Selection |
Select the elements to process for this correction. Note: For a forced reversal correction, element selection is unavailable for entry. |
P.I. Target Calendar |
Click to access the Positive Input page. |
Supporting Element Overrides – Target Calendar |
Click to access the Payee Calendar SOVR page. |
Review Triggers |
Click to view, edit, and add retroactive triggers. |
Retro Triggers Exist (retroactive triggers exist) |
This system will select this check box if a trigger exists that falls on or before the period end date of the calendar to be corrected, and if the trigger represents the same country as the country associated with the pay group of the off cycle group. If the check box is deselected, you must manually create the trigger or make the correction to data that will cause the trigger to be generated. |
Retro Triggers |
Displays a list of retro triggers associated with the same country as the correction. |