PAYMENT BATCHES PROCESS Background Process and Trouble Shooting

Noah Chanmala, Tai Ellis, Amish Vanjaria, and Eric Falkner Oracle Corporation

Abstract
This paper focuses on the Oracle Payables Applications payment batch process. This paper is written for intermediate to advanced Oracle Payables users. The scope of this paper involves background processing and trouble shooting. This paper assumes that the readers have thorough knowledge of Navigating and setting up an Oracle Payables Application.

Scope
I. Process Overview II. Select Invoices III. Build payments IV. Modify V. Format payment VI. Confirm payments VII. Cancel Payment Batches & Void Payments

I.

Process Overview

Prior to creating a payment batch, four setup issues are required. First, define a bank for bank branches with which you do business. Second, define bank accounts. Third, choose a predefined or custom payment format. Finally, define payment documents for disbursements for each bank account. The following is an overview of the steps required to create payment batch payments: 1) Initiate the payment batch by entering the criteria for invoices you want to pay. The payment batch process selects invoices, then builds the payments. It determines which invoices will be paid on each payment document, and lists this information for you on the Preliminary Payment Register. 2) Make any necessary modifications to your payment batch, such as selecting additional invoices, deselecting invoices, deselecting suppliers, etc. Once modifications are complete, the modify payment batch process automatically builds the payments if any invoices were added. 3) Format payments to produce an output file. 4) Print checks from the output file if you are not creating electronic payments or sending the output file to a third party for printing.5) Confirm the payment batch by recording the document numbers associated with each payment. During this step,

the invoice status is updated to Paid and a document number is associated with the invoice and invoice payment. AP_SELECTED_INVOICES_ALL AP_INV_SELECTION_CRITERIA_ALL AP_INVOICES_ALL AP_PAYMENT_SCHEDULES_ALL

II.

Select Invoices

When a payment batch is started one row for each record is created in the

AP_INV_SELECTION_CRITERIA_ALL table.
This table stores the criteria that a payment batch uses to select invoices for payments. The module name for the AutoSelect process is APXPBSEL. The Select Invoices, or AutoSelect, is the first step in the payment batch process. The AutoSelect process starts by loading records that meet the invoice selection criteria into the table AP_SELECTED_INVOICES_ALL from the tables AP_INVOICES_ALL and AP_PAYMENT_SCHEDULES_ALL. The criteria that AutoSelect uses to determine which record to select from AP_INVOICES_ALL and AP_PAYMENT_SCHEDULES_ALL is stored in AP_INV_SELECTION_CRITERIA_ALL. To be sure that no duplicate invoices get selected, invoices that are already selected in another payment batch are not selected. Invoice payments that have no remaining payment amounts are not selected either.

Common Issues:
One of the most common issues in the selection process is when invoices are available to be paid, but are not being selected for the payment batch. Here are some things that would cause an invoice not to be selected in a payment batch: 1) 2) 3) 4) The invoice is not approved. The invoice is not due yet. Check the payment schedule due date. The paygroup of the invoice is different than the paygroup used in the payment batch. The Use PO Encumbrance field may not be initialized. This needs to be done in release 10.7 before creating a payment batch for the first time. a) Go to the Financials Options form (Setup->Options->Financials). b) Go to the encumbrance region. c) Check the field Use PO Encumbrance. d) Save. Unchecked the field, Use PO Encumbrance. Save. 5) The currency used on the invoice may not match the currency for the payment format you are using. If the payment format is to handle a currency other than the functional currency, the field Multiple under the Currency region must be checked. 6) The supplier site option Hold all Payments is checked. This will prevent invoices for that supplier site from being selected.

Problem: AutoSelect runs for a long time and seems to hang. There are no errors in the log file. The function fails before it writes to a temporary file in the directory /usr/tmp. Solution: Verify that directory $AP_TOP/usr/tmp has enough space and that you have write permissions on the directory. Problem: Q: Under what conditions do invoices with discounts get picked up by a Payment Batch? Solution: If the Payment Batch option Pay only when due = yes, then only payments due will be picked up. The invoice that has a discount, but is not due yet, will be disregarded. Only invoices that have a payment due AP_SELECTED_INVOICES_ALL AP_SELECTED_INVOICE_CHECKS_ALL date from the payment schedule that is less than the pay through date will get picked up. If Pay only when due = no then three factors apply: 1) Invoices that have vendor sites with a Pay Date Basis of Due Date will get picked up if the due date is before the pay through date. 2) Invoices that have vendor sites with a Pay Date Basis of Discount and Always Take Discount = Yes will get picked up if discount date is before the pay through date.3) Invoices that have vendor sites with a Pay Date Basis of Discount and Always Take Discount = No will get picked up if discount date is before the pay through date and the payment date is before the discount date.

III.

Build Payments

The module name for the Build Program is APXPBBLD. From the list created by AutoSelect, the Build program determines which invoices will be paid on each payment document, and lists this information on the Preliminary Payment Register if selected. The Build program is spawned when AutoSelect has completed. When the Build Program starts, the application uses information from the table AP_SELECTED_INVOICES_ALL to create rows in the table AP_SELECTED_INVOICE_CHECKS_ALL. In addition to creating rows in the AP_SELECTED_INVOICE_CHECKS_ALL, the build payments program also performs the following tasks: Assigns document numbers for payments Assigns Check Ids Renumbers the remaining documents starting from the first_available_document Updates the payment batch status to BUILT Resets the prososed_amount to the payment_amount.

To summarize, this process collects the information from AP_SELECTED_INVOICES_ALL table to be placed into the AP_SELECTED_INVOICE_CHECKS_ALL table for use in the next process, which is the Format process, to create a payment document (i.e., check). The figure below shows the example of an overflow document when you have defined seven invoices per remittance, but there are actually ten invoices for the payment. Oracle Payables will actually print two checks, in order to have all ten invoices include in the payment. It assigns the first check with a status of Void. The second check has a status of Negotiable with a total payment equalling the sum of both checks. This is assuming the Pay Alone flag is not set. Invoice 01 ..$100 Invoice 02 ..$100 Invoice 03 ..$100 Invoice 04 ..$100 Invoice 05 ..$100 Invoice 06 ..$100 Invoice 07 ..$100 Check 1 .$700 Invoice 08 ..$100 Invoice 09 ..$100 Invoice 10 ..$100 Check2 .$1,000 Negotiable AP_SELECTED_INVOICE_CHECKS_ALL AP_CHECKS_ALL.

Common Issue
Problem: Standard Build Payment errors with ORA-0001: unique constraint (AP_SELECTED_INVOICE_CHECKS_U1) violated. Solution: This error is dealing with the system sequence being out of sync, which creates the violation of the check id sequence number. Using the following SQL script to drop and create the sequence, as well as the index, to bring the sequence back in sync again. SELECT ap_selected_invoice_checks_s.nextval FROM dual; DROP SEQUENCE ap_selected_invoice_checks_s CREATE SEQUENCE ap_selected_invoice_checks_s INCREMENT BY 1 START WITH 20000 DROP INDEX ap_selected_invoice_checks_ul CREATE INDEX ap_selected_invoice_checks_ul ON ap_selected_invoice_checks (selected_check_id); ap_selected_invoice_checks (selected_check_id);

Problem: You receive the error message: APP-10056 payables is unable to submit your concurrent request when you run a payment batch with Select, Build and Print Preliminary Payment Register selected. Solution: This error is due to the printer setup. The Preliminary Payment Register Program will look for the default printer setting at the user profile level. If there is no default setting at the user profile, the system will look for the printer assigned at the Program level (Concurrent => Program => Define). APP-10056 will occur if there is no printer set at either location.

IV.

Modify

Modify allows you to change what was done in the AutoSelect and Build processes. You can modify the payment amount of an invoice, prevent payment to a supplier, prevent payment of a particular invoice, or add an invoice that was not originally selected. If you add invoices to a payment batch, it will automatically be rebuilt. 1. To add an invoice to a payment batch, enter the Supplier name and Site. Select Yes for Pay Supplier. The approved invoices for the supplier site are displayed. For each invoice you want to add to the payment batch, select Yes for Pay Invoice. 2. If there is an approved, unpaid invoice you want to include in the payment batch, even though it does not meet the selection criteria, you may manually enter the invoice number in the Selected Invoices region to add it to the payment batch. 3. To add an invoice that has been excluded because the payment batch exceeds the maximum outlay, choose Force as the Pay Option. 4. To remove an invoice from a payment batch, query the Supplier name and Site. The invoices for the supplier site which were selected for the payment batch are displayed. To remove an invoice from the batch, select No for Pay Invoice. 5. To remove all invoices for a particular supplier site from a payment batch, query the Supplier name and Site. Select No for Pay Supplier. 6. To change payment or discount amounts for a selected invoice, query the Supplier name and Site. The invoices for the supplier site that were selected for the payment batch are displayed. Alter the payment or discount information for the invoice. (You cannot adjust the payment amount or the Discount amount on invoices that include withholding tax.) AP_SELECTED_INVOICE_CHECKS_ALL AP_CHECKS_ALL AP_INVOICE_PAYMENTS_ALL AP_INVOICES_ALL AP_PAYMENT_SCHEDULES_ALL 7. To change the supplier bank account for electronic payments, query the Supplier name and Site. The scheduled payments for the supplier site that were selected for the payment batch are displayed. If you enable the Allow Remitto Account Override Payables option (Setup => Options => Payables => Payments), you can change the Remitto Account to another bank account assigned to the supplier site that uses the same payment currency.

V.

Format

The module name for the format process is usually either APXPBFEG or APXPBFOR. Many customers create their own Format program. The Format program creates the output file that is used to print checks. This process inserts the payment record from AP_SELECTED_INVOICE_CHECKS_ALL into AP_CHECKS_ALL. There are two standard executables for printing checks: APXPBFOR is the Oracle Standard Format and APXPBFEG is the Evergreen Format. Evergreen is the company that supplies forms and printer cartridges that are compatible with the Evergreen check format. Oracle Payables includes five standard concurrent programs that format checks. Each of these five programs uses one of the two executables, with varying Execution Options. You may view these programs in the Define Concurrent Program form when you are signed on with System Administrator responsibilities.

Evergreen Format
If you navigate to Concurrent => Program => Define and query the Executable APXPBFEG, you will see three different concurrent programs in the Short Name field. The following is a description of each of the concurrent programs: 1) APXPBFEG: The default name for this program is Evergreen, Long . This is the basic Evergreen payment format. It has no special formatting and is designed for non-laser printers. It does not use any Execution Options. 2) APXPBFEF: The default name for this program is Evergreen, Form Feed. This format is designed to be used with laser printers when printing on preprinted check stock. There is a form feed (Control L) after every page which is required for laser printers. The print style is portrait and the Execution Option is p_continuous_stationery=N 3) APXPBFEL: The default name for this program is Evergreen, Laser. This format is designed to be used with laser printers when printing on blank check stock. This process requires a laser printer which uses a cartridge (normally purchased from Evergreen). It prints all the information on the check, including company name and logo, bank name, signature(s) and the MICR encoded line at the bottom of the check. If this program is used without the printer cartridge, you will see two large exclamation marks (!!) near the signature line. The print style is Portrait, Laser and the Execution Options vary, but must contain at least p_printer_code_mask = 101,102,111,121,122,141 and p_continuous_stationery=N.

Oracle Standard Format

If you query on the Executable APXPBFOR, you will see two concurrent programs. The following is a description of each of the concurrent programs:

1) APXPBFOR: The default name for this program is Standard Oracle. This format is designed for non-laser printers. The print style is Dynamic Portrait and there are no Execution Options. 2) APXPBFOF: The default name for this program is Standard Oracle, Form Feed. This format is designed for laser printers.

VI.

Confirm

Confirm is the final step in processing a payment batch and should be done prior to sending out the checks. Invoices are not considered paid, even if checks are printed, until confirm has been done. If you have any unconfirmed payment batches, you cannot close a period or use the same payment document for any other payments until you confirm the payment batch. The module name for the Confirm process is APPBCF. It records the document numbers associated with each payment. During this step, the system updates the invoices status to paid and associates a payment number with the invoice and invoice payment. The confirm process applies criteria entered by the user in the confirm form to create the checks and payments for this payment batch. The user-provided criteria indicates whether the physical payment documents created conform to what the system thinks happened. This information is passed through records in the AP_CHECKRUN_CONFIRMATIONS table. Each record represents a range of documents and what happened to them. The four status include: Setup, Printed, Skipped, Spoiled. Setup. Payables automatically displays the setup checks used to align your printer. Payables automatically voids these checks when you confirm a payment batch. The number of setup checks is specified in the Payment Document region of the Bank Accounts window. Printed. Either the checks printed properly or the Electronic payments formatted correctly. Ranges of Printed documents must end on a negotiable Skipped. The printer skipped over these checks and nothing printed on them. These documents can be reused for single payments. Spoiled. The printer malfunctioned and ruined these documents, so they cannot be reused. Payables automatically voids these documents. Note: For Electronic payments, confirm the entire range of payments as Printed, or cancel the entire batch if there were problems. If your printer malfunctions during printing, you can record the status of the printed documents, as well as those that were damaged, and cancel the remainder of the payment batch. Alternately, you can choose Cancel Remainder. Payables updates the status of the invoices paid to Paid and prints the Final Payment Register for the recorded portion of the batch.

If your printer malfunctions during printing, you can record the status of the printed documents, as well as those that were damaged, and restart check printing at the next available document number. Alternately, choose Restart Payment Batch. Payables updates the status of the invoices paid to Paid and prints the Final Payment Register for the recorded portion of the batch. Payables starts a new payment batch for the remainder of the payment batch. Enter the first payment document number you want to use to restart the payment batch. Choose OK to have Payables automatically Build the unprinted checks. After Payables completes the build process, you have the option of modifying the restarted payment batch before formatting, printing, and confirming the payments. When you confirm, Payables automatically enters the batch confirmation information you entered earlier. Enter confirmation information for the restarted payments to complete confirmation for the batch. The confirm program first updates the AP_SELECTED_INVOICE_CHECKS_ALL records, then transfers those records to AP_CHECKS_ALL. In addition, the AP_SELECTED_INVOICES_ALL records are transferred into the corresponding AP_INVOICE_PAYMENTS_ALL, AP_INVOICES_ALL and AP_PAYMENT_SCHEDULES_ALL. Any interest payments are transferred into AP_INVOICES_ALL, which have corresponding AP_INVOICE_DISTRIBUTIONS_ALL, and AP_PAYMENT_SCHEDULES_ALL entries. The payment document is updated to reflect the payments made and appropriate sequential numbers are assigned to the checks. Finally, the Payment Batch temporary records (i.e., records in AP_CHECKRUN_CONC_PROCESSES_ALL and AP_CHECKRUN_CONFIRMATIONS_ALL) are deleted and an output report is generated showing any undistributed payments. Confirm can also be used to cancel the payment batch, in which case all the temporary are deleted and the system looks like the payment batch had never started.

Confirming a Partial Batch and Restarting

To record a partial batch and restart check printing, go to the Confirm Payment Batch window. Record the checks as Setup, Skipped, or Printed, and then choose Restart Payment Batch. Do not record any checks as Spoiled. Instead, void any destroyed documents. For example: The setup checks, checks 100 and 101, printed successfully. Checks 102-109 printed successfully. Checks 110-199 did not print because the database went down. In the Confirm Payment Batch window, Payables records checks 100101 as Setup. You record checks 102109 as Printed. Choose Restart Payment Batch. When Payables prompts you to enter the document number with which it should resume printing, enter 110. Payables restarts processing the remainder of the payment batch using check 110 as the beginning check number. When you choose Restart, Payables builds payments and formats a new output file for the invoices that should have been paid with checks 110

199. You then print and confirm, using the same payment batch name. When you print the restarted portion of the payment batch, Payables will use checks 110 111 as Setup checks. It will print on check 112, the check that originally should have been paid on check 110. Confirming a Partial Batch and Canceling the Remainder: To record a partial batch and cancel the remainder, go to the Confirm Payment Batch window. Record the checks as Setup, Skipped, Spoiled or Printed. Then choose Cancel Remainder. This is similar to restarting the payment batch, but you cancel the remainder and plan on initiating another payment batch at a later time. For example: The setup checks, checks 100 and 101, printed successfully. Checks 102-140 printed successfully. Check 141 was destroyed when it was jammed in printer. Checks 142-199 did not print, because the printer jammed. In the Confirm Payment Batch window, Payables records checks 100101 as Setup. Record checks 102140 as Printed and check 141 as spoiled. Then choose Cancel Remainder. Payables updates to Paid the status of the invoices paid by the Printed checks, and updates to Unpaid the status of the invoices associated with the spoiled and the remaining payments. Initiate a new payment batch to pay the invoices that should have been paid by checks 141 200. Confirming a Payment Batch with Skipped Payments: To record a completed payment batch, if a check skipped during printing, go to the Confirm Payment Batch window. For example: The setup checks, checks 100 and 101, printed successfully. Checks 102-140 printed successfully. Check 141 was skipped. Checks 142-199 printed successfully. In the Confirm Payment Batch window, Payables records checks 100101 as Setup. Record checks 102140 and checks 142199 as Printed. Record check 141 as Skipped. When you record a check as Skipped, Payables automatically adjusts the check numbering sequence to reflect the printed results. You can then reuse the skipped check for a manual check or void it in the Payables Document region of the Banks window. Confirming a Payment Batch with a Spoiled Check: To record completed payment batch, if a check was damaged during printing, go to the Confirm Payment Batch window. For example:

 The setup checks, checks 100 and 101, printed successfully. Checks 102-140 printed successfully. The ink smeared on check 141, and it is illegible. Checks 142-199 printed successfully. In the Confirm Payment Batch window, Payables records checks 100101 as Setup. Record the entire range of 102199 as Printed. Pull check 141, and void it using the Actions window of the Payment Workbench. You can then pay the invoices that should have been paid by check 141 on a single payment or in another payment batch. Do not record check 141 as Spoiled. Recording a printed range after a spoiled range would result in an adjustment to the check numbering sequence, causing Payables to record incorrect payment information, as it would use check number 141 again.

Common Issues:
Problem: APP-00247: You must specify the printer before running a report. Solution: This error indicates that there is no printer defined. As the System Administrator Responsibility, go to Concurrent => Program => Define, query APPBCF (Short Name), and define a specific printer for the Program. Or go into Profiles System and select a printer for the profile option called Printer at the appropriate level. (Site, Responsibility, User) Problem: APP-10208: The document number you entered is greater than the last available number for the payment document. Solution: First you will have to cancel or confirm any payment batches that are currently using this payment document. Then navigate to Setup => Payment => Banks. Query your bank and bank account. Click on Payables Documents. Select the alternate region Additional Information. Change the Last Available to a higher number (99999999999 is the maximum number it will take). Note: You cannot overlap numbers for payment documents. Save. Then you can start a new payment batch using this document. Problem: APP-10056: Payables is unable to submit your concurrent request. Contact System Administrator. Solution: Check that the printer style listed in the concurrent program definition (Concurrent => Program => Define) for APPBCF is associated with the printer (Install => Printer => Types, query by printer type) . Problem: The Payment Batch is stuck in Confirming status. Solution: If your payment batch is stuck in a status of Confirming, and you cannot cancel it through Payables (i.e., Action => Cancel), you can reference note 182988.1 for Release 11i issues , which utilizes a downloadable script to help identify and diagnose payment batch issues. For issues in release 10.7 or 11, please log an iTAR on Metalink.

VII.

Canceling Payment Batches and Voiding

Payments
When you cancel a Payment Batch, the Payment Batchs payment document becomes available for another payment batch. You cannot cancel a Payment Batch if it has been confirmed. Once the payment batch is confirmed, you would have to void individual payments, taking the desired action on the invoice. Voiding payments will update the invoice(s) to a status of unpaid.

Major Tables Involved In Payment Batch Process

AP_SELECTED_INVOICES_ALL AP_INV_SELECTION_CRITERIA_ALL AP_INVOICES_ALL AP_PAYMENT_SCHEDULES_ALL AP_SELECTED_INVOICE_CHECKS_ALL AP_CHECKS_ALL AP_INVOICE_PAYMENTS_ALL AP_PAYMENT_SCHEDULES_ALL AP_INVOICES_ALL

About the Authors

Noah Chanmala, Tai Ellis, Amish Vanjaria, and Eric Falkner are Technical Analysts for the Oracle Payables support team.