CUSTOMIZATION AND IMPLEMENTATION OF ORACLE PAYMENT IN R12.1.1 SUPRIT MELINAMANI AUGUST 12, 2010
For Internal Use Only
Page 1 of 6
Table of Contents Introduction:
........................................................................................................................................... 3
Existing payment process in 11i. .......................................................................................................... 3 Challenges during the upgrade: ............................................................................................................... 4 Payment formats: ................................................................................................................................ 5
For Internal Use Only
Page 2 of 6
Introduction: The
client implemented the Oracle eBusiness suite 11.5.10.2 in 2007 to replace the legacy and the mainf rame system used earlier. This included implementing the AR, AP GL, p roject accounting, project costing and f ixed assets modules. The client is now upgrading the 11.5.10.2 ve rsion of eBusiness suite to R12.1.1 and the upgrade involves implementing the payment module in R12. The
payments module combines both funds disbursement and funds capture functionality into a single payment engine. Organizations can generate payments across multiple organizations, currencies and regions. Better working capital management can be achieved by providing cash managers with visibility into
cash inflows and outflowsAdditionally, a full audit trail and control is supported through a single
point of payment administration. Existing
payment process in 11i. Payment batch set
Payables document Bank Account Payables Format
Payables Program
Concurrent Program
Executable
Payments flow in 11i The
Client use the 11i payment batch set functionality extensively as they have a high volume of checks, wire, ACHs and clearing payments made on a daily basis. Payments are also generated in the form of quick checks and recorded payments for checks, wires and ACH. The
amount of disbursements made by the client in a month on an average is nearly $60 million. The client uses more than 400 different payment documents for disbursement across all the operating units, currencies and payment methods. A payment batchset in 11i is def ined based on the disbursement type (domestic or international), payment format and payment currency. Apart f rom submission of payment batch set process the payment batchset workbench enables user to def ine new payment batches for a
For Internal Use Only
Page 3 of 6
payment batchset and selective choose certain payments batches f rom the payment batchset for processing. When a payment batchset is submitted for processing, the chosen payment batches def ined in batch set can be selected, built, formatted and conf irmed. Each of these payment batches contain payments for invoices grouped together for a given vendor or payments for pay alone invoices. This way a large number of payments with different currencies can be processed easily at the same time by grouping them into
batchset.
Challenges during the upgrade: Payment process in R12 is based on payment templates. These are the blue prints of a payment batch. A template def ines the paygroup, payment currency, operating unit and payment date for each disbursement bank account, payment document, payment process prof ile and exchange rate.
It
also
helps in def ining the process automation options for the payment and handling validation error for document and payments. A payment template needs to have a payment process prof ile associate to it if the payment process needs to be automated. This is necessary because the Payment process prof ile contains all the rules for disbursement such as the processing type, payment completion point, payment method, bank account and currencies that can be used. It also contains the payment grouping, payment limits and payment sorting
and separate remittance rules to create a payment instruction.
Every payment process prof ile needs a format to be associates to it. The format contains information about the XML publisher format template and these templates contain the format layout as def ined in the specif ications provided by the banks which process the payments. In R12 a template
has been def ined for each of the payment document that is used to make the disbursement as a template can be setup only for a single paygroup in Oracle. These templates will then have to be grouped into template sets which would be submitted for processing. Thus emulating the payment batch set functionality f rom 11i. However unlike 11i there is not f ront end screen to submit a payment template and the payment manager dash board allows a user to submit a payment template for processing but a user can only submit one template at a time for processing. Few of the biggest challenges during the upgrade were to: 1. Provide a screen similar to the payment batchset workbench with functionality to submit payments for processing for several payment templates at a time. 2. Ability to choose selected payment template f rom the set for processing. 3. Ability to add new payment template to the set for processing.
Bank Account
Payment Template Page 4 of 6
For Internal Use Only
Payment process Prof ile Payment document
Payments flow in R12
Payment
formats:
In 11i
a payment format is a concurrent program that can be of any type for example XML, sqlplus, plsql procedure, oracle reports, Host, Java concurrent program etc. However in R12 all the standard formats have been setup to use the XML publisher template and all the custom formats need to be def ined using XML publisher templates. The
client has 7 custom payment format def ined using plsql procedures. Upgrading to R12 would require us to redef ine all of these formats through XML templates. This was particular an issue as the time duration for the upgrade project was less and redoing all the custom formats would mean extensive testing with the bank which usually takes up a signif icant amount time and resource. The next
big challenges were to:
1. Design the system in such a way that it reuses the existing plsql format programs. 2. Reduce the amount of time required for testing by user and the bank.
The
upgrade involved Design, mapping, customization and development of existing payment process to R12.
For Internal Use Only
Page 5 of 6
There
were various challenges encountered during the upgrade the following briefly explains how issues were approach and solved. 1) DESIGN: During design an approach had to be determined to setup the payments module as the payment process has signif icantly changed in R12 and new features like payment process prof iles, payment templates, formats, templates and the payments manager dashboard had to be used. Functionality similar to the payment workbench had to be provided. 2) MAPPING: Mapping involves creating a payment template for every payment batch line f rom the payment batch set in 11i. There are about 400 templates that were needed to be created and each of these takes 5 minutes when done manually. This would amount to around 6 hours if 4 people did it and this was still not a practical option as a) Manual entries are prone to errors. b) Post upgrade the nightly batch would be run and there may not be a 6 hour gap between post upgrade and nightly batch run. 3) CUSTOMIZATION: The payment batch set functionality was not longer available in R12 and an alternative to that had to be provided to the business to enable them to easily process the payment while providing the same flexibility that a payment batch set workbench provided. Payment dashboard access had to be customized to segregate the payment processes based on the user roles. 4) DEVELOPMENT: Custom Payment format programs for ACH, WIRES, CHECKS, the positive pay and separate remittance advice program had to be modif ied. '(6,*1
(The solution for the above is discussed in the solutions and implementation part)
Solution and Implementation The
above challenges were addressed by using look ups and form personalization.
Oracle provides the lookup functions to store lookup name values this was used to def ine a payment template set. Each template set in the
For Internal Use Only
Page 6 of 6
