Payroll Management

Payroll Payment and Distributions Overview

Using Oracle HRMS you can define payment methods for your enterprise and define any rules for validating or processing the distribution of pay.

Payroll Payment and Distributions in Oracle HRMS

You provide for payment and distribution by defining payment methods for your enterprise and then specifying which of these organizational payment methods are valid for the payrolls that you create. This enables you to set up a flexible pattern of payment in which you can pay individual employees by a single payment method, or by a combination of valid payment methods.

Key Concepts

To enable you to set up payment and distributions correctly, you need to understand these key concepts:

• Payment methods for your enterprise

• Cash Management and Oracle Payroll

Reporting on Payroll Payment and Distributions

See: Reports and Processes in Oracle HRMS, Oracle HRMS Configuring, Reporting, and System Administration Guide

Payment and Distributions

Payment Methods for Your Enterprise

You can define as many payment methods as you require for your enterprise. When you create a payroll, you can select which of these methods are valid for employees assigned to that payroll. You select one method as the default method for the payroll. To choose the payment methods for an individual employee, use the Personal Payment Method window. If you do not enter any personal payment methods, the employee is paid by the default method for the payroll.

Payment Methods and Payment Types

Any payment method that you define must belong to one of the payment method types that your enterprise supports. The most common payment method types are:

• Direct Deposit

• Check/Cheque

• Cash

Your particular enterprise may support a different range of types. Additionally, there can be local variations within each type. For example, the direct deposit type is NACHA in the U.S., BACS in the U.K. and BECS in Australia.

However, in all enterprises you can define multiple payment methods for the same payment method type.

You can also define payment methods for third party payments, such as court-ordered wage attachments. Third party payments are always made by cheque/check, so methods for these payments must have the type Cheque (Check).

Valid Payment Methods

A valid payment method is a payment method that:

• Belongs to one of the payment method types approved in your enterprise

  For example, payments by cash are not allowed in some enterprises.

• Is an accepted local variation for your enterprise

  For example, U.S. direct deposit payments can be made only by NACHA transfer and not by BACS

Payment Method Types: Required Information

When you define a payment method, always include the required information for the payment method type:

Payment Method Type	Required Information
Check/Cheque	Source bank account name and number. The source account is the account from which your enterprise makes the payment. The payee account details are only known to the payee. You do not record them in Oracle Payroll.
Direct Deposit	Source and destination account details. The destination account is the payee account. Because payments transfer directly to a named account, Oracle Payroll can make direct deposits only if you supply source and destination account details.
Cash	Coinage analysis. If your enterprise makes cash payments, you use the coinage analysis to specify the denominations of notes and coins in which employees receive payment.

Payment Methods and Employees

Each employee must have at least one valid payment method, but you can also use multiple payment methods for an individual employee.

Payment Methods and Source Bank Accounts

When you pay employees from separate source accounts, each source account must have a separate payment method. You cannot share a payment method across several different source bank accounts. However, you can create multiple payment methods for the same source bank account.

Payment Methods: Summary

Observe these guidelines when defining your payment methods:

• Each payroll must have at least one valid payment method.

• Each payroll must have a default payment method.

• Each employee must have at least one valid payment method.

• Each source account must have at least one valid payment method.

Your sequence for defining payment methods and attaching them to a payroll is:

1. Define your organizational payment methods.

   See: Defining a Payment Method

2. Link your organizational payment methods to a payroll.

   See: Defining a Payroll, Oracle HRMS Payroll Processing Management Guide

Cash Management and Oracle Payroll

Oracle Cash Management manages and controls the enterprise cash cycle. The Cash Management auto reconciliation matches Oracle Payroll against bank statement lines if the transaction meets the following criteria:

• The Oracle Payroll payment number matches the statement line payment number.

• The Oracle Payroll payment amount matches the statement line payment amount.

Cash Management accesses a view of payments generated by Oracle Payroll and compares it against the information on the bank statement. This process generates error messages on mismatched transactions.

Each time a new payment method is created, the bank details transfer to Oracle Accounts Payable. When defining a payment method, you must enter the GL Cash Account field to work with Cash Management.

Important: Because payment method details are passed to Accounts Payable from Payroll, it is important to ensure that you are entering this information correctly. If you inadvertently enter incorrect details, you could end up with reconciliation issues later.

Cash Management is available only for the Payroll payment methods of checks/cheques and electronic fund transfers (such as NACHA in the U.S, Direct Deposit in India).

Important: If you want to use Cash Management fully, you must install Oracle Accounts Payable and Oracle Accounts Receivable due to the interdependency of the products. All accounting functions take place in Accounts Payable and Accounts Receivable, and Cash Management provides the engine for reconciliation and forecast.

Setting Up Integration of Cash Management with Oracle Payroll for EFT Reconciliation

For setup steps to integrate Cash Management with Oracle Payroll, see the Oracle Cash Management User Guide.

Additional Steps to reconcile EFT payments for the UAE legislation:

Oracle HRMS provides a reconciliation function, pay_ae_tran_identifiers.get_eft_recon_data for AE EFT Payments (AE Direct Deposit AED). This function is predefined in the RECONCILIATION_FUNCTION column of the PAY_PAYMENT TYPES table. This function retrieves your Unique Identifier for the bank statements.

To specify your own Unique Identifier:

1. Add the following data to the lookup PAYMENT_TRX_CONC_IDENTS

   • Code: AE Direct Deposit AED

   • Meaning: <Your Unique Identifier>

   • Enabled: Y

2. Create your reconciliation function. For details on how to write a reconciliation function, refer to Creating a Reconciliation Function on My Oracle Support, with note ID 949409.1.

3. Use the HRMS Manager responsibility and navigate to the Further Payment Method Info flexfield (Payroll > Payment Methods > Others). Specify the new function name in the Reconciliation Function segment of the flexfield.

Defining a Payment Method

Use the Organizational Payment Method window to define payment methods for your enterprise.

From this window, you:

• Supply the name and starting date of your payment method.

• Enter the details of the source bank account from which your enterprise makes the payment.

• Specify the General Ledger (GL) accounts that hold reconciliation and error details for the payment method.

• Handle costing for the payment method. For example, you can specify whether to transfer the costs to GL and whether costing applies to cleared payments only, uncleared payments only, or a combination of cleared and uncleared payments.

• Confirm that your source bank account in Oracle Payroll is the same bank account that Oracle Cash Management uses to clear your payments. This confirmation assures you that you are operating with a single consistent bank account rather than with duplicate accounts that introduce accounting errors.

To define a payment method

Supply a name and start date for your payment method

1. Set your effective date so that it reflects the date when you want to begin using this payment method.

2. Enter a name for the payment method, and select the payment method type.

   For a third-party payment method, always select the type Check/Cheque. The default currency for your business group appears automatically.

3. If an alternative currency exists for your payment method, select it.

4. If your payment method controls payments to a third party such as a benefits carrier or garnishment receiver, check the Third Party Payment box.

Enter the source bank details for your payment method

5. Navigate to the Source Bank tab. The Country for your source bank account appears automatically.

6. Enter the Bank Details field to open the Bank Details window. Enter information about the account from which your enterprise intends to make payments.

   If you are using Cash Management, include the following information:

   • Account Name

   • Account Type

   • Account Number

   • Bank Name: If this already exists, enter the name exactly as it appears in Accounts Payable.

   • Bank Branch: If this already exists, enter the name exactly as it appears in Accounts Payable.

   Italy Users: You can enter the Bank Name, Bank Location, Account Number, and Account Name. The IBAN Account displays by default.

   Ensure that you enter any additional bank details that are specific to your enterprise. For example, bank details for U.S. payment methods always require a transit code. The transit code, or transit routing number is the nine-digit number that identifies the financial institution. If the transit code is incorrect, the funds will not be posted to the account.

   South Africa Users: Enter the account holder's name and indicate whether the account holder relationship is joint, own, or third party.

   Belgium, Denmark, Finland, France, Germany, Hungary, Ireland, the Netherlands, Norway, Poland, Russia, Spain, and Sweden users: Enter the Bank Identifier Code (BIC) and International Bank Account Number (IBAN) in the Bank Identifier Code and the IBAN Number fields, respectively. Note that you must enter at least one of the account numbers, that is, either the International Bank Account Number (IBAN) or the Account Number. If you enter the Account Number, then the Bank Code and Branch Code fields are mandatory.

   Warning: Always review the account setup for Oracle Accounts Payable before you define the account in Oracle Payroll. The details for your Payroll account must exactly match the account details in Accounts Payable. Otherwise, Accounts Payable creates an extra account with marginally different details. This duplicate account introduces errors when you reconcile payments between Payroll and Accounts Payable.

Specify what type of payments to cost for this payment method

7. Navigate to the Costing tab. Each check box indicates a particular type of payment. Check the boxes for each type of payment that you want to cost. When you subsequently run the Costing of Payment process, it costs each type of payment as you have indicated. The entries that you make for an individual check box can imply automatic checking of related boxes. Your choices are:

   • Cost Payment: Check this box to specify that you want to cost only uncleared payments for this payment method.

   • Cost Cleared Payment: Check this box to specify that you want to cost only cleared payments for this payment method. If you check this box, the Cost Payment box is also checked by default.

   • Cost Cleared Voided Payment only: Check this box to specify that you want to cost any voided payments that have also been cleared by Oracle Cash Management. If you check this box, the Cost Payment and Cost Cleared Payment boxes are also checked by default.

   • Exclude External/Manual Payment: Check this box to exclude any external/manual payments from costing. This exclusion is useful if you are using this payment method as a dummy payment method to cancel a previous payment, or if you are making a payment by cash. If you check this box, the Cost Payment box is also checked by default.

   • Transfer to GL: Check this box to specify that costed payments should transfer to General Ledger. If you check this box, the Cost Payment box is also checked by default.

Specify the GL accounts for this payment method

8. Navigate to the General Ledger tab.

9. Select Ledger to indicate the ledger to use if you intend to reconcile payments using Oracle Cash Management.

10. Select the GL Control Account.

11. Select GL Cash Account to indicate which cash account to use for the reconciliation of payments.

    The entry for Description appears automatically by default, depending on what you enter in the GL Cash Account details.

12. Select the Cash Clearing Account.

13. Select the Error Account.

    When you first specify the GL accounts for a bank account, these then become the default GL accounts for any other payment methods that use the same bank account. The defaults apply for all new payment methods using the bank account. They also apply retrospectively for any existing payment methods that were already using the same account. However, you can override these defaults by entering your preferred GL accounts on the General Ledger tab.

    At this point, check that your Payroll setup and Cash Management setup are fully integrated.

Confirm that you can reconcile payments in Cash Management

14. Navigate to the Cash Management tab. You cannot change the information on this tab, but you can confirm that your GL accounts are correct.

15. To confirm that Oracle Cash Management is operating with the same source bank account that you are using in Oracle Payroll, view the check box. If the box is checked, then Oracle Cash Management holds the bank account for this payment method, and you can reconcile payments knowing that you are using an identical account in Payroll, and in Cash Management.

    However, if the box is not checked, this indicates that Oracle Cash Management does not hold the details for your Payroll account. This may indicate that duplicate accounts exist and you should exercise caution when you reconcile your payments.

Enter further information for the payment method

16. Enter further information to determine how to process this payment method. Click in the Further Information field to see the range of further information for your enterprise. For Japan users only: Enter the company code and company name. Select the delimiter type for the Direct Deposit file.

17. For Norway users only: Enter values for the following fields to define the payment method level. (The same payment type supports the ISO20022 and older Telepay process).

    Field	Description
    Initiating Party Name	Enter the name of the known party.
    Sender ID	Enter the initiating party ID. This unique organization identification is assigned by an institution using an identification scheme. Typically, this is the customer-ID in the debtor bank based on the Brønnøysundregistrene and their Central Coordinating Register of Legal Entities, or other identification arranged with the bank.
    Scheme Name	Enter the code for the identification scheme as published in an external list. The options are BANK and CUST: BANK: Debtor/creditor relates to a sub-level agreement under the main agreement (a bilateral agreement between a customer and a bank) regarding a special service or subsidiaries or divisions. When the scheme name is BANK, the Sender ID should have a Customer Service ID assigned by the bank. CUST: Debtor/creditor relates to the main-agreement with the financial institution. When the scheme name is CUST, the sender ID should be the organization number of the initiating party.
    Batch Booking	Indicate whether [the requestor] has requested a single entry per individual transaction or a batch entry for the sum of the amounts of all transactions within the group of a message. The options are: No: Single Booking requested. Yes: Batch Booking requested. This default value is Yes. Note: The Yes and No values are reflected in XML as true and false.
    Service Level Code	The service level code specifies a pre-agreed upon service or level of service between the parties as published in an external service level code list. Select one of the following options: NURG (Non-urgent Payment): Select as the default. SDVA (Same Day Value): Intercompany only (not for salaries). SEPA (Single Euro Payments Area) URGP (Urgent Payment): Only suppliers (SUPP) but not for salaries.
    Payment File Format	This field indicates which supported payment file format and process are in use. The supported processes are Telepay and ISO 20022. Telepay: Indicates that the older file format and process, the Norwegian Payment Process, are in use. This is the default value if the field is blank. If this value is set, and you run the newer ISO20022 process, then an error occurs. ISO20022: Indicates that the ISO 20022 file format and process are in use. If this value is set and you run the older Telepay process, the following error message appears: Bank file format processed is not according to specified set up on Payment method. Note: If you see this message, you must roll back the error process before running the new process.
    Payment Identification ID	The payment identification ID is a reference assigned by a sending party to identify the payment information block within a message.
    Payment Method	Select one of the following values to specify the payment type to use for transferring the funds: CHK: Cheque TRF: Credit Transfer. This default value is TRF.
    Debtor Name	Enter the name of the debtor party.
    Debtor ID	The debtor ID is a unique identifier assigned to a debtor organization by an institution using an identification scheme.

Viewing Statement of Earnings

Oracle Payroll enables you to view an employee's statement of earnings (pay advice) without having to run the Pay Advice report.

You do this using the Statement of Earnings window.

There are various ways to access statement of earnings information. The information displayed may vary depending on whether you have run the PrePayments process or just a payroll run.

The information displayed in the Statement of Earnings window reflects the information in the printed pay advice.

The payroll run generates four types of Statement of Earnings (SOE):

• Master Assignment Action SOE for each employee and shows aggregate Year to Date balances

• Regular Payroll Run SOE for each employee and shows Period to Date and Year to Date balances

• Separate Check SOE only if employee has an element with Separate Check input value set to Yes

• Tax Separate Run SOE if employee has an element(s) with any of the following input values:

  • Separate Check set to Yes

  • Tax Separately set to Yes

  • Deduction Processing is set to other then All

Canada only: The Payroll Run SOE displays one "Master Assignment Action" master record and multiple records with second and third layer run types.

If you are processing Multiple Assignment Payments, then the PrePayment Statement of Earnings displays consolidated earnings and deductions information. The header information displayed on the Statement of Earnings is obtained from the primary assignment; however, if this assignment is not processed, then the header information is taken from the first assignment processed in the PrePayment process.

To view the last payroll with PrePayments run against it

Perform one of the following:

• Select View | Statement of Earnings.

• From the Assignment window, choose Others and select Statement of Earnings.

• Choose the Statement of Earnings window in Fastpath.

To view the most recently run QuickPay results

1. From the Assignment window, choose Others and select QuickPay.

2. Choose View Results, and select Statement of Earnings from the View Results window.

To view the statement of earnings information without running PrePayments

See Viewing Assignment Process Results for an Assignment or Viewing Assignment Process Results for a Payroll Assignment.

Setting Up Payslip Information and Generating Payslips

You need to identify any additional information you want to appear on your payslips using payslip balances and elements. Once you have identified the information to archive and display, run your regular payment and archive processes and generate your payslip for printing or viewing online.

To set up your payslip

1. Select the payslip balances and elements to be included in your payslips.

   See: Entering Payslip Information

   For UK, Netherlands, and South Africa: Enter the information balances and elements through the following:

   See: Identifying Balances for the Payslip, Oracle HRMS Enterprise and Workforce Management Guide and Identifying Elements for the Payslip, Oracle HRMS Enterprise and Workforce Management Guide

   For Ireland: Enter the balances and elements information in the SOE Balances and SOE Elements windows.

   See: Selecting SOE Balances, Oracle HRMS for Ireland, Supplement and Selecting SOE Elements, Oracle HRMS for Ireland, Supplement

2. For online payslips, enter self-service preference information to indicate how you want to view them. You can specify these settings at the organization, location, and person levels.

   See: Entering Self-Service Preference Information, Location Extra Information Types, Oracle HRMS Enterprise and Workforce Management Guide, and Person Extra Information Types, Oracle HRMS Workforce Sourcing, Deployment, and Talent Management Guide

3. Configure your online payslip to view through Oracle Self-Service.

   See: Online Payslip, Oracle Self-Service Human Resources Deploy Self-Service Capability Guide

   US, Canada, Mexico, and UAE only: Oracle Payroll uses an RTF template to produce the online payslip through XML Publisher. You can use the default template or create your own.

   See: Oracle XML Publisher Administration and Developer's Guide and Oracle XML Publisher Report Designer's Guide.

   For Ireland: To include the regular payment date of the payroll period in your online payslip, set the Visible property of the Regular Payment Date field to Yes.

4. US, Canada, Mexico, and UAE only: Oracle Payroll provides the ability to customize the content of your employee payslips to suit your business needs. Prior to making any changes, however, you should review the default content to best determine what changes you require. See: Payslip Region Information, Oracle HRMS Payroll Processing Management Guide (Mexico)

   To change balances or include additional balances on the payslip:

   1. From the Total Compensation menu, select Basic and then Balance.

   2. Query for the element whose balance you want to add, and click Attribute.

   3. Click on a new row under Attribute, and choose the attribute you want to display from the list of values. This represents where the current balance will appear on the payslip.

   4. Choose a dimension from the list of values.

   5. To delete an entry, select the row and click Delete.

   6. Save your changes.

   Note: These changes do not take effect on the payslip until you rerun the Payroll Archiver Process for the affected payroll period.

Generating the Payslip

You must have completed the payroll runs, prepayments, and payment processes prior to generating the payslip.

5. Run the archive process to gather the latest payroll information.

   See: Extracting Information to Appear on the Payslip

6. You can view the payslip online through Self-Service.

7. Print your payslips in the usual way. Users in the Netherlands and China, run the payslip report to produce a formatted report ready for printing and sending out to your employees.

   See: Printing the Payslip, Oracle HRMS Payroll Processing Management Guide

Extracting Information to Appear on the Payslip

You run the payslip archive process to extract and gather relevant information to appear on your employees' payslips. The archiver accesses the payslip information for the dates you select and copies the information across to storage archive tables, where it is picked up and converted into a format for printing and distributing to employees or for viewing online through the self service application.

Run this process after each payroll period to enable Self-Service. You must complete the payroll runs, prepayments, and payment processes before you can run the payslip archive process.

Netherlands, US, and Mexico only: If you are producing paper reports, use this process to view your current payslip.

Run the payslip archiver from the Submit Request window.

To run the payslip archiver

1. Select your country's payslip archive process in the Name field.

   China and Netherlands: Select the Payslip Archiver.

   India: Select the Payroll Reports Archive (India).

   Ireland: Select the IE Legislative Reports Generator. See: Running the Legislative Reports Generator, Oracle HRMS for Ireland, Supplement

   Mexico: Select the Payroll Archiver. See: Managing the Payroll Archiver, Oracle HRMS Payroll Processing Management Guide (Mexico)

   South Africa: See: Pay Advice Generation - Self Service (South Africa), Oracle HRMS for South Africa, Supplement

   UK: See: Payslip Generation Self-Service, Oracle HRMS Payroll Processing Management Guide (UK)

   US and Canada Payroll: If required, you can set the PAY:Show Payslip with Zero Net Pay profile option to archive the payroll data and generate payslips for those employees receiving a net pay amount of zero.

   For US, see: Managing the Payroll Archive, Oracle HRMS Payroll Processing Management Guide (US)

   For Canada, see: Running the Canadian Payroll Archiver, Oracle HRMS Payroll Processing Management Guide (Canada)

2. In the Parameters window, select a payroll name and consolidation set. This selects the employees for whom you want to run the report. When you select a payroll, the default consolidation set is displayed.

3. Enter the start and end dates for the period of time you want the information extracted. You typically run this process for the same dates you ran your payroll.

4. India: Select whether you want to mail individual payslip or view consolidated payslips in the Generate Payslip field.

5. Choose Submit.

After running the Payroll Archiver, you can use the Payroll Actions Not Processed report to see what employees (and corresponding payroll processes) were not archived but did fall within the report's parameters.

Running the Pay Advice Alignment Report

Run this report before you run the Pay Advice report. It shows printer alignment details for your sample pay advice.

You run the Pay Advice Alignment report from the Submit Requests window.

To run the Pay Advice Alignment report

1. In the Name field, select the report name.

2. Choose the Submit button.

Running the Payments Summary Report

Run this report when you want to see payments totalled by payment method type and organizational payment method for a specified payroll and payroll period. Account details for each organizational payment method are also listed.

You run the report in the Submit Requests window.

To run the Payments Summary Report

1. In the Name field, select the report name. Then enter the Parameters field to open the Parameters window.

2. Select the payroll and payroll period for which you want to see the information.

3. If you want to restrict the information by consolidation set, select the name of the set.

4. Choose the Submit button.

Running the Pay Advice Report

Run this report to generate pay advice for all employees for a specified payroll and period. This is a sample report which you can customize. You run it after completing the Pre-payments process for a payroll. To check printing alignment before generating pay advice run the Pay Advice Alignment report.

You run the Pay Advice report from the Submit Requests window.

To run the Pay Advice report

1. In the Name field, select the report name. Then enter the Parameters field to open the Parameters window.

2. Select the payroll for which you want to generate pay advices.

3. Enter the period for which you want to generate pay advices and the date on which you want to generate them.

4. Do one of the following:

   • If you want to generate pay advices for all employee assignments, leave the Assignment Number field blank.

   • If you want to generate a single pay advice for an employee assignment, enter the employee assignment number.

5. Select the sort orders 1 to 6 for employees whose mailing address is set to Office/Blank.

   Note: Use the people group flexfields to capture or configure office address details.

6. Choose the Submit button.

   Note: You can also view this report from the Assignment Process Results window, where you select an individual assignment and the process you want to view the report for.

Payroll Processing and Analysis

Post-Processing for a Payroll

PrePayments Process

Within Oracle Payroll the PrePayments process enables you to select a payment method to pay your employees. You can distribute employee pay over more than one method using either a percentage or monetary split.

You can override the PrePayments process. For example, suppose you have run the normal payroll run and made payments via one payment method. You then have to run supplementary payments for some employees and pay them by a different payment method. The PrePayments process, having distributed the regular payments over the payment methods entered, allocates the supplementary payments to the override method.

Cheque/Check Writer Process

Run the Cheque/Check Writer process to determine the generation of cheques/checks for a specified payroll and consolidation set over a specified time period.

You can generate contiguous serial numbers for cheque/check printing, and you can use this feature to account for cheque/check stationery used during the cheque/check printing process. If you do this, you also need to take into account the cheques/checks you use to carry out the alignment of your printer.

A sample cheque/check report is supplied with the Cheque/Check Writer process. You can customize this report, or add your own cheque/check style to meet your enterprise requirements.

Oracle Payroll provides automatic cheque/check numbering for the Check Writer process. You can keep track of cheque/check numbers when you process multiple cheques/checks per day.

Note: Your System Administrator can enable the HR: Default Check/Cheque Number Method profile which enables you to use the automatic check/cheque numbering process.

See User Profiles, Oracle HRMS Configuring, Reporting, and System Administration Guide

Void Cheque/Check Payments Process

Run the Void Cheque/Check Payments process when you want to void cheques/checks you have issued using Oracle Cheque/Check Writer. You may want to do this if there is a printing error or if the cheques/checks you print are afterwards lost. The process cancels the cheques/checks issued, records details of the cancellation, and enables you to give a reason for cancelling.

Check Writer - Override Payment Date Process

When you reissue a check after voiding it using the Void Check Payments process, the Check Writer process prints the check with the original Payment Date by default. Using the Override Check Date feature, you can replace the original check date with a check date of your choice. For reporting purposes, the Payment Register Report captures the replacement date from the reprinted check.

External/Manual Payments Process

Use the External/Manual Payments window to record cash or cheque/check payments to employees from external sources or petty cash. The window enables you to record details of each payment.

Post Process Window

Setting up Electronic File Transfer

Oracle HRMS enables you to submit employee and payment details to the bank in the form of a bank transfer file. To process the electronic file transfer, you must complete several steps.

1. Create a formula for each section of the EFT file: Header, Details, and Footer, to write the appropriate record in the specific format. You can use the following three sample formulas to create your own formula:

   • AE_EFT_HEADER_CUSTOMER

   • AE_EFT_BODY_CUSTOMER

   • AE_EFT_FOOTER_CUSTOMER

   See: Writing or Editing a Formula, Oracle HRMS FastFormula User Guide

2. Record the formula details to the payment method.

   See:Defining a Payment Method

3. Enter the values for Bank codes in the user extensible lookup AE_BANK_CODES.

   See: Adding Lookup Types and Values, Oracle HRMS Configuring, Reporting, and System Administration Guide

4. Run the payroll process.

   See: Starting a Payroll Run, Oracle HRMS Payroll Processing Management Guide

5. Run the pre-payment process.

   See: Running the Pre-payment Process, Oracle HRMS Payroll Processing Management Guide

6. Submit the EFT request using the Submit Request window.

   See: Running the Payment Output File

7. View the output of the EFT file.

Running the Payment Output File

You run the Payment Output File from the Submit Request window.

To run the payment output file

1. Select the payment output file in the Name field.

2. In the Parameters window, optionally enter the payroll name.

   Note: You can restrict the processing of assignments to the specified payroll on the effective date.

3. Select the consolidation set.

4. Enter a start date for any prepayments to the employee.

5. Enter the effective date.

6. Select a payment method.

7. Enter the process date or date of transfer.

8. Click Submit.

Running the Payroll Register Report

You can review payroll run results for each employee by running the Payroll Register report. This report helps you validate employee earnings and deductions, and identify any exceptions for further investigation. Payroll Register report is also useful for auditing. For example, auditors can refer to this report to verify that all listed employees exist and are at work or that the employer is following the updated pay rates to pay the employees. For best advantage, run the payroll register report once a month after the main payroll run and before the actual payment to employees.

You can run the payroll register report for either an organization or a payroll. If you run the payroll register for an organization, the application runs the report for all the payslip archives in the specified period. If you run the payroll register for a payroll, the application reports any payslip archives processed for that particular payroll in the selected period.

You run this report from the Submit Request window.

To run the payroll register report

1. In the Name field, select one of the following to open the Parameters window:

   • For UAE - UAE Payroll Register

   • For Kuwait - Kuwait Payroll Register

2. Select the entity to run the report for organization or payroll.

   If you select Organization, you can also select the organization hierarchy and version, or the name of the organization for this payroll report.

   If you select Payroll, select the payroll name for the business group.

3. Select the end date for archived payrolls. If you do not select an end date, the application selects an end date closest to the date of the last archive.

4. Select a sort order for the report. You can choose up to three sort parameters. If you do not choose a sort order, the application sorts the records by employee number.

5. Click the Submit button.

Processing Employer/Employee Deductions

Calculating Social Insurance

Oracle HRMS enables you to record and process the SI contributions for both private and federal sector employees. You can also calculate payment exceptions, such as the employer temporarily paying the employee's SI contribution.

The application uses the SI contributory salary of an employee as input to calculate the SI contribution.

To calculate SI contributions for private sector employees

1. Select the employer sector at the Legal Employer level.

   See: Entering Legal Employer Details

2. Select the local nationality at the Business Group level. All the employees whose nationality matches the business group nationality are eligible for social insurance.

   See: Entering Local Nationality Information

3. Select the formula for determining SI contributory salary.

   See: Entering Reference Formula Details

4. Attach the predefined Social Insurance element to the employee to ensure that Social Insurance processing occurs when you run the payroll for this employee.

   • For a Saudi national working in UAE, you can ensure that the social insurance calculation is according to the percentages stipulated by Saudi law. For this, you must create the SA GOSI element and link it to the Saudi national. If this element is not attached to the employee, then the employee's and employer's contribution for social insurance is as per UAE percentages. However, when the employer's subscription is less than the amount calculated through percentages as per the Saudi laws, the SA Surplus Employer Social Insurance element holds the difference in subscription in case the country of citizenship is going to pay the difference. The SA Employee GOSI on behalf of Employer element holds the difference in case the employee is going to pay on behalf of the country of citizenship. If the employee decides to pay, then the amount is held in SA Employee GOSI element on behalf of employer. If the country of citizenship decides to pay on behalf of the employee, then the amount is held in the SA Surplus Employer Social Insurance element.

   • For a Kuwait national working in UAE, you can ensure that the social insurance calculation is according to the percentages stipulated by Kuwait law. For this, you must create the KW Social Insurance and link it to the Kuwait national. If this element is not attached to the employee, then the employee's and employer's contribution for social insurance is as per UAE percentages. However, when the employer's subscription is less than the amount calculated through percentages as per the Kuwait laws, the KW Surplus Employer Social Insurance element holds the difference in subscription in case the country of citizenship is going to pay the difference or, the KW Employee Social Insurance on behalf of Employer element holds the difference in case employee is going to pay on behalf of the country of citizenship. If the employee decides to pay, then the amount is held in KW Employee Social Insurance element on behalf of employer. If the country of citizenship decides to pay on behalf of the employee, then the amount is held in the KW Surplus Employer Social Insurance element.

   See: Making Manual Element Entries, Oracle HRMS Compensation and Benefits Management Guide

5. Run the payroll process for the employee.

   See: Starting a Payroll, Oracle HRMS Payroll Processing Management Guide

To calculate SI contributions for federal sector employees

1. Create an event group to group together the proration events, such as change in working hours or pay grades.

   See: Defining Event Groups

2. Write a proration formula that calculates the value of the elements according to the changes made during the pay period to the values of these elements.

   See:Writing Proration Formula, Oracle HRMS FastFormula User Guide

3. Create an element with a primary classification of Earnings and a secondary classification of Subject to Social Insurance.

   See: Defining an Element

4. Link the proration formula and the event group to the element using the Proration tab in the Element Description window.

5. Link the earnings element to payroll using the Element Link window.

   See: Defining Element Links, Oracle HRMS Compensation and Benefits Management Guide

6. Attach the Social Insurance element to the employee to ensure that Social Insurance processing occurs when you run the payroll for this employee.

   • For a Saudi national working in UAE, you can ensure that the social insurance calculation is according to the percentages stipulated by Saudi law. For this, you must create the SA GOSI element and link it to the Saudi national. If this element is not attached to the employee, then the employee's and employer's contribution for social insurance is as per UAE percentages. However, when the employer's subscription is less than the amount calculated through percentages as per the Saudi laws, the SA Surplus Employer Social Insurance element holds the difference in subscription in case the country of citizenship is going to pay the difference. The SA Employee GOSI on behalf of Employer element holds the difference in case the employee is going to pay on behalf of the country of citizenship. If the employee decides to pay, then the amount is held in SA Employee GOSI element on behalf of employer. If the country of citizenship decides to pay on behalf of the employee, then the amount is held in the SA Surplus Employer Social Insurance element.

   • For a Kuwait national working in UAE, you can ensure that the social insurance calculation is according to the percentages stipulated by Kuwait law. For this, you must create the KW Social Insurance and link it to the Kuwait national. If this element is not attached to the employee, then the employee's and employer's contribution for social insurance is as per UAE percentages. However, when the employer's subscription is less than the amount calculated through percentages as per the Kuwait laws, the KW Surplus Employer Social Insurance element holds the difference in subscription in case the country of citizenship is going to pay the difference or, the KW Employee Social Insurance on behalf of Employer element holds the difference in case employee is going to pay on behalf of the country of citizenship. If the employee decides to pay, then the amount is held in KW Employee Social Insurance element on behalf of employer. If the country of citizenship decides to pay on behalf of the employee, then the amount is held in the KW Surplus Employer Social Insurance element.

   See: Making Manual Element Entries, Oracle HRMS Compensation and Benefits Management Guide

7. Select the employer sector at the Legal Employer level.

   See: Entering Legal Employer Details

8. Select the local nationality at the Business Group level. All the employees whose nationality matches the business group nationality are eligible for social insurance.

   See: Entering Local Nationality Information

9. Run the payroll process for the employee.

   See: Starting a Payroll, Oracle HRMS Payroll Processing Management Guide

Calculating Gratuity

Oracle HRMS for UAE calculates the gratuity amount payable to an employee on termination. In accordance with UAE Labor Law, you calculate the gratuity when you process the termination of the employee. You have the flexibility to offer the standard gratuity based on contract types, or a discretionary gratuity which can vary from the recommended standard amount but is still within UAE Labor Law. You can also supply a list of termination reasons to determine employee eligibility for the gratuity payment.

To calculate standard gratuity based on labor law requirements

1. Select the basis of gratuity calculation at the Legal Employer level.

   See: Entering UAE Gratuity Details

2. Attach the formula at the Legal Employer level for calculating the monthly salary of the employee.

   See:Entering Reference Formula Details

3. Define the contract type for the employee. The gratuity payable differs for each contract type.

   See:Entering Additional Assignment Details

4. The application does not consider any unapproved or unauthorized absence from work while calculating the period of service for gratuity processing. To track such absences, create an absence type of category Unpaid Leave and create an absence record for the employee.

   See: Absence Categories and Types, Oracle HRMS Compensation and Benefits Management Guide

   See: Entering Absences, Oracle HRMS Compensation and Benefits Management Guide

5. The application includes a predefined list of termination reasons that you can use to determine if the employee is eligible for a gratuity. You can also define your own termination reason for the employee.

   See: Setting up User Tables, Columns, and Rows, Oracle HRMS Configuring, Reporting, and System Administration Guide

6. Attach the Gratuity element to the employee to ensure that gratuity processing occurs when you run the payroll for this employee.

   See: Making Manual Element Entries, Oracle HRMS Configuring, Reporting, and System Administration Guide

7. Run the payroll process for the employee.

   See: Starting a Payroll, Oracle HRMS Payroll Processing Management Guide

To calculate gratuity using your own gratuity formula

1. Attach the formula at the Legal Employer level for calculating the gratuity payable to the employee.

   See:Entering Reference Formula Details

2. Attach the Gratuity element to the employee to ensure that gratuity processing occurs when you run the payroll for this employee.

   See: Making Manual Element Entries, Oracle HRMS Configuring, Reporting, and System Administration Guide

3. Run the payroll process for the employee.

   See: Starting a Payroll, Oracle HRMS Payroll Processing Management Guide

Payroll Statutory Deductions and Reporting

Process Part of a Payroll

Oracle Payroll enables you to run a payroll and conduct post-processing on a payroll that has completed successfully. You can also enter subsequent changes and corrections for a payroll that has not completed successfully.

Oracle Payroll makes use of the following concepts when implementing payroll procedures:

Assignment Sets

Occasions when you need to use assignment sets for the payroll run include:

• You need to process the night shift earlier than the rest of the payroll as they must receive their pay advices the night before the rest.

• You need to process a correction run, as entries were not received in time for the normal run and the overtime must be paid this period.

• You want to process an additional run for a long service award, which the enterprise is presenting as a cheque/check to each qualifying employee.

To fulfil these requirements, you can select from a range of assignments:

• Include all assignments

• Include or exclude individually identified assignments

• Use a formula to include or exclude certain groups of assignments

Consolidation Sets

A consolidation set is a grouping of payrolls that simplify post-run processing and reporting. It enables you to produce a single set of reports, costing results, and other results for all payrolls in a consolidation set. When you run a payroll, make sure that you have named the consolidation set to which the payroll belongs.

Element and Distribution Sets

With a normal payroll run, you would want to include all elements, but for a long service award bonus you would want to include only the bonus element and the statutory elements. You first calculate gross pay for ascertaining the gross amount to transfer into the payroll account. Then you complete the gross to net calculation.

You can select element sets as follows:

• Include all elements

• Include or exclude individually identified elements

• Include or exclude classifications of elements.

Canada only: When creating a Run set, you need to explicitly add the Canadian Tax recurring element to your element set.

US only: When creating a Run set, you need to explicitly add the VERTEX recurring element to your element set.

The predefined elements for Oracle Payroll are processed for every payroll run in which they have been included. The deductions are recalculated using the period totals, the amount already paid in previous runs is deducted, leaving the remainder as the deduction for the new payroll run.

QuickPay

QuickPay enables you to carry out payroll processing for individual employees. You can use QuickPay to pay employees who are leaving and who require payment immediately. If an employee asks what their net pay will be this month, you can run QuickPay to find the answer, then roll it back to remove all results from the database.

QuickPay: Two Options for PrePayments:

Once the QuickPay run has a status of Complete, you have a choice of two options for post-run processing:

• Include the QuickPay in the batch prepayments processing for the assignment's payroll.

  Choose this option if, for example, you have a new employee who joins after the payroll run for the current period has taken place. Instead of rolling back the whole payroll and resubmitting it with the new employee added, you run QuickPay instead so that you can include the new employee in the consolidation set for batch prepayments.

• Start the PrePayments process from the QuickPay window, if necessary overriding the default payment method.

  Choose this option if, for example, an employee is leaving and is waiting to be paid by cash or cheque/check.

Troubleshooting QuickPay: Concurrent Manager

When you start the QuickPay process, the screen freezes, and you cannot delete or update the QuickPay definition until the process completes.

You may receive one of the following error messages:

• The process has not started

  This means either that the concurrent manager has not been started, or that there are other requests of a higher priority. Ask your system administrator to start your request or change its priority.

• The process has started but has not finished

  Ask your system administrator to investigate the reason for this.

Running Reports

Running Social Insurance Reports

You can generate the following statutory social insurance reports for submission to GPSSA from the Submit Request window:

Report	Report Name in Submit Request Window
Form 1	UAE Form 1
Form 2	UAE Form 2
Form 6	UAE Form 6
Form 7	UAE Form 7
Monthly contributions for private sector employees	UAE Monthly Contributions (Private Sector)
Monthly contributions for federal sector employees	UAE Monthly contributions (Federal Sector)

To run the SI reports

1. Select the name of the report that you want to generate.

2. In the Parameters window, select the employer for whom you want to run the report.

3. Enter the year and month for which you want to generate the report.

4. Click OK.

Running the Wage Protection System (Private Sector) Report

UAE Private Sector employers submit a monthly Wage Protection System report to the Ministry of Labor. This report contains information about employees' wages and certifies that the employers pay the correct amount to all the employees.

Use the UAE Wage Protection System (Private Sector) Report to track the total number of employees, the total number of employees paid, the total number of employees not paid, and the total amount paid to the employees. This information helps to detect any violation in comparison to the Ministry of Labor records.

Run this report from the Submit Requests window.

To run the Wage Protection System (Private Sector) Report:

1. In the Name field, select the report name and click in the Parameters field to open the Parameters window.

2. Enter the following:

   • Employer

   • Month

   • Year

   • Name

   • Title

   • Total Number of employees according to Minister of Labour records.

   • Total Number of employees according to payroll.

   • Total Number of employees paid.

   • Total Number of employees who did not get paid.

   • Total Amount Paid to employees.

   Note: The last four parameters are not mandatory. If they are not entered, they will get calculated in the system and will be displayed in the output of the UAE Wage Protection System report.

3. Choose the Submit button.

RetroPay Processing

Overview of RetroPay Processing

Purpose of the RetroPay Process

Run the RetroPay process to ensure that your payroll run for the current period reflects any backdated payments or deductions. Backdated adjustments can occur when:

• An employee receives a pay award that is backdated to a previous pay period.

• The payroll department makes a retrospective correction for an error that occurred in a previous pay period

For example, at the start of the current pay period, this employee has a pay award backdated to pay period 1. The employee has not yet received any payments for this award. In the current pay period the employee is entitled to payments that represent the backdated amounts for:

• Each of the preceding payroll periods (pay periods 1 to 4)

• The current pay period

You run your RetroPay process to ensure that the employee receives correct payment when you next run the payroll.

Period Earned is Distinct from Period Paid

When backdated payments occur, the accuracy of your subsequent payroll processing depends on distinguishing between:

• The period in which the payment was earned

• The period in which the payment was made

For example, the taxation implications are different for:

• A pay award backdated to period 1 and not paid until the current period. You may want to tax this award in the current period.

• A correction to an underpayment in period 3 which is paid to the employee in the current period. You may want to tax this correction in period 3 rather than in the current period.

The RetroPay Process Does Not Overwrite Your Historical Payment Records

You never overwrite historical payroll data when you run RetroPay. Although you recalculate all periods that have retroactive changes whenever you run a RetroPay, you never modify the stored results for these periods. Instead, you create one or more RetroPay entries to receive the process results.

Think of the RetroPay process as a calculator holding results in memory so that it can process a final set of results. The RetroPay process uses your historical results to calculate the changes for the current period. The results for your current period change, but your historical records remain unchanged.

Process RetroPay with Overlapping Periods

The RetroPay process recalculates payroll runs, balance adjustments and reversals from a particular date onwards, the start date of the recalculations. When you have retroactive changes overlapping another retroactive change, the application resets the start date to the earliest start date of the RetroPay processes and recalculates.

For example, you perform a RetroPay (RetroPay 1)for an assignment in period 3, with Payroll Runs being recalculated from a start date of period 1. In period 5, you perform another RetroPay (RetroPay 2) for the assignment with a start date of Period 3. The second RetroPay detects an overlap of RetroPays and sets the start date to the earliest start date.

In this case, the application sets the start date as Period 1. An overlapping override occurs to ensure that the balances are correct for the RetroPay process.

The processing of overlapping RetroPay results in an overall increase in time to process the RetroPay. If there are multiple overlaps, the increase in time is excessive.

RetroPay Processes Available in Oracle Payroll

Oracle Payroll provides several versions of RetroPay, for example Enhanced RetroPay, RetroPay by Element, and so on. However, in most situations, you only have access to a single version of RetroPay.

How To Identify Your Version of RetroPay

Navigate to the Submit Requests window, and search for RetroPay. Your search returns the name of the single version of RetroPay enabled for your use, for example, Enhanced RetroPay.

An exception occurs in transitional situations. If you are replacing RetroPay by Element with Enhanced RetroPay, the Submit Requests window enables you to select each version of RetroPay so that you can complete the transition.

Summary of Available RetroPay Processes

We recommend Enhanced RetroPay as the standard version of RetroPay for new customers to adopt. Older RetroPay versions do exist, and this table exists as reference so that you can distinguish between each version. In practice however, your System Administrator determines which version of RetroPay you can use, and you are unlikely to see any reference to RetroPay versions that are unavailable to you .

RetroPay Process	Distinguishing Features
Enhanced RetroPay	Enables you to Identify the reasons for backdated changes to individual elements, Reprocess an assignment from the exact point at which a change occurred rather than reprocessing the entire pay period because it contains a backdated change.
RetroPay by Element	Enables you to identify the value of backdated changes for individual elements
RetroPay by Run	Only for use with Oracle HRMS (Japan)
RetroPay (by Aggregate)	Does not differentiate backdated payments at element entry level. Produces a single aggregated RetroPay This is the original version of RetroPay. You can continue to use RetroPay (by Aggregate) but we recommend that new customers should implement Enhanced RetroPay rather than RetroPay (by Aggregate)

Implications of Migrating Between RetroPay Processes

You cannot run one category of RetroPay with data that you have already run on a different category of RetroPay. For example, if your localization has moved from RetroPay by Run to Enhanced RetroPay, you cannot use Enhanced RetroPay on data previously processed in RetroPay by Run.

When to Run the RetroPay Process

The RetroPay Process and the Payroll Cycle

It is important to run your RetroPay process at the correct point in the payroll cycle. Always run RetroPay immediately before you run a payroll, and, for greatest accuracy, as close to the cut-off date as possible. The cut-off date is the point at which all data entry for the payroll is complete.

The RetroPay Process Always Precedes a Payroll Run

The RetroPay process cannot occur after your payroll run. If you run your payroll and then discover further backdated adjustments you must hold them over until a later payroll period and run the RetroPay process in that subsequent payroll period.

Backdated Adjustments Are Always Paid in the First Open Payroll Period

When you run a RetroPay process in your current payroll period, any backdated adjustments are always paid in your current payroll period. So, a RetroPay process in period 5 calculates any backdated adjustments from periods 1 to 4, and marks them for payment in period 5.

You cannot stipulate that a RetroPay process in period 5 should withhold any resulting payments until a future pay period. For example, you cannot stipulate that a RetroPay run in period 5 should withhold payments until period 8.

If you want to use a future payroll period such as period 8 to make payments of backdated amounts for periods 1 to 4, then you must wait until period 8 before you run your RetroPay process.

Troubleshooting RetroPay

The most common RetroPay problems occur when the RetroPay process completes, but produces unexpected results.

Consult these tables for quick reference on common RetroPay difficulties and their solutions. The problem description links or refers to extra information where you need more details to solve a problem.

• Troubleshooting Enhanced RetroPay and Retro-Notification

• Troubleshooting Earlier Versions of RetroPay

Troubleshooting Enhanced RetroPay and Retro-Notification

Problem Description	What to Do
Enhanced RetroPay is not available when you expected it to be, or you do not have the Retro Components button on the Recalculation tab of the Elements window.	This is a single problem - your localization has not implemented the legislation rule ADVANCED_RETRO.
View RetroPay Status does not display some of my expected choices	Contact your System Administrator. The configuration of View RetroPay Status is determined at setup. If the legislation rule RETRO_STATUS_USER_UPD is set to Y, then you have a choice when you view RetroPay status. You can either exclude the assignment from RetroPay processing (you select Deferred), or include it (you select Confirmed Awaiting Processing). However, if RETRO_STATUS_USER_UPD is set to N, then the assignment is automatically included in the next RetroPay run (it displays in View RetroPay Status as Included Awaiting Processing).
After setting up Enhanced RetroPay for the United States, the Enhanced RetroPay run does not produce any results. Also: the Retro-Notification report (Enhanced) for the United States does not record a salary change for an employee unless you add the changed details from View RetroPay Status.	In both cases: Navigate to the Element window and ensure that the Default Component check box is checked. The United States has one component only (RetroPay) and one reprocess type (Reprocess) - you must check the Default Component check box for the element.
RetroPay Element field is missing when Enhanced RetroPay is enabled.	This is intended behavior. The RetroPay Element field is hidden when Enhanced RetroPay is enabled. You now add your RetroPay elements from the Retro Components button available from the Recalculation tab of the Elements window.
How do I know whether Enhanced RetroPay is enabled for my legislation?	System Administrators can run the following SQL code to determine whether Enhanced RetroPay is enabled. select * from pay_legislation_rules where rule_type like '%ADVANCED%RETRO%' and legislation_code = 'xx'; (Where "xx" is your legislation code). If the SQL query returns a rule mode of Y, then Enhanced RetroPay is enabled for your legislation.

Troubleshooting Earlier Versions of RetroPay

Problem Description	What To Do
RetroPay process element entry not generated for one or more assignments.	Check that the element links exist, then check your RetroPay setup.
Unexpected value returned.	Check your RetroPay setup.
Start and end times ignored.	Check for a previous RetroPay run that overlaps with your current run. If there is an overlap, rerun a new RetroPay with dates that fully include the period processed by the earlier RetroPay.
RetroPay Warning: Process Log shows zero employees in error - did not create element entries for processed employees.	Check that you are using the correct balance in the RetroPay set. If you are processing RetroPay within a single calendar year, choose a balance that represents gross pay for year to date. If your RetroPay spans two years, do not select a balance with the _YTD dimension.
Cannot use the Element Entries window to delete RetroPay generated elements.	Roll back the RetroPay process, remove the unwanted assignments from the assignment set and then rerun RetroPay. Note: The RetroPay process does not permit use of the Element Entries window to make these changes. This is expected behavior rather than an error.
RetroPay Error: APP-6370 Cannot create an entry past the termination rule date.	The setup of your RetroPay element (specifically, the termination rule) does not enable you to process terminated employees. Remove the assignments of terminated employees from your assignment set and then rerun RetroPay.

Detailed Problem Resolutions

This section provides step-by-step solutions for more complex problems.

Check that the Element Links Exist, and then Check Your RetroPay Setup

If the RetroPay process does not generate a RetroPay element for one or more assignments, follow this sequence to correct the problem,:

1. Check that there is a valid, current element link for each assignment in the RetroPay set. If the links do not exist, the RetroPay process can still calculate a retro-payment but cannot attribute the calculation results to an assignment.

2. Check that RetroPay entries exist for this assignment. Do this by inspecting the log file for the HR_HRPROC_EE_NOT_CRE message and searching for the text Warning RetroPay has detected no change. This text indicates that RetroPay entries do not exist. There are no differences between the original payroll run and the RetroPay run.

3. Check that your RetroPay setup correctly defines all the required balances. The RetroPay process always uses a balance to track the difference between an original entry and a retro entry. If retro-payments do not specifically feed your RetroPay balances, then the RetroPay process cannot identify that a retro-payment has occurred.

   Example (from U.K. Payroll)

   If you specify an NI balance in your RetroPay setup and then make changes to element entries that are not subject to tax or NI, your run results will be different when you compare the original run and the retro-paid run. However, the RetroPay element does not include these changes because it can only report on those differences that affect the NI balance.

4. Confirm that your RetroPay element has a classification of Earnings. The Earnings classification ensures that you can pay the amounts identified by the RetroPay process. Other classifications, such as Information, do not allow you to make payments.

5. Find out whether your RetroPay definition includes any Year to Date (_YTD) balances. If you run a RetroPay process that spans the end of year, you could see unexpected results if you are using _YTD balances. Errors occur because the payroll run clears the_YTD balance at the end of year in preparation for the next year.

6. Check that there is a correct end date for the payment of RetroPay entries. Do this by View | Lists | Employees by Element to see whether the entry was created for an unexpected period. If this is the case, set the end date to the first date of the payroll period in which the RetroPay entry should be paid. For example, if you run RetroPay for June to September 2004 to pay back pay in October 2004, your start date should be 01-JUN-2005 and your end date 01-OCT-2005.

Check Your RetroPay Setup

If the RetroPay process returns an unexpected value follow this sequence to correct the problem,:

1. Check the logic of the RetroPay setup to determine that you are feeding the correct balance and confirm that you are not feeding the correct balance more than once.

2. Find out whether your RetroPay definition includes any Year to Date (_YTD) balances. If you run a RetroPay process that spans the end of year, you may see unexpected results if you are using _YTD balances. Errors occur because the payroll run clears the_YTD balance at the end of year in preparation for the next year.

3. Establish whether there are changes elsewhere in the application that might impact the value of a balance. This can be a difficult area to identify because anything that feeds the balance specified in the RetroPay definition can potentially affect the RetroPay.

   In particular:

   • Balances like Gross Pay can reflect multiple changes to an assignment. These changes can affect the recalculated value of that assignment.

   • Generic changes such as updates to a formula can affects the results of associated elements, and introduce balance value changes that subsequently affect RetroPay values.

Setting Up Retro-Notification and RetroPay

Follow this process to set up the Retro-Notifications report, and the correct RetroPay process for your payroll.

Set Up the RetroPay Component

1. The RetroPay component determines the default style of RetroPay processing for your localization. For example, you can specify that your default style is Tax When Paid, rather than Tax When Earned .

   Note: The Tax When Paid Retro Style is available for China localization users only.

   You can use either of the following methods to set up your RetroPay component:

   Method	How To	Advantages
   Set Up the Organization DFF	From the Additional Organizational Information window: Select Retro Component Usages. Select the Tax Area. Enter a Retro Style, for example, Tax When Paid. Enter an Effective Start Date. Enter an Effective Date. Choose OK to confirm your choices.	Processing the retrospective payments for all employees in the same style is a faster alternative than setting up details at the element level for each assignment. This method does not prevent you from making changes for individual assignments when you view RetroPay status.
   Set Up Retro Components and Spans at Element Level	From the Element window: Query the element. Choose the Recalculation tab. South African users: Select the predefined ZA Statutory Updates event group from the list of values in the Recalculation Events field. Alternatively, you can create and attach an event group of your choice. Choose the Retro Components button. Important: Do not enable the Retro Component of the elements that are themselves being used to process retropay for another element. Select a Recalculation Reason. Select a Reprocess Type. Select an Element Span to indicate the start date and end date on which you want to report.	You can modify entries at element level to make exceptions for particular assignments.

   Note: Your localization may advocate one of these as the preferred method.

Set Up the Retro-Notifications Report

2. Determine whether a retrospective change in Oracle Payroll will appear in the Retro-Notifications report. Set up an event group to contain all the retrospective change events that you want to record.

   See: Setting Up the Retro-Notifications Report

Set Up Your RetroPay Process

3. Although Enhanced RetroPay is the recommended RetroPay process for most localizations, your System Administrator can also set up these earlier versions of RetroPay.

   See: Setting Up RetroPay by Element

   See: Setting Up RetroPay by Run and RetroPay (by Aggregate)

Setting Up the Retro-Notifications Report

You use the Retro-Notifications report to identify any changes that have a retrospective effect for payrolls that you have already run. You can define the relevant types of change by setting up an event group to specify the changes. Follow these steps to set up the Retro-Notifications report:

To enable dynamic triggers

1. Navigate to the Dynamic Triggers window.

2. Enable any dynamic triggers that the application generates. It is important to enable these triggers to ensure your payroll processing updates each database table correctly. The recommended minimum list of triggers to enable for the Retro-Notifications report is as follows:

   Table Name	Trigger Type
   PAY_ELEMENT_ENTRY_VALUES_F	Update
   PAY_ELEMENT_ENTRIES_F	Update
   PAY_ELEMENT_ENTRIES_F	Insert
   PAY_ELEMENT_ENTRIES_F	Delete

To define an event group

1. Navigate to the Table Event Group window.

2. Enter a name for your Event Group, for example, Retro-Notification Events.

3. Select Retro as your event groups type.

4. Save your entries.

5. Select the events that will produce notification if retrospective changes occur. Specify the following information to identify the type of update and the database table to which it applies:

   • Update Type

   • Base Table Name

   • Column Name

   For example:

   Update Type	Table	Column Name
   DateTrack Correction	PAY_ELEMENT_ENTRY_VALUES_F	SCREEN_ENTRY_VALUE
   DateTrack Update	PAY_ELEMENT_ENTRIES_F	EFFECTIVE_START_DATE
   DateTrack Update	PAY_ELEMENT_ENTRIES_F	EFFECTIVE_END_DATE
   DateTrack End Date	PAY_ELEMENT_ENTRIES_F
   DateTrack Insert	PAY_ELEMENT_ENTRIES_F
   DateTrack Delete	PAY_ELEMENT_ENTRIES_F

To enable the Incident Register

1. Navigate to the Functional Area Maintenance window.

2. Query the Incident Register and ensure that you have triggers defined.

3. Decide whether to capture the triggers by legislation, business group, or payroll. Navigate to each tab to make your selection.

Setting Up RetroPay by Element

RetroPay by Element is the recommended RetroPay process for most localizations, and is required if you use Enhanced RetroPay.

To set up RetroPay by Element:

1. Create the retroactive element. The recommended settings are:

   • Non-recurring

   • Multiple entries allowed

   View this element in the RetroPay field of the Element Description window. By default, retroactive elements use the same name as the element that they represent, but you can change this name for user-defined elements.

2. Enter retroactive changes using DateTrack.

3. Create assignment and element sets including the assignments and elements for retroactive processing. The element set type is Run Set.

   Note: North American HRMS: For earnings elements defined as Reduce Regular, include the Special Features element in the element set.

   Use one of two methods to create your assignment set:

   • Use the Assignment Set window. This method is useful when you have a few employees to include in a RetroPay run and you are confident that you can identify all the employees that you want to include.

   See: Creating an Assignment Set, Oracle HRMS Payroll Processing Management Guide

   • Run the Retro-Notifications report to automatically generate an assignment set of all employees with retrospective changes.. This method is useful if you want to be certain that your assignment set includes all potential changes. You can edit this assignment set to add and remove assignments.

   See: Running the Retro-Notifications Report

Setting Up RetroPay by Run and RetroPay (by Aggregate)

You should consider setting up Enhanced RetroPay in preference to RetroPay by Run or RetroPay (by Aggregate). However, we include setup information on these older types of RetroPay as reference.

To set up the RetroPay process for RetroPay (by Aggregate) and RetroPay by Run

Each step applies to both RetroPay (by Aggregate) and RetroPay by Run unless explicitly indicated otherwise.

1. Create an assignment set to define the set of employee assignments that you want to change. There are two methods of doing this:

   • Use the Assignment Set window. This method is useful when you have a few employees to include in a RetroPay run and you are confident that you can identify all the employees that you want to include.

   See: Assignment Sets, Oracle HRMS Payroll Processing Management Guide

   • Run the Retro-Notifications report to automatically generate an assignment set of all employees with retrospective changes. This method is useful if you want to be certain that your assignment set includes all potential changes. You can edit this assignment set to add and remove assignments.

   See: Running the Retro-Notifications Report

2. In the Element Entries window, make the necessary date effective updates to element entry values for each employee assignment in the set.

   See: Making Manual Element Entries, Oracle HRMS Compensation and Benefits Management Guide

3. Make other changes if necessary to salary information or to other database values relevant to the backdated changes.

4. In the Element window, define the RetroPay elements you require to receive entries of the retroactive adjustments. Your definition must include the following:

   • An appropriate element classification such as Earnings or Voluntary Deduction (not Information)

   • The processing type Nonrecurring

   • The rule Multiple Entries Allowed

   • Input values with these names:

     • Pay value

     • Start date (not necessary for RetroPay by Run)

     • End date (not necessary for RetroPay by Run)

   See: Defining an Element (Payroll Users)

5. In the Element Link window, link the element to define your eligibility criteria.

   See: Defining Element Links, Oracle HRMS Compensation and Benefits Management Guide

To create a RetroPay set

1. In the RetroPay Set window, enter a name and a description for the RetroPay set you are creating. Save this information before moving to the next block.

2. Select the balance in which the RetroPay process will create new values, such as Gross Pay to Date. You can select more than one balance. However, for RetroPay by Run the balance dimension must always be ASG_RETRO_RUN.

   For RetroPay (by Aggregate), if you plan to run the process over several past payroll periods, check that you are not going through an end of year or similar period where the application resets balance totals to zero. If necessary, adjust the balance dimension span to ITD.

3. Select the RetroPay element you have defined to receive the values of the updated balance.

4. Select an input value for the element. Normally this value is Pay Value, but you can also calculate RetroPay hours by including an Hours input value.

Setting Up Enhanced RetroPay with Component Usages and Element Time Spans

Standard RetroPay is the default RetroPay processing method for the Netherlands. It enables you to deal with any earnings changes made in the previous or current year, and any changes to tax and social insurance, impacting payroll calculations made in the current year. To carry out RetroPay processing, for every earnings element defined, you must set up two RetroPay elements, both with the skip rule Once Each Period assigned. These elements require the primary classifications Earnings, for changes in the previous year, and Retro Earnings, for changes in the current year. The same rule applies to imputed elements with the classifications Imputed Earnings and Retro Imputed Earnings. You set up RetroPay component usages to define how RetroPay will process the component. For each of these components you define an element time span to specify the start and end dates of the retro processing, and which RetroPay element applies for each time span.

Note: Each RetroPay element you create must have the skip rule, Once Each Period, assigned to it. Users in the Netherlands select a particular RetroPay method by running the concurrent program Enable Dutch RetroPay Method and selecting, either standard or replacement. The default entry is standard.

Only add assignments requiring RetroPay processing to the RetroPay set. The RetroPay process posts retro entries for each of the assignments in the RetroPay set. Note that these retro entries always include any changes to tax and SI information, even if there are no retrospective earnings entries.

Each pre-tax or pre_si and pre-tax deductions element processed by RetroPay must have a corresponding RetroPay element with a primary classification of Retro Pre-Tax Deduction or Retro Pre-SI and Pre-Tax Deduction. You must also define a RetroPay Component Usage and an Element Span Usage for the original element for each RetroPay method used, whether Standard or Replacement. All earnings elements require a corresponding RetroPay element and link.

For further information on the methods of RetroPay available for the Netherlands, see: RetroPay for the Netherlands, Oracle HRMS Payroll Processing Management Guide.

For further information on how to enable your RetroPay method of choice, see:Enabling the Method of RetroPay, Oracle HRMS Payroll Processing Management Guide.

For further information on how to override the Replacement RetroPay method for the Netherlands, see: Business Groups: Entering Dutch Business Group Information, Oracle HRMS Enterprise and Workforce Management Guide.

Important: If you do not require the Replacement method of RetroPay, you do not have to enable the Standard method, as it is the default method.

Defining Retropay Earnings Elements

You enter element information in the Element window.

An example of defining an earnings element for Netherlands payroll appears in the notes below.

1. Define your salary element with the primary classification of Earnings.

2. Choose the Balance Feeds Control button. In the Balance Feed Control region select the appropriate element classifications from the list of values.

   Note: Netherlands users, for example, select the classifications SI Income Subject to Standard Tax: Earnings and Subject to Standard Tax: Earnings.

3. Choose the Balance Feeds button to view the resulting balances feeding the element.

   Note: You must now set up two retropay elements with the skip rule Once Each Period assigned.

4. Define the retropay element for the previous salary year, with the primary classification Earnings.

   Note: Netherlands users, in the Processing region, click on the Skip Rule and select NL_ONCE_EACH_PERIOD from the menu.

5. Choose the Balance Feeds Control button. In the Balance Feed Control region select the appropriate element classifications from the list of values. Retropay elements for the previous year that are subject to tax must always be subclassified as subject to special tax, regardless of the tax category of the original earnings element. If an original earnings element is subject to standard tax, then the retropay element must be subject to special tax. This includes SI Income and SI Gross Salary elements that are subject to tax.

   Note: Netherlands users, for example, select the classifications SI Income Subject to Special Tax: Earnings and Subject to Special Tax: Earnings.

6. Choose the Balance Feeds button to view the resulting balances feeding the element.

7. Save your work.

8. Define the retropay element for the current salary year, with the primary classification of Retro Earnings.

   Note: Netherlands users, in the Processing region, click on the Skip Rule and select NL_ONCE_EACH_PERIOD from the menu.

9. Choose the Balance Feeds Control button. In the Balance Feed Control region select the appropriate element classifications from the list of values. Retropay elements for the current year, subject to tax, must always be subclassified the same as the tax category of the original earnings element. If an original earnings element is subject to standard tax, then the retropay element must be subject to standard tax also. This includes SI Income and SI Gross Salary elements that are subject to tax.

   Note: Netherlands users, for example, select the classifications SI Income Subject to Standard Tax: Earnings and Subject to Standard Tax: Earnings.

10. Choose the Balance Feeds button to view the resulting balances feeding the element.

11. Save your work.

12. You can now set up your retropay components and element span usages.

Setting Up Retropay Component Usages

Retropay component usages assign the components to the salary elements you created, ensuring all the elements recalculate with the latest values.

1. Query your defined salary element, in the Element window.

2. Select the Recalculation tab, and check the Retro Components button.

3. In the Retropay Components region of the Retropay Element window, choose the component field, and an appropriate component from the list of values.

   Note: Netherlands users select the Retro Component Standard, or Replacement as required.

4. Select the Reprocess Type. If you select Static, then Retropay will not process any changes to the element when running the relevant component. Opting for the Reprocess Type ensures the element changes process.

   Note: Netherlands users select the Reprocess Type, Reprocess. Dutch Retropay processes the period of change, and not the nature of change, such as a correction or backdated change. As a result, the whole retro period reprocesses.

5. Save your work.

6. You can now enter the element time spans.

   Example of a standard retropay component set up for an earnings element

   Element	Component Name	Reprocess Type	Comments
   User Defined Element	Standard	Reprocess	Retro Earnings

   Example of a replacement retropay component set up for an earnings element

   Element	Component Name	Reprocess Type	Replace Run	Use Override Dates
   User Defined Element	Replacement	Reprocess	Yes	Yes

Setting Up Element Span Usages for Earnings Elements

The element time span usages defines the start and end dates for retropay processing. Most elements have the standard time span of Start of Current Year to End of Time already assigned, to cover any changes made in the current year. The exceptions for the Netherlands are standard taxable income and standard tax deduction, which include the timescales Start of Current Year to End of Previous Quarter, and Start of Current Quarter to End of Time, to cover student taxation. For each earnings element, or imputed earnings element with a defined retropay component usage, you must define two element span usages. These element span usages cover the earnings for both the current and the previous year, defining not only how far back processing should cover, but also up to where a particular retropay element carries forward the retro changes. You must define your retropay elements and components before defining the element time spans.

Set up the Element Span Usages in the Retropay Elements window.

1. Query your defined salary element in the Element window.

2. Select the Recalculation tab, and check the Retro Components button.

3. In the Retropay Elements region, select the appropriate time spans from the From and To fields, to define the time period the retropay element is covering.

   Note: In the Time Spans fields, for each earnings element or imputed earnings element with a standard retropay component usage defined, you must define the element span usages for both the current and previous years. For example, for the retropay element, Retro Salary Previous Year, you define the time span from Start of Time to End of Previous Year. For each earnings, or imputed earnings element with a replacement retropay component defined, you must define the element span usage for the current year. You can set up a second time span to cover the previous year, if required.

4. Select the retropay elements you created from the Retropay Element field.

5. Save your work.

   Example of earnings element span definitions for both standard and replacement components

   Element	Component	Span From	Span To	Retropay Element
   User Defined Element	Standard	Start of Time	End of Previous Year	Retro Earnings Previous Year
   User Defined Element	Standard	Start of Current Year	End of Time	Retro Earnings Current Year
   User Defined Element	Replacement	Start of Current Year	End of Time	Retro Earnings Current Year
   User Defined Element	Replacement	Start of Time	End of Previous Year	Retro Earnings Previous Year

Setting Up Overlapping RetroPay Using Balance Adjustments

If you have overlapping periods for making retro payments, ensure that the Retro Overlap feature is enabled. This process recalculates from the latest reprocess date and uses Balance Adjustments. Follow these steps to set up the Retro Overlap feature :

To set up Retro Overlap using Balance Adjustments

1. Run the corresponding concurrent program to enable the retro overlap feature for your localization, for e.g. Enable Retro Overlap for all UK Business Group.

2. Set up all the Retro Element Types and associate them with their corresponding elements.

3. Define a retro element for every element that feeds a balance. The Balance Adjustment process uses the retro entries created in future periods to do adjustments.

4. Enable the 'Do Not Process' check box for any new retro elements used for retro balance adjustments.

Understanding the Sequence of Your RetroPay Activities

Follow this sequence to:

1. Identify outstanding backdated adjustments

2. Monitor and control the processing of backdated adjustments

3. Include backdated adjustments in your next payroll run.

You can only run the Retro-Notifications report and view RetroPay status if you are using RetroPay by Element, or the version of RetroPay by Element sometimes referred to as Advanced or Enhanced RetroPay.

This sequence does not apply to RetroPay by Run and RetroPay (by Aggregate)

Run the Retro-Notifications Report

1. Run the Retro-Notifications report to identify any backdated changes that have not been included in a payroll run.

   You can save your summary of backdated changes into either an assignment set or an event group.

   Once you have identified the retrospective changes, you can then decide whether to include them in your RetroPay process.

   The Enhanced Retro-Notifications report uses the Payroll Events Model to identify what changes have occurred to your underlying data. If these changes correspond to the retrospective types of change that you want to be notified about, then these changes appear on the Retro-Notifications report.

   See: Setting Up Retro-Notification and RetroPay

   See: Running the Retro-Notifications Report

View RetroPay Status and History

2. Once you have identified unprocessed retrospective payments, you can determine how you want to process these changes.

   

   The Retro-Notifications report identifies the assignments with backdated adjustments. If you defer, then the assignment is not included when you next run RetroPay.

   You can also include additional assignments that the Retro-Notifications report did not identify. This typically occurs when you discover additional backdated adjustments that were not known about when you ran the Retro-Notifications report.

   The following diagram shows the sequence of statuses for each RetroPay status:

   

   Once RetroPay processing begins, the initial status changes to an intermediate status of Processing.

   You can query all retro assignments that are at the initial (outstanding) status, and all retro assignments at the final (completed) status.

   The following diagram shows what statuses are included when your query All Outstanding, and All Completed:

   

   See: Viewing RetroPay Status and History

Run the RetroPay Process

3. You enable Oracle Payroll to make retrospective adjustments for the combination of changes identified on the Retro-Notifications report, and subsequently modified when viewing RetroPay status.

   See: Running Enhanced RetroPay

   See: Running RetroPay by Element

   RetroPay by Element already enables you to distribute retrospective payments across individual elements.

   If you have Enhanced RetroPay you can decide whether each retrospective payment requires:

   • A full reprocessing in which you recalculate all amounts for the current payroll. This option is typical when you are processing backdated payments, or when you want to deduct tax for backdated amounts in the period when it was earned, rather than in the current payroll period.

   • A limited reprocessing in which you recalculate only some of the amounts for the current payroll. This option is typical when you are processing corrections, or when you want to deduct tax for retrospective changes in the current payroll period rather than in the period when it was earned.

   Components for RetroPay

   Oracle Payroll describes each different type of Enhanced RetroPay run as a component. For example, you could set up a component Earnings Correction for the element Basic Salary. A component always has:

   • A name (for example, Earnings Correction)

   • A reprocess type (Static, Partial, Reprocess) to determine how to process the component

   Element Spans for RetroPay

   You can also attach element spans to your selected element. An element span provides a start and end date for retrospective processing.

   See Setting Up Retro-Notification and RetroPay

Verify Your RetroPay Results

4. When you have run the RetroPay process, verify your results and correct any errors.

Run Your Payroll

5. Finally, run your payroll to reflect the adjustments that you have made for the retrospective payments.

Viewing RetroPay Status and History

You use the RetroPay Status window to control how you want to process changes that have a retrospective impact. You typically find outstanding retrospective changes where changes are entered in Self-Service HRMS independently of Oracle Payroll.

Use the RetroPay Status window to:

• Identify any assignments that have changes implying retrospective processing.

• Specify how you would like to process any outstanding retrospective changes.

• Confirm that your application has processed the specified requests.

• Create or update multiple retro assignments for status as Awaiting Processing or Deferred.

You can still use the Retro-Notifications report to identify all outstanding retrospective changes that have not been applied, and group them into an assignment set ready for processing.

See: Running the Retro-Notifications Report

However, the advantage of using the RetroPay Status window is that you can identify what you want to process, or exclude from processing, and then mark your selections for completion. Additionally if you have to create or update multiple retro assignments, you can do so using the Web ADI spreadsheet.

To search for assignments that have retrospective changes

1. Select the search criteria for assignments that you want to view. If you do not select any criteria, then your search returns all assignments that have retrospective changes. You can search for any of these criteria:

   Name: Specify a name, or search for all names.

   Assignment Number: Specify an assignment or search for all assignments.

   Recalculation Date: Use this start date and end date to determine the period for retrospective changes.

   Status: Select the status that you want to identify.

   • All Completed. This status displays all assignments with retrospective implications that are already processed.

   • All Outstanding. This status displays all assignments with retrospective implications that are not yet processed.

   • Awaiting Processing. This status indicates that this assignment has cleared for processing and that the processing will occur in the next payroll run.

   • Completed. This status indicates that this assignment has now been processed.

   • Completed – Deferred Forever. This status indicates that the retro assignments created by the system are deferred forever. The action of the retro assignment (RETRO_ASSIGNMENT_ACTION_ID) is to changed to –1. The retro assignments are not processed in the future nor reported with the new status.

   • Deferred. This status indicates that an assignment was scheduled for processing, but that the processing was deferred and will not occur until you change the status.

   • Processing. This status indicates that an assignment is being processed.

   Recalculation Reason: This criterion indicates why retrospective processing is necessary and enables you to search particular categories of retrospective change to process them independently of other retrospective changes.

2. Click Go when you have selected all your search criteria.

To change the status of an assignment

You typically change the status of an assignment when you want to defer processing that was previously scheduled, or to indicate that you have already processed this change even though it was automatically scheduled.

1. Select the assignment that you want to change.

2. Select the new status for the assignment from the Change Status list of values.

3. Click Change Status.

To view the elements included on each assignment

1. Select the assignment name in the Name column.

2. View the elements for this assignment, and the Recalculation Reason for each element.

To update or delete elements for each assignment

1. Select the assignment name.

2. Click Update to add an element to the assignment.

3. Click Delete to remove an element from the assignment.

To confirm that your specified requests have been processed

1. Query the individual assignment, but leave the status field blank.

2. Alternatively, query all assignments with a status of All Completed or All Outstanding and check the details for your individual assignment.

To create multiple retro lines

1. Select the Create Retro Lines button.

2. A spreadsheet opens.

3. In the spreadsheet that appears, enter new records with a status of Awaiting Processing or Deferred.

4. Click on Upload. You can select Commit All Rows or Each Row option, if you want the application to validate all records and commit or validate each record prior to uploading the details to the database. If you select Each Row option, then all successful records will be uploaded and error records will not be uploaded. Only on successful validation, the application makes changes to the database.

   If you select the Upload All Rows or Each Row, then the application does not validate the details prior to uploading.

To update the multiple retro lines

1. Query the assignments with Awaiting Processing or Deferred.

2. Click on Download to Spreadsheet check box and click Go

3. In the spreadsheet that opens, you can update the status. You cannot modify any employee or assignment information but can only change the status of the assignment or you can delete the retro entry or update the reprocess date of the retro entry.

   Note: In the Entry Delete/ Update column, ensure to select the applicable value if there are any entry changes made. If you do not select any value the application does not make any changes to the database.

4. Click on Upload. You can select Commit All Rows or Each Row option, if you want the application to validate all records and commit or validate each record prior to uploading the details to the database. If you select the Each Row option, then all successful records will be uploaded and error records will not be uploaded. Only on successful validation, the application makes changes to the database.

   If you select the Upload All Rows or Each Row, then the application does not validate the details prior to uploading.

Running the Retro-Notifications Report

Use the Retro-Notifications report to

• Identify all retrospective changes that have occurred since the last payroll run.

• Automatically save these changes into an assignment set or as an event, depending on which Retro-Notifications report that you use in your localization.

• Produce a report that lists the employees included in the assignment set and the trigger event that included them. You can view this output through Concurrent Manager by clicking the View Output button. Your reporting output is stored under the title Retro-Notifications Report (Internal).

Retro-Notification information is particularly useful when changes with retrospective impact are entered in Self Service HRMS independently of the Payroll department.

The Retro-Notifications report does not perform any RetroPay processing. It only identifies element entries that have changed. You must still run your RetroPay process separately to process these changes. When you produce the assignment set, or event group, you can decide whether to:

• Run your RetroPay process on all assignments in this assignment set.

• Edit the assignment set or event group to remove or add assignments, and then run your RetroPay process.

• Take no retrospective action on any of the assignments in the assignment set.

You can use the RetroPay Status window to schedule automatic processing.

You run the Retro-Notifications report from the Submit Processes and Reports window.

To run the Retro-Notifications report

1. Select Retro-Notifications report in the Name field. If the parameters window does not open automatically, click in the Parameters field to open it.

2. Select the payroll. You can only run this report for a single payroll.

3. Select the last Report Period that you want to run the report for. The List of Values contains all periods for your selected payroll. The report runs for all periods up to and including the one you select.

4. Select an Event Group for the report to use. You can only run this report for a single event group. A default event group captures changes made at element level, but you can override the default, if, for example, you are testing your initial setup.

5. Enter the name of the Assignment Set that you want the report to generate. You can use this assignment set as a starting point for further processing of the assignments identified in the report.

   Note: The assignment set name generated by the report will include what you enter in the Generated Assignment Set field followed by the Report ID.

6. If you want to produce this report in Portable Document Format, (PDF), select a template.

7. Select OK and Submit.

   When you have generated the assignment set remember to run your RetroPay process for those retrospective changes that you want to process. You can either run your RetroPay process directly or, if your RetroPay process is RetroPay by Element, or Enhanced RetroPay you can use the RetroPay Status window to schedule your processing.

Running the Retro-Notifications Report (Enhanced and Enhanced PDF)

Use this report to

• Identify all retrospective changes that have occurred since the last payroll run.

• Automatically save these changes into an assignment set, or as an event, depending on which Retro-Notifications report you use in your localization.

• Produce a report (.a01) that lists the employees included in the assignment set and the trigger event that included them. You can view this output through Concurrent Manager by choosing the View Output button.

This information is particularly useful when changes with retrospective impact are entered in Self Service HRMS independently of the Payroll department.

The Retro-Notifications report does not perform any RetroPay processing. It only identifies element entries that have changed. You must still run your RetroPay process separately to process these changes. When you produce the assignment set, or event group, you can decide whether to:

• Run your RetroPay process on all assignments in this assignment set.

• Edit the assignment set or event group to remove or add assignments and then run your RetroPay process.

• Take no retrospective action on any of the assignments in the assignment set.

You can use the RetroPay Status window to schedule automatic processing.

You run the Retro-Notifications (Enhanced) report from the Submit Processes and Reports window.

To run the Retro-Notifications (Enhanced) report

1. Select the payroll. You can only run this report for a single payroll

2. If you want to see the retro-notifications for a particular event group, select an overriding event group.

3. If you are running the PDF-enabled version of this report, select a template for your PDF output.

4. Select OK, and submit.

Running Enhanced RetroPay

Use the Enhanced RetroPay process to distribute backdated amounts or corrections that you have identified from the Retro-Notifications report.

You run the Enhanced RetroPay process from the Submit Requests window.

To run the Enhanced RetroPay process

1. Enter an effective date to indicate the date from which you want to create the retrospective elements for Enhanced RetroPay process.

2. Select the payroll.

3. If you want to create retrospective entries in a different pay period other than effective date, enter an entry creation date. The application creates retrospective entries in the pay period in which the Entry Creation Date occurs.

   If you leave this field blank, the application creates the default retrospective entries as of Effective Date.

4. Click Submit

Running RetroPay by Element

Use the RetroPay by Element process to distribute backdated amounts or corrections that you have identified from the Retro-Notifications report.

You run the RetroPay by Element process from the Submit Requests window.

To run the RetroPay by Element process

1. Select an assignment set.

2. Select an element set.

3. Select a start date and end date.

   The end date must be within the current payroll period and must have a date after the latest effective check/cheque date.

4. Click Submit

   Oracle Payroll temporarily rolls back and reprocesses all the payrolls for all assignments included in the assignment set from the start date specified. The application compares the old balance values with the new ones, and creates entry values for the RetroPay elements based on the difference.

   These entries are processed for the assignments in the subsequent payroll run for your current period.

   There are no changes to your audited payroll data.

Running RetroPay by Run or by Aggregate

You run the RetroPay processes in the Submit Requests window.

To run the RetroPay processes

1. In the Name field, select your RetroPay process.

2. In the Parameters window, select the assignment set.

3. Select the RetroPay set.

4. Enter the start date and end date for the recalculation. The default end date is the current date. The application will create the RetroPay element in the payroll period that includes the current date.

   The end date must be within the current payroll period and must have a date after the latest effective check/cheque date. If you already processed a run for the pay period, for example, because of an earlier supplemental run, you cannot include the RetroPay elements for the current regular payroll run. To process these RetroPay elements you must include them in the subsequent run.

5. Click Submit.

   Oracle Payroll temporarily rolls back and reprocesses all the payrolls for all assignments included in the assignment set from the start date specified. The application compares the old balance values with the new ones and creates entry values for the RetroPay elements based on the difference.

   These entries are processed for the assignments in the subsequent payroll run for your current period.

   There are no changes to your audited payroll data.