Managing Off-Cycle Processing

This chapter provides an overview of off-cycle processing, lists common elements, and discusses how to:

• Define common values for off-cycle groups.

• Record manual payments.

• Correct or reverse finalized results.

• Make unscheduled payments.

• Process periods in advance.

• View results of off-cycle processing.

Understanding Off-Cycle Processing

This section discusses:

• Differences between on- and off-cycle runs.

• Types of off-cycle transactions.

• Features of off-cycle processing.

• Steps for entering off-cycle requests.

• Processing and postprocessing steps.

• Source and target calendars.

• Off-cycle batch processing.

• System elements for developing off-cycle rules.

Differences Between On- and Off-Cycle Payrolls

On-cycle processing refers to executing regularly scheduled runs. In Global Payroll these are recurring runs for which a period, calendar, and calendar group have been predefined. A paygroup 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 and off-cycle processing is the way in which you enter instructions for what and who to process.

See Also

Processing Payroll

Types of Off-Cycle Transactions

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.

• Unscheduled 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.

Features of Off-Cycle Processing

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.

  See Defining Payee Net Pay Elections.

• 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 the system resolves. The Stop Regular Resolution option enables you to prevent the resolution of all primary elements, with the exception of any retroactive or positive input for those elements. Alternatively, you can select 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.

• Define iterative triggers definitions for modifications.

  For all off-cycle transactions, iterative triggers are enabled, such that the addition or change to any data on the off-cycle pages will automatically cause the payee with data changes to be recalculated when the user next runs the calculate phase for the off-cycle calendar group.

  Note. 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, Unscheduled payments and Advances, accordingly.

  See Setting Up Trigger Definitions.

Steps for Entering Off-Cycle Requests

You can enter multiple off-cycle requests for the same paygroup and target period.

To enter requests for off-cycle transactions:

1. Create an off-cycle group using the Off Cycle Requests (GP_OFFCYCLE_SETUP) component.

   An off-cycle group identifies which off-cycle transactions to process and the processing instructions, including who and what to pay and when to pay it. Its purpose is similar to a calendar in an on-cycle process, except that you enter specific instructions for each payee. Off-cycle group setup includes two steps:

   1. Name the off-cycle group and enter various default instructions for all transactions on the Intro page.

   2. For each transaction, enter instructions on the page that's specific to that transaction type.

2. Create a calendar group for the off-cycle run on the Calendar Group page.

   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.

   Note. You can create a calendar group for an off-cycle run directly on the Intro page of the Off Cycle Requests component by clicking the Create Calendar Group button. When you click this button, the system automatically populates the Calendar Group page with the information required to generate the off-cycle calendar group.

See Also

Defining Calendar Groups

Processing and Postprocessing Steps

To process requests for off-cycle transactions:

1. Initiate the off-cycle run.

   Use the same run control page that you use to initiate on-cycle runs. This page, the Payroll/Absence Run Control page, can be accessed by navigating to Global Payroll & Absence Mgmt, Absence and Payroll Processing, Off Cycle, Process Off Cycle. Or the same page can be accessed by navigating to Global Payroll & Absence Mgmt, Absence and Payroll Processing, Calculate Absence and Payroll.

   When the system recognizes the entered calendar group as an off-cycle group, it sets the Suspend Active setting to on for the processing phases where it is relevant (Identify and Calculate).

2. Finalize te run once you're satisfied with the processing results.

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.

See Also

Entering Processing Instructions

Off-Cycle Batch Processing

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 only be active in one run at a time.)

Here's what the system does when you submit an off-cycle request:

• Checks to see if 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, suspends the payee in the off-cycle calendar group.

Transaction processing varies depending on the type of off-cycle requesting being processed.

Manual Payments

With manual payments, batch validation checks to see if the calculated gross and net pay accumulator amounts match the gross 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 will have to match in order to finalize the payroll.

During batch processing the process list associated with the run type entered will be used.

• Earnings and deductions entered on the manual payment request:

  • Only resolved if on the process list.

  • Eligibility is bypassed, including generation control.

  • Pre and Post-process formulas are resolved. Overrides from post-process formulas will not be applied.

  • No individual components are resolved. But if the user adds a component it will be stored and added to any accumulator in which it belongs. An example would be if Units are entered as hours, the amount is not used to calculate an amount, just to update this units balances.

• Earnings and deductions resolve depending on the presence of positive input entered in the off-cycle request, as well as the stop regular resolution and limit element set elections.

• Supporting Elements will always be 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.

Corrections

Off cycle corrections are based on retroactive processing just like 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 being corrected or reversed.

• The retroactive method used is based on the type of correction being processed:

  • Normal Retro – Follows retroactive method based on the triggers and rule setup.

  • Replacement – Corrective retroactive method is forced.

  • Reverse – Normal Retro – Follows retroactive method based on the triggers and rule setup.

  • Reverse – Replacement – Corrective retroactive methods is forced.

• For the calendar 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 entered in the off-cycle request, as well as the stop regular resolution and limit element set elections.

  • 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.

Unscheduled Payments

During batch processing the process list associated with the run type entered will be used.

• Earnings and deductions entered on the unscheduled payments request follow on-cycle batch processing logic:

  • Only resolved if on the process list.

  • Eligibility is considered, including generation control.

  • Pre and post-process formulas are resolved.

  • Individual components are resolved, as needed.

• Earnings and deductions resolve depending on the presence of positive input entered in the off-cycle request, as well as the stop regular resolution and limit element set elections.

• Supporting Elements will always be resolved if they are on the process list.

• Both, period and element segmentation triggers are ignored.

• Entries from Time and Labor and the Manage Variable Compensation application are not picked up.

Advances

For advances, calendar groups are processed with the applicable calendars. Batch processing follows the same logic as on-cycle processing.

System Elements for Developing Off-Cycle Rules

The following table provides information about delivered system elements that are used during off-cycle processing:

Common Elements Used in This Chapter

Defining Default Values for an Off-Cycle Group

This section provides an overview of off-cycle group setup and discusses how to create an off-cycle group and define its default values.

Understanding Off-Cycle Group Setup

Use the Off Cycle Requests component (GP_OFFYCLE_SETUP) to create an off-cycle group and to define default instructions for the transactions to be processed. On the component's Intro page you enter a description of the group and select the default payment date and payment method for all transactions. After entering instructions on the Intro page, you complete a separate page of the component for each transaction type 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, unscheduled 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 Used to Define Default Values for Off-Cycle Transactions

Defining Common Values for Off-Cycle Transactions

Access the Intro page by entering the paygroup, target period ID, and name for the off-cycle group.

Description	Enter a long description of the off-cycle group.
Payment Date	This field enables you to specify a common payment date for all the transactions included in the off-cycle group.
Payment Method	This field enables you to specify a common payment method for all the transactions included in the off-cycle group.
Processing Status	Displays Unprocessed, Processing initiated, Processing finalized, or Canceled, depending on the status of the off-cycle payroll process. Once processing is finalized, you cannot make changes to the off-cycle group. Canceled appears if a user has canceled the calendar group with which the off-cycle group is associated.
Calendar Group	This value displays after you associate the off-cycle group with a calendar group. The system clears this value if you remove the off-cycle group from the calendar group.
Create Calendar Group	Click to generate a calendar group for the off-cycle group you are defining. When you click this button, the system displays the Calendar Group page pre-populated with the required calendar group information. Click OK to accept the system-defined calendar group. Note. This button appears on the page only after you save the off-cycle request. After the off-cycle request is associated with a calendar group, the button disappears. Note. Note that this button enables you to associate a single off-cycle request (group) with a calendar group. If you want to combine multiple off-cycle requests in the same calendar group, you should create the calendar group manually and add the separate off-cycle requests to the calendar group directly on the Calendar Group page.

Recording Manual Payments

This section provides an overview of recording manual payments and discusses how to record manual payment details.

Understanding the Recording of Manual Payments

A manual payment is a check 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 update 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.

Pages Used to Record Manual Payment Details

Recording Manual Payment Details

Access the Manual Payments page.

Employee ID	Enter the employee ID for whom you created the manual payment. The section will limit itself to payees (and jobs) that at one time or another were associated with the paygroup associated with the off-cycle group.
Empl Rcd Nbr (employee record number)	Select the job for which you created the manual payment.
Period (Calendar) Paid	Enter the pay period the manual payment covers.
Payment Date	Enter the payment date applicable to the off-cycle payment. Defaults the payment date from the off-cycle group, if it exists. You can override this value based on the individual payment. Note. Payment date as noted earlier can be used to determine what period balances to update. It may be different from the issue date of the original payment.
Payment Details	Click this link to access the Manual Payment Detail page, where you can enter all earning and deduction elements associated with the manual payment.

Processing Controls

Select the Processing Controls tab.

Period Begin Date and Period End Date	Defaults from the target period ID. These values can be overridden.
Run Type	Defaults from the calendar paid. This value can be overridden.

Payment Keys

Select the Payment Keys tab.

This tab displays the payments keys that have been set up at the pay entity level. It will only be visible if there are payment keys set up. The user can override the payment keys. If no payment keys are overridden the system will use the payment keys of the period end date of the target calendar.

Note. If you override one payment key, you override them all.

Entering Payment Details

Access the Manual Payment Detail page.

Payment Number	Enter the number associated with the payment number, cash receipt, check, or bank transfer for this manual payment.
Issue Date	Enter the date the payment was issued and payable to the payee.
Payment ID	In order to include this payment in the payment reconciliation, add the payment ID applicable to the manual payment.
Validate	After you enter all data for the page, click to validate the entries for the manual payment. The validation process will verify the input gross and net amounts are equal to the calculated gross and net accumulator amounts to ensure the amounts are entered correctly. If the values do 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	Once the validation process is run, the Validation Status is automatically updated. Valid values are: Not Validated – Indicates 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 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. Since the element needs to be resolved during calculation the system will not be able to validate until the calculation.
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, 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.

Note. By simply 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

Correcting or Reversing Payroll Results

This section provides an overview of correcting payroll results and discusses how to enter instructions to correct payroll 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.

Understanding Payroll Result Corrections

There are four types of corrections that can be processed. They are:

• Normal Retro.

• Replacement.

• Reversal – Normal Retro.

• Reversal – Replacement.

Example of a Normal Retroactive Correction and a Replacement Correction

Example: The user is aware that the payee was underpaid 50 USD in February. In actuality the pay was increased as of January 1st from 100 USD to 110 USD.

For a normal retroactive correction, 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 as follows:

For a replacement correction, 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 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 as follows (note the shift in retroactive mode):

Example of a Reversal – Both Modes

The off-cycle request for a reversal will force the reversal regardless of whether the underlying data has been changed to reflect the fact that the payee is ineligible or not, meaning:

• If the necessary data corrections have already taken place to reflect that the payee should not have been paid, the request for an adjustment or a replacement will have the same effect.

• If the necessary data corrections are not made, a subsequent retroactive process will reidentify and recalculate the reversed payment.

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 there were no changes in January (despite the trigger on January 1st).

For a normal retroactive reversal, the retroactive processing mode dictated by the underlying triggers are respected, but the other rules are abandoned. For a forwarding client this would shape up as follows (in terms of balances and target calendar calculations).

• All elements will be forwarded (the system ignores the retroactive processing set)

• All elements will be recalculated (the system ignores the retroactive recalculate setting)

For a corrective client this would develop as follows (in terms of balances and target calendar calculations):

• No elements will be forwarded (the system ignores the retroactive processing set)

• All elements will be recalculated (the system ignores the retroactive recalculate setting)

Replacement reversals 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 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 will be forwarded (the system ignores the retroactive processing set)

• All elements will be recalculated (the system ignores the retroactive recalculate setting)

For a forwarding client this would develop as follows (in terms of balances and target calendar calculations):

For a corrective client there is no principal difference between reversal – normal retroactive and reversal – forced replacement.

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 in 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.

Pages Used to Correct Payroll Results

Making Corrections

Access the Corrections page.

Employee ID	Enter the employee ID for whom you created the payment. The section will limit itself to payees (and jobs) that at one time or another were associated with the paygroup associated with the off-cycle group.
Empl Rcd Nbr (employee record number)	Select the job for which you created the payment.
Calendar To Correct	Select the finalized calendar that needs a correction made to it.
Type of Correction	Enter the type of correction. Valid values are: Normal Retro, Replacement, Reversal – Normal Retro, and Reversals – Replacement.

Note. When processing reversals you need to void the payment, which can be done 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.

Processing Controls

Select the Processing Controls tab.

Select Stop Regular Resolution if applicable to this correction. If a Limited Element Set needs to be processed, enter it here.

Note. For Reversal - Normal Retro, the Stop Regular Resolution check box will be selected and unavailable for entry. In addition, the Limited Element Set field will be unavailable.

Associated Data (Links)

Select the Associated Data (Links) tab.

From this tab, you can click links to access the positive input pages for the corrected calendar and the target calendar. Also, you can access the Supporting Element Overrides page for the payee and calendar. You can click a link to view, edit, and add retroactive triggers.

Payment Method (Override)

Select the Payment Method (Override) tab.

Select the payment method for the correction.

Making Unscheduled Payments

This section provides an overview of unscheduled payments and discusses how to enter instructions for unscheduled payments.

Understanding Unscheduled Payments

Unscheduled 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 the system calculates the amount for unscheduled payments based on the criteria that you enter.

Items and amounts paid with an unscheduled payment are typically entered as one-time positive input.

Pages Used to Enter Instructions for Unscheduled Payments

Entering Instructions for Unscheduled Payments

Access the Unscheduled Payments page.

Employee ID	Enter the employee ID for whom you created the payment. The section will limit itself to payees (and jobs) that at one time or another were associated with the paygroup associated with the off-cycle group.
Empl Rcd Nbr (employee record number)	Select the job for which you created the payment.
Select Pay Period (Calendar)	Select the source calendar. You can select from open or closed payroll calendars only.
Payment Date	The default value comes from the Intro page if a value was entered on that page.

Processing Controls

Select the Processing Controls tab.

Run Type	The run type identifies the process list to use during processing. The system displays the run type that's associated with the selected pay period (source) calendar, by default. To use a different run type, make a selection here. 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 unscheduled payment and select the new run type here.
Stop Regular Resolution	Select if applicable for this unscheduled payment
Limited Element Set	Enter the limited element set here if needed for processing.

Note. To prevent regular earnings deductions from appearing on the unscheduled payment, you will probably want to select either Stop Regular Resolution or enter a Limited Element Set field value.

Associated Data (Links)

Select the Associated Data (Links) tab.

P.I. For Target Calendar (positive input for target calendar)

Click to access the Positive Input page where you can enter positive input for the target calendar. The system generates a target calendar based on the target period ID. The calendar name consists of the target period ID plus a four-digit 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.)

Supporting Element Overrides

Click the detail button to access the Payee / Calendar Overrides page, where you can override the value of a bracket, date, duration, formula, or variable for a specific unscheduled payment.

Payment Keys

Select the Payment Keys tab.

This tab is identical to the Payment Keys tab on the Manual Payments page. You can override the values of any payment keys that have been defined for the pay entity that is associated with the paygroup.

See Recording Manual Payments.

Payment Method (Override)

Select the Payment Method (Override) tab.

You can override the default payment method that is displayed on this tab. The default value comes from the Intro page.

Processing Advances

This section provides an overview of advances and discusses how to enter instructions for advances.

Understanding Advances

Advance processing is the processing of on-cycle calendars ahead of their regular schedule. Examples include payments for early termination or a full or partial period advance.

Note. The advance on-cycle calendars are processed individually exactly like they would have been within their scheduled run. The only difference is the timing. For lump-sum payments, create an unscheduled payment; not an advance payment.

Page Used to Enter Instructions for Advance Payments

Entering Instructions for Advance Payments

Access the Advance Payrolls page.

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 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 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

Processing Controls

Select the Processing Controls tab.

Calculate From Date and Calculate Thru Date

To issue a payment for a partial period, enter the begin and end dates for the period of time to be paid. 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- and off-cycle transactions, which is not a desirable outcome. As an example, if you're paying a 10-day salary advance, there's 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 rules applies whether or not the run type allows duplicates for the calendar period.

Associated Data (Links)

Select the Associated Data (Links) tab.

Absence Entitlement Adjustment	Click to access the Adjust Absence Balances page where you can adjust entitlement balances.
Earning / Deduction Overrides	Click to access the Positive Input page, where you can override earnings and deductions.

Payment Method (Override)

Select the Payment Method (Override) tab.

On this tab, you can override the default payment method for the payroll calendars.

Viewing Results of Off-Cycle Processing

To view the results of an off-cycle run you can:

• Check the Processing Status field on the Intro page of the Off-Cycle Request component to see the processing status for the entire off-cycle group.

• View the Results by Calendar Group pages.

• View the Payee Messages pages.

The last two items are covered in the payroll processing chapter.

See Also

Viewing Results by Calendar

Viewing Payee Messages