CUSTOMIZATION AND IMPLEMENTATION OF ORACLE PAYMENT IN R12.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
mainframe system used earlier. This included implementing the AR, AP GL, project accounting, project
costing and fixed assets modules. The client is now upgrading the 11.5.10.2 version 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 outflows. Additionally, 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 defined based on the disbursement type
(domestic or international), payment format and payment currency. Apart from submission of payment
batch set process the payment batchset workbench enables user to define new payment batches for a

For Internal Use Only Page 3 of 6

payment batchset and selective choose certain payments batches from the payment batchset for
processing.

When a payment batchset is submitted for processing, the chosen payment batches defined in batch set
can be selected, built, formatted and confirmed. 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 defines the paygroup, payment currency, operating unit and payment date for each
disbursement bank account, payment document, payment process profile and exchange rate. It also
helps in defining the process automation options for the payment and handling validation error for
document and payments.

A payment template needs to have a payment process profile associate to it if the payment process
needs to be automated. This is necessary because the Payment process profile 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 profile 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 defined in
the specifications provided by the banks which process the payments.

In R12 a template has been defined 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 from 11i. However unlike 11i there is not front 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 from the set for processing.
3. Ability to add new payment template to the set for processing.

Payment Template
Bank Account
For Internal Use Only Page 4 of 6
Payment process Profile

Payment document
Format
 XML Template

Data definition

Concurrent Program

Executable

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 defined using
XML publisher templates.

The client has 7 custom payment format defined using plsql procedures. Upgrading to R12 would
require us to redefine 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 significant 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 significantly changed in R12 and new features like payment process profiles, 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 from 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 modified.

DESIGN:

(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 define a payment
template set. Each template set in the

For Internal Use Only Page 6 of 6