Pre-Payments Process

Pre-Payments Process

The Pre-Payments process prepares the payments generated by the Payroll Run for payment. It prepares payments for each assignment and inserts the results into PAY_PRE_PAYMENTS for each payment method for an assignment.

The Pre-Payments process also:

Setting Up Payment Methods

During implementation, you set up your own specific payment methods with source account details. When you hire an employee, you can record one or more payment methods for the employee, and apportion payment by percentage or amount. You can also record payment methods in different currencies.

The Pre-Payments process prepares payments following the payment methods for each assignment. There are three predefined payment types that Oracle Payroll processes:

You can set up as many payment methods as you require (based on the three predefined payment types) to support your business needs.

Every payroll has a default payment method. Pre-payments uses the default method when there is no personal payment method entered for a specific assignment.

Note: You cannot have a default method of type Magnetic Tape. This is because Magnetic Tape payment methods require knowledge of the employee's bank account details, including prenotification details in the US.

See Prenotification

Payment methods are processed in order of their priority for an assignment. For example, an employee may want:

  1. 50% of the salary to be paid directly into their bank account by Magnetic Tape payment

  2. 100 dollars paid by Cheque/Check

  3. 100 dollars paid in Cash

Pre-Payments prepares the payments in priority order, provided that the amount to be paid covers the payments. If there is less to be paid than the payment methods specify, the system pays up to 100% and stops. If there is more to be paid than the payment methods specify, the system adds the excess to the last payment method.

Preparing Cash Payments (UK Only)

If you are using Oracle Payroll to prepare cash payments, you can calculate the banknote and coinage requirements for each employee. Pre-Payments breaks down the amount into the individual monetary units for payment and insert the results into the PAY_COIN_ANAL_ELEMENTS table.

You can define the monetary units for each currency you pay for cash payments administered through Oracle Payroll. You can also define cash analysis rules to specify minimum numbers of each denomination of the currency.

Setting Up a Cash Rule

The are two steps to setting up a cash rule:

  1. Alter the package body hr_cash_rules

    The alteration should test for the name of the cash rule you want to set up and then perform the payment. For example, if the rule name is 'TENS AND FIVES' then enter the following:

    if cash_rule = 'TENS AND FIVES' then
    
    --
    
    hr_pre_pay.pay_coin(6, 10)
    
    hr_pre_pay.pay_coin(3, 5)
    
    --
    
    -- number to pay ---^  ^--- unit value of currency
    
    --
    
    end if;\
    

    Using this cash rule with a currency of dollar results in a minimum of 6 ten dollars and 3 five dollars being paid (given sufficient funds).

  2. Register the rule.

  3. Enter the Lookup Values window and query the Lookup type of CASH ANALYSIS.

  4. Add the new Cash rule with the meaning and description fields set to TENS AND FIVES.

  5. Use the cash rule when setting up an organization payment method.

Prenotification (US Only)

Prenotification validation (also known as prenoting) applies to payment methods of the type Magnetic Tape. This validation is performed when bank details require checking before a payment can be made. For example, when an employee has changed banks or changed bank details, a payment value of zero is made to the employee's bank account. The payment is then made by subsequent methods, or by the default method.

Consolidation Sets

Pre-Payments is run for a consolidation set. A consolidation set is a tag that ties groups of actions together. You can use a consolidation set to prepay all assignment actions in the set that have not yet been prepaid. These assignment actions can be for different payrolls and different time periods. For example, you could use a consolidation set to force the magnetic tape process to pay both of a company's payrolls where one is monthly and one is weekly.

Third Party Payments

Third party payments are post tax deductions from an employee's salary, that are paid to organizations or individuals. For example, court orders are payable to a municipal court whereas child support orders may be directly payable to a spouse, or other individual.

These payments are processed in a slightly different way. The element entry that produces the run result value for the payment holds details of which payment method to use. This enables you to make more than one entry of a third party payment element to an assignment, with each entry representing a payment to a different party. For example, an employee can pay a third party element of Child Support to two different people.

Third party payments can only be made by magnetic tape or cheque/check. Cash payments are not allowed. In addition, these methods pay the full amount of the payments, so only one method is used. There is no default method for these payments, so a payment method must always be specified. US: If the magnetic tape prenote validation fails, the process creates an error for that assignment.

Exchange Rates

Pre-Payments calculates the currency conversion if the payment is in a different currency to that of the remuneration balance (the element output currency in the case of third party payments). If the process cannot find the exchange rate for the two currencies, it creates an error for the assignment.

Overriding Payment Method

You can specify an overriding payment method when making a prepayments run. This method overrides the personal payment methods, so the full amount of the payment is made by the overriding method. The only exceptions are the third party payments; these are paid by the method specified in the element entry.

The overriding payment method can be either:

You cannot specify magnetic tape payments as an override method, as this type of payment requires prior knowledge of bank account details.

The Process

The Pre-Payments process creates payroll actions and assignment actions. The assignment actions are based on assignment actions of the payroll/consolidation set specified that do not have interlocks to a prepayment process. The interlocks guarantee that Payroll Run cannot be rolled back until Pre-Payments is rolled back. Thus, the new assignment actions are created with interlocks to the run's assignment actions.

See: Assignment Level Interlocks

Chunking

The assignment actions are split into groups called chunks, the size of which are denoted by the CHUNK_SIZE action parameter in the PAY_ACTION_PARAMETERS table. The process could spawn several threads (child processes), depending on the THREADS action parameter. Each thread then picks a chunk to process, processes the assignment actions and then picks another chunk until all the chunks are processed. The number of threads can be used to enhance performance on multiprocessor machines.

PL/SQL Procedures

The main part of the C process (the section that performs the payment), is a harness for PL/SQL procedures. The PL/SQL procedures create the entries in the Pre-Payment table.

The threads process the assignment actions by:

Error Handling

Errors encountered while processing can be at two levels:

Using the MAX_ERRORS_ALLOWED action parameter you can set the number of assignment errors that can be processed before an error should be raised at payroll action level. If MAX_ERRORS_ALLOWED is not found then the chunk size is used as a default.

All the error messages are written to the PAY_MESSAGE_LINES table with a more detailed explanation in the log file.

This method of handling errors enables Pre-Payments to continue processing if minor errors are encountered. For example, if Pre-Payments has thousands of assignments to process and a few are paid by cash but the currency details have not been loaded, the process creates an error for the assignments with cash payments ("Process unable to perform the cash breakdown"). Most assignment actions complete, only the assignments with errors have to be rerun.