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.

Payslip Modeler Overview

The Payslip Modeler enables employees and payroll administrators to model a paycheck/payslip by running a mock payroll run.

Employees can use this feature to make decisions regarding various benefit options and savings using the estimates. They can check their estimated take-home pay based on an upcoming bonus or tax refunds.

Payroll administrators can use this feature to answer employee queries or to perform what-if analysis.

The terms Payslip Modeler/Paycheck Modeler refer to the same functionality. The application displays these terms depending on your localization.

The Payslip Modeler is not available by default for your localization. Contact your system administrator to check if it is available for your localization.

For more information, see Using Payslip Modeler, Oracle Self Service Human Resources Deploy Self-Service Capability Guide

See: Setting up Payslip Modeler

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.

Map the Payee organization to make third party payments

16. Click the Payees button.

17. The Payees button is enabled only when the following conditions are met:

    • The Third Party Prepayments functionality has been enabled for your legislation.

    • The profile option PAY: Use Third Party PrePayments Rollup is set to Yes using the System Profile Values window for all Payment Methods with Third Party Payment check box selected. See User Profiles, Oracle HRMS Configuring, Reporting, and System Administration Guide for more information.

18. In the Payee Organization window, enter any number of Third Party Payee Organization with different bank account details.

19. You can specify the payment period on which the payment becomes eligible to be paid, in Payment Period field, thus deferring the payments from each period until the payments are paid.

20. When you enter an organization with multiple bank accounts, enter the Overriding Balance to distinguish the amounts to be paid into each account.

Enter further information for the payment method

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

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

Setting Up a Global Statement of Earnings

Oracle HRMS enables you to view the online statement of earnings (SOE). To enable the correct display of values on your statement of earnings, you must complete each of these setup steps.

To set up the global statement of earnings:

1. Create a user category through the lookup SOE_USER_CATEGORY.

   See: Creating User Types and Statuses, Oracle HRMS Enterprise and Workforce Management Guide

2. Set the value of the user category that you created as the profile value for the profile PAY: Statement of Earnings User Category.

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

3. Add the predefined element sets for your earnings and deductions to the SOE Information EIT at the business group level.

   For Canadian and US users only: SOE Information functionality is not available for Canadian and US legislations.

   Swedish users only: Ensure that you have enabled your elements to display a code. You do this at the business group level by entering Extra Element Details for each element. When you select the EIT, you can make a further selection of Element Name, and specify a code for your selected element. This ensures that your SOE displays the element code in the earnings, deductions, and information regions.

   See: Business Group: Entering SOE Information, Oracle HRMS Enterprise and Workforce Management Guide

4. Create an element set containing all the elements that you want to see displayed in the information region of the SOE.

   For South Africa only: The Information region has been renamed to Fringe Benefits and Other Non Payments region. You use the predefined ZA SOE Fringe Benefits and Other Non Payments element set to display information in that region. You enter this element set in the Elements 3 field when you define your SOE Information at business group level.

   The South African localization does not use balance attribution.

   Users should now restart the Apache server as instructed in the final step.

5. Complete the SOE Detail Information EIT by adding the elements in your element set, and the SOE display balances to the EIT at the business group level.

   See: Business Group: Entering SOE Detail Information, Oracle HRMS Enterprise and Workforce Management Guide

6. Link the predefined SOE balance attribute to your business group. The attribute name is likely to have a leading localization code followed by the stem _SOE_BALANCE_ATTRIBUTES.

7. Define the attributes for your SOE balances.

8. Restart the Apache server and then check the SOE to ensure that the SOE displays the requirements that you selected.

Running the Enable or Disable Global SOE Process

You use this process to determine how your statements of earnings are displayed. You have a choice of the forms-based SOE, or the global SOE which is framework-based and readily customizable. You can either:

• Enable the global SOE if you want to override the forms-based default

• Disable the global SOE if you prefer to continue using the old forms-based format.

You run the Enable or Disable Global SOE process from the Submit Request window.

To run the Enable or Disable Global SOE:

1. Select the Enable or Disable Global SOE process in the name field.

2. Enter whether you want to Disable or Enable the Global SOE in the parameters window.

3. Click OK and choose the Submit button.

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

8. US and Canada only: Oracle Payroll provides the flexibility to choose the way annual salary is calculated and reported on the Online Payslip (both HTML and PDF). This flexibility is available through the HR: Base Annual Salary Display on Standard Work Conditions profile option.

   See: Defining the Profile Option for Pay Annualization, Oracle HRMS Payroll Processing Management Guide (US)

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.

Payslip Modeling

Setting Up Payslip Modeling

Before you can use the Payslip Modeler, you must ensure to set up the following:

1. Ensure set the profile option HR: Enable Payroll Simulation to Yes to use this module. If the profile option is set to No, you cannot use the payslip modeler.

   See: User Profiles, Oracle Human Resources Management Systems Configuring, Reporting, and System Administration Guide

2. You can set the profile option HR: Enable Multiple Assignments for Payroll Simulation to Yes to select the secondary assignment when there are multiple assignments. If set to No, then you can run the payslip modeler process on the primary assignment only.

   See: User Profiles, Oracle Human Resources Management Systems Configuring, Reporting, and System Administration Guide

3. You can enable or disable the payslip modeler at the Payroll level by specifying Yes in the Enable Simulation field. You cannot run a payroll run and payslip modeling simultaneously. If the Payslip Modeler is enabled, then you can set locking period, number of days prior to and after a specified date for enabling or disabling the payslip modeler. This restricts users from making updates to payroll information while modeling their payslip during a mock payroll run during the specified period.

   See: Defining Payroll, Oracle HRMS Payroll Processing Management Guide

4. If you want use payslip modeler then you must select the document type as Payslip Modeler in the Self-Service Preference window at the business group level or the organization level.

   See: Entering Self Service Preference Information

5. If you want to restrict any elements from being processed in the modeler process, create an element set and include the elements you want to exclude. Specify the element set in the Modeler Exclusion Element Set in the Self-Service Preference window at the business group level or the organization level.

   This skips the elements within the element set from being processed and the elements are not available for users to select while running a modeling process.

6. Specify the Payroll Simulator Template in the Self Service Preference window at the business group level or organization level. If no template is specified, then the application uses the default template to generate the model payslip. Users can create their own templates associated with the Data Definition PAY<LEG_CODE>SIMPAYSLIP.

   See: Entering Self Service Preference Information

7. To enable an element to be available for payslip modeling, query the element and select Yes in the Enable Simulation field in the Element Extra Information window. You can enter input values for this element required for simulation in the Element Description window. Only user enterable input values are available for Payslip modeling.

   If the Multiple Entries check box is enabled for an element, then you cannot use this element for payslip modeling. Instead, create a copy of the base element, enter input values, attach the appropriate formulas and balances as the base element and then use this element for payslip modeling. Ensure that this new element is not used for payroll run.

   It is necessary to create a new element for the corresponding Multiple Entries Allowed element and setup the new element as Yes for Enable Simulation. Ensure to specify the earlier element as Original Element under Simulation Details for the new element. Enter input values, attach the appropriate formulas and balances as the new element. This is to ensure that Simulation ignores the Original element entries in Simulation run and uses only new element entry.

   Example to Understand the Restrictions on Multiple Entries Allowed Enabled Elements

   The unavailability of Yes for Multiple Entries Allowed enabled elements is an expected behavior of Paycheck Modeling.

   For example, consider an employee with an Overtime Element. This element entry is added on the days when employee works overtime. For a month, if employee does overtime for 10 days, then this element entry gets added 10 times. If the employee wants to model a paycheck and view the net take home after working overtime for 10 days or more, then it will not be practical to add 10 entries for 10 days from Paycheck Modeling page. Instead, the employee can add the total overtime hours. Therefore an element which conveys the total overtime hours for the Pay period instead of each day can be used. If there are already some Overtime entries added to the employee in the application for current period, then it is necessary to suppress these entries when the employee tries to model Overtime hours so that Paycheck Modeling/Simulation gives desired results depending on the inputs.

   To handle this scenario, the Overtime Element (the elements with Multiple Entries Allowed) is not allowed to be directly enabled for Simulation. Instead it is necessary to create a new element to support Simulation. The element created for simulation can have changes to Input Values validation. If there are any rules or validations on the maximum number of hours that can be entered, say, Overtime entries can accept maximum of 5 hours per day, these can be relaxed in new element to suit the requirement of simulation so that users can add 50 hours for complete month in single entry.

   For the new element, it is necessary to specify the existing Overtime element as Original Element under Simulation Details. This will ensure that whenever employee tries to model Overtime hours using new element, any existing Overtime element entries are ignored during Paycheck Modeling/Simulation.

   See: Defining Elements

   Note: There is a restriction for Predefined elements being used for payslip modeling. For predefined elements, if you setup the details for a predefined element in one business group, then these details will be accessible to other business groups. For example, for predefined element Regular Salary element, if you want to enable Input Value A for one Business Group and Input Value B for other Business group, then this is not possible. This limitation occurs for predefined elements applicable to all Localizations. Therefore if there are multiple business groups, then you must define a single structure for the predefined elements.

   If there are custom elements, then the custom elements are accessible only for that business group.

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 other nationals working in UAE, you can do the following:

   • 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 other nationals working in UAE, you can do the following:

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

Additional Information: RetroPay Overlap is not available by default for all localizations. To use this feature, localizations must need to enabled it.

For more information on RetroPay Overlap , refer to RetroPay Overlap - A Technical White Paper Note ID 842307.1 on My Oracle Support

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 Enhanced RetroPay and Retro-Notification

Problem Description	What to Do
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,the Enhanced RetroPay run does not produce any results. US only :the Retro-Notification report (Enhanced) 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.

Troubleshooting 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 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 Enhanced RetroPay with Component Usages and Element Time Spans

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 RetroPay run as a component. You set up RetroPay component usages to define how RetroPay will process the 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 Time Spans for RetroPay

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. If you are creating RetroPay elements manually, you must follow the process given below to set up retro components and element spans to process RetroPay correctly.

Tip: Check if your Localization has components and time spans predefined that you can use to process retropay.

Additional Information: Check if your localization has any upgrade processes enabled if you are upgrading your current elements.

Setting Up Retropay Component Usages

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

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

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

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

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: Do not enable the Retro Component of the elements that are themselves being used to process retropay for another element.

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.

5. Save your work.

6. You can now enter the element time spans.

Setting Up Element Span Usages for 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. 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 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.

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

5. Save your work.

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

Given below is the sequence of 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.

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

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.

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.

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.

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.

Viewing RetroPay Enhanced Results

You can query the assignment actions of the Retropay Enhanced process and review the corresponding retro entries created.

Note: Oracle Payroll delivers the "RetroPay Enhanced Results" (PAY_WS_RETRO_RESULTS) function to view the RetroPay enhanced results and this function is also associated with the global View menu (GLB_HRMS_VIEW_INFO). By default, this function is available in the US (US_HRMS_VIEW_INFO) and Canada (CA_HRMS_VIEW_INFO) menus. For the Mexico localization, the seeded "MX HRMS Navigator" menu includes the global GLB_HRMS_VIEW_INFO menu. Therefore, the "RetroPay Enhanced Results' function will be available to all responsibilities associated with the seeded "MX HRMS Navigator" menu.

If required, system administrators must add the "RetroPay Enhanced Results" function to other localization seeded menus and custom menus.

To view the RetroPay Enhanced Results:

1. Click the View Results on the Assignment Process Results window to view the results for a particular the Retropay Enhanced assignment action.

2. Query the Assignment Actions of the Retropay Enhanced process effective between the specified dates for a given assignment or payroll. You can enter any of the following to query the retro assignment actions

   • assignment number

   • full name

   • effective date from and effective date to

   • payroll name

   • status of the assignment action

3. Click on the following details of the Retropay Enhanced assignment actions matching the search criteria to display the appropriate information:

   • Full Name – Click on the Full Name to get the list of Retro Entries created by the selected action.

   • Assignment Number

   • Action Status - If the action is in Error status, then click on the status to review the error messages.

   • Effective Date – View the effective date of the Retropay Enhanced assignment action.

   • Reprocess Date – Date provided by the Retropay Notification Report or the Retro Status Page.

   • Overlap Date – Overlap Date calculated by the Retropay Enhanced process internally. During the process, the run actions are rolled back and re-run from this date for the assignment.

4. In the Retropay Entries section, you can view the following information:

   • retro element

   • effective start date

   • effective end date

   • retro component

   • base element - the element for which the retro element is created

   • original date earned

   • Details – Click on the icon in the Details column to display the input values of the retro element created with a comparison of the run result values from the original period. The table also displays the retro element entries with their input values from the same source in previous periods. The comparison assumes that the base element and retro element have the same set of input values with the same order of display sequence.

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

After you have defined the components and element time spans, you can check the retrospective changes occurred. Oracle Payroll provides two types of retro notification reports that you can use report to identify all retrospective changes that have occurred since the last payroll run. This information is particularly useful when changes with retrospective impact are entered in Self Service HRMS independently of the Payroll department.

Oracle Payroll enables you to produce the report either in a text format or as PDF format. You can choose to run the report depending on your requirement:

• Retro -Notifications (Enhanced) Report – run this report to generate the output in text format

• Retro -Notifications (Enhanced PDF) Report - run this report to generate the output in PDF format that you can further customize to meet your requirements.

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. After you have run the Retro-Notifications report, you can

• Run your RetroPay process on all assignments

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

• Take no retrospective action on any of the assignments.

You can use the RetroPay Status window to schedule processing.

You run the Retro-Notifications (Enhanced) or the Retro-Notifications (Enhanced PDF) 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 want a report, select Yes in the Generate Report parameter.

4. Click OK, and submit.

To run the Retro-Notifications (Enhanced PDF) 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. If you want a report, select Yes in the Generate Report parameter.

5. Click 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 Quick RetroPay

Run Quick RetroPay to process any retrospective payments for a single assignment. You run the Quick RetroPay process from the Submit Requests window.

Note: It is not mandatory to run the Retro-Notifications Report for QuickRetropay process.

To run the Quick RetroPay process

1. Enter a date on which you want to create the derived retro element entries. This is mandatory.

2. Select the assignment number of the assignment for which you want to run the backdated change. This is mandatory.

3. If you want the retro entries to get created in a different payroll period than that of Effective Date, then you specify an Entry Creation Date. This is optional.

4. Enter an earliest date from which you want to reprocess the assignment backdated changes. If you do not specify any date, then the application calculates it internally. This is optional.

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

6. Click Submit.