Managing Off-Cycle Payments

This chapter provides an overview of off-cycle processing and discusses how to:

• Record manual payments.

• Process payroll corrections.

• Make additional payments.

• Issue advance payments.

Note. Refer to PeopleSoft Global Payroll 9.1 PeopleBook for information about off-cycle setup and processing.

See Also

Configuring Off Cycle Transactions

Managing Off Cycle Processing

Understanding Off-Cycle Processing

This section discusses:

• The off-cycle process.

• Types of off-cycle transactions.

The Off-Cycle Process

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.

Types of Off-Cycle Transactions

The four types of off-cycle transactions are:

1. Manual payments

   Manual payments enable you to enter payments that you have calculated and paid outside of the payroll system. Examples include paying a new hire with a manual check because his or her pay details were not entered in time for the normal pay run.

2. Corrections

   Corrections enable you to correct results of any finalized payroll. Examples include recalculation due to a sickness not entered in the system on time or unpaid overtime.

3. Additional payments

   Additional payments enable you to enter onetime payments that fall outside the normal payroll process. Examples include onetime bonuses and expense reimbursement.

4. Advances

   Advances enable you to pay payees before their normally scheduled pay run. Examples include salary due on termination.

Recording Manual Payments

Manual payments are payments that you record for items that you calculate and pay outside of the system, such as cash and check payments. In Spain, manual payments might correspond to advances, expenses, or special payments such as bonus or a commission paid outside the regular cycle.

When you are entering manual payments for Spanish payees, Oracle recommends that all calculations be manually calculated outside the system and then entered. You need to carefully consider the following areas when entering manual payments:

• Selecting the target period ID when you are adding a new off-cycle request.

  Oracle recommends that you select the target period that coincides with a previous finalized calendar or the current open calendar.

• Specifying calendar control information on the Manual Payment Detail page.

  The selection of the payment date directly affects how elements are accumulated. For example, if you have an accumulator that accrues based on period end date, the payment date may not update the accumulator balances at the right time.

  The period begin date and period end date are provided by default from the target period ID. Oracle recommends that you not change these dates because the delivered Spanish rules are designed to calculate using whole periods and may not automatically segment if a partial period is entered.

• Selecting processing controls on the Manual Payment Detail page.

  The run type is provided by default from the calendar paid, and Oracle recommends that you use the default. To ensure that the payee's manual payment is processed by the system, you must select the Allow Duplicates check box on the run type; otherwise, the payee may not be processed again if the system detects that they have already been processed in the period.

  The option that you select in the Element Selection group box indicates the elements to process with the off-cycle transaction. If using the Limited Element Set value, you need to ensure that all elements calculate independently of pre-posting or post-processing formulas because these do not resolve during off-cycle processing.

Note. Manual payments are used to record monetary values only; absence accumulators are not updated when you use this method.

Processing Payroll Corrections

The payroll corrections functionality of off-cycle payroll processing enables you to change finalized results for specific employee and calendar combinations due to such things as user error or missing information.

A common cause of missing information is that your company might run payroll before the end of the month to ensure that employees receive their money by the last day of the month. Because of the early payroll run information might be missing from the remaining days of the month that you need to report to Social Security, such as terminations, hires, sicknesses, and overtime.

PeopleSoft Global Payroll for Spain provides two options for reporting the missing information to Social Security in a FAN file.

• One option is to wait until the next payroll and run retroactive processing of payroll as part of the payroll calculation for the subsequent month to correct the payroll and pay for differences. You must report this retroactive processing information in a complementary FAN file when generating the FAN file for the subsequent month. Because you are reporting the information late, Social Security charges a surcharge. PeopleSoft Global Payroll for Spain calls this running a pure retroactivity.

• To avoid paying the accompanying surcharge for the complimentary FAN file report, you can use off-cycle processing to make payroll corrections for the affected payroll. You can run a correction in one of two ways:

  • Run off-cycle processing to make payroll corrections for the affected payroll so that you can report the information to Social Security using the latest payroll run.

    This is called correcting a payroll. By running the payroll correction before the subsequent payroll run, you can avoid generating a complimentary FAN file and its accompanying surcharge.

  • Run a special run type CORRECCION to produce the same effect.

Note. Technically, a payroll correction is a retro calculation in which the system behavior is changed to deliver Social Security and tax data in a different way using PeopleSoft Global Payroll for Spain elements.

This section discusses:

• Corrections using the CORRECCION. run type.

• Corrrections using Global Payroll Core off-cycle functionality.

• Setup variables for corrections.

• Additional correction scenarios.

Corrections Using the CORRECCION Run Type

To run a payroll correction using a special calendar with a specific run type of CORRECCION:

1. Run the regular payroll for the month, finalize it, and pay it.

2. Enter new data that affects that payroll run.

3. Create a correction calendar using the Calendars component (GP_CALENDAR) or the Automatic Calendar Creation component (GP_AUTO_CAL).

   The system automatically runs a correction for all the employees affected by pending changes, provided that for the calendar and calendar group you:

   • Select for the calendar the same period ID as the period ID of the calendar to be corrected.

     (This informs the system to perform a correction calculation rather than a true retroactivity calculation)

   • Select for the calendar a run type of CORRECCION.

   • Select for the calendar the payee selection option of All Payees with ...

   • Select for the calendar the additional criteria option of Pending Retroactive Changes.

   • Select for the calendar group the Process retro triggers check box for the off-cycle calendar group.

4. Run the payroll for the correction calendar to perform the correction calculation.

5. Run the banking process for the off-cycle calendar group to pay employees the difference between the regular payroll calculation and the correction payroll calculation.

6. Generate monthly legal reports.

7. Generate payslips:

   • If you select the original calendar group, the system generates one payslip that corresponds to the first payroll calculation.

   • If you select the new target calendar group, you can select whether you want to print recalculated values or differences between the new calculated values and the original calculation.

Example of Processing a Payroll Correction Using the CORRECCION Run Type

The following example illustrates how to process a payroll correction for PeopleSoft Global Payroll for Spain. Assume that you run the regular payroll for January on January 25. To do so, create the corresponding calendar and calendar group called ENE PAYROLL. On January 30^th, finalize the January payroll and run the banking process for the calendar group ENE PAYROLL.

On February 2, the payroll administrator receives positive input about overtime for EMP1 that corresponds to the January payroll calendar. (Note that in this example we assume that a retro trigger is defined for GP_PI_MNL_DATA.) On February 5 the payroll administrator realizes that no reduction was entered for employee EMPL2 and enters the reduction at the contract data level. (Note that in this example we assume that a retro trigger is defined for CNTRCT_DATA_ESP. In both of these cases the system generates a retro trigger for each of these employees that will cause retroactive processing for January the next time that you run the payroll process. You can check which employees are affected by retro calculations on the Review Triggers page by selecting Global Payroll & Absence Mgmt, Absence and Payroll Processing, Prepare Payroll, Review Triggers.

On February 15 the payroll administrator wants to run a correction of January payroll to consider all the changes that happened after it was run. He doesn't want this correction to cause Social Security complementary reporting. (Note that because the payroll administrator is still on time to generate the FAN file for January, the company does not have to submit a complementary FAN file to Social Security and does not incur the corresponding surcharge.) The payroll administrator creates a calendar group containing just one calendar with the necessary conditions for running a payroll correction.

The payroll administrator runs the new calendar group and, after checking results, finalizes the payroll run. To pay differences, the payroll administrator runs the banking process for the calendar group ENE CORRECCION. The process generates a banking file that contains just the delta between the first payroll run and the correction calculation.

When the payroll administrator or another user runs tax or Social Security reports, the system uses the recalculated values. For the FAN file, the report includes modifications that were made in February affecting January in the regular report, not a complementary report.

The payroll administrator can generate payslips for January, printing one payslip for the ENE PAYROLL calendar group that corresponds to the first payroll calculation for January and another payslip for the ENE CORRECCION calendar group that corresponds to the delta calculation between the first calculation and the correction calculation. When printing payslips, payroll administrators can select to print the recalculated values or the values that correspond to the delta calculation between the first calculation and the correction calculation.

Corrections Using Global Payroll Core Off-Cycle Functionality

PeopleSoft Global Payroll for Spain delivers off-cycle configurations for correcting off-cycle requests that are related to the following situations: new hires, new terminations (for terminations after the first payroll run), and payroll correction. Define configurations for off-cycle requests on the Off-Cycle Configuration page.

To run corrections using core Global Payroll off-cycle functionality:

1. Run the regular payroll for the month, finalize it, and pay it.

2. Enter new data that affects that payroll run.

3. Create an off-cycle request.

   Select Global Payroll & Absence Mgmt, Absence and Payroll Processing, Off Cycle, Off Cycle on Demand and then perform the following steps:

   1. Select as the target period ID the period that you want to correct.

   2. Create a request by providing the information about the off-cycle processing that you want to run.

   3. List the employees for whom you need to enter data to correct the finalized payroll in the Corrections - List Payees and Calendars grid.

   4. Access the Correction Request Details page to enter the calendar to correct.

   5. Click the PI Calendar to Correct link to enter the positive input into the finalized payroll that you want to correct.

   6. Click the Absence Event Entry link to enter absences affecting the finalized payroll that you want to correct.

   7. Provide a supporting element override in the target calendar by accessing the supporting element overrides, clicking the Target Calendar link, and entering a value 1 for the variable CLI VR CORRECCION.

4. Create a calendar group on the Off Cycle On Demand page.

5. Click the Calculate button on the Off Cycle On Demand page to run the off-cycle processing and perform the off-cycle calculations.

6. Click the View Status and Results link to check processing results.

7. Finalize the off-cycle processing so that you can pay the delta.

Setup Variables for Corrections

Global Payroll for Spain includes two setup variables that enable you to control how the system processes tax deductions and tax percentage calculation during corrections calendar calculation:

Note. These setup variables also affect how the system processes inactive segment calculation.

See Also

Segmentation

Additional Correction Scenarios

This section provides examples of correction scenarios that you can manage using Global Payroll for Spain.

Example of a Correction Affecting a Month with Retro

Assume that you have run a May payroll for an employee. This payroll process includes retro processing for April due to a salary increase that was made effective as of April, and overtime entered retroactively for April.

For the May payroll run, the system:

• Calculates the IRPF RTR deduction to compute taxes for retro deltas.

• Applies current recalculated tax percentages to the retro deltas.

After finalizing and paying the May payroll, you realize that there was additional overtime that needs to be paid in May. You enter the additional overtime as positive input and create an off-cycle correction calendar to process it. This off-cycle correction recalculates the May payroll and includes the added overtime.

• Retro deltas that were executed during the first run of the May payroll.

• The most recent results for the May calendar.

Example of a Correction Affecting a Month without Retro and Previous Months with Retro

Assume that you have run a May payroll for an employee that does not include any retro processing. After finalizing and paying the May payroll, you are informed that the employee should have received both a salary increase effective for April and overtime for April. Because you have not yet processed the legal reports, you decide to run a correction calendar for May to process the retro changes for April.

During the correction process, the system:

• Takes the salary increase into account for the recalculation of the May payroll.

• Recalculates the tax percentage for May.

• Forwards the retro deltas for April to the correction calendar because it is the calendar that triggered the retro processing.

• Generates negative net pay for the correction calendar because it processes only the tax deductions that are linked to the retro deltas.

• Stores the retro deltas to the corresponding tax result record.

• Recalculates the tax percentage to account for the impact of the retro deltas on the tax base. The system calculates the new taxable base using the last calculated base (recalculation for May) plus the retro deltas being forwarded to the correction calendar.

  Note. The value of the CLI VR CAL TAX PCT setup variable must be Y for the system to recalculate the tax percentage.

  See Setup Variables for Corrections.

When you run the official reports, the system takes into account the last calculation for May and the retro deltas from April.

Example of a Correction Affecting a Month with Retro and Previous Months with Retro

Assume that you have run a June payroll for an employee that includes retro processing affecting May due to a salary increase that was effective in May and overtime entered retroactively for May. The system calculated retro deltas during this June payroll calculation. After finalizing and paying the June payroll, you are informed that the salary increase should have been effective for April and for an increased amount, and that there was additional overtime that should have been entered for April. Because you have not yet processed the legal reports, you decide to run a correction calendar for June to process the retro changes for April and May.

During the correction process, the system:

• Takes the salary increase into account for the recalculation of the June payroll.

• Maintains the values of the retro deltas associated with the original June calendar and forwards the new retro deltas from both April and May to the correction calendar.

• Generates new results for the extra period.

• Generates negative net pay for the correction calendar because it processes only the tax deductions that are linked to the retro deltas.

• Stores the retro deltas to the corresponding tax result record.

• Recalculates the tax percentage to account for the impact of the retro deltas on the tax base. The system calculates the new taxable base using the last calculated base (recalculation for June) plus the retro deltas being forwarded to the correction calendar.

  Note. The value of the CLI VR CAL TAX PCT setup variable must be Y for the system to recalculate the tax percentage.

  See Setup Variables for Corrections.

When you run the official reports, the system takes into account the last calculation for June and the retro deltas from both April and May.

Making Additional Payments

Use the additional payments functionality that is part of off-cycle processing to make onetime unscheduled payments that are processed outside of the normal on-cycle payroll. Examples include onetime bonuses, awards, and expense reimbursements. These transactions are similar to manual payments in many respects; however, the system calculates the amount for additional payments.

You need to consider the following areas when entering additional payments:

• When you are selecting the period paid, Oracle recommends that you select the previous finalized calendar or the current open calendar.

• Use this method to record monetary values only. Absence accumulators will not be updated.

Issuing Advance Payments

Advance processing is the processing of on-cycle calendars ahead of their regular schedule. Use the advance functionality of off-cycle processing when you want to pay an employee before his or her normal on-cycle pay run. Examples include payments for early terminations (for which the termination payment needs to be paid immediately and not in the next on-cycle pay run), full period advances, and partial period advances.

Observe the following guidelines when making advance payments:

• Always select the next open calendar, because skipping calendars may update accumulators incorrectly.

• Absence accumulators calculate automatically for the calendar group selected.

PeopleSoft Global Payroll for Spain delivers an off-cycle configuration for advance payments off-cycle requests that you can use for advance terminations. Define configurations for off-cycle requests on the Off-Cycle Configuration page.

See Also

Configuring Off Cycle Transactions