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 Enterprise Global Payroll 9.1 PeopleBook for information about off-cycle setup and processing.
See Also
Configuring Off Cycle Transactions
This section discusses:
The off-cycle process.
Types of off-cycle transactions.
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.
The four types of off-cycle transactions are:
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.
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.
Additional payments
Additional payments enable you to enter onetime payments that fall outside the normal payroll process. Examples include onetime bonuses and expense reimbursement.
Advances
Advances enable you to pay payees before their normally scheduled pay run. Examples include salary due on termination.
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.
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. Due to your reporting the information late, Social Security charges a surcharge. PeopleSoft Enterprise 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 Enterprise Global Payroll for Spain elements.
Two ways are available to run a payroll correction of a finalized payroll:
Use a special calendar with a specific run type of CORRECCION.
Use core Global Payroll off-cycle functionality.
Running Corrections Using a Specific Run Type
To run a payroll correction using a special calendar with a specific run type of CORRECCION:
Run the regular payroll for the month, finalize it, and pay it.
Enter new data that affects that payroll run.
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 a period ID that has begin and end dates that are the same as the period 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.
Run the payroll for the correction calendar to perform the correction calculation.
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.
Generate monthly legal reports.
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 and also select to print just the retro calculation, the system prints one payslip corresponding to the delta calculation between the first payroll calculation and the correction payroll calculation.
The following example illustrates how to process a payroll correction for PeopleSoft Enterprise 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 30th, 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 know that this correction will 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.
Running Corrections Using Off-Cycle Functionality
PeopleSoft Enterprise 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:
Run the regular payroll for the month, finalize it, and pay it.
Enter new data that affects that payroll run.
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:
Select as the target period ID the period that you want to correct.
Create a request by providing the information about the off-cycle processing that you want to run.
List the employees for whom you need to enter data to correct the finalized payroll in the Corrections - List Payees and Calendars grid.
Access the Correction Request Details page to enter the calendar to correct.
Click the PI Calendar to Correct link to enter the positive input into the finalized payroll that you want to correct.
Click the Absence Event Entry link to enter absences affecting the finalized payroll that you want to correct.
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.
Create a calendar group on the Off Cycle On Demand page.
Click the Calculate button on the Off Cycle On Demand page to run the off-cycle processing and perform the off-cycle calculations.
Click the View Status and Results link to check processing results.
Finalize the off-cycle processing so that you can pay the delta.
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.
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 Enterprise 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