Oracle R12 AP Check Printing Setups and Process Document

Oracle R12 AP Check Printing Setups and Process Document
Raju Ch
EXECUTIVE OVERVIEW
Generating payment checks from the E-Business Suite has traditionally required either a third party or
considerable customization of the delivered check print reports. The check print format is very specific to each
banking organization, requiring specific fonts and pixel-perfect layout. The existing E-Business Suite reports
generate flat text output and do not support these features. Oracle XML Publisher now offers an integrated, costeffective method to generate the check output directly from the E-Business Suite.
INTRODUCTION
Check printing from the E-Business Suite has historically required a third-party solution that can either query the
necessary data and format the output or accept the existing flat text output generated by the provided check print
programs. To then generate the checks, the format components had to be placed with pixel-perfect precision onto
the page using the necessary MICR font to format the bank routing number and bank account of the payee.
Alternatively customers could take the existing check print program and customize it to format the output
correctly. These solutions are costly in terms of their implementation, their ongoing maintenance and their
complexity. This all adds to the total cost of ownership for the E-Business Suite.
Oracle XML Publisher offers integrated functionality that allows customers to design their own check format
using familiar desktop tools that can then be applied to a check print data source, whether that is the seeded
Oracle Report or a custom solution. This format is easily maintainable and can include all the necessary
components required in the final output to be printed onto blank check stock.
Taking this approach reduces the complexity of the systems surrounding the check generation and thereby
reducing the total cost of ownership of the E-Business Suite.
Pre-requisites:
Download BI Publisher Template Builder for Word version 10.1.3.4.1 from download.oracle.com
Basic requirements to start creating checks are to have an RTF file (Template) and an XML file (data definition).
There are 2 ways that you can have an RTF file:
o Create your own, or
o (Recommended) Download standard oracle Template
Nav : Payables Manager > Setup > Payment > Payment Administrator > Formats > XML Publisher Format
Templates
Query and download the RTF file
Standard Check Format IBYDC_STD1.rtf or
Standard Check Format (Stub After Payment) IBYDC_STD1A.rtf
Go to Metalink and Check Oracle Note 457539.1. This note says that the Package IBY_FD_EXTRACT_EXT_PUB
controls the XML extract used in check printing. The supplied version can be found in
$IBY_TOP/patch/115/sql/ibyfdxeb.pls
Better way is to follow the instructions in Doc ID: 465389.1 R12 Create Or Modify A Payment Format Using
XML Builder. This note explains the same steps that I have defined below
MICR Fonts. This is another important requirement which you will run into later on. So I have decided to address
it right away because you may end up spending a lot more time if you start thinking about it later. One of the
easiest way is to buy the MICR font from a third party like IDAutomation (http://www.idautomation.com/) and
use MICRW1B.ttf. Typical cost is around $750.00 per user license you may need to purchase only one license.
You may also download their Demo version which is good for testing.
Raju Ch
The good news is that Oracle also provides a MICR font which is available if you have downloaded the BI
Template Builder. Some banks reject this font, but so far I did not have any problem with the bank that we used.
Download and install BI Publisher ver 10.1.3.4.1
Font File Location: C:\Program Files\Oracle\BI Publisher\BI Publisher Desktop\Template Builder for
Word\fonts\ MICR____.TTF
In order to use this file in the RTF template, copy the font file MICR____.TTF to C:\WINDOWS\Fonts
At this stage, you may or may not have designed the Check template. But you can still use IBYDC_STD1.rtf
downloaded earlier.
Following steps are needed to create a check in AP from scratch. These steps may also be used to create the initial
payment to get the XML file.
Raju Ch
Step 1: Create XML Template

Navigation : Payables Manager Setup Payment Payment Administrator Formats XML Publisher
Format Templates
Click 'Create Template'

Enter below details
Name
: XX_APPS88_CHECK
Code
: XX_APPS88_CHECK
Application
: Payments
Type
Data Definition
Default File Language
Default File Territory
: RTF
Upload your RTF File
: Oracle Payments Funds Disbursement Payment Instruction Extract 1.0

: English
: UNITED STATES
Raju Ch
Raju Ch
Step 2: Create Payment Format

Navigation : Payables Manager > Setup > Payment > Payment Administrator > Formats > Formats
Select Type = Disbursement Payment Instruction
Click on Create
Enter below details
Name
: XX_APPS88_CHECK
Code
: XX_APPS88_CHECK
Data Extract
XML Publisher Extract
: Oracle Payments Funds Disbursement Payment Instruction Extract 1.0

: XX_APPS88_CHECK (XML Template name created in Step 1)
Raju Ch
Raju Ch
Step 3: Create Payment Document

Navigation : Payables Manager > Setup > Payment > Bank Accounts
Account name
: BofA-204
Query up your Bank Name. It is assumed that your Bank has already been setup in AP.
Select the Bank Account and click on Manage Payment Documents.
Click on Create
Enter:
Name
: XX_APPS88_CHECK
Paper Stock Type

Attached Remittance Stub
: Blank Stock or Prenumbered Stock

: Yes
If you have remittance stub, check the box for Attached Remittance Stub
Important: If you check the above box, a new field called Number of Lines per Remittance Stub will show up.
This is number that you will have to find out by trial and error once you start testing your template. Initially, set it
to a lower number, say 15.
Format : XX_APPS88_CHECK (Enter Format defined in step 2)
First Available Document Number:
Last Available Document Number
Enter any other information that you may need.
Click Apply
Raju Ch
Step 4: Create Payment Profile

Navigation : Payables Manager > Setup > Payment > Payment Administrator > Payment Process Profiles
Click on Create
Enter
Code
XX_APPS88_CHECK
Name
XX_APPS88_CHECK
Payment Instruction Format
XX_APPS88_CHECK (As defined in Step 2)
Processing Type
Printed
Payment Completion Point
When the Payment Instruction is Formatted
Default Payment Document
Document created in Step 3
Payment File
Send to Printer
Check the box Automatically Print After Formatting (Note: You may choose not to check this box initially it
will help in testing)
Default Printer: Valid oracle printer name
Click Apply
Raju Ch
Now you are all set to create checks. All you have to do is create an Invoice, or select any existing validated
invoice for a vendor.
Raju Ch
There is one more thing that you must check before creating the payment.
Verify Concurrent Program
Go to Application Developer or Sys Admin responsibility and bring up the concurrent program Format payment
Instructions
Navigation : Concurrent > Program > Define > F11 > Format Payment Instructions > Ctrl-F11
(Short Name: IBY_FD_PAYMENT_FORMAT)
Set Output Format to XML: Use this option to first generate your XML (Data Definition) file
Set Output to PDF : This will create your check in PDF format once your check template is ready. Also, Set Style to
PDF Publisher in this case.
There is one more way to get the XML, In the formats change xml publisher name to Extract Identity
Navigation : Payables Manager > Setup > Payment > Payment Administrator > Formats > Formats
Query with format name(XX_APPS88_CHECK) and change the XML Publisher Template value to Extract
Identity.
Raju Ch
Raju Ch
How to Submit a Request to create Payments

Submission process for AP Checks/Payments has also changed in R12. Most of the options are now available in
HTML screens. The good news is that you can create templates (Not XML templates - these are different) so that
you do not have to enter the same information every time you submit a request.
Submit Request:
Navigation : Payables Manager > Payment Manager > Submit Single Payment Process Request
Following parameters are minimum required - you can enter others as necessary:
Payment Process Request
name (Mandatory)
: Provide any useful Name
Use Template
: Leave Blank
Payee
: Vendor Name
Payment Method
: Check (Or any other name that has been setup is payment method)
Raju Ch
Click on Payment Attributes Tab:

Payment Date
: Defaulted to today's date
Disbursement Bank Account
: BofA-204 (Enter your Bank Account Name associated with this payment)
Payment Document
: XX_APPS88_CHECK (Enter payment document name created in Step 3 above)
Payment Process Profile
Payment Exchange Rate Type
: XX_APPS88_CHECK (This value will get filled automatically with the profile
defined above in step 4)
: Enter valid excahnge rate type (Ex: Corporate, Spot)
These parameters are sufficient to create a payment. Click on Submit in order to process. However, I do
recommend following steps also in the begining.
Click on Processing Tabs:
Check following boxes
Stop Process for Review After Scheduled Payment Selection. This step will stop after building the
payments so that you can review the payments selected, and cancel any of them, if necessary
Stop Process for Review After Creation of Proposed Payments
Click on Submit. Click on Home. Click on Monitor Requests.
Raju Ch
Raju Ch
How to Create Template for Request Submission

Note: All of the fields in this process are the same as in 'Submit Single Request'. Enter any fields that you repeat
for request submission. In the above example, usually leave the Payee field blank if you want to run for separate
vendors every time. Once the template has been created and saved, you may enter the template name in the field
'Use Template' in the example above.
There are several other options which I haven't explored yet. I will add more once I get to try them out.
Navigation : Payables Manager > Payment Manager > Create Template
Name : XX_APPS88_CHECK
Scheduled Payment Selection Criteria:
The Scheduled Payment Selection Criteria tab allows you to specify invoice selection criteria for the AutoSelect
process to use when it selects eligible invoices/memos for the batch, such as
The Payment Attributes tab allows you to specify how the batch will be paid, including:
what Payment Date you want to see on the payments (required)
which internal bank account you want to pay from (optional)
which set of Payment Documents you want to use (optional)
which Payment Process Profile you want to use (will default if Payment Documents are specified)
which Payment Exchange Rate Type you want to use (required)
other items related to financial methods of paying this batch
Raju Ch
The Processing tab allows you to specify features you want to use during the PPR process, and how they should
work:
Maximize Credits
Stop Process for Review After
Scheduled Payment Selection
Calculate Payment Withholding
and Interest During the Scheduled
Payment Selection
Stop Process for Review After
Creation of Proposed Payments
Create Payment Instructions
: Check this if you want the system to apply any available memos up to the
point where the payment for the supplier will be zero (and you have done
setups to allow for zero payments)
: Check this if you want to stop the PPR process after the initial batch of
eligible invoices/memos has been selected so you can review the batch and
modify the batch, if needed
: Check this if interest and/or WH tax was not previously calculated (at the
time of invoice validation). If checked, the system will calculate it during the
Build process
: Check this if you want to stop the PPR process after the proposed payments
have been created so you can review the proposed payments, and modify the
payments, if needed
: Select whether you want the system to automatically kick off the Create
Payment Instructions program automatically, or if you would prefer to kick
off the program manually from the SRS form
The Validation Failure Results tab allows you to specify what should happen if a Document (an invoice/memo)
or a Payment fails a pre-defined (or user-defined) Validation:
If a DOCUMENT fails a validation, the system should:
Reject only those document(s) that failed, and proceed with the rest
Reject all of the suppliers documents even if only one of their documents fails validation
Reject all documents selected for the PPR if ANY document in the batch fails validation
Stop the process for a review of the failed document(s)
If a PAYMENT fails validation, the system should:
Reject only those payment(s) that failed, and proceed with the rest
Reject all of the suppliers payments even if only one of their payments fails validation
Reject all payments selected for the PPR if ANY payment in the batch fails validation
Stop the process for a review of the failed payment(s)
Raju Ch
Raju Ch
PPR - Payment Process Profile

PPR Process:
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).
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".
Raju Ch
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.
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.
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.
Sort and 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
Raju Ch
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"
PPR Status:
NEW:A1:A58
Raju Ch
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 theTake 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:
Raju Ch
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".
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 toPRINTED.
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.
PPR Reports:
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".
Raju Ch
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.

Submitting PPR with Submit Single Format Payment Process Request
Search with payment details
Navigation : Payable Manager Payments Entry Query with below details
Operating Unit
: Vision Operations
Bank Account
: BofA-204
Payment Method
: Check
Status
: Negotiable
Or
Click on the find button and enter the values and click on find
Raju Ch
Raju Ch
Void the payments

Click on Actions Check the Void Ok
Raju Ch
Then submit the PPR
Payment Process Request Name : XX_APPS88_CHECK_PPR_004

Template : XX_APPS88_CHECK (Use the above created template to populate the values)
Click on Submit.
Raju Ch
Query with PPR and then click on go
Raju Ch
Raju Ch
Raju Ch
Click on the Record Print Status button and click on Continue (Record Print Status : Screen shot is missing )
Raju Ch
Raju Ch

Submitting the PPR with Create Printed Payment Instructions
Navigation : Payable Manager Payments Entry Click on find
Operating Unit
: Vision Operations
Bank Account
: BofA-204
Payment Method
: Check
Status
: Negotiable
Raju Ch
Void the payments

Click on Actions Check the Void Ok
Raju Ch
Then submit the PPR
Payment Process Request Name : XX_APPS88_CHECK_PPR_005

Template : XX_APPS88_CHECK (Use the above created template to populate the values)
Click on Submit.
Raju Ch
Raju Ch
Raju Ch
Raju Ch
Payment Process Profile

Payment Currency
Internal Bank Account
Payment Document
Select Payments from Source Product
Select Payments from Payment Process Request
Select Payments from Legal Entity
Select Payments from Organization Type
Select Payments from Organization
Print Now
Raju Ch
: XX_APPS88_CHECK
: USD
: BofA-204
: XX_APPS88_CHECK (it will populate by default)
: Payables
: XX_APPS88_CHECK_PPR_005(Above created PPR)
:Vision Operations
: Operating Unit
: Vision Operations
: No
Raju Ch
Raju Ch
Raju Ch
Raju Ch
Raju Ch
Raju Ch
Raju Ch
Raju Ch
Raju Ch

Oracle R12 AP Check Printing Setups and Process Document

Uploaded by

Copyright:

Available Formats

Oracle R12 AP Check Printing Setups and Process Document

Uploaded by

Document Information

Original Description:

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Oracle R12 AP Check Printing Setups and Process Document

Uploaded by

Copyright:

Available Formats

What are the prerequisites for setting up check printing using XML Publisher?

What are the prerequisites for setting up check printing using XML Publisher?

What are the steps to create a check template using XML Publisher?

What are the steps to create a check template using XML Publisher?

Oracle R12 AP Check Printing Setups and Process Document