R12: MASTER

TROUBLESHOOTING GUIDE
FOR PAYMENT PROCESS
REQUESTS (PPRS) FOR
ORACLE PAYABLES
Posted by Raju ERP
1. What is a Payment Process Request (PPR), and How Are PPRs Created and
Managed?
What is a PPR?
Ans) 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.
How is a new PPR submitted?
Ans) 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.
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.
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.
Stopping & Voiding Completed Payments
You can record a "Stop Payment" action or a "Void" action on one or more completed payments
using thePayments tab on the Payments Manager Dashboard.
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.
Scheduling PPRs using PPR Templates
You can use the name of a PPR Template as the Request Name on the Schedule Payment Process
Requestform 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.
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 theFunds 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 Account

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

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

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.

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.

o
o
o
o

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

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

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

o
o
o
o

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

o
o
o
o

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"
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".
o
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.
o
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.
o
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.
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:
o
Quick Payment = a single computer-generated payment to be
generated and printed or transmitted using Oracle
o
Manual Payment = a single payment already generated outside of
Oracle (such as bank wires, hand-written checks, etc.)
o
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.
http://orafinappssetups.blogspot.in/2013/02/r12-master-troubleshooting-guidefor.html