R12 Payment Process Request - Functional and Technical Information [ID 821133.

1] Modified 12-MAY-2009 Type WHITE PAPER Status PUBLISHED

In this Document Abstract Document History R12 Payment Process Request - Functional and Technical Information Overview Submitting a Single Payment Process Request Document Selection Payables Build Payments - Payments Format Payments - Payments Confirm Payments - Payables

Applies to:
Oracle Payables - Version: 12.0.0 to 12.1 Information in this document applies to any platform.

Abstract
This whitepaper provides an overview of the Payment Process Request (PPR) processing in Payments in R12. It will cover technical details of PPR processing and the different tables involved during the process.

Document History
Author : Lakshmi Nilacantan Create Date 01-MAR-2009 Update Date 07-MAY-2009

R12 Payment Process Request - Functional and Technical Information

Payment Process Requests

Overview
Under Funds disbursement page, users can submit Payment Process Requests (PPR) to generate payments. There is an option to submit a single Payment Process Request or schedule Payment Process Requests. There are four steps in the processing of a PPR. a) Document selection b) Build Payments c) Format Payments d) Confirm Payments Document selection and Confirm Payments are handled by Payables (AP) code while Build Payments and Format payments are handled by Payments (IBY) code.

Submitting a Single Payment Process Request

Mandatory Fields - Payment process request name, pay through date Under Payment Attributes tab Payment Date, Payment Exchange rate type. Payment Process Profile and Disbursement bank account are optional fields. Under Processing tab, options are available to stop the process after document selection / payment and also how to create Payment Instruction. Under Validation Failure Results tab, choose option that best suits the business needs regarding how to handle validation failure on document(s) or payment(s). Click on Submit to submit the Payment process request.

Document Selection Payables

Code: AP_AUTOSELECT_PKG When a Payment Process request is submitted, a record is created in AP_INV_SELECTION_CRITERIA_ALL with a checkrun_name which is the same as the payment process request name. Payment Profile and Internal Bank Account from which payments have to be made do not have to be specified during invoice selection. User who submits the PPR does not need know this information. These values can be provided by at a later stage by a Payments Manager or Administrator. Selection: Invoices are then selected based on due date, discount date, paygroup and other criteria provided by the user while submitting the PPR. The selection process is handled by the calling product The table AP_SELECTED_INVOICES_ALL is populated with selected invoices. AP_UNSELECTED_INVOICES_ALL is populated with unselected invoices. Locking: After selecting the documents, the invoices are locked to prevent other check runs from selecting the same invoices. AP_PAYMENT_SCHEDULES_ALL.checkrun_id is populated on the selected documents. Review: If the Payment Process Request has been setup to Stop Process for Review After Scheduled Payment Selection, the process stops for user review. The status of the PPR is set to Invoices Pending Review. If the Stop Process for Review After Scheduled Payment Selection was not enabled, at the end of invoice selection, build program is submitted automatically. If no invoices met the selection criteria and no payment schedules selected for payment, the PPR is cancelled automatically and the status of the PPR is set to Cancelled - No Invoices Selected If user review required, after the user reviews the selected payment schedules and clicks on Submit, AP calls the IBYBUILD program. Valid Statuses and actions At the end of this step, the valid statuses are a) Invoices Pending Review or b) Cancelled - No Invoices Selected or c) Other statuses from missing information such as Missing Exchange rates If PPR status is Cancelled-No Invoices Selected, there are no valid actions available. For others, the actions available are a) Terminate the PPR or

b) Modify / proceed to submit the PPR and start the build process.

Build Payments - Payments

Code: IBY_DISBURSE_SUBMIT_PUB_PKG Build Payments creates record in IBY_PAY_SERVICE_REQUESTS with call_app_pay_service_req_code = checkrun_name. Primary Key: PAYMENT_SEVICE_REQUEST_ID Key Columns: CALL_AP_PAY_SERVICE_REQ_CODE -> PPR name CALLING_APP_ID PAYMENT_SERVICE_REQUEST_STATUS INTERNAL_BANK_ACCOUNT_ID MAXIMUM_PAYMENT_AMOUNT MINIMUM_PAYMENT_AMOUNT DOCUMENT_REJECTION_LEVEL_CODE PAYMENT_REJECTION_LEVEL_CODE REQUIRE_PROP_PMTS_REVIEW_FLAG CREATE_PMT_INSTRUCTIONS_FLAG Note: The displayed status of the PPR is generated by ibyvutlb.pls There is a get_psr_status function that derives the display sttaus of the PPR on the dashboard. Some of the values for PAYMENT_SERVICE_REQUEST_STATUS in the table are PAYMENT_SERVICE_REQUEST_STATUS -----------------------------DOCUMENTS_VALIDATED INFORMATION_REQUIRED INSERTED PAYMENTS_CREATED PENDING_REVIEW TERMINATED VALIDATION_FAILED The build program populates the IBY_DOCS_PAYABLE_ALL table with the payments. Link to the payment service request table is through PAYMENT_SERVICE_REQUEST_ID. Key Columns: Payment_service_request_id Calling_app_doc_ref_number -> invoice_number Document_payable_id Document_status Payment_currency_code Payment_amount Document_amount Exclusive_payment_flag Payment_method_code Payment_id Formatting_payment_id Ext_payee_id Payee_party_id Payment_profile_id Internal_bank_account_id Calling_app_doc_unique_ref2 -> invoice_id Calling_app_doc_unique_ref3 -> payment number

a) Internal Bank Account/Payment Process Profile Assignment: Code: IBY_ASSIGN_PUB If the payment process request has the internal bank account and payment profile assigned to it, the same is assigned to all the documents in the PPR. If a default internal bank account and PPP were not provided when submitting the PPR, Oracle Payments attempts to default the values. If it cannot find a default value for all the documents, the PPR is set to INFORMATION REQUIRED status. The display status of the PPR is Information Required - Pending Action User should complete the missing information and Run Payment Process to continue. b) Document Validation Code: IBY_VALIDATIONSETS_PUB During this step, Oracle Payments validates all the documents using Payment Method based validations and then payment format based validations.. b.1 - If all the documents pass validation, all the documents are set to a status of VALIDATED and the request status is set to Documents Validated. b.2 If there are any validation failures, Oracle Payments uses the system option used while submitting the PPR to determine the next action. The DOCUMENT_REJECTION_LEVEL_CODE of the PPR can have the following values which determine how the document processing will continue when there is a validation failure REQUEST - Reject all documents in this PPR DOCUMENT - Reject only the document in error PAYEE - Reject all the documents related to the supplier NONE - Stop the request for review b.2.1 REQUEST The status of the payment process request is updated to Failed Document Validation. Oracle Payments calls the calling application and AP releases the rejected documents so they can be paid through another Payment process request. b.2.2 DOCUMENT Oracle Payments rejects all documents that failed validation. Oracle Payments then calls the calling application and AP releases the rejected documents so they can be paid through another Payment process request. The rest of the documents are set to VALIDATED status and the ppr is set to Documents Validated status. b.2.3 PAYEE Oracle Payments rejects all documents for the supplier that had one or more documents that failed validation. Oracle Payments calls the calling application and AP releases the rejected documents so they can be paid through another Payment process request. The rest of the documents are set to VALIDATED status and the ppr is set to Documents Validated status. c) Create Payments Code: IBY_PAYGROUP_PUB The validated documents are then grouped into proposed payments based on the grouping rules, both user defined and hard coded. Example: If exclusive_payment_flag = Y on a document, its paid on a separate payment. It then numbers the payments (internal identifier not the check numbering) and validates the created payments. Records are inserted into IBY_PAYMENTS_ALL that holds the payment information for the selected

documents. The build program then updates the IBY_DOCS_PAYABLE_ALL table with the payment_id and formatting_payment_id values that corresponding to the payment that pays the document. IBY_PAYMENTS_ALL links through payment_service_request_id. Key Columns: Payment_service_request_id Payment_id Payment_method_code Payment_status Payments_complete_flag Payment_amount, Dicount_amount_taken Internal_bank_Account_id Ext_payee_id Payment_instruction_id Payment_profile_id Void_date The PAYMENT_REJECTION_LEVEL_CODE can have the following values which determine how the payment processing will continue when there is a validation failure REQUEST Reject all payments in the request PAYMENT Reject only those payments in error NONE Stop the request for review Request Entire PPR is rejected. Oracle Payments raises a business event that calls AP to release the documents. The status of the payment process request and proposed payments is updated to REJECTED. Payment Payments that failed validation are rejected and AP releases the documents that belong to the payment that failed validation. The other payments are accepted. The accepted payments get a status of CREATED. None Payments that failed Validation are set to Failed Validation and allows for user intervention. Status of the PPR is set to PENDING REVIEW If in the PPR setup, Stop Process for Review After Creation of Proposed Payments is enabled, the PPR status is set to Pending Proposed Payment Review. This status prevents further processing until user takes action. If this option to stop for review is not enabled, the status of the PPR is set to Payments Created. In this status, payment instruction can be created for the PPR.

Format Payments - Payments

Code: IBY_PAYINTSR_PUB, IBY_CHECKNUMBER_PUB When a PPR is submitted, there are two options The CREATE_PMT_INSTRUCTIONS_FLAG can be a Y or N Y Payment Instruction will be automatically created after payments are created. N Application waits for standard request submission for Payment Instruction. IBY_PAYMENT_INSTRUCTIONS_ALL stores the payment instruction information. If the PPR is setup to automatically submit instruction, the payment_service_request_id will be populated in iby_payment_instructions_all because the instruction will be specific to the PPR In this case, the instruction can be linked to the PPR using PAYMENT_SERVICE_REQUEST_ID If the PPR processing is setup for the user to submit the instruction as a standard request, then when

the instruction is submitted, then the instruction is linked to the PPR through the payments selected by the instruction. The link in this case will be through iby_payments_all.payment_instruction_id

Key Columns in IBY_PAYMENT_INSTRUCTIONS_ALL Payment_instruction_id Payment_profile_id Payment_instruction_status Payments_complete_code Payment_count Print_instruction_immed_flag Transmit_instr_immed_flag Internal_bank_account_id Payment_document_id Payment_date Payment_reason_code Payment_currency_code Format: The following processing occurs during the format step. a) Number the payments Check Numbering b) Create XML Extract message c) Pass the extract to XML publisher d) Oracle XML Publisher (BI publisher) applies the format template e) BI publisher formats and stores the output f) Oracle Payments then updates the status of the Payment Instruction and the Payments. If successful, the status of Payments and Instruction is Formatted. Print Checks: a) Users can load stationery into the printer and print checks at this stage. b) Determine if the checks printed ok. If not reprint

Confirm Payments - Payables

Code: AP_PMT_CALLOUT_PKG Record Print Status of the checks to confirm the payments. Oracle Payments calls ap_pmt_callout_pkg.payment_completed to confirm the payments. This does the following: a) Assigns sequence/values Document sequencing. b) Creates data in AP_CHECKS_ALL with appropriate data from IBY tables. Checkrun_name = ppr name and checkrun_id = checkrun_id from IBY table. c) Data inserted into AP_INVOICE_PAYMENTS_ALL for the corresponding checks. d) AP_PAYMENT_SCHEDULES_ALL for the invoices are updated to indicate the payment details and status. e) The documents paid in this PPR are released by setting the checkrun_id on the payment schedules to null. f) AP_INVOICES_ALL is udpated to show payment status g) Data is deleted from the AP_SELECTED_INVOICES_ALL h) Data is deleted from AP_UNSELECTED_INVOICES_ALL

R12 Payment Batch FAQs [ID 579383.1]

Modified 10-NOV-2008

Type FAQ

Status PUBLISHED

In this Document Purpose Questions and Answers Payment Batch 1. What is the Payables Payment Batch Data Gathering Script? 2. Why doesn't Scheduled Payment Requests Select Any Invoices? 3. Why can't I Void a Payment Document After Upgrade to R12? 4. Why does the Payment Process Request Show Currency Amounts with "PT" Characters? 5. Why does the Status of the Payment Process Request Incorrectly show Formatting? 6. Why doesn't Scheduled Payment Process Request Select any Invoices? IMPORTANT References

Applies to:
Oracle Payables - Version: 12.0.0 to 12.0.5 Information in this document applies to any platform.

Purpose
The purpose of this document is to provide 'FAQs' for the Payment Batch topic.

Questions and Answers Payment Batch 1. What is the Payables Payment Batch Data Gathering Script?
This test gathers all the information related to a single payment batch. This test is only to be used during problem diagnosis, when instructed by Oracle support. See Note 416706.1 for more information.

2. Why doesn't Scheduled Payment Requests Select Any Invoices?

Cause: Bug 6926344 SCHEDULED PPR SELECTS NO INVOICES Tables AP_CURRENCY_GROUP and AP_PAY_GROUP are not populated when scheduled PPR is being executed therefore if the template had a currency or pay group specified the request is marked as having specific currencies or pay groups but there is no list to compare them to. The fix for this bug is included in appbselb.pls is 120.43.12000000.17, available in unpublished patch 6926344 (This patch is available through controlled release. Please contact support for assistance

with obtaining the patch.) See Note 566290.1 for more information.

3. Why can't I Void a Payment Document After Upgrade to R12?

Cause: Bug 6312110 Unable To Void A Payment Document - Frm-40654: Record Has Been During the upgrade any check stock with a custom payment format is not upgraded. Since the check is associated with a check stock that is not there the void cannot be completed. The fix for this bug is included in apichecb.pls 120.11.12000000.3, available in Patch 6312110. Alternately apply the latest Rup patch identified in Note 423541.1. See Note 457529.1 for more information.

4. Why does the Payment Process Request Show Currency Amounts with "PT" Characters?
Cause: Bug 6350666 AMOUNT VALUE IS APPENDED WITH 'PT' IF NEGATIVE CURRENCY PROFILE IS '(XXX) (This bug is unpublished and unavailable via MetaLink.) In release 12 the currency amount value is appended with "PT" when the profile value Currency: Negative Format parameter is set to '(XXX)': Bug 6350666: AMOUNT VALUE IS APPENDED WITH 'PT' IF NEGATIVE CURRENCY PROFILE IS '(XXX)'. (Bug 6350666 is unpublished and unavailable on MetaLink.) The fix for this bug is included in CurrencyHelper.java 120.0.12000000.2, available in Patch 6350666. See Note.465074.1 for more information.

5. Why does the Status of the Payment Process Request Incorrectly show Formatting?
Cause: The status of the PPR as shown in the User Interface is a derived status based on the statuses of the different payments in the PPR. Payments that have a FAILED_VALIDATION status, the derived PPR status incorrectly showed Formatting status. Any payment that failed validation and was rejected should be set to REJECTED status: Internal Bugs 6686639 and 6709700 GSIAP R12 PAYMENT PROCESS REQUEST STATUS IS WRONG EVEN IF THE PAYMENT IS CREATED: The fix for this issue is included in Patch 6686639 (This patch is available through controlled release. Please contact support for assistance with obtaining the patch.) Alternately apply the latest Rup patch identified in Note 423541.1. See Note 550504.1 for more information.

6. Why doesn't Scheduled Payment Process Request Select any Invoices?

Cause: When submitting a Payment Process Request, the Format and Payment Document for the Payment Process Profile does not match the Internal Bank account. The format and document in Payment Process Profile (PPP) used in PPR should match with what is setup for the internal bank account. -- To implement the solution, please execute the following steps: First, check what Format is set in Internal Bank. Navigation: Setup -> Payment -> Bank Accounts 1) Query on the Bank Account 2) Select the Account Name then Click on Manage Payment Documents 3) Under Payment Document, it will list the Payment Document and the Format for this bank account Then, check what is set up in Payment Process Profile. Navigation: Setup -> Payment -> Payment Administrator 4) Query on the Payment Process Profile (PPP) that you're using in Payment Process Request (PPR). 5) Click on Update. 6) Then go to Payment Instruction Format tab, check the value of Payment Instruction Format field. The value should be the same Format used in the bank account above. See Note 577692.1 for more information.

IMPORTANT
If you did not find the information you were searching for, please review the following Payables documents: Note 578232.1 R12 Proactive Intelligence Center: Oracle Payables Note 396084.1 Oracle Payables Documentation Resources, R12 Note 562887.1 R12 Helpful Tips for a Successful R12 Oracle Payables Implementation Note 557869.1 EBS R12 Oracle Financials Critical Patches Note 405627.1 Oracle Payables Release 12 Known Issues Additional R12 documents: Note 580299.1 R12 Best Practices for Adopting Oracle E-Business Suite Note 461705.1 EBusiness R12 Upgrade Guide Note 602615.1 How to Locate the Latest R12 Product-Specific Information using New MetaLink Features

References
BUG:6926344 - EMEA:ACT:R12:SCHEDULED PPR SELECTS NO INVOICES NOTE:416706.1 - Payables Payment Batch Data Gathering NOTE:465074.1 - Payment Process Request Shows Currency Amounts With "PT" Characters NOTE:550504.1 - Incorrect Status of the Payment Process Request shows Formatting NOTE:566290.1 - Scheduled Payment Requests Do Not Select Any Invoices NOTE:577692.1 - R12: Scheduled Payment Process Request Selects No Invoices