Académique Documents
Professionnel Documents
Culture Documents
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
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.
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.
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.
o
o
o
o
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
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
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
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:
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