This chapter provides an overview of off cycle processing and discusses how to:
Initiate off cycle transactions.
Record manual payments.
Correct or reverse finalized results.
Make additional payments.
Process advances.
Process and view results for off cycle transactions.
This section discusses:
Differences between on cycle and off cycle runs.
Types of off cycle transactions.
Features of off cycle processing.
Steps for entering off cycle requests.
Processing and postprocessing steps.
Off-cycle batch processing.
System elements for developing off cycle rules.
Element Selection |
The option that is selected determines the resolution of primary elements (earnings and deductions) on the process list. Values are: All: Select to have the system follow the same resolution as if this were an on cycle payroll process. Elements with Positive Input: Select to have the system resolve only those elements that are entered in positive input.
Note. Regardless of which selection you make the system
will always process positive input entries. |
Off Cycle Group |
Identifies a set of off cycle transactions to process. The name of an off cycle group is user-defined. You can use any value. |
Payment Date |
The date that the system uses to determine:
|
Payment Method |
Values are Cash, Check, Postal Order, Use Normal Distribution, and Pay Primary Account Only. This field applies to all transaction types except manual payments. The selected payment method determines the payment method that might be assigned through rules during the calculation process. |
Period Begin Date and Period End Date |
Dates the system use to determine:
Manual payments, corrections, and additional payments inherit these dates from the target calendar; you can override the default dates. Advance payments inherit these dates from the source calendar, the calendar that is being advanced; you cannot override these dates for advances. |
Supporting Element Overrides |
Click the Supporting Element Overrides button to access the Payee Calendar SOVR page, where you can override the value of a bracket, date, duration, formula, or variable element for a specific payee and calendar. |
Target Period ID |
Affects the period for which balance accumulators are updated. The target period provides the default values for the period begin date and period end date for all transaction types except advances. For advances, the target period determines the process begin date and process end date. |
On cycle processing refers to performing regularly scheduled runs. In Global Payroll, these are recurring runs for which a period, calendar, and calendar group have been predefined. A pay group with a monthly frequency has twelve regularly scheduled on cycle payrolls each year.
Off cycle payroll processing refers to processing payments and making corrections to finalized results outside of the normal payroll schedule. Off cycle transactions are typically made to correct prior payments or to make early termination payments that can't wait until the next scheduled on cycle payroll.
Note. Quarterly bonuses, commission payments, and other regularly recurring transactions that are processed less frequently than regular payroll runs often involve large groups of payees, and can be managed most efficiently as on cycle processes.
With the exceptions that are explained in this chapter, the concepts that apply to on cycle processing also apply to off cycle processing: retroactivity, segmentation, calendars and calendar groups, running calculations, banking, and general ledger. The primary difference between on cycle and off cycle processing is the way in which you enter instructions for what and who to process.
See Also
Global Payroll supports four types of off cycle transactions:
Manual payments
You can record payments for items that you calculate and pay outside of the system, such as cash or check payments.
Corrections
These are transactions that correct the results of a finalized payroll. Examples include paying a new hire who was not included in the regular run and reversing a bonus payment that was made to a payee in error.
Additional payments
These are one time payments, such as a special bonus or expense reimbursement that fall outside of the on-cycle process and for which calendars would not ordinarily be defined.
Advances
Advances are the processing of segments before they are normally scheduled, such as the early payment of wages due to termination, or the processing and pay of leave in advance.
With off cycle processing, you can:
Override a payee's normal payment method.
You can override the payment method that's defined for a payee on the Net Distribution page or that is defined through rules during the calculation process. For example, you can issue a check to a payee for a one time bonus, even though the payee's regular monthly salary is paid through a direct deposit.
Limit which elements are resolved.
For all off cycle transactions except advances, you can use two features to limit the primary elements (earnings and deductions) on the process list that the system resolves. The Element Selection section enables you to select which primary elements you want resolved, with the exception of any retroactive or positive input for those elements. You can select all elements, elements with positive input, or a limited set of primary elements to process.
Override supporting elements.
For all off cycle transactions except advances, you can override the values of brackets, dates, duration, formulas, and variables for a given payee and calendar. Advances will take these overrides from the calendar definitions of the calendars being advanced.
You can enter multiple off cycle requests for the same pay group and target period.
To enter requests for off cycle transactions:
Create an off cycle group using the Off Cycle On Demand (GP_ONDEMAND) component.
An off cycle group is a group of payees and payments that are processed together. It identifies which off cycle transactions to process and the processing instructions, including who and what to pay (pay group) and when to pay it (target calendar ID). Its purpose is similar to a calendar in an on cycle process, except that you enter specific instructions for each payee. Name the off cycle group on the Off Cycle On Demand page.
Enter individual requests for payments.
The Off Cycle On Demand component prevents you from performing off cycle steps out of order. You will enter a request by clicking either the Create Request or Edit Request button. If at least one request has been created, the button is labeled Edit Request.
When the button is selected, you are transferred to the main request page, which includes the valid off cycle types for your organization. On this main page, you indicate the payee ID by type of transaction. Next, select the detail link and you are transferred to the individual detail page for the transaction type.
Note. Use the Off Cycle Configuration page to configure the fields that are displayed on each detail page for each off cycle transaction. By configuring these pages, you can greatly reduce the fields and options that appear when creating an off cycle transaction.
Create a calendar group for the off cycle run.
A calendar group for an off cycle run identifies the off cycle groups to process together (whereas a calendar group for an on cycle process identifies the calendars to process together). Use the same page to create all calendar groups, completing the fields that pertain to off cycle processing.
You can create a calendar group for an off cycle run from the Off Cycle On Demand page of the Off Cycle On Demand component by clicking the Create Calendar Group button. When you create the Calendar Group through the dashboard, the system uses the name of the off cycle group (one of the keys) as the name of the calendar group. Also, the system populates the Calendar Group page with the other information required to generate the off cycle calendar group.
Note. When processing a correction request, ensure retro triggers exist to recalculate the payments requested for correction.
To process requests for off cycle transactions:
Initiate the off cycle run.
Use the Off Cycle On Demand page of the Off Cycle On Demand component to initiate off cycle runs by clicking the Calculate button. The calculation is performed as a remote call. The remote call causes the browser to remain on the Off Cycle On Demand page for the duration of the calculation process. Any pertinent messages are displayed upon completion. Each time the calculation is run, the system cancels the payees, identifies the payees that are eligible for calculation, and calculates all elements for the payees.
Note. Off cycle processing can also be run using the Calculate Absence and Payroll page as it would for an on cycle process.
When the calculation finishes, it opens the Payee Status page. From this page, you can access the Results by Calendar Group page as well as the Payee Messages page. The Payee Status page reflects whether the results are calculated. From this page, you can review:
Payee Calculation Status.
Payee Results.
Payee Messages.
Note. When the calendar group is created, you can access the Payee Status page at any time by clicking the View Status and Results link.
When you review the processing results, you can choose to:
Cancel the calculation. Click the Cancel button on the Off Cycle On Demand page.
Calculate again due to changes made to the off cycle transactions. Click the Calculate button on the Off Cycle On Demand page.
Finalize the end the payroll calculation. Click the Finalize button on the Off Cycle On Demand page. Once this is done, move on to Step 3.
Run all post processes, such as Banking, General Ledger, Send Cost to TL, and reports.
Each post processing step needs to be run with the same sequence as on cycle. You must initiate these steps using the same navigation as in an on cycle payroll.
See Also
Entering Processing Instructions
Viewing Payee Status and Updating a Payee's Processing Instructions
With off cycle processing, the system automatically suspends affected payees from other runs in which they are active so that they can be included in the off cycle process. (A payee can be active only in one run at a time.)
Here's what the system does when you submit an off cycle request:
Checks whether the payee is associated with an open calendar group.
If yes, suspends the payee in the calendar group so that the payee can be calculated immediately in the off cycle group.
Note. If the Calculation status is set to Frozen, the system suspends the payee in the off cycle calendar group.
Transaction processing varies depending on the type of off cycle request being processed.
With manual payments, batch validation checks whether the calculated gross-pay and net-pay accumulator amounts match the gross-pay and net-pay amounts input. A message is issued, and payee is placed in error if these calculated gross and net do not match the input gross and net amounts. The amounts must match to finalize the payroll.
During batch processing, the process list that is associated with the run type that was entered is used.
Here's what the system processes when manual payments are being processed:
Earnings and deductions that are entered on the manual payment request:
Are only resolved if on the process list.
Are not checked for eligibility, including generation control.
Have pre and post process formulas are resolved; however any post-process formula attempts to modify the earning or deductions value will not be applied.
Do not have individual components resolved. But if the user adds a component, it is stored and added to any accumulator in which it belongs. For example, if units are entered as hours, the amount is not used to calculate an amount, just to update this unit balances.
Other earnings and deductions will resolve dependent on the element selection. .
Supporting elements are always resolved if they are on the process list.
Both period and element segmentation triggers are ignored.
Entries from PeopleSoft Enterprise Time and Labor and the Manage Variable Compensation application of PeopleSoft Enterprise Human Resources are not picked up.
Off cycle corrections are based on retroactive processing similar to the retroactive corrections that take place during on cycle runs:
A trigger must exist on or before the pay period end date for the calendar that is being corrected or reversed.
The type of correction is one of two choices to process:
Replacement: Replaces an existing payment that was paid incorrectly.
Forced Reversal: Reverses an existing payment that should not have been paid regardless of whether the payee is still eligible.
One of two types of retroactive methods are available to process:
Use Existing Retro Rules: Follows retroactive method based on the triggers and rule setup.
Forced Corrective: Corrective retroactive method is forced.
For the calendar that is being corrected or reversed, the earnings and deductions resolve based on normal processing and eligibility.
New calendars are created and will be processed. If delta's exist and are to be forwarded, these new off cycle calendars that are automatically generated will receive these deltas:
Earnings and deductions resolve depending on the presence of positive input that is entered in the off cycle request, as well as the element selection.
All supporting elements on process lists are resolved.
Segmentation triggers are ignored.
Entries from PeopleSoft Time and Labor and the Manage Variable Compensation application are not picked up.
During batch processing, the process list that is associated with the run type that was entered is used.
Earnings and deductions that are entered on the additional payments request follow on cycle batch processing logic:
They are resolved only if they are on the process list.
Eligibility is considered, including generation control.
Pre process and post process formulas are resolved.
Individual components are resolved, as needed.
Earnings and deductions resolve depending on the presence of positive input that is entered in the off cycle request, as well as element selection.
Supporting elements will always be resolved if they are on the process list.
Both period and element segmentation triggers are ignored.
Entries from PeopleSoft Time and Labor and the PeopleSoft Manage Variable Compensation application are not picked up.
For advances, calendar groups are processed with the applicable calendars. Batch processing follows the same logic as on cycle processing.
The following table provides information about delivered system elements that are used during off cycle processing:
System Element |
Description |
Values |
GP TX TYPE |
Identifies the transaction type. |
|
OFF CYCLE |
Identifies whether calendar is off cycle or on cycle. |
|
GP CORR TYPE |
Identifies the correction type. |
|
This section provides an overview of preliminary entry for off cycle transactions and discusses how to:
Create an off cycle request.
Enter basic off cycle information.
You can create an off cycle request by accessing the Off Cycle On Demand page or the Off Cycle Requests page. Use the Off Cycle On Demand component (GP_ONDEMAND) to create an off cycle request, process the request, and view the results. Use the Off Cycle Requests component (GP_OFFCYCLE_REQ) to enter the employee ID for the applicable off cycle transaction type. After entering the employee ID on the Off Cycle Request page, you complete a separate page of the component to complete details for each transaction type that you intend to process.
If a payee has entries for more than one transaction type, the system processes the transactions in the following order: manual payments, corrections, additional payments, and advance payments. To process the transactions in any other order, set up separate off cycle groups and process the payments in separate runs.
Page Name |
Definition Name |
Navigation |
Usage |
GP_ONDEMAND |
Global Payroll & Absence Mgmt, Absence and Payroll Processing, Off Cycle, Off Cycle On Demand, Off Cycle On Demand |
Access the pages to:
|
|
GP_OFFCYCLE_REQ |
|
Access the detail pages of the off cycle transaction types for the employee IDs that are entered. |
Access the Off Cycle On Demand page by entering the pay group, target period ID, and name for the off cycle group (Global Payroll & Absence Mgmt, Absence and Payroll Processing, Off Cycle, Off Cycle On Demand, Off Cycle On Demand).
Create Request or Edit Request |
Click to create a request on the Off Cycle Request page. When the request has been created, the button reads Edit Request, which you click to edit the off cycle request that is created. |
Create Calendar Group or Edit Calendar Group |
Click to access the Calendar Group page to create a calendar group for processing the off cycle transactions. When the calendar group has been created, the button reads Edit Calendar Group, which you click to edit the calendar group that is created. |
Calculate |
Click to calculate the off cycle transactions. The calculation is performed as a remote call. The remote call causes the browser to remain on the Off Cycle On Demand page for the duration of the calculation process. Note. The simplified approach of the Calculate push-button does not allow certain options like freezing calculations or running the process with element trace on. If this is desired, go to the Calculate Absence and Payroll page to process the off cycle calendar group. |
View Status and Results |
Click to access the Payee Status page. Use this page to view payees by process indicator, calculation status, or other criteria and specify the action that the system is to take. Also, you can access the Results by Calendar Group component (GP_RSLT_CAL_RUN) or Payee Messages component (GP_MESSAGE) by clicking the links on the Payee Status page. See Viewing Payee Status and Updating a Payee's Processing Instructions, Viewing Results by Calendar, Viewing Payee Messages. |
Finalize |
Click to finalize an off cycle run. This button is available only after the calendar group has been successfully calculated. |
Cancel |
Click to cancel an off cycle run. This option becomes available as soon as the off cycle group has been associated with a calendar group. |
Request entered , Calendar Group Created , Results can be finalized , and Finalized |
The check boxes to the right of the push buttons on the Off Cycle On Demand page are unavailable for entry. The system maintains these check boxes, which consists of milestones, that indicate how far along you are in the off cycle process. For example, if you have already created the request, completed your calendar group creation, and run a calculation once with no errors, the system selects several check boxes (Request entered, Calendar Group Created, and Results can be finalized) on the Off Cycle On Demand page, representing the steps you have already completed. |
Access the Off Cycle Request page by entering the pay group, target period ID, and name for the off cycle group (Global Payroll & Absence Mgmt, Absence and Payroll Processing, Off Cycle, Off Cycle Request, Off Cycle Request).
Employee ID |
Enter the employee ID in the applicable off cycle transaction section. The section will limit itself to payees (and jobs) associated with the pay group that is associated with the off cycle group. |
Empl Rcd Nbr(Employee Record Number) |
Select the job for which you want to create the off cycle transaction. |
Reason |
Select the default reason code or the reason code that is applicable to the off cycle request being created. This field is available only if you have configured the off cycle transaction type to use reason codes. The configuration is completed on the Off Cycle Configuration page. Note. A reason code is only used if a configuration has been created for the transaction type. If you enter a reason code it means you have chosen a specific configuration. |
Payment Details, Correction Details, or Advance Details |
Click to access the Manual Payment Detail page, Correction Detail page, Additional Payment Detail page, or Advance Detail page, where you enter the details for the applicable off cycle transaction type. |
This section provides an overview of the recording of manual payments and discusses how to record manual payment details.
A manual payment is a payment that is prepared outside of the Global Payroll system. You might have a remote office with no access to Global Payroll that occasionally needs to write a manual payment to process a last-minute payroll adjustment. Or you might correct errors in system-produced paychecks by producing manual payments.
Because manual payments are created outside of the system, you must record them manually into Global Payroll to updating your employees' earnings, deductions, garnishments, and tax balances.
For example, employee 8101 was hired in a remote office on January 1. The clerk did not notify the central office of the new hire. So when the payroll was produced for the January run, the new employee did not receive a check. The payroll clerk therefore calculated and produced a manual payment to be processed in an off cycle run. He then forwarded the check information to the central office to be entered into the system.
Manual payments are processed in off cycle payroll runs.
Page Name |
Definition Name |
Navigation |
Usage |
GP_OFFCYCLE_M_SEC |
Click the Payment Details icon in the Manual Payments section of the Off Cycle Request page. |
Enter all manual payment details. |
Access the Manual Payment Detail page (click the Payment Details icon in the Manual Payments 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 Configuring Off Cycle Transactions.
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). Note. Payment date, as noted previously, can be used to determine what period balances to update. It may be different from the issue date of the original payment. |
Period Begin Date and Period End Date |
Supplied from the target period ID. Dates the system use to determine:
Manual payments, corrections, and additional payments inherit these dates from the target calendar; you can override the default dates. Advance payments inherit these dates from the source calendar, the calendar that is being advanced; you cannot override these dates for advances. |
Run Type |
Enter a run type for the calendar, unless you are using reason codes and the reason selected configures the run type for you. |
Element Selection
The fields in this section indicate the elements to process with the off cycle transaction. Select the desired option. For a manual payment the most logical choice is Elements with Positive Input.
Payment Key Overrides
The fields in this section display the payment keys that have been selected at the pay entity level. It will be visible only if payment keys are set up. The user can override the payment keys. If no payment keys are overridden, the system uses the payment keys values retrieved from the payees job information as of the period end date.
Note. If you override one payment key, you must override them all.
Manual Payment Detail
Payment Number |
Enter the number that is associated with the payment number, cash receipt, check, or bank transfer for this manual payment. |
Issue Date |
Enter the date that the payment was issued and payable to the payee. |
Payment ID |
To include this payment in the payment reconciliation, add the payment ID that is applicable to the manual payment. |
Gross Pay |
Enter the gross pay of the manual payment. |
Net Pay |
Enter the net pay of the manual payment. |
Calculated Values |
The Last Validated Gross and Last Validated Net values are derived based on how the earnings or deductions, which are entered on the positive input details, are defined to contribute to the gross and net accumulators. Since an earning or deduction can accumulate less than 100 percent to an accumulator, the calculated gross and net may be different from the input values of Gross Pay and Net Pay. |
Validate |
After you enter all data for the page, click to validate the entries for the manual payment. The validation process verifies that the input gross and net amounts are equal to the calculated gross and net accumulator amounts to ensure that the amounts are entered correctly. If the values are not equal, the manual payment detail can be saved but not processed. The input gross and net pay must equal the calculated gross and net accumulators before a manual payment can be validated and then processed. The only exception is when you have a status of validate at calculation time. |
Validation Status |
When the validation process is run, the Validation Status is automatically updated. Not Validated: Indicates that the calculated gross and net accumulators do not match the entered gross and net, or that the payment was saved and not validated. Validated: Indicates that the calculated gross and net accumulators match the entered gross and net. Validate at Calculation Time: Indicates that the earnings or deductions contributed to the accumulator based on another element. Because the element needs to be resolved during calculation, the system is not be able to validate until the calculation. |
Note. By entering all the earnings and deductions and then clicking the Validate button, you can use the page as a calculator to determine the gross and net for you, (and as such it can serve as a calculator when you issue the manual payment itself).
Earnings and Deductions Details
Element Name |
Enter all the earning and deduction elements that are used in this manual payment. |
Unit, Rate, Amount, Base, Percent, and Currency Code |
Enter values in the applicable fields for each element of the manual payment. |
Percent Contribution |
Based on the element's definition, this displays the percent to add or subtract from the gross pay and net pay accumulators for this element. Note. If the element contributes based on another element, the element name appears. If the element contributes differently to gross and net, then ##### appears in this field. The system displays a message when the element contributes differently to gross and net, which reads # - Percent Contributions are different for Gross and Net. |
Calculated Value |
Displays the value this element contributes to the gross and / or net accumulator, after the validation process is run. |
Supporting Element Overrides |
Click to access the Supporting Element Overrides page, where you can override values of supporting elements for a specific earning or deduction. If override details are entered, the Details check box will be selected. |
Supporting Element Overrides - Payment Level |
Click to access the Payee Calendar SOVR page, where you can override values of supporting elements for this manual payment. This override applies to all supporting elements processed. |
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.
This section provides an overview of payroll result corrections and discusses how to enter instructions to correct payroll results.
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.
Page Name |
Definition Name |
Navigation |
Usage |
GP_OFFCYCLE_C_SEC |
Click the Correction Details icon in the Calendars to Correct section of the Off Cycle Request page. |
Enter instructions for processing payroll corrections. |
|
GP_PI_MNL_ERNDED |
|
Enter positive input for the calendar with the corrections that are needed. Enter positive input for the target calendar. Note. 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. See Pages Used to Make Additional Payments, Pages Used to Process Advances. |
|
GP_ABS_EVENT |
Click the Absence Event Entry link on the Correction Request Detail page. |
Enter absence events that need correcting. Note. This link is available only if PeopleSoft Enterprise Absence Management is installed. |
|
GP_PYE_CAL_SOVR |
Click the Supporting Element Overrides - Target Calendar link on the Correction Request Detail page. |
Enter or review supporting information for the element override. This page is also used to enter additional payment instructions. |
|
GP_TRIGGER_RTO |
Click the Review Triggers link on the Correction Request Detail page. |
Enter or review retroactive trigger information. |
Access the Correction Request Detail page (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 Configuring Off Cycle Transactions.
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 Defining Banking Instructions, Reconciling Transactions Manually. |
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. |
This section provides an overview of additional payments and discusses how to enter instructions for additional payments.
Additional payments are one time payments that are processed outside of the normal processing cycle. Examples include a one time bonus, an award, expense reimbursement, or rent paid for an employee's housing. These transactions are similar to manual payments in many respects; however, additional payments are paid in the system, whereas manual payments are typically paid outside of the system, and are recorded in the system after payment has been made.
Items and amounts that are paid with an additional payment are typically entered as one time positive input.
Page Name |
Definition Name |
Navigation |
Usage |
GP_OFFCYCLE_U_SEC |
Click the Payment Details icon in the Additional Payments section on the Additional Payment Detail page. |
Enter instructions for processing additional payments. |
|
GP_PI_MNL_ERNDED |
Click the Positive Input link on the Additional Payment Detail page. |
Enter positive input for the target calendar. |
|
GP_PYE_CAL_SOVR |
Click the Supporting Element Overrides link on the Additional Payment Detail page. |
Override the value of a bracket, date, duration, formula, or variable for a specific additional payment. |
Access the Additional Payment Detail page (click the Payment Details icon in the Additional Payments section on the Additional Payment Detail page).
Note. The fields that are available for entry on this page
depend on the configuration settings that are created for this type of off
cycle transaction.
This page shot displays the page as it will be presented when no configuration
exists.
See Configuring Off Cycle Transactions.
Calendar ID |
The system generates a target calendar based on the target period ID. The calendar name consists of the target period ID plus a sequence number for the transaction. (You cannot access the calendar through the Calendar component; however, the system stores data for the calendar in the results table.) |
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). |
Period Begin Date and Period End Date |
Supplied from the target period ID. Dates the system use to determine:
Manual payments, corrections, and additional payments inherit these dates from the target calendar; you can override the default dates. Advance payments inherit these dates from the source calendar, the calendar that is being advanced; you cannot override these dates for advances. |
Run Type |
The run type identifies the process list to use during processing. If the elements to be resolved are not included in the process list that's associated with the selected source calendar, you can create a new process list and run type for the additional payment and select the new run type here. |
Payment Method |
Select the payment method for the additional payment. |
Element Selection |
Select the elements to process for this additional payment. Note. To prevent regular earnings and deductions from appearing on the additional payment, you will probably want to enter a Limited Element Set field value or enter all the elements to process on the Positive Input page, along with selecting the Elements with Positive Input option. |
Payment Key Overrides |
This section is identical to the Payment Keys Overrides section on the Manual Payment Detail page. You can override the values of any payment keys that have been defined for the pay entity that is associated with the pay group. |
Positive Input |
Click to access the Positive Input page, where you can enter positive input for the target calendar. |
Supporting Element Override |
Click the detail button to access the Payee Calendar SOVR page, where you can override the value of a bracket, date, duration, formula, or variable for a specific additional payment. |
This section provides an overview of advances and discusses how to enter instructions for advance payments.
Advance processing is the processing of on cycle calendars ahead of their regular schedule. Examples include payments for early termination and a full or partial period advance.
Note. The advance on cycle calendars are processed individually exactly as they would have been within their scheduled run. The only difference is the timing. For lump-sum payments, create an additional payment, not an advance payment.
In another chapter of this book, there is additional information about processing advances using on cycle processing.
See Entering Calendar Override Instructions for a Payee.
Page Name |
Definition Name |
Navigation |
Usage |
GP_OFFCYCLE_A_SEC |
Click the Advance Details icon in the Advances section on the Advance Request Details page. |
Enter instructions for processing an advance payment. |
|
GP_PI_MNL_AE |
Click the Adjust Absence Balancesbutton on the Advance Request Detail page. |
Adjust entitlement balances. |
|
GP_PI_MNL_ERNDED |
Click the Positive Input button on the Advance Request Detail page. |
Override earnings and deductions. |
|
GP_TRIGGER_RTO |
Click the Review Triggers link on the Advance Request Detail page. |
Enter or review retroactive trigger information. |
|
GP_ABS_EVENT |
Click the Absence Event Entry link on the Advance Request Detail page. |
Enter absence events that are related to the advance payment. |
|
GP_PYE_RUN |
Click the Review Payee Calendar Override link on the Advance Request Detail page. |
Enter override details for the payee calendar for the period that is being advanced. |
Access the Advance Request Detail page (click the Advance Details icon in the Advances section on the Advance Request Details page).
Note. The fields that are available for entry on this page
depend on the configuration settings that are created for this type of off
cycle transaction.
This page shot displays the page as it will be presented when no configuration
exists.
See Configuring Off Cycle Transactions.
Note. The system will not process more than one advance
for the same calendar group and person within the same off cycle run. If
you need to advance smaller fractions of the same pay period (such as the
1st through the 5th and
the 10th through the 11th)
at the same time, you must set up two different requests and process each
in a separate run.
In addition, if two advances are set up for the same payee and calendar
group in two different off cycle requests, and you attempt to process these
together in the same run, the system issues a warning that informs you that
the duplicate was discovered and that all but one request will be ignored.
You can ignore the warning and proceed, or go back and modify the request
before processing.
List Payees and the Calendar Groups to Advance
Calendar Group |
Select the unfinalized calendar group that is associated with the pay group. In the Calendars grid, the system lists all calendars associated with the selected calendar group in their processing order. |
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). |
Calculate From Date and Calculate Thru Date |
To issue a payment for a partial period, enter the begin and/or end dates for the period of time to be paid. For example, for a monthly pay calendar to process from the 1st to the 15th you only need to enter the 15th as the end date, to process from the 16th to the end of the month the user only needs to enter 16th in the begin date. Entering dates here causes period segmentation to occur during the off cycle run, without the presence of a segmentation trigger. (Segmentation triggers would affect both on cycle and off-cycle transactions, which is not a desirable outcome. As an example, if you're paying a 10 day salary advance, you have no reason to segment a payee's bonus payment or absence data for the same period.) To avoid unintentional duplicate payments, whenever from and through dates are defined for a calendar, subsequent processes will review the segments to ensure that new segments do not cover the same period of time for the same calendar. This rule applies regardless of whether the run type allows duplicates for the calendar period. |
Payment Method |
You can override the default payment method for the payroll calendars. |
Adjust Absence Balances or Positive Input |
This button is used to access either the Adjust Absence Balances page or the Positive Input page. The page accessed depends on whether the calendar in the list is an absence calendar or a payroll calendar. If it is an absence calendar, click to access the Adjust Absence Balances page, where you can adjust entitlement balances. If it is a payroll calendar, click to access the Positive Input page, where you can override earnings and deductions. |
Review Triggers |
Click the link to access the Retro page to review, add, or delete triggers. |
Absence Event Entry |
Click to access the Absence Event Entry page to enter absence events that are associated with this advanced payment. |
Review Payee Calendar Override |
Click to access the Payee Calendar Override (GP_PYE_RUN) component. You can view or modify overrides here. The system respects all payee calendar overrides when processing the advance payment, including overrides to prevent the processing of calendars. |
Overrides Exist |
This indicator will be turned on if payee calendar overrides exist for the calendar group. |
The Off Cycle On Demand component is used to create a request and create a calendar, as well as to process and view off cycle requests. On the Off Cycle On Demand page, you can calculate a run, view results, and finalize or cancel the process. Every time you calculate a run, the system first cancels all results then identifies and calculates the off cycle request. Therefore iterative trigger set up is not needed, as long as you run the calculation process from the On Demand page. If you use the Calculate Absence and Payroll Run Control page to calculate your off cycle requests, iterative triggers are necessary to cause a re-identification and recalculation if you select the Calculate option without selecting the Recalculate All option.
Retroactive and segmentation triggers still need to be created for off cycle transactions. The system will not create triggers unless you have set up the proper trigger definitions for each country. The records for which you should create trigger definitions are GP_OFFCYCL_M_VW, GP_OFFCYCL_C_VW, GP_OFFCYCL_U_VW, and GP_OFFCYCL_A_VW. These correspond to manual payments, corrections, additional payments, and advances, respectively.
See Setting Up Trigger Definitions.
When you are processing from this page, a remote call is made to calculate, finalize, or cancel the run, depending on the button that you click. This causes the process to run while remaining on the Off Cycle On Demand page. It will not redirect you to the Calculate Absence and Payroll page. If you want to run the process with a resolution chain, streams, or process lists, you will have to run it using the Calculate Absence and Payroll page, the same page from which you run the on cycle payroll processes. When you have run the calculation process successfully from the Off Cycle On Demand page, the system will automatically transfer you to the Payee Status page, upon completion of calculation or finalize. When the you run cancel, instead of redirecting you to the Payee Status page, a message appears that confirms the cancel process ran successfully.
Note. More detail on processing and viewing payroll is in the payroll processing chapter and the chapter on viewing and finalizing payroll results.
See Also
Understanding Payroll Processing
Viewing Payee Status and Updating a Payee's Processing Instructions