How to Setup and Extend R12 Payments

Introduction
With R12 came the restructuring of how Payments(checks and electronic) are handled and setup in Payables. Within this document you will learn how to setup the minimum requirements in order to process payments. This includes Bank Setup, Formats, XML Templates, Payment Process Profiles, how to extend the iby_fd_extract_ext_pub to include custom data, attach font mapping sets(MICR) in XML Publisher, as well as a solution on how to secure the electronic signatures for printed checks.

Setting up the Bank, Branch, Account, and Payables Document
The first step in setting up payments in R12 is to define the Bank and at least one Branch. Use the Manage Banks and Branches page to access pages to specify general information and define addresses and contacts for banks and bank branches. See: Create Banks, Oracle Cash Management User's Guide and Define Bank Branches, Oracle Cash Management User's Guide.

Next we need to create a bank account that we can use for payments. Use the Manage Bank Accounts page to access pages to create account owners and use, controls, access, and contacts. Also specify general information for your bank accounts. See: Bank and Account Administration: Define Bank Accounts, Oracle Cash Management
User's Guide.

Once we have defined which bank account we will be using for payments, we need to create Payables Documents to actually make payments. These documents will serve as the ‘type’ of payment we will be trying to make. Use the Manage Payment Documents region on the Manage Bank Account page to access the Payment Documents page. From this page, you can access pages to create payments documents, update payment documents, and void skipped
documents. See: Oracle Cash Management User's Guide.

Payment Setups
First we should set up the system security options. These security options control settings for payment instrument encryption, masking, and credit card control. See: Oracle Payments Implementation Guide.
Next you should set up validations related to the payment method. By setting these values up you ensure that funds capture and funds disbursement transactions are valid, in addition to being correctly formatted before they are printed or submitted to payment systems. Oracle Payments Implementation Guide.
Now we should turn our focus to the XML Publisher Templates. We need to either define new templates or use seeded templates to properly format the output. At this point if you had a custom font such a MICR.ttf or some other font, we could create the font, font mapping set, and assign it directly to the template for use while processing payments. Oracle Payments Implementation Guide.
Next we should create the payment format(s)s that will be tied to the template(s) we just created in XML Publisher.
I recommend applying validations at this point to make sure your transactions are complete. In the case of creating a format used to send electronic payments, I would add the following 3 validations: US NACH Payment Instruction Validation, US NACHA Payee Validation, and US NACHA Internal Bank Validation. This will insure that the Payment Instruction is less than 100,000,000, that the Payee routing number is 9 digits, and that the internal bank
account routing number is also 9 digits. You might also consider add a user-validation that makes sure the Payee bank account number is not null. Oracle Payments Implementation Guide.
Two other things you can consider setting up are Transmission Configurations and Payment Systems. These allow for the delivery of transactions along with the collaboration of Oracle Payments with external payment systems.
These are not necessarily required. Oracle Payments Implementation Guide.

Funds Disbursement Setups
The predefined Payment Methods are typically the only thing that you will
need in order to process payments. These are the means by which you will be making a payment to a third party.
Payment Method Defaulting rules determine what payment method will be applied to an invoice during invoice creation.
Finally we should set up our Payment Process Profiles. These profiles comprise of several types of payment processing information, including specifications for formatting and transmission. Without a Payment Process Profile we would be unable to process payments.

IBY_FD_EXTRACT_EXT_PUB
This package allows the ability to add additional data to the XML structure at multiple levels. These levels include:

Get_Ins_Ext_Agg -- This API is called once only for the payment instruction.
Get_Pmt_Ext_Agg -- This API is called once per payment.
Get_Doc_Ext_Agg -- This API is called once per document payable.
Get_Docline_Ext_Agg -- This API is called once per document payable line.
Get_Ppr_Ext_Agg -- This API is called once only for the payment process request.

XML Publisher Setups for fonts
Utilizing the built in functionality of XML Publisher within the eBusiness Suite will allow us to add the appropriate fonts need in order to print checks. Add the appropriate fonts
and then create a “FO to PDF” font mapping set within the XML Publisher Administration. You will then need to assign the font mapping set to the TemplateConfigurationFO Processing setup. If the font is necessary globally, you could optionally set the font mapping set value at the global configuration setup instead.

To add the font -- XML Publisher AdministratorAdministrationFont Files(Create Font File)
To add the Font Mapping Set -- XML Publisher AdministratorAdministrationFont Mappings(Create Font Mapping Set)
To set the FO ProcessingFont Mapping Set value globally -- XML Publisher
AdministratorAdministrationConfigurations – Expand PropertiesFO ProcessingFont Mapping Set and set the value accordingly.
To set the FO Processing at the template level – Query TemplateEdit Configuration -- Expand PropertiesFO ProcessingFont Mapping Set and set the value accordingly.

Securing the signatures and MICR font
Here are some ‘no cost’ best practices for securing the signatures related to AP Checks. First you should limit access to the responsibility that has access to the output of the ‘Format Payment Instructions’ concurrent program that print the checks. In R12 unless you have setup
rules/grants in User Management responsibility to allow access to see others output this should not be a problem. Second you should regularly purge the output of ‘Format Payment Instructions’. Lastly, limit access to the directory where the electronic signatures are stored.

Our solution is a combination of all of the above. We keep our signatures in $OA_MEDIA/zint/sig directory. This directory is restricted by IP address so that only the applications server has access to these files. The files have a naming convention of {INSTANCE][VOID_FLAG]_[POSITION_NAME].gif(ex. PRODN_Chair.gif). This means that I only want the file to be accessible to PROD Instance, only if the void flag is N, and only for our County
Chairman. We use the concatenation features of XML Publisher to generate the file name on demand. This prevents potential fraud from test instances. To secure the MICR line on the check, we use a simple “IF” condition to determine which instance the check is being ran from and print(or not print) accordingly. These are some simple steps that you can take to help secure the checks and signatures for AP check printing.

Conclusion
R12 changes the way payments are handled compared to previous versions such as 11i. This
version of payments takes full advantage of the integrated XML Publisher module to provide enhanced visual check output without the use of 3rd party systems. The flexibility to issue multiple payments of different payment methods within one Payment Process Request is just one of the ways the R12 has enhanced the Payment Process. The ability to utilize the IBY_FD_EXTRACT_EXT_PUB API is a fast and efficient way to get additional data in to the XML structure. The above solution allows the user a simplistic way to issue payments that is similar to 11i.