Master Troubleshooting Guide for Payment Process Requests

Document 1305001.1

https://support.oracle.com/epmos/faces/DocContentDisplay?_afrLoop...

R12: Master Troubleshooting Guide for Payment Process Requests (PPRs) for Oracle Payables [VIDEO] [ID 1305001.1 1305001.1]] Modified: Apr 16, 2013

Type: TROUBLESHOOTING

Status: PUBLISHED

Priority: 1

To Bottom

Comments (0)

In this Document Purpose Troubleshooting Steps 1. What is a Payment Process Request (PPR), and H ow 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 NOT INVOLVING 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

1 f 17

11/6/2013 11 30 AM

Document 1305001.1


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 seq uential 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 h as been replaced in R12 by a new module called the Payments Manager module (IBY), which offers a nu mber 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 f 17

11/6/2013 11 30 AM

Document 1305001.1


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 a fter: 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" p ayments 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 p rior 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 p ayment instruction to "Terminated", and informs the source product of the terminated documents payable. Then for each p ayment 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 See Note 1497006.1 for detailed instructions.

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! Y ou 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 f 17

11/6/2013 11 30 AM

Document 1305001.1


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 pe riodic basis, such as once/multiple times a day, once/multiple times a week, once/multiple times a month, etc. T he 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 rev iew the information found in: Note 312353.1: Check Printing Using XML Note 1353280.1: R12: Master Troubleshooting Guide for Ora cle 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 S ort 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 f 17

11/6/2013 11 30 AM

Document 1305001.1


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 p rocess -- 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 See Note 1497314.1 for detailed instructions.

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 pop ulated 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 payab les 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 IBY BUILD 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 f 17

11/6/2013 11 30 AM

Document 1305001.1


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 p ayments. 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 assign ed 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 VALI DATED in the tables and the request status is displayed as "Documents Validated". If there any document validation failures, Oracle Payments uses the p arameter setting for "Documents" on the Validation Failure Results tab on the PPR h eader (the DOCUMENT_REJECTION_LEVEL_CODE) to d etermine 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 PP R.

FORMAT PAYMENTS

6 f 17

11/6/2013 11 30 AM

Document 1305001.1


(Codes: IBY_PAYINTSR_PUB, IBY_CHECKNUMBER_PUB): The Format Payments process is handled by Oracle Payments (IBY). When a PPR is s ubmitted, 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 P PR through the payments selected b y 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 T he 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 P ayment 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 p ayments Print checks: Users can load stationery into the printer and print checks at this stage by clicking o n the Take Action icon for the related Payment Instruction on the Search PPRs windo w. 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 pap er 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 y ou 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 f 17

11/6/2013 11 30 AM

Document 1305001.1


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 P ayment 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 P ayment 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 o f each payment. You can sp ecify 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 b y check. When you print checks, then you can e lectronically transmit a list of payments to the bank or pay ment 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 p ositive pay file. R12 Oracle Payments offers two versions of the Positive Pay report: the Positive Pay File program, and the Positive Pay File with Add itional Parameters program.These programs replace the R11i report called the P ositive 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 d ifferent 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 f 17

11/6/2013 11 30 AM

Document 1305001.1


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 b y the user on the head er of the PPR, the P PR 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 p revent 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 S election 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 w ithholding 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, a nd the Build Payments program is starting. It may appear ag ain later after the user provides any required ba nk 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 o f 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 w ill see a payment instruction file for each type of payment method. PAYMENT INSTRUCTION STATUSES: An "electronic" type of pay ment 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 f 17

11/6/2013 11 30 AM

Document 1305001.1


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 pro blems 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 (P PR). 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. Return to Table of Contents

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). Th ere 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 o r transmitted using Oracle Manual Payment = a single pa yment already generated outside of Oracle (such as ba nk wires, hand-written checks, etc.) Refund = a single payment to a supplier, usually to repay o ne 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 p ayments, 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 Wo rkbench , 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:

10 f 17

Document Number:

Document Name:

Note 823104.1

R12: Scheduled Payment Selection Rep ort Displays Unused Credits for All Operating Units

Note 823453.1

R12 Users Are Able To View & Cancel Other OU's Payment Process Requests (PPRs)

11/6/2013 11 30 AM

Document 1305001.1


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 - Secu rity 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 - S ecurity 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 do cumentation 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: 1. 2. 3. 4.

Other > Concurrent > Find button Place your cursor on the report that errored Click on the View Log button Save the log using File > Save As

Or, from the Oracle Forms Main Menu, navigate to: 1. View Menu > Requests > Find button 2. Place your cursor on the report that errored 3. Click on the View Log button

11 f 17

11/6/2013 11 30 AM

Document 1305001.1


4. Save the log using File > Save As

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 T ransactions to identify data corruption. If you have a KNOWN data corruption this script will tell you what to do NOTE: If you want to p roactively run this script as a concurrent process before running a P PR, see Note 1361255.1: How to Register the AP Data Validation Script as a Concurrent Program. This is a g reat 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 "Supe r 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 to select "Check" instead of "Invoice" (even for e lectronic payments).

d) Other great resources: Note 1174813.1 R12: Generic Data Fix (GDF) Patch for Payment Schedule, Payment Status, Overpayment and I ncorrect 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 T race 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 e rror message, copy the error code(s) (which will contain letters and numbers, such as "ORM-20001") and the error message itself.

12 f 17

11/6/2013 11 30 AM

Document 1305001.1


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, s ee Note 1361255.1: How to Register the AP Data Validation Script as a Concurrent Program . For more information about GDFs and how to use th em, see: Note 1327956.1: R12: Frequently Asked Questions (FAQ) on the Or acle 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 d irectly involves one or more invoices selected for payment) Return to Table of Contents

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 high ly recommended at the time, but not always implemented by customers, so to further facilitate adoption of these P ayables 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: Payab les RPC for (Core AP) - The most critical of the three RPCs for AP Contains recommended fixes for the core functional modules: Payables (AP), P ayments (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 "Wo rkflow" 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 f 17

11/6/2013 11 30 AM

Document 1305001.1


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 Encoun tered an Unexpected Error"

Note 1314130.1

Comprehensive Listing of Other Known Issues & Solutions for the AutoSelect step

BUILD PAYMENTS

14 f 17

11/6/2013 11 30 AM

Document 1305001.1


Document Number: Document Name: Note 1314118.1


Note 1312983.1


Note 1311320.1

Consolidated Listing of Error Messages: "Cannot Va lidate Documents"

Note 1311418.1

Consolidated Listing of Error Messages: "Cannot Create P ayments"

Note 1322526.1

Consolidated Listing of Error Messages: "Cannot Complete C heck Numbering"

Note 1544651.1

R12: Payments Error: "You Have Encoun tered 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 1314118.1


Note 1312983.1


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 S erver Using SFTP While Validating Host Key

Note 1544651.1

R12: Payments Error: "You Have Encountered a n Unexpected Error"

Note 977326.1

R12: Bank Charges / Discount / AWT Calculated But Not Deducted from Payment

CONFIRM PAYMENTS Document Number: Document Name: Note 1314118.1


Note 1322437.1

Consolidated PPR Termination Issues Note

Note 1312983.1


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 Document Number: Document Name: Note 1314118.1


Note 1318577.1

Comprehensive Listing of Known Issues & Solutions for Payment Reports


15 f 17

11/6/2013 11 30 AM

Document 1305001.1


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 P erformance


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 P ayables. 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 w ork 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 o n how to address your unique issues in AP!

16 f 17

11/6/2013 11 30 AM

Document 1305001.1


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 al ready 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 f 17

11/6/2013 11 30 AM

Master Troubleshooting Guide for Payment Process Requests

Recommend Documents