Master Troubleshooting Guide For Payment Process Requests

In this Document
Purpose
Troubleshooting Steps
1. What is a Payment Process Request (PPR), and How Are PPRs Created and Managed?
What is a PPR?
How is a new PPR submitted?
Modifying Payment Process Requests
Terminating Payment Instructions
Stopping & Voiding Completed Payments
PPR Templates
Scheduling PPRs using PPR Templates
Required Setups
Printing Checks
"Skipped" and "Spoiled" Check Numbers

2. How does the PPR Process work?
DOCUMENT SELECTION ("AUTOSELECT")
BUILD PAYMENTS
FORMAT PAYMENTS
CONFIRM PAYMENTS

3. PPR Reports: There are several reports related to PPR processing

4. PPR Process STATUSES and What They Mean

5. Alternatives to using Payment Process Requests

6. Data/Function Security for PPRs

7. Diagnostic Tools

8. Identifying What Went Wrong and Finding a Solution
ISSUES INVOLVING AN ERROR MESSAGE:
ISSUES NOT INVOLVING AN ERROR MESSAGE:

9. CRITICAL: RPCs (Recommended Patch Collections) for Oracle Payables

10. HOT TOPICS:
a. What to do when a PPR gets "stuck"
b. What to do when invoices get "stuck" with the Status "Selected for Payment"
c. What to do when you are unable to terminate a PPR

11. Troubleshooting Issues within the Individual Steps of an PPR process
AUTOSELECT
BUILD PAYMENTS
FORMAT PAYMENTS
R12: Master Troubleshooting Guide for Payment Process Requests (PPRs) for Oracle
Payables [VIDEO] [ID 1305001.1]
To Bottom
Modified: Apr 16, 2013 Type: TROUBLESHOOTING Status: PUBLISHED Priority: 1 Comments (0)
Document 1305001.1 https://support.oracle.com/epmos/faces/DocContentDisplay?_afrLoop...
1 of 17 11/6/2013 11:30 AM
CONFIRM PAYMENTS
PAYMENT REPORTS

12. Environment Issues: Performance, Hardware, Database, Memory or other peripheral issues

13. Logging a Service Request

Standard Patching Process
Patch Wizard
Have more questions?
References
Applies to:
Oracle Payments - Version 12.0.0 and later
Oracle Payables - Version 12.0.0 and later
Information in this document applies to any platform.
AP_AUTOSELECT_PKG
IBY_DISBURSE_SUBMIT_PUB_PKG
IBY_ASSIGN_PUB
IBY_VALIDATIONSETS_PUB
IBY_PAYGROUP_PUB
IBY_PAYINSTSR_PUB
IBY_CHECKNUMBER_PUBAP_PMT_CALLOUT_PKG
Purpose

This Note is intended to teach you about the processes involved in completing a Payment Process Request (PPR), and to guide
you through a set of sequential steps that will help to facilitate troubleshooting PPR issues in Release12.
SCROLL UP TO SEE TABLE OF CONTENTS
Troubleshooting Steps
1. What is a Payment Process Request (PPR), and How Are PPRs Created and Managed?
What is a PPR?
In R12, a Payment Process Request, or "PPR", is a payment batch. The Payment Batch entry form used in R11i has been replaced
in R12 by a new module called the Payments Manager module (IBY), which offers a number of new features related to payment
batch processing.
Oracle Payments User's Guide, Release 12.1
(Part No. E13415-04), August 2010
Page 5-1:
"To present a simplified overview of the Oracle Payments payment process:
1. The process begins when a source product, such as Oracle Payables, needs to pay "documents
payable", such as invoices [and memos].
2. Oracle Payables groups the documents payable into a "payment process request" [a batch for
payment] and submits it to [the] Oracle Payments [module].
3. Within [the payment process request], the Build Payments program groups [the] documents payable
into groups known as ["proposed] payments", which represent individual checks or electronic
[payments].
4. The Create Payment Instructions program groups [the proposed] payments into "payment
2 of 17 11/6/2013 11:30 AM
instructions". Payment instructions are then printed or submitted electronically to payment systems or
banks.
The process described above applies whether the payment was created using the Payments Workbench in AP, or as part
of a Payments Request Process (PPR) created in the Payments module (IBY).

How is a new PPR submitted?
Using the Submit a Single Request link on the Payments Manager Dashboard (or the button on the Search PPRs window), users are
taken to a PPR entry form made up of a header and several tabbed regions. Users can enter search criteria for the invoices they
want to pay, and parameters surrounding the payment process itself using the fields on the tabbed regions.
See the Oracle Payables Users Guide > Chap 5 > Creating Multiple Payments for more information.
See Note 1307420.1 R12: How to Submit a New Payment Process Request (a "payment batch") for detailed instructions.
FYI...to see a PPR process in action, click here to see the "R12 Payables Payments Process Requests - an Overview"
webcast (originally broadcast on August 9, 2011), which shows a PPR being entered, submitted, and processed -- including a
review of all the associated concurrent programs spawned by the PPR processing! You can also download a copy of the
webcast from Note 740964.1: Advisor Webcast Archived Recording.

Modifying Payment Process Requests
You can modify the batch of invoices that the system selected for you, and the proposed payments generated by the system, using
"review" windows along the course of the PPR process. These review "stops" are optional. When creating a new PPR, you can set
parameters on the Processing tab that will cause the PPR process to stop after: 1) the system initially selects the invoices to be
paid by the batch, and/or 2) after the PPR process has compiled the "proposed payments". This gives you an opportunity to review
(and if necessary, modify) the invoices and "proposed" payments before they are turned into formatted Payment Instructions.
See the Oracle Payables Users Guide > Chap 5 > Reviewing Selected Invoices (under the sub-section Initiating Payment
Process Requests) for more information.
See Note 462791.1 for detailed instructions.

Terminating Payment Instructions
You can terminate a set of Payment Instructions at any time prior to marking the payments "Complete" - even if they have been
printed - by using the Terminate icon on the Payment Instructions tab on the Payments Manager Dashboard. When this action is
taken, Oracle Payments sets the status of the payment instruction to "Terminated", and informs the source product of the
terminated documents payable. Then for each payment in the payment instruction, Oracle Payments sets the status to "Canceled".
The source product unlocks the documents and resets their status so they are ready for future selection
See Oracle Payments Users Guide > Chap 4 > Action 3: Terminate Payment Process .

Stopping & Voiding Completed Payments
You can record a "Stop Payment" action or a "Void" action on one or more completed payments using the Payments tab on the
Payments Manager Dashboard.
See Oracle Payments Users Guide > Chap

PPR Templates
To make entry of a new single PPR faster and easier, you can create a PPR"Template" with the search criteria and parameters that
you typically use on your PPRs. Then when creating a new PPR, simply enter the name of the template in the header, and the
pre-defined settings on the template are automatically copied to the fields on the header of your new PPR for you! You can accept
the defaulted values, or edit them for the new PPR
See the Oracle Payables Users Guide > Chap 5 > Creating Payment Process Request Templates for more information
See Note 1312158.1 R12: What are PPR Templates, and how can I create and use them?
3 of 17 11/6/2013 11:30 AM

Scheduling PPRs using PPR Templates
You can use the name of a PPR Template as the Request Name on the Schedule Payment Process Request form in the Payments
Manager module, allowing users to schedule PPRs to run automatically on a periodic basis, such as once/multiple times a day,
once/multiple times a week, once/multiple times a month, etc. The scheduling parameters are generally the same as for scheduling
Oracle Reports or other processes
See the Oracle Payables Users Guide > Chap 5 > Creating Payment Process Request Templates for more information
See Note 1312158.1: R12: What are PPR Templates, and how can I create and use them?

Required Setups
To maximize all the features available in creating Payment Process Requests (and to minimize the possibility of issues), you will
want to become familiar with both the required and recommended setups that are necessary before running your first PPR. Some
setups in the Payments module (IBY) are common to both the Funds Capture (receipts) and the Funds Disbursement
(payments) roles that the module provides. They include:
access control
APIs
servlets
transmission
security
Configurable setups include:
Payment Methods
Bank Instruction Codes
Delivery Channel Codes
Payment Reason Codes
Payment Process Profiles ("PPPs")
Disbursement System Options
Payment Formats
XML Publisher Payment Templates
Internal Banks, Branches, and Bank Accounts
Suppliers
External Bank Accounts
See Note 1358208.1: R12: Oracle Payables Payments Setup Guide for complete details on how to enter and manage your
Payables Payments setups.

Printing Checks
Before printing checks the first time, be sure to review the information found in:
Note 312353.1: Check Printing Using XML
Note 1353280.1: R12: Master Troubleshooting Guide for Oracle Payables Check Printing issues
Note 1348102.1: R12: Master Troubleshooting Guide for Oracle Payables Payment Formats & associated XML Publisher
Templates
Note 819066.1: How To Get An XML File To Use For Developing Custom Templates For Check Printing
Note 1068527.1: R12 How to Control the Sort Order of Payments in AP Payment Batch Format Output Files
"Skipped" and "Spoiled" Check Numbers
Skipped Check Numbers: If you use pre-numbered paper check stock when running a Payment Process Request ("PPR")
in R12, you may have experienced a common issue faced by most Payment Administrators -- skipped checks during the
printing process (most often when the batch was printed using a laser printer). That is, one or more unused checks get
"stuck" to the check above it in the feeder bin, and slip through the printing process unprinted. When that happens, the
check numbers that were actually printed and the check numbers that appear on the related payment reports are no longer
in-sync with one another. It's important that the system is informed of these "skipped" check numbers as soon as possible so
your reports will reflect appropriate check numbers, and the Last Issued Document Number field on the Define/Update
4 of 17 11/6/2013 11:30 AM
Payment Documents window for the associated Bank Account is properly updated as well. Use the Skipped Payment
Documents region on the Record Print Status window to manually enter the skipped check numbers before you confirm the
PPR.
Spoiled Check Numbers: Another common issue that Payment Administrators often face is the dreaded "spoiled" check
during a printing process. A "spoiled" check is when your printer "eats up" (physically destroys) a payment document as it
goes through the printing process -- usually causing the printer to stop until you remove the mangled document, and re-start
the printer. "Spoiled" checks can actually be defined as ANY unuseable paper payment documents (checks) that have become
unuseable for ANY reason (for instance, perhaps one of your boxes of unused checks was destroyed due to a flood or fire).
So printer jams aren't the only cause for "spoiled" checks -- but they are the most common. It's important that the system is
informed of these "spoiled" check numbers as soon as possible, so your reports will reflect appropriate check numbers, and
the Last Issued Document Number field on the Define/Update Payment Documents is properly updated as well. Spoiled
checks can be marked as "spoiled" in Oracle by either: 1) reprinting a replacement check for the supplier/creditor in the same
PPR before confirming the PPR, or 2) manually marking the check number as "spoiled" on the Spoiled Payment
Documents region of the Record Print Status window, and then paying the supplier/creditor on a later PPR or Quick Payment.
See Oracle Payments Users Guide > Chap 5
Return to Table of Contents

2. How does the PPR Process work?
Once the user has entered their desired parameters on the header of the PPR, and clicks on the Submit button, the PPR process
follows the following four (4) program steps:

DOCUMENT SELECTION ("AUTOSELECT")
(Code: AP_AUTOSELECT_PKG): The Selection process is handled by Payables (AP), the calling product.
When a PPR is submitted, a record is created in AP_INV_SELECTION_CRITERIA_ALL with a checkrun_name, which is the same as
the PPR Name.
Selection: Invoices are then selected based on Due Date, Discount Date, Pay Group, and other criteria provided by the
user while completing the PPR header.
The table AP_SELECTED_INVOICES_ALL is populated with selected invoices.
The table AP_UNSELECTED_INVOICES_ALL is populated with the invoices that were not selected.

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 (invoices).

Review:If the PPR has been setup to Stop Process for Review After Schedule Payment Selection (option available on the
header of the PPR), the process stops for user review after the initial selection of payables documents has been
completed. The status of the PPR is set to "Invoices Pending Review". After the user reviews and/or modifies the selected
documents, and clicks on the Submit button, AP calls the IBYBUILD program.
If the Stop Process for Review After Schedule Payment Selection parameter was not enabled, then at the end of
invoice selection, the Build program is submitted automatically.
If no invoices met the selection criteria, the PPR is canceled automatically and the status of the PPR is set to
"Canceled - No Invoices Selected".

BUILD PAYMENTS
(Code: IBY_DISBURSE_SUBMIT_PUB_PKG): The Build Payments process is handled by Oracle Payments (IBY).
5 of 17 11/6/2013 11:30 AM
The Build Payments program first creates a record in IBY_PAY_SERVICE_REQUESTS with call_app_pay_service_req_code =
checkrun_name.
The Build Payments program goes on to populate the IBY_DOCS_PAYABLE_ALL table with the proposed payments.
The link to the payment service request table is through the PAYMENT_SERVICE_REQUEST_ID.
Internal Bank Account / Payment Process Profile Assignment(Code: IBY_ASSIGN_PUB): If the PPR has a default
internal bank account and Payment Process Profile (PPP) assigned to it on the header of the PPR, the values are assigned
to all of the selected documents in the PPR.
If a default internal bank account and PPP were not provided by the user on the header of the PPR, Oracle
Payments attempts to default the values. If it cannot find a default value for all of the selected documents, the PPR
status is set to "INFORMATION REQUIRED". The user display shows it as "Information Required - Pending Action".
The user will need to use the Information Required window to provide the missing internal bank account(s) and
PPP(s) for each selected document.
Document Validation (Code: IBY_VALIDATIONSETS_PUB): During this step, Oracle Payments validates all the
documents (selected invoices & memos) using Pre-Defined and User-Defined Validations assigned to Payment Methods
assigned to the selected documents. Afterward, the program validates all the documents again, using the Pre-Defined and
User-Defined Validations assigned to Payment Formats associated with the PPPs specified on the PPR.
If all the documents pass validation, all the documents are set to a status of VALIDATED in the tables and the request
status is displayed as "Documents Validated".
If there any document validation failures, Oracle Payments uses the parameter setting for "Documents" on the Validation
Failure Results tab on the PPR header (the DOCUMENT_REJECTION_LEVEL_CODE) to determine the next action.
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 PPR for review
For more information about VALIDATIONS, see Document 1384297.1 R12: Payments Grouping and Validations
Explained
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. It then numbers the proposed payments with an internal identifier
(not "the" check number) and validates the payments.
For more information about GROUPING, see Document 1384297.1 R12: Payments Grouping and Validations
Explained
Records are inserted into IBY_PAYMENTS_ALL that holds the payment information for the selected documents
(invoices). The Build Payments program then updates the IBY_DOCS_PAYABLE_ALL table with the payment_id and
formatting_payment_id values of the payment associated with each document.
If there any payment validation failures, Oracle Payments uses the parameter setting for "Payments" on the
Validation Failure Results tab on the PPR header (the PAYMENT_REJECTION_LEVEL_CODE) to determine the next
action.
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 PPR for review
If the PPR setup Stop Process for Review After Creation of Proposed Payments is enabled on the Process tab of the
PPR header, the displayed PPR status is set to "Pending Proposed Payment Review". This status prevents further
processing until user takes action.
If this option to stop for a review is not enabled, the displayed status of the PPR is set to "Payments Created". In
this status, payment instructions can be created for the PPR.

FORMAT PAYMENTS
6 of 17 11/6/2013 11:30 AM
(Codes: IBY_PAYINTSR_PUB, IBY_CHECKNUMBER_PUB): The Format Payments process is handled by Oracle Payments (IBY).
When a PPR is submitted, the program checks the setting for the Create Payment Instructions parameter on the Process tab of the
PPR header to determine if the associated payment instruction(s) (PI) should be created automatically after the payments are
created (the CREATE_PMT_INSTRUCTIONS_FLAG = Y), or if the program is to wait for a manual kick-off of the Format Payment
Instructions program through the Standard Request Submission form (SRS) (the CREATE_PMT_INSTRUCTIONS_FLAG = N).
If the PPR is set up to automatically submit instruction(s), 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(s) can
be linked to the PPR using PAYMENT_SERVICE_REQUEST_ID.
If the PPR is set up for the user to submit the instruction program manually on the SRS form, then when the instruction(s)
is submitted, the instruction(s) is linked to the PPR through the payments selected by the instruction(s). The link in this
case will be through the payment_instruction_id in IBY_PAYMENTS_ALL.
In addition, the following processing occurs during the Format Payments step (see The Extract and Format Operation Flow section
in Note 1348102.1 "R12: Master Troubleshooting Guide for Oracle Payables Payment Formats & associated XML Publisher
Templates"):
Number the payments (paper checks and possibly, electronic payments)
Create XML extracted message
Pass the extract to Oracle XML Publisher (also known as "BI Publisher")
XML Publisher applies the formatted template to the payments
XML Publisher formats and stores the output
Oracle Payments then updates the status of the Payment Instruction(s) and the PPR. If successful, the displayed status of
the PPR is "Formatted", and the status of the Payment Instruction(s) will be "Formatted" for electronic payments and
"Formatted - Ready for Printing" for check payments
Print checks:
Users can load stationery into the printer and print checks at this stage by clicking on the Take Action icon for the
related Payment Instruction on the Search PPRs window.
Determine if the checks printed OK, and if so, click on the Take Action icon again to be taken to the "Record Print
Status" window, and click on the Record Print Status button. If there were problems with the printing process
(paper jams, skipped checks, etc.) -- especially if you are using pre-numbered check stock -- use the Reprint button
to reprint the batch and record any spoiled (ruined) and/or skipped check numbers.
Transmit electronic payments:
Electronic payments can be transmitted at this point.

CONFIRM PAYMENTS
(Code: AP_PMT_CALLOUT_PKG): The Selection process is handled by Payables (AP).
In order to confirm the printing of paper checks, the user needs to use the Record Print Status window to confirm which
pre-numbered paper stock printed OK, and which (if any) were skipped or were damaged beyond repair ("spoiled").
Oracle Payments calls ap_pmt_callout_pkg.payment_completed to confirm the payments. During this step, the program does the
following:
Assigns sequence values for Document Sequencing (Vouchering).
Creates data in the AP_CHECKS_ALL table with the appropriate data from the IBY tables.
Inserts data into the AP_INVOICE_PAYMENTS_ALL table for the corresponding checks.
The documents (invoices) are updated in the AP_PAYMENT_SCHEDULES_ALL table to indicate in the Invoices Workbench
the payment details and status.
The documents not paid in this PPR are released by setting the checkrun_id on the Payment Schedules to NULL.
The AP_INVOICES_ALL table is updated to show the payment status in the Invoices Workbench for those documents that
were paid by the PPR.
Data for this PPR is deleted from the AP_SELECTED_INVOICES_ALL table.
Data for this PPR is deleted from the AP_UNSELECTED_INVOICES_ALL table.
"Completing" Electronic Payments: Electronic payments are not "confirmed" in the same way that paper documents are
handled. The system will automatically mark electronic payments as "completed" based on the setting you chose for the
"Completion Point" field on the header of the associated Payment Process Profile (PPP):
"Built" = the payments will be marked as "complete" when the Build process completes
"Payment Instruction is Created" = the payments will be marked as "complete" when the PI is created
Payment Instruction is Formatted" = the payments will be marked as "complete" when the PI has successfully completed
the Formatting process
"Payment Instruction is Transmitted" = the payments will be marked as "complete" when they are transmitted"

For more information about the four PPR process steps and related reports, see Note 821133.1 R12 Payment Process Request -
Functional and Technical Information
7 of 17 11/6/2013 11:30 AM
To find more information about creating Payment Process Requests (PPRs), review:
Chapter 4: "Funds Disbursement Process Flows" in the Oracle Payments Users Guide
Chapter 5: "Funds Disbursement Process Home Pages" in the Oracle Payments Users Guide
Chapter 3: "Understanding Oracle Payments" > "Understanding Funds Disbursement" section in the Oracle Payments
Implementation Guide
NOTE: Check for the version of the Oracle Payables User Guide that is specific to your version of the E-Business Suite
applications by looking for your apps version (i.e., R12, R12+, R12.1, R12.1+, etc.) on the Oracle Documentation Library List,
then click on the link for your version, and then click on the Documentation tab.
After the documentation library opens, scroll down the menu on the left until you find the Financials section (for R11.5.10
through R12.1.1), or the Financial Management section (for R12.1.1+ through R12.1.3).
Under the Financials section name, search for a link to "Financials" and click on it. Then search on the right side of the
screen for the link for the Oracle Payables Users Guide, and click on it.
Under the Financial Management section name, search for "Procure to Pay (Payables)" and click on it. Then search on
the right side of the screen for the link for the Oracle Payables Users Guide, and click on it.
3. PPR Reports: There are several reports related to PPR processing
Payment Process Request Status Report: The Payment Process Request Status Report is a report that you can run
that displays proposed payment information. You can request the report to run automatically after proposed payments
have been created and validated or run the report by standard report submission. The report provides parameters, such as
the Payment Process Request name/identifier and runs if the Payment Process Request status is "Payments Created".
Payment Instruction Register: Once a payment instruction has been formatted, payments within that payment
instruction can be reviewed in report format. The Payment Instruction Register can be run at any time after payment
instruction creation. The report lists the various statuses of payments within the payment instructions, such as Formatted
or Transmitted.
Separate Remittance Advice:The Separate Remittance Advice is a report sent to a payee that lists the documents
payable paid as part of each payment. You can specify the format for the remittance advice document and the delivery
method.
Positive Pay: A positive pay file is a security measure in the form of a document that the deploying company sends to its
payment system or bank to inform it of payments made by check. When you print checks, then you can electronically
transmit a list of payments to the bank or payment system that indicates the checks you printed, so the bank or payment
system knows what checks to pay. This list prevents the payment system or bank from paying fraudulent checks, since
such checks are not listed on the positive pay file.
R12 Oracle Payments offers two versions of the Positive Pay report:
the Positive Pay File program, and
the Positive Pay File with Additional Parameters program.These programs replace the R11i report called the Positive
Pay Report.
To see samples of these reports, plus samples and descriptions of more seeded payments-related reports, see: Section
5: Payments Reports on Note 1320497.1 R12: Master Troubleshooting Guide for Issues in the (AP) Payments
Workbench.


4. PPR Process STATUSES and What They Mean
As a Payment Process Request transitions through the different stages of processing, the PPR will display a "Status" to let you
know where in the process the PPR has progressed to, and what's going on with it.
Per Note 821133.1 "The displayed status of the PPR is generated by ibyvutlb.pls. There is a get_psr_status function that
derives the display [status] of the PPR on the dashboard."
8 of 17 11/6/2013 11:30 AM
FYI...to see a PPR process in action, click here to see the "R12 Payables Payments Process Requests - an Overview"
webcast (originally broadcast on August 9, 2011), which shows a PPR being entered, submitted, and processed --
including a review of all the associated concurrent programs spawned by the PPR processing! You can also download a
copy of the webcast from Note 740964.1: Advisor Webcast Archived Recording.
The list below is not a comprehensive list of EVERY possible Status that may appear on a PPR (or on its associated Payment
Instruction file(s)), but it does include the statuses most commonly encountered:
NEW:
This status indicates that the PPR has been successfully submitted for processing, and the AutoSelect program is
digesting the criteria provided by the user on the header of the PPR in preparation of the automatic selection the
invoices and memos related to that criteria.
SELECTING INVOICES:
This status indicates that the AutoSelect program is selecting the eligible invoices/memos for the payment batch
based on Due Date, Discount Date, Pay Group, and other criteria provided by the user on the header of the PPR.
CANCELLED - NO INVOICES SELECTED:
If no invoices or memos met the selection criteria provided by the user on the header of the PPR, the PPR is
automatically terminated and the status changes to this status.
"MISSING..." STATUSES:
Other statuses may appear at this point in the process if the user failed to included required information on the PPR
header, such as "Missing Exchange Rates", etc.
INVOICES SELECTED:
After selecting the documents (invoices/memos), they are locked to prevent other checkruns from selecting the
same documents.
INVOICES PENDING REVIEW:
This status will only appear if you selected the Stop Process for Review After Scheduled Payment Selection option
on the Processing tab of the PPR header. This status means that the PPR process has stopped, and is waiting for
you to review the invoices and memos that were selected for payment (and make any changes to the batch, as
needed). Click on the Take Action icon to be taken to the Review Selected Scheduled Payments window.
CALCULATING SPECIAL AMOUNTS:
This status will only appear if you selected the Calculate Payment Withholding and Interest During the Scheduled
Payment Selection option on the Processing tab of the PPR header. This status means that interest and withholding
tax are being calculated and applied, as necessary, to the invoices and memos selected for this payment batch.
ASSEMBLING/ASSEMBLED PAYMENTS:
An "interim" status, it appears after the calculation for interest and withholding has been completed, and the Build
Payments program is starting. It may appear again later after the user provides any required bank account and PPP
information for the invoices/memos ("documents") selected.
INFORMATION REQUIRED - PENDING ACTION:
This status appears if you did not provide a default Internal (Disbursement) Bank Account and/or PPP on the
header of the PPR. In that case, you need to click on the Take Action icon to be taken to a form where you can
decide which internal bank account and PPP should be used for each invoice and memo selected for payment.
PENDING PROPOSED PAYMENT REVIEW:
This status will only appear if you selected the Stop Process for Review After Creation of Proposed Payments option
on the Processing tab of the PPR header. In this case, the system is waiting for you to review (and modify, if
needed) the proposed payments for this batch. Click on the Take Action icon to be taken to the Review Proposed
Payments window.
FORMATTING:
This status indicates that the proposed payments have been turned into payment instruction files. At this point, you
will want to click on the Show link to view the new associated payment instruction file(s). Each payment instruction
file with have their own PI Reference Number. If you have both electronic and paper ("check") payments involved
in this payment batch, you will see a payment instruction file for each type of payment method.
PAYMENT INSTRUCTION STATUSES:
An "electronic" type of payment instruction file will usually be marked as FORMATTED at this stage, which
means the PI has been created, (and based on your setups) may also have been transmitted, and even
marked as "Complete".
9 of 17 11/6/2013 11:30 AM
A "check" type of payment instruction file will (based on your setups) usually be marked as FORMATTED -
READY FOR PRINTING, which means the payment instruction file was created, and is waiting to be sent
to your printer. Click on the Take Action icon to send the file to the printer.
Afterward, the Status will change to SUBMITTED FOR PRINTING. Click on the Take Action icon again to
"confirm" the payments (Record Print Status). This is also where the user will have an opportunity to
"Reprint" the payment instruction file, if there were problems during the first printing process. Once the
payment instruction file has been printed, an internal Payment Reference Number is assigned to the
payment, along with a Paper Document (Check) Number.
Once the user clicks on the Record Print Status button (and confirms it), the payment instruction file's Status
changes again, this time to PRINTED.
CONFIRMED PAYMENT:
Once the payment instructions have been transmitted/printed and confirmed, the Status of the PPR changes to this
status to indicate a successfully completed payment batch (PPR).
TERMINATED:
If the user terminates a PPR anytime prior to confirmation of the payments (using the Terminate icon), the status
will change to "Terminated", and the PPR is permanently closed.

5. Alternatives to using Payment Process Requests
Creating PPRs is the only method of creating payments in the Oracle Payments module (IBY), but you can still create single
payments using the Payments Workbench form in Oracle Payables (AP). There are three types of single payments that you can
create using the AP Payments Workbench form:
Quick Payment = a single computer-generated payment to be generated and printed or transmitted using Oracle
Manual Payment = a single payment already generated outside of Oracle (such as bank wires, hand-written checks,
etc.)
Refund = a single payment to a supplier, usually to repay one or more overpayments received in Oracle Receivables, or
to refund a credit account balance in Oracle Payables.
Remember that the Payments Workbench is limited to creating only single payments, and requires that the user manually select the
desired invoices and/or memos to pay.
Payment Process Requests (PPRs), on the other hand, are by far the most popular and heavily used payment programs for Oracle
users because the Oracle Payments disbursement engine enables you to greatly simplify your procedures for managing complex
payment processes that span multiple payment methods, formats, check stocks, transmission protocols, currencies, organizations,
and bank accounts.
For more information about single payments in the AP Payments Workbench, review Note 1320497.1 R12: Master
Troubleshooting Guide for Issues in the (AP) Payments Workbench, and click here to watch the "R12 Payments Workbench
Basic Functionality" webcast (originally broadcast on August 16, 2011).

6. Data/Function Security for PPRs
Most companies have business requirements that dictate limited user access to certain forms, functions, and/or data within Oracle
Payables and Payments. The Notes listed below discuss many approaches to form, function and data security:
Document
Number:
Document Name:
Note 823104.1 R12: Scheduled Payment Selection Report Displays Unused Credits for All Operating Units
Note 823453.1 R12 Users Are Able To View & Cancel Other OU's Payment Process Requests (PPRs)
10 of 17 11/6/2013 11:30 AM
Unpublished Note
956414.1
R12: Payment Batch Sets in R12? and How to Create A PPR Using Multiple Payment
Documents (file a new SR and ask for access to this Note)
Note 1149963.1 R12: Invoice Batches for Other OUs Can Be Selected in PPRs
Note 1156813.1 R12 Users Can Access And Modify Payment Process Requests From Other Operating Units
Note 1296320.1 R12: Selected Payment Schedules Report shows data for all organizations
Note 1297328.1 R12: How To Make A Responsibility Show Only Payments Related To A Specific Operating Unit
Note 1305987.1 R12: "Invoice Batch" LoV on the PPR entry window shows all OUs
Note 1306213.1 R12: Is It Possible To Pay Two Invoices Belonging To 2 Operating Units In 2 Different Ledgers
In One PPR?
Note 1323146.1 R12: Bank Account LOV in Payment Attributes Tab of PPR Template Does Not Limit Values
Based on Access Permission
Note 1351475.1 R12: Payment Process Request Data for Other Operating Units Showing in the Search PPR
Results

To find more information about Form, Function, or Data Security in the E-Business Suite, review:
Chapter 2: "Access Control with Oracle User Management Funds Disbursement Process Flows" in the Oracle
E-Business Suite System Administrator's Guide - Security
Chapter 4: "Oracle Application Object Library Security" in the Oracle E-Business Suite System Administrator's Guide
- Security
NOTE: Check for the version of the Oracle E-Business Suite System Administrator's Guide - Security that is specific
to your version of the E-Business Suite applications by looking for your apps version (i.e., R12, R12+, R12.1,
R12.1+, etc.) on the Oracle Documentation Library List, and then click on the link for your version. Once you have
clicked on the link for your version of the apps, click on the Documentation tab to see the documentation library.
Under the Reference section (for R12.0.x), or the System Administration section (for R12.1.x) on the right, search for
the link for the Oracle E-Business Suite System Administrator's Guide - Security guide and click on it.

7. Diagnostic Tools
In this section, we'll talk about some of the diagnostic tools available to you. There are several types:
Concurrent Process Log Files (such as the Build Payments process, etc.)
Application Diagnostic Outputs (such as a PPR Data Collector, or AP List, etc.)
Diagnostic Scripts (such as a Check_IBY or Check_Vendor, etc.)
FND Debug Logs
Trace Files
a) First, make a soft copy of the log file(s) for the concurrent process(es) that errored out, and review each closely for error
messages. To make a soft copy of a concurrent program, navigate to the Concurrent Requests window using the Payables Manager
responsibility (or equivalent):
From the Home Page Main Menu, navigate to:
Other > Concurrent > Find button 1.
Place your cursor on the report that errored 2.
Click on the View Log button 3.
Save the log using File > Save As 4.
Or, from the Oracle Forms Main Menu, navigate to:
View Menu > Requests > Find button 1.
Place your cursor on the report that errored 2.
Click on the View Log button 3.
11 of 17 11/6/2013 11:30 AM
Save the log using File > Save As 4.

b) Next, run the script "ap_gdf_detect_pgk.sql" discussed in
Document 1360390.1 R12: Diagnostic Script to Validate Data Related to Invoice and Payment Transactions to identify data
corruption.
If you have a KNOWN data corruption this script will tell you what to do
NOTE: If you want to proactively run this script as a concurrent process before running a PPR, see Note 1361255.1: How
to Register the AP Data Validation Script as a Concurrent Program. This is a great way to catch issues BEFORE the stress
of period-end.
For more information about GDFs and how to use them, see:
Note 1327956.1: R12: Frequently Asked Questions (FAQ) on the Oracle Payables Generic Data Fixes (GDF's)
Available
Note 874903.1: What is a Generic Datafix Patch (GDF) and what GDFs are available for Payables?
c) If the results of the "Super GDFs" for both Invoices and Payments do not offer a solution for you, then pull the following
diagnostic reports to review your back-end data (and/or to upload to Support):
PPR Data Collector (see unpublished Note 463728.1: R12: Oracle Payables Payment Process Request (PPR) Data Collector
Test)
AP List - for a specific payment (See Note 732163.1: R12.0.6+ : Oracle Payables Invoice Data Data Collection Test)
The AP List can be created for an invoice or a payment using the Search Criteria field. Use the <LoV> to select "Check"
instead of "Invoice" (even for electronic payments).

d) Other great resources:
Note 1174813.1 R12: Generic Data Fix (GDF) Patch for Payment Schedule, Payment Status, Overpayment and Incorrect
Payment amount issues
Note 1206075.1 R12: Frequently Asked Questions (FAQ) on the Oracle Payables Generic Data Fixes (GDF's) Available
Note 1367272.1 R12 Generic Data Fix (GDF) Patch for Payment stuck when Invoices On "Spoiled Checks" remain in
"Selected For Payment" Status
Note 1370214.1 R12 Generic Data Fix (GDF) Patch for Orphan Bank Accounts

e) If requested to do so by Support, run one or more Debug Logs and Trace Files:
Note 458371.1: How to Get the R12 Trace and FND Debug File / FND Log for Payables Processes. This Note explains how to
capture both types of outputs.


8. Identifying What Went Wrong and Finding a Solution
When a PPR fails with an error message, it is important to review the concurrent log files for the Build Payments concurrent
program and/or the Format Payment Instructions concurrent program for any error messages. Reviewing the log files for errors can
assist in finding setup related issues or environment issues that caused the process to fail.
Once you have found the error message, copy the error code(s) (which will contain letters and numbers, such as
"ORM-20001") and the error message itself.
12 of 17 11/6/2013 11:30 AM
Paste the error code into the Search Knowledge Base field on the Home Page in My Oracle Support
When the results appear, filter the results by clicking on the links on the left-side menu: Product Category > Oracle
E-Business Suite > Financial Management > Procure to Pay > Oracle Payables (or Oracle Payments)
Use the error message you copied from the log file to help you find documents related to your specific issue. Oracle has
developed numerous Detailed Troubleshooting Guides (Notes) for specific error codes. Look for them in the Support
Recommended section at the top of your search results.
If you are unable to find a document related to your specific issue, click on the Procure to Pay link in the breadcrumbs on
the left to return to the previous search level.
Click on the Oracle Payments (or Oracle Payables) link to search the documents listed in the system under that Product
Category.
When a PPR fails and the concurrent program log files do not show an error message, run the script "ap_gdf_detect_pgk.sql"
discussed in Note 1360390.1: R12: Diagnostic Script to Validate Data Related to Invoice and Payment Transactions to identify data
corruption. If you have a KNOWN data corruption this script will tell you what to do.
If you want to proactively run this script as a concurrent process before running the PPR, see Note 1361255.1: How to Register the
AP Data Validation Script as a Concurrent Program.
For more information about GDFs and how to use them, see:
Note 1327956.1: R12: Frequently Asked Questions (FAQ) on the Oracle Payables Generic Data Fixes (GDF's) Available
Note 874903.1: What is a Generic Datafix Patch (GDF) and what GDFs are available for Payables?
If you are still unable to find information related to your specific issue, file a new Service Request with Oracle Support and upload
the following to the SR:
screenshot(s) of the issue, as it happens
related concurrent program log files
a PPR Data Collector report (if the PPR was entered and submitted)
an AP List for a related invoice (if the issue directly involves one or more invoices selected for payment)

9. CRITICAL: RPCs (Recommended Patch Collections) for Oracle Payables
Since the release of 12.1, a number of recommended patches for Oracle Payables were made available as standalone patches to
help address important business process issues. Adoption of these patches was highly recommended at the time, but not always
implemented by customers, so to further facilitate adoption of these Payables patches, Oracle has now consolidated them into a
single Recommended Patch Collection (RPC).
In January 2012, the first set of "RPCs" for the R12.1 versions of the Oracle Payables application were released by Oracle
Development. They were updated in August 2012.
There are three RPCs for Payables, as of August 2012:
Patch 14273383:R12.AP.B - R12.1: Payables RPC for (Core AP) - The most critical of the three RPCs for AP
Contains recommended fixes for the core functional modules: Payables (AP), Payments (IBY) and EBTax (ZX). Requires
prerequisite patches (check the prerequisites list in the patch's Readme file). Very small footprint compared to other
patches (just 1,979 files vs 1,700 on a typical AP patch)
Patch 13563481:R12.AP.B - R12.1: Payables RPC for (iSupplier)
Contains recommended fixes for the AP-iSupplier integration (but does not include fixes for the PO-iSupplier integration).
No patch prerequisites are required. One functional prerequisite is required. Refer to Note 1267188.1 - "How to use tax
rules using the Not Equal To operator, and complete the recommended action items. Very small footprint (only 1,465
files)
Patch 13563489:R12.AP.B - R12.1: Payables RPC for (WF/PCARD)
Contains recommended fixes for the non-core functional modules known as "Workflow" and "Procurement Card". No
prerequisites are required. Very small footprint (1,446 files)

In addition, there may be a number of critical recommended patches that were not included in the Aug 2012 RPCs for Oracle
13 of 17 11/6/2013 11:30 AM
Payables. If so, you'll find them on the following two Notes in My Oracle Support:
Note 1397581.1 R12.1: Payables Recommended Patch Collection (AP RPC), August 2012
Note 954704.1 EBS: R12.1 Oracle Financials Recommended Patches, August 2012

For more information about these RPCs, as well as information about available RPCs for other AP-related modules, watch this
video:

10. HOT TOPICS:
See troubleshooting Note 1310948.1 R12 Payables: Troubleshooting PPRs that are "Stuck"
See troubleshooting Note 1092897.1 R12 Payables: Troubleshooting Invoices Stuck due to a Payment Process Request (PPR)
See Note 1322437.1 R12: Consolidated PPR Termination Issues & Solutions


11. Troubleshooting Issues within the Individual Steps of an PPR process
AUTOSELECT
Document Number: Document Name:
Note 952763.1 Detailed Troubleshooting Guide: When Eligible Invoices are not Selected for Payment
Note 1312983.1 Consolidated PPR Performance Issues Note
Note 1314118.1 Consolidated PPR Errors Note
Note 1544651.1
R12: Payments Error: "You Have Encountered an Unexpected Error"
Note 1314130.1 Comprehensive Listing of Other Known Issues & Solutions for the AutoSelect step
BUILD PAYMENTS
14 of 17 11/6/2013 11:30 AM
Note 1311320.1 Consolidated Listing of Error Messages: "Cannot Validate Documents"
Note 1311418.1 Consolidated Listing of Error Messages: "Cannot Create Payments"
Note 1322526.1 Consolidated Listing of Error Messages: "Cannot Complete Check Numbering"
Note 1544651.1
R12: Payments Error: "You Have Encountered an Unexpected Error"
Note 1313372.1 Comprehensive Listing of Other Known Issues & Solutions for the Build Payments step
Note 1307434.1 PPR is Getting Terminated Even Though Build Payment is in Progress
FORMAT PAYMENTS
Document
Number:
Document Name:
Note 1310948.1 Detailed Troubleshooting Guide for "Stuck" PPRs
Note 1092897.1 Detailed Troubleshooting Guide for "Stuck" Invoices With a Status of "Selected for Payment"
Note 414336.1 R12: How To Assign/Modify XML Publisher Payment Templates
Note 312353.1 R11i and R12: Check Printing Using XML Publisher
Note 1316553.1 Comprehensive Listing of Known Issues & Solutions related to Payment Formats & XML Templates
Note 1317095.1 Comprehensive Listing of Other Known Issues & Solutions for the Format Payments step
Note 1183343.1 R12: Format Payment Instruction With Text Does Not Include A Total
Note 457539.1 R12: Can Users Customize XML Extract?
Note 977371.1 R12: Format Payment Instructions With Text Output Has Null Output
Note 781267.1 R12 Output Of Format Payment Instructions With Text Output Is Null When Using European Number
Format
Note 943180.1 R12: Error in Transmitting ACH File to the Bank Server Using SFTP While Validating Host Key
Note 1544651.1 R12: Payments Error: "You Have Encountered an Unexpected Error"
Note 977326.1 R12: Bank Charges / Discount / AWT Calculated But Not Deducted from Payment
CONFIRM PAYMENTS
Note 1322437.1 Consolidated PPR Termination Issues Note
Note 1321238.1 Comprehensive Listing of Other Known Issues & Solutions for the Confirm Payments step
Note 1142354.1 R12: Not Able To Confirm The Payment Process Request (PPR) Due to Null pointer exception Error
PAYMENT REPORTS
Note 1318577.1 Comprehensive Listing of Known Issues & Solutions for Payment Reports
15 of 17 11/6/2013 11:30 AM

12. Environment Issues: Performance, Hardware, Database, Memory or other peripheral issues
PPR Performance, Setup, and Troubleshooting are outlined in detail in the following documents:
Note 1312983.1 R12: Troubleshooting PPR Performance issues
Coming soon!: Setup PPRs for Optimal Performance


13. Logging a Service Request
This note and the auxiliary notes referenced within attempt to guide you to resolution of most known issues with PPRs.
If you find that you require assistance after completing the steps outlined in this note, please log a new Service Request in My
Oracle Support, and provide the following information to expedite resolution of your issue:
1) Can you replicate the issue?
2) Do you have any research findings that would help us in understanding or troubleshooting this issue? If yes what?
3) Did this work before? If so what has changed?


We hope you found this information useful. Our desire is to provide the right information when you need
it. Please let us know how we are doing -- RATE this document on the right-side of this display.
Standard Patching Process
Please consult as well the recommended patch lists for Payables. The list includes consolidated patches that contain fixes for
issues that had been critical:
For the R12.0.x codeline, see Note 557869.1
For the R12.1.x codeline, see Note 954704.1
Patch Wizard
Important: While a patch may contain several hundred files, the impact on your system is most likely far less. Patches contain
hard-prerequisites that are intended to make a patch work on a very low code baseline. The Patch Wizard Utility will give
you a detailed impact analysis for the patch BEFORE you apply it. Please refer to Note 976188.1 for more information on this
important utility.
Have more questions?
Join our growing Oracle Payables Community and learn from your peers and Oracle on how to address your
unique issues in AP!
16 of 17 11/6/2013 11:30 AM
You can access the main Oracle Communities page at https://communities.oracle.com/portal/server.pt/community
/payables/284
If you are enrolled,the Payables community will be listed on your left. If you're not already enrolled in the Payables community,
you can do so by clicking on Profile > Community Subscriptions region > Edit Subscriptions.
References
NOTE:1497314.1 - R12: How to Record "Skipped" and "Spoiled" Check Numbers in Oracle Payments/Payables
Related
Products
Oracle E-Business Suite > Financial Management > Procure to Pay > Oracle Payments > FD Core > Payment Process Requests
Oracle E-Business Suite > Financial Management > Procure to Pay > Oracle Payables > Pmt PayReports PBatch & Prepay
Keywords
AUTOSELECT; BUILD PAYMENTS; CONFIRM; FORMAT PAYMENTS; MASTER NOTE; REPORT; TROUBLESHOOT
Translations
English Source Korean
Back to Top
17 of 17 11/6/2013 11:30 AM

Master Troubleshooting Guide For Payment Process Requests

Transféré par

Informations du document

Titre original

Copyright

Formats disponibles

Partager ce document

Partager ou intégrer le document

Options de partage

Avez-vous trouvé ce document utile ?

Ce contenu est-il inapproprié ?

Droits d'auteur :

Formats disponibles

Master Troubleshooting Guide For Payment Process Requests

Transféré par

Droits d'auteur :

Formats disponibles

In this Document

Vous aimerez peut-être aussi