r12 payments

8/17/2019 R12 Payments

1/35

COLLABORATE 13 – OAUG Forum Page 1 of 35

Copyright ©2013 Bechtel Corporation

Oracle R12 Payments: An In-depth Technical Setup Configuration for

R12 Upgrade

Vinod Dua

Bechtel Corporation

Editor’s Note: The purpose of this paper is to describe the high-level technical configuration for

Release 12 Payment process. Since the setup configuration of payment process has drastically changed

in Release 12, this paper has attempted to highlight all the changes in comparison with 11i payment

configuration. Additionally, some valuable tips have been addressed to speed up the customizations

development.

Overview

Bechtel is among the most respected engineering, procurement, and construction companies in the

world. We stand apart for our ability to get the job done right – no matter how big, how complex, or howremote the project. For 115 years, customers have placed their confidence in Bechtel’s ability to manage

large projects in which they have substantial investments. Our legacy of more than 22,000 successful

projects in 140 countries reflects a longstanding commitment to quality. It’s a commitment we are proud of

and one that’s been substantiated by independent audits and customer loyalty.

Bechtel implemented Oracle Financials (Release 9.4) in the early 1990’s. Since then it has been

upgraded multiple times and software patches have also been regularly applied to stay current with the

technology. In 1999, all financial instances were upgraded to 10.7 to meet Y2K requirements. In 2003, a

major initiative was undertaken and all 10.7 financial instances were consolidated into One Single Global

Instance (Oracle 11i). This effort took almost three years. Following this consolidation, Oracle 11i has

been upgraded to Release 11.5.10 and Oracle patches have been regularly applied.

In 2007, Oracle released Oracle R12. The premier support for Release 11i ended in 2010 and the

extended support ends in 2013. Due to this, a business decision was made to upgrade Oracle Release

11i to Oracle Release 12.1.3, which is the latest release.

The upgrade to Release 12 requires database versions to be 11g. As a result, all the financial instances

are being upgraded to 11g in preparation for the upgrade to R12, occurring in the 1st PMC Oracle cycle.

Release 12 also includes many architectural changes in technology and processes, therefore an

extensive study and analysis is being conducted to capture all the improvements and key changes.

Bechtel has three 11i financial instances, and many other custom application 11i instances. The R12

upgrade has been successfully done on the two smaller financial instances, and several custom

application instances. The complex financial instance with 1TB database, 25 sets of books, and 24

operating units is under development and unit testing.

R12 Payments Benefits

In Oracle Release 12, the Centralized Payment Processing engine combines both Funds Disbursement

and Funds Capture into one payment system. Organizations can now leverage the centralized processing

engine across multiple operating units, currencies, payment methods, and pay groups to increase the

real-time visibility of cash inflows and outflows.


2/35



In Oracle Release 12, Payments have a new concept of “Payment Process Request” similar to Release

11i “Payment Batch.” This feature has better controls, more visibility and flexibility, and thus has

enhanced the overall performance of Payment process.

Oracle has also streamlined all the customizations by introducing standard payment XML tags. Custom

objects typically include check formats and PL/SQL Packages to create Electronic Data Interface (EDI)

files to be sent to the trading partners. To speed up the customizations, custom hooks to standardpackages have also been provided. Overall, the configuration/customizations changed in R12 were

designed to help organizations improve their payment processes.

The new release of Oracle R12 has brought in many enhancements to the Payment Process. Some of

the key benefits are:

Offers Centralized Payment Processing to consolidate Payment runs

Gives Payables transparency by using Payment Process Manager Dashboard

Provides Payment Process Controls and enhanced accurate Payment Information using PaymentProcess Profile

Eliminates redundant Payment Processes using Payment Templates

Uses MOAC to help the Shared Service Centers drive cost savings and increase the quality ofinformation they provide

Includes Banks and Branches as part of the TCA architecture

Increases effectiveness of Master Data – Fewer Configuration Steps

Reduces Customization by using Standard Oracle-provided XML Tags and RTF Templates Allows for easy customization through the use of Standard Extensions or hooks to XML Tags

Things to Consider

During an upgrade from Release 11i to Release12, Oracle recommends the following:

Confirm is cancel the status of all open Payment batches Update the NULL Bank BranchesCountry Code to either “USA,” or the respective country code

Closely analyze and document all customizations

Use standard custom naming conventions; it is advisable to use the Custom Objects names thesame as one would use Oracle Standard Objects

Reduce downtime by using SQL to validate the configuration

R12 Payments Process Changes

The R12 Payments has many process changes. Key changes include:

To create Quick Checks / Manual Checks, Payment Process Profile is used, which is new to R12

The use of Templates to run/schedule payment batches The use of Payment Dashboard to forecast cash balances and monitor payment batches


3/35



R12 Payment Setup Technical Configuration Changes

In the upgrade from Oracle 11i to Oracle Release 12, many changes have been made to Payment

Configuration.

Banks, Branches and Bank Accounts

This section will explain the details of Banks, Branches, Bank Accounts, and the Payment Process. Ineach section, the 11i and R12 tables and changes will be described. Let’s take an existing bank accountfrom 11i instance and see the corresponding changes in R12.

Table 1.1 – Details

S No Form Name Field Name Value

1 Banks Bank Name XXX Bank Name

Bank Branch Name XXX Bank Branch Name

Institution Bank

Description XXX Bank Name2 Address Country France

Address Line1 X1 Address 1

Address Line 2 X2 Address 2

City PARIS

Postal Code 92974

3 Bank Accounts Operating Unit XXX Operating Unit

Bank Account Name XXX Bank Account Name

Bank Account Number X123456

Account Type Internal

Currency EUR

Cash Account Cash Account

Multiple Currency Payments Yes

Allow Zero Payments Yes

Banks

The Banks in Release 12 are treated as PARTIES, as they are shared with AR, CM, and Payables. Theyare part of TCA architecture. Note that when we upgrade from 11i to R12, the AP_BANK_BRANCHS

table still exists but it has no role in R12. The Banks from this table are converted to HZ_PARTIES and

this table is now obsolete. When you create a new Bank, the data gets inserted into HZ_PARTIES.


4/35



Table 1.1.1 – Banks

Oracle 11i Oracle R12

Table Name Column Name Table Name Column Name

· · · ·

AP_BANK_BRANCHES BANK_NAME HZ_PARTIES PARTY_NAME

The following columns in HZ_PARTIES are important.

Table 1.1.2 – Table Details

Table Name Column Name Comments

HZ_PARTIESPARTY_ID This will be used in

CE_BANK_BRANCHES_V asBANK_PARTY_ID

PARTY_NUMBER System Generated

PARTY_NAME Bank Name

PARTY_TYPE Defaults to ORGANIZATION

ORIG_SYSTEM_REFERENCE AP BANK:1000 – Points to 11iBank_Branch_Id

ORIG_SYSTEM_REFERENCE AP BRANCH:1000 – Points to 11iBank_Branch_Id

From the Payables Super User Responsibility, navigate to the below screen

This screen shows all the Banks, Branches and Bank Accounts. This screen is same from any AP Super

user r esponsibility. The “+” sign under each country indicates that there are many banks and branchesdefined in the country. As we drill down, the “Total Accounts” column indicates the number of Bank Accounts associated with each branch.

Bank Branch

The Banks Branches in Release 12 are also part of TCA architecture. The Bank Branch is created as

another record in HZ_PARTIES. The Bank and Bank Branches are linked together by


5/35



HZ_RELATIONSHIPS. The Oracle 11i AP_BANK_BRANCHES table is replaced by

AP_BANK_BRANCHES_V. This view has the base tables from HZ _PARTIES. Note that when we

upgrade from 11i to R12, the AP_BANK_BRANCHS table still exists but it has no role in R12.

Table 1.2.1 – Tables

Oracle 11i Oracle R12Table Name Column Name Table Name Column Name

· · · ·

AP_BANK_BRANCH

ES

BANK_BRANCH_NA

ME HZ_PARTIES PARTY_NAME

AP_BANK_BRANCH

ES BANK_NUM

HZ_ORGANIZATION_PROFIL

ES

BANK_OR_BRANCH_NUMB

ER

The following Release 12 tables are very important.




CE_BANK_BRANCHES_V asBANK_PARTY_ID


PARTY_NAME Bank Branch Name

PARTY_TYPE Defaults to ORGANIZATION

ORIG_SYSTEM_REFERENCE AP BRANCH:1000 – Points to 11iBank_Branch_Id

HZ_RELATIONSHIPS SUBJECT_ID This is the PARTY_ID from HZ_PARTIES.This can be for a Bank or a Branch

SUBJECT_TABLE_NAME Always HZ_PARTIES

OBJECT_IDVery Important field. For a Bank, this fieldwill have the PARTY_ID of the BankBranch.

OBJECT_TABLE_NAME Always HZ_PARTIES

RELATIONSHIP_CODEFor a Bank, it is HAS_BRANCH and for aBank Branch it has BRANCH_OF

RELATIONSHIP_TYPE BANK_AND_BRANCH

HZ_ORGANIZATION_PROFILES PARTY_IDPARTY_ID of the Bank Branch from

HZ_PARTIES

BANK_OR_BRANCH_NUMBER Bank Branch Number

BRANCH_CODE Bank Branch Number


6/35



The Banks Branches is now a View in Release 12.

Table 1.2.3 – View Details

View Name Tables Used in the View Comments

CE_BANK_BRANCHES_V HZ_ORGANIZATION_PROFILES

HZ_CODE_ASSIGNMENTS

HZ_PARTIES

HZ_ORGANIZATION_PROFILES

HZ_RELATIONSHIPS

HZ_CONTACT_POINTS

Bank Accounts

The Banks Accounts in Release 12 are also part of TCA architecture. The Bank Account is created as

another record in HZ_PARTIES. Note that when we upgrade from 11i to R12, the

AP_BANK_ACCOUNTS_ALL table still exists but it has no role in R12.

From the Payables Super User Responsibility, navigate to the below screen.

A simple search region is displayed when the “Bank Accounts” is opened. To find an existing 11iConverted bank account, type the bank account name with a % sign. Some of the 11i bank accountnames have been changed in Release 12. They have been appended by the 11i Operating Unit as shownin the next screen.


7/35



In Release 12 the INTERNAL Bank Accounts have been separated from EXTERNAL Bank Accounts in

two different tables.




· · · ·

AP_BANK_ACCOUNTS_A

LL

BANK_ACCOUNT_NA

ME

CE_BANK_ACCOUNT

S BANK_ACCOUNT_NAME

BANK_ACCOUNT_NU

M BANK_ACCOUNT_NUM

BANK_BRANCH_ID

BANK_BRANCH_ID. This is

the PARTY_ID of the Bank

Branch from HZ_PARTIES

BANK_ID. This is the

PARTY_ID of the Bank from

HZ_PARTIES

SET_OF_BOOKS_ID

ACCOUNT_OWNER_PARTY_

ID

CURRENCY_CODE CURRENCY_CODE

ORG_ID ACCOUNT_OWNER_ORG_ID

HZ_PARTIES


8/35



When a new INTERNAL Bank Account is created in Release 12, a record is inserted in HZ_PARTIES aswell. For an upgrade from 11i to Release 12, HZ_PARTIES does not have the Bank Account.




CE_BANK_ACCOUNTSBRANCHES_V asBANK_PARTY_ID


PARTY_NAME Bank Account Name

PARTY_TYPE Defaults to PARTY_RELATIONSHIP

ORIG_SYSTEM_REFERENCE NULL

Check Formats

The Check Formats in Release 12 are XML Templates. The table AP_CHECK_FORMATS is now

obsolete. All the Standard Check Formats have been converted to XML Template. The names of these

templates can be found in IBY_FORMATS_B. The AP_CHECK_FORMATS table still exists but it has no

role in R12. The 11i Check Format executable name can be easily queried in this table using the

REFERENCE_FORMAT_CODE. The R12 Format Code, Format Type Code, and Format Template Code

can then be derived for each Oracle Standard Check Format.




· · · ·

AP_CHECK_FORMATS NAME IBY_FORMATS_TL FORMAT_NAME

IBY_FORMATS_B FORMAT_CODE

FORMAT_TYPE_CODE

FORMAT_TEMPLATE_CODE

Therefore, in Release 12, ALL THE CUSTOM FORMATS have to be converted to XML Template.



9/35



The Administration of Formats is an OA Framework Form.

The Setup of Formats involves the following steps:a. Create a RTF Template for the Check/EFT Formatb. Register the Templatec. Define Format, link them to XML Template and assign other validations

For an existing XML Format, the “Formats” Task Name opens up with the below screen.


10/35



To create a new Format, click the “Create” Button.

All the 11i Formats have been converted into XML Template. The next few screen shots will show how tocreate a Custom Check Formats which does not upgrade.

A Def ault “Code” is “SAMPLE_FORMAT_CODE”. This needs to be changed to Custom Format Code

which will be used in the Template.


11/35



The other information for “Data Extract” has the following options.

Choose “Oracle Payments Funds Disbursement Payment Instruction Extract, Version 1.0”

a. “XML Publisher Template” and “Name” is the Registered Template and Name.b. “Type “. Choose “Disbursement Payment Instruction”.

Check Stocks

The Check Stocks in Release 12 are associated with Bank Account Setup. This is the same as 11i. The

table AP_CHECK_STOCKS_ALL still exists but it has no role in R12.




· · · ·

AP_CHECK_STOCKS_ALL NAME


12/35



Perform a “Simple Search” on the Bank Account Name. The 11i Bank Account Name is appended withOperating Unit.

The results of the “Simple Search” is as shown :

Select the Bank Account Name using the “Radio” Button. Click on “Manage Payment Documents.”


13/35



Once the Bank Account has been queried and selected, the existing Payment Documents will show up:


14/35



For new Check Stocks, use the “Create” button and enter the required information as in 11i.


15/35



Valuable Tips prior to the R12 Upgrade

Before the Upgrade is completed, make sure the following is done:

1. Make sure all Payment Batches are either “Canceled” or “Confirmed”. There should not be any

payment batch in any other stat.

2. Update the NULL Bank Country Code to the required country. If this is not done, R12 defaults the

NULL country code to “United States.”

3. Cleanup banks, branches, and bank accounts before the upgrade.

Valuable Tips after the R12 Upgrade

The Oracle Release 12 has some new features in every module which has helped the organizations to

secure data and control access. It has also enhanced the usability of some modules, especially in

payments.

After the Upgrade is done, use the following SQL’s to speed up your configuration.

1. By default – Masking is setup on Internal and External Bank Accounts. If the same bank account

is used in multiple operating units, the upgrade process appends the ORG_ID after the bank

account name. Also if the first four characters of Bank Account Numbers are same, then

unmasking helps.


Click “Payment Administrator”. Go to Task “System Security Options”


16/35



Set up “Number of Digits” to display for External Bank Accounts

2. Bank Accounts Tolerances fields for Internal Bank Accounts are now mandatory in the Bank

Accounts OA Form. If you are editing any internal bank account, you will have to use a tolerance

amount and percentage. Use the following SQL to update them:

UPDATE ce_bank_accountsSET ap_amount_tolerance = 0,ar_amount_tolerance = 0,

ap_percent_tolerance = 0,ar_percent_tolerance = 0,ce_amount_tolerance = 0,ce_percent_tolerance = 0,recon_oi_amount_tolerance = 0,recon_oi_perence_tolerance = 0

WHERE account_classification = 'INTERNAL'

3. Bank Accounts Descriptive Flex Fields (DFF) are the same but in R12.1.3 they are hosted inCE_BANK_ACCOUNTS table. In 11i, if a Bank Account Number has a dash “-“, the dash will be

removed in R12. The 11i bank account number with dashes has been upgraded to

CE_BANK_ACCOUNTS. MASKED_ACCOUNT_NUM.

4. The Bank Account number length is restricted to 11 characters in the Bank Accounts OAF Form.

5. The Documents for each bank account has been moved to a different table:

IBY_DOCUMENTS_B.


17/35



6. The Bank Account Numbers are masked in R12. The masking can be done either in thebeginning of the bank account number or at the end of the bank account number. After masking,only the first four or last four characters will show in the screen.

7. The Bank Account Number cannot have special characters such as hyphens, dashes, colons, orother special characters.

8. After the upgrade, check to see if the Bank Account Number is enabled for “Payables” and “CashManagement”


18/35



How to Speed Up Payment Configuration and Customizations

E-Business Suite Customizations are the key to every upgrade process. Customization costs can inflate

the lifecycle effort cost by at least 75%. As a result, the challenge every organization faces today is

determining what customizations have been made, and then deciding what to do about them. Since every

organization has specific customizations, Oracle has attempted to document many examples and

recommend the best practice to bring those customizations into R12. Oracle has more than 15 different

types of customizations, modifications, and extensions. Here are some of the important customizations

which are affected by the R12 upgrade:

Folders – If you have created custom folders, you will have to re-create them again after theupgrade.

Form Personalization - Some of the Form Personalization will work but there are significantchanges in Invoice Workbench and Supplier Workbench. Additionally, Payments Administration isa new module and all personalization will have to be created again.

Custom Check Formats will have to be re-done using XML/eText.

Any EDI Payment Program written in PL/SQL Package will have to be rewritten using StandardOracle XML Template.

If you have used Descriptive Flex Fields (DFF) from AP_BANK_ACCOUNTS_ALL table for anyreports, then those reports will need to be changed to point to CE_BANK_ACCOUNTS.

Types of Payments

In Release 11i, many organizations have four major categories of payments:

a. Clearing or Quick Check Payments – Mainly used for Clearing or recording purposes

b. Manual Checks – Printing on a custom check stock

c. EDI Payments - Batch Processing for Electronic Data Exchange (EDI)

d. Third Party Payments with specific file format

To speed up customizations for the above payment types, do a quick analysis of the existing bank, bankbranches, bank accounts, and check formats in 11i using the following SQL. You can either hard-code theOperating Unit in the SQL or use the bank accounts which have been used to pay in the last 18-24months depending on your needs.

SELECT hou.name,abaa.org_id,aipa.set_of_books_id sob,abb.bank_name,abb.bank_branch_name,abb.bank_num,abaa.bank_branch_id,

aca.currency_code,gcc.concatenated_segments cash_account,abaa.asset_code_combination_id cash_account_id,abaa.bank_account_name,abaa.bank_account_num,abaa.bank_account_id,aia.pay_group_lookup_code,aca.payment_method_lookup_code,acsa.name document_name,


19/35



max(aca.check_date ) last_used_date,acsa.check_stock_id,acf.name payment_format_name

FROM ap.ap_checks_all aca,ap.ap_invoice_payments_all aipa,ap.ap_invoices_all aia,ap.ap_check_stocks_all acsa,ap.ap_bank_accounts_all abaa,ap.ap_bank_branches abb,apps.gl_code_combinations_kfv gcc,ap.ap_check_formats acf ,hr_operating_units hou

WHERE aca.check_id = aipa.check_id AND aipa.invoice_id = aia.invoice_id AND aca.check_stock_id = acsa.check_stock_id AND aca.bank_account_id = abaa.bank_account_id AND abb.bank_branch_id = abaa.bank_branch_id AND gcc.code_combination_id = abaa.asset_code_combination_id AND acsa.check_format_id = acf.check_format_id AND aca.check_date >= '01-JAN-12'

AND aca.org_id = hou.organization_idGROUP BY aca.bank_account_name,

aia.pay_group_lookup_code,aca.payment_method_lookup_code,acsa.name,acsa.check_stock_id,abaa.org_id,aipa.set_of_books_id,abaa.bank_account_id,abb.bank_name,abb.bank_num,abb.bank_branch_name,abaa.bank_branch_id,

abaa.bank_account_name,abaa.bank_account_num,abaa.asset_code_combination_id,gcc.concatenated_segments,acf.name,acf.check_format_id,aca.currency_code,

hou.nameORDER BY 2,max(aca.check_date );

Download the output of this SQL into an Excel File.

System OrgId SOB

BankAccountId Bank Branch

BankBranchId

XXX_Clearing 5001 1002 10002 XXX Bank Branch 10000

XXX_Quick Check 5006 1009 10020 XXX Bank Branch 10006

XXX_Manual_Check_Stock 5166 11009 10282 XX_Bank_BR1 20008

XXX_EDI 5366 22009 15642 XX_Bank_BR2 210008


20/35



ZZ17_Third_Party 5426 25009 16028 XX_Bank_BR3 223008

Bank Branch Name Bank NumberCurrencyCode

CashAccount

Bank AccountName

XXX Bank Branch Name EUR XXXX Bank AccountName 1

XXX Bank Branch Name CNY XX1XX Bank AccountName 2

XXX Bank BranchName1 03030 USD XX2

XX Bank AccountName 3

XXX Bank BranchName2 2333 AUD XX3


XXX Bank BranchName3 3300 PEN XX4


BankAccountNumber

DocumentName

CheckStockId Payment Format Name

X12344555 CLEARING-EURO 10003 Clearing Payment-EUR

X12344555AQUICK-CHECK-CNY 10013

Evergreen Long CHK FormatCNY

X12344555B USD_CHECK 10273 BEC-PRAIRE-QCHK

X12344555C EDI-EFT-AUD 10773 BAP-EDI-AUD-EFT

X12344555D PAYLINK-PEN 11353 Bechtel Paylink Format - PEN

Format Payment Program Program Short Name

CheckFormatId

PaymentMethod

Oracle Standard Format Payments APXPBFOR 10001 CLEARING

Evergreen Format Payments Program APXPBFEG 10004 CHECK

BECHTEL CUSTOM QUICKCHECK BAPCKFEG1 10224 CHECK

Bechtel EDI Format Program BAP_EDI_FORMAT 10504 EFT

Bechtel Paylink Format Program BAP_PAYLINK_FORMAT 10984 PAYLINK

R12 - IBY Format Code

R12 - IBYFormatName

Custom R12 -Payment ProcessProfile Code

Custom R12 -PaymentProcess Profile

IBY_PAY_CHK_STANDARD_1StandardCheck Format

BAP_PAYMENT_CLEARING

Bechtel - ClearingPayment

IBY_PAY_CHK_STANDARD_2ExternalCheck Format BAP_PAYMENT_CHECK

Bechtel - CheckPayment


21/35



There are three important fields, Payment Format Name, Format Payment Program, andProgram Short Name. Sort the data by these fields.

Query the program short name from 11i using the below query to find out the corresponding R12IBY Format Name.

SELECT ifb.format_code r12_format_code,ifb.format_template_code r12_format_template_code,ift.format_name r12_format_name

FROM ifb_formats_b ifb,ifb_formats_tl ift

WHERE ifb.format_code = ift.format_code AND ift.langugae = ‘US’ AND ifb.reference_format_code = ‘program_short_name’;

Update the Excel with IBY Format Code and IBY Format Name.

Clearing / Quick Check Payment

To minimize customization and configuration, follow these steps:

Create a custom check format for recording/clearing using the standard R12 format code.

Navigation Path: Setups/Payments/Payment Administrator

Create new Format.

Enter the following details

Field Name Field Value

Code CUSTOM_FORMAT_CODE

Name Custom Format Code Name

Type Disbursement Payment Instruction


22/35



Data Extract

Oracle Payments Funds Disbursement PaymentFormat Instruction Extract, Version 1.0

XML Publisher Template Standard Check Format

Attachments None

Create a Custom Payment Process Profile.



Field Name Field Value Comments

Code CUSTOM_CHECK_PROFILE

Name Custom Check Profile

Processing Type Electronic

Electronic Processing Channel Oracle Payments

Payment Completion Point

When the PaymentInstruction is Formatted

Allow Manual Setting ofpayment Completion No

Payment Instruction Format Custom Format Code Name

This is under"PaymentInstruction

Format" Tab


23/35



Now the R12 Check Stock table is ready to be updated with this new Format. This willautomatically connect the newly created custom Payment process profile. This can be done for all

bank accounts possessing this check Format in 11i.

UPDATE ce_payment_documentsSET object_version_number = 2,

format_code = 'CUSTOM_FORMAT_CODE'WHERE internal_bank_account_id IN (SELECT bank_account_id FROM ap_bank_accounts_all)

Note: The 11i Bank accounts table gets moved as is after the upgrade, but it is no longer used.

This step helps you when making manual/quick payments for clearing. The “Payment ProcessProfile” then defaults for each document name for the bank account. If this is not done, then you

have multiple payment process profile to choose which is confusing, cumbersome, and error

prone.

Care must be taken as the above SQL updates all the check stocks to Clearing/Quick Check.

Manual Check

Manual checks printed on a check stock stationary must be customized in R12. The 11i check stock is notupgraded to R12. To customize the check stocks, follow the steps:

In 11i, generally the custom check stock is copied from the Standard Oracle check format, suchas “Evergreen Format.” Find the concurrent program short name for the standard check format.

Query the “Program Short Name” in IBY_FORMATS_B.REFERENCE_FORMAT_CODE.

Find out the “Format Code” and “Format Template Code” from the table.

This is the starting point for the Customization.

The setup of Custom Formats involves the following steps:

Create a RTF Template for the Check/EFT Format Register the Template Define Format, link them to XML Template and assign other validations

To create a new Format, use the “Create” Button

A Default “Code” is “SAMPLE_FORMAT_CODE>” This needs to be changed to Custom Format

Code which has been created as a Template.


24/35



The other information, such as, “Data Extract,” has the following options

Choose “Oracle Payments Funds Disbursement Payment Instruction Extract, Version 1.0”

“XML Publisher Template” and “Name” is the Registered Template and Name “Type.”. Choose “Disbursement Payment Instruction”




25/35





Code CUSTOM_CHECK_PROFILE

Name Custom Check Profile

Processing Type Electronic



When the PaymentInstruction is Formatted


Payment Instruction Format Custom Format Code Name

This is under"PaymentInstructionFormat" Tab

Once the Custom Check Stock is configured, attach it to the Bank Account as a new PaymentDocument. The Custom Payment Process Profile automatically gets associated.

Create a Payment Batch using the Bank Account and Custom Payment Document.

The output of the Payment Batch is an RTF Template.

Delete the xml fields which are not required and re-format the RTF Template to look similar to the11i Check Format.

EDI Payments

Every organization has customized check stocks for printing checks. When we complete the upgrade

from 11i to R12, none of the custom check formats will be converted. The custom check stocks will

have to be converted to the RTF template using the standard payment XML Tag.

Payment Batches are normally created when the organization is either printing a check on a pre-printed check stock or creating an EDI file to be sent to the bank.

In both circumstances, Oracle R12 provides a standard mechanism to create an XML tag. ThisXML tag can then be used to create an RTF template for Check printing, or it can be used as

input for an EDI file. One standard XML tag can be created for all custom check formats and EDI files.

To create an standard payment XML tag, it is necessary to create a new Format and a PaymentProcess Profile as shown below:


26/35




Create new Format.

Enter the following details.

FieldName Field Value

Code CUSTOM_FORMAT_CODE_FOR_XML

Name Custom Format Code Name for XML

Type Disbursement Payment Instruction

Data Extract

Oracle Payments Funds Disbursement PaymentFormat Instruction Extract, Version 1.0

XML Publisher Template Extract Identity

Attachments None




27/35





Code CUSTOM_CHECK_PROFILE_XML

Name Custom Check Profile for XML

Processing Type ElectronicElectronic ProcessingChannel Oracle Payments


When the Payment Instruction isFormatted


Create Payment System Transmissions



Select Protocol Local File System Delivery Click "Create Configuration"

Name Bechtel File System Delivery

Enter Name and leave the rest

as default


28/35



Create Payment Systems




Code BAP_EDI

Name Bechtel EDI Payment Systems

Processing Model Processor

Bank Account

Transfer Yes This is under "Funds Capture"

Name Bechtel EDI Format Code This is under " Formats"

Type Disbursement Payment Instruction This is under " Formats"

Name Local File System Delivery This is under " Formats"

Add a new row under "Settings

Required by Payment Systems"

Code TEST

Name TEST

Data Type Date


29/35



Update the Payment Process Profile for “Payment System” Tab

Search for “BAP_EDI_PAYMENT_PROFILE

Click “Update”

Navigate to “Payment System” Tab and enter the details as shown below

Also update the following:

Field Name Field Value


Payment Completion Point When the Payment Instruction is Transmitted

Now run a Payment batch using this new Payment Process Profile. You can either create a newTemplate or enter the selection criteria for the batch manually. Make sure under the “Process Automation” tab, “Stop Process for Review After Scheduled Payment Selection” is checked. Thisprompts the payment batch to stop after the creation.

Select / De-select invoices for this payment batch.

Submit the Payment batch for completion. Once the batch has been “Formatted” the XML tag can be found in the output of the Concurrent

Program “Format Payment Instructions.”


30/35



Output of “Format Payment Instructions” is the Standard Oracle XML Tag

-

+ Batch Information

+ Payment Process Profile Name

+ Payment Format Code

+ Document Name

+ Total Checks

+ Payer, Bank Accounts and Details

+ Organization Details

For creating an extension or a custom hook to the standard Payment XML tag, Oracle hasprovided a package “IBY_FD_EXTRACT_PUB”.

This package can be used to create custom tags as needed:

XML File Level

IBY_FD_EXTRACT_EXT

_PUB Function To

Modify

Example of Parameter Usage

OutboundPaymentInstr

uction

Get_Ins_Ext_Agg(p_pay

ment_instruction_id IN

NUMBER)

SELECT * FROM

iby_pay_instructions_all WHERE

payment_instruction_id =

p_payment_instruction_id;

OutboundPaymentGet_Pmt_Ext_Agg(p_pa

yment_id IN NUMBER)

SELECT * FROM iby_payments_all

ipa WHERE ipa.payment_id =

p_payment_id;

DocumentPayable

Get_Doc_Ext_Agg(p_do

cument_payable_id IN

NUMBER)

SELECT * FROM

iby_docs_payable_all dp WHERE

dp.document_payable_id =

P_document_payable_id;

DocumentPayableLine

Get_Docline_Ext_Agg(p

_document_payable_id

IN NUMBER,

p_line_number IN

NUMBER)


31/35



PaymentProcessProfile

Get_Ppr_Ext_Agg(p_pa

yment_service_request_

id IN NUMBER)

SELECT * FROM

iby_pay_service_requests WHERE

payment_service_request_id =

p_payment_service_request_id;

Top Level: Outbound Payment Instruction:

This is the top level of the XML File and there is one Outbound Payment Instruction per

Payment process request.

Level 2: Outbound Payment:

This is the Payment Level, i.e. an individual check or BACS payment amount to a

supplier. There can be multiple Outbound Payments per Outbound Payment Instruction.

Level 3: Document Payable: Details the documents (i.e. invoices) being paid. There can be multiple Document

Payable tags per Outbound Payment.

Level 4: Document Payable Line:

This level details the invoice line. There can be multiple Document Payable Line tags per

Document Payable.

Third-Party Payments

Every organization has sometimes a very unique requirement when making payments. This is due to

legacy system or the third-party company which is being used for making payments. The file format forthese kinds of payments is very specific and unique which cannot be easily customized using RTF

Template or eText. The R12 Payment configuration and Customization for these kinds of file formats is

not recommended by Oracle, but still can be done. The assumption is that a Concurrent Program already

exists which is either a SQL or a PL/SQL package which creates this file format.

Follow the steps to accomplish exactly the same file format:

Create a new Custom Payment Method – “Third-Party Payment Method”

Create a new Custom Format – “Third-Party Format;” use the Oracle Standard XML Template

used for Clearing Payments or Check Payment

Create a new Custom Payment Process Profile using the “Third-Party Payment Method” and

specify any currency if applicable

Add the “Organization Names” to the Custom Payment Process Profile to make it very specific to

the Third-party payment


32/35



Create a Custom Payment Document (Check Stock) for the Internal Bank Account using the

Custom Third Party Format

Create a Payment Template with all the required Payment Attributes; Disbursement Bank

Account, Payment Document Name, Payment Process Profile, and Payment Exchange Rate

Make sure under “Process Automation” Tab, the check box labeled “Stop Process for Review

After Scheduled Payment Selection” is checked

Create a Payment Batch using this new Template

Select/De-Select invoices and “Submit” the Payment batch

The Payment Batch completes normally and stops at the status “Formatting”

Change the Custom 11i SQL or PL/SQL Package code to reflect the R12 Payment tables

11i Tables Comments R12 Tables AP_INV_SELECTION_CRITERIA_ALL No Change AP_INV_SELECTION_CRITERIA_ALL

PO_VENDORS Changed AP_SUPPLIERS

PO_VENDOR_SITES Changed AP_SUPPLIER_SITES_ALL

AP_SELECTED_INVOICE_CHECKS Obsolete IBY_DOCS_PAYABLE_ALL

AP_SELECTED_INVOICES_ALL No Change AP_SELECTED_INVOICES_ALL

IBY_PAY_SERVICE_REQUESTS

IBY_PAYMENTS_ALL

Change the program to pick up all the selected invoices with Payment Batch Status =

“Formatting”

Run the Custom program to format the file as required


33/35



If the formatted file needs to be FTP to the Third-Party software, create a small shell script to FTP

the file

Update the status of the Payment batch to “Formatted” after the file has been successfully FTP to

the Third-Party system

Confirm the Payment Batch

Note: This is a Non-Standard way of creating a Payment File.

Lessons Learned

During the R12 upgrade process, and in particular for the Payments, the following points could speed up

configuration and save an organization lost productivity caused by rework, while limiting the need for

additional patches.

First and foremost, make sure to cancel all payment batches in 11i before upgrading to R12. The

Payment batch status of all the batches should be e ither “Confirmed” or “Canceled.”

Cleanup Bank, Branches, and Bank Accounts in 11i prior to the upgrade. Make sure the NULL

country codes for Banks are updated with a Country code. If this step is not done, during the R12

upgrade the Banks country code will default to “United States.”

The Location Code used in 11i for Legal Entity MUST have a valid Location Address, in particular

“Country.” The R12 Upgrade is dependent on this. The Bank Accounts and other default

configuration will be incomplete if this step is missed. The only way to repair this is to apply

additional patches.

In R12, because the Banks, Branches and Bank Accounts are now Parties, the upgrade process

makes some of the banks redundant if it is setup by currency in 11i.

It is advised to unmask the Bank Account Numbers for initial configuration and setups. When a Payment Batch is created in R12 using the XML tag, the “Check Number” tag does not

contain the “Check Number.” It contains a unique sequence “Payment Instruction ID.” Thus, care

must be taken to find the “Check Number“ from the “Payment Instruction ID” and update the

corresponding table when the EDI acknowledgement file is received from the bank.

The Oracle Standard XML Tag is very detailed and exhaustive. Oracle has incorporated almost

every minute detail of Payer, Payee, Bank, and other invoice information. Do not try to over-write

the Standard tag information using the Extension. Instead, try to configure correctly so that the

tag’s information gets populated during Payment Batch creation.

In 11i, “Pay Group” plays a very important role in Payment Batch process. In R12, the role of “Pay

Group” is very limited; it is only used to select invoices. The “Pay Group” is NOT saved in any

R12 payment table. Therefore, any customization in terms of reporting using the Pay Group is

difficult to achieve.

Do not underestimate EDI Payments using XML tags. Since this is relatively new in R12, end-to-

end testing is essential.

Make sure to print the XML RTF template for Check Stocks.


34/35



11i vs. R12 Payments: Table Level Comparison

We have also noted that many of the 11i Payment tables have changed in R12. Below is a summary of

some of the key configuration tables for 11i and R12.

S.No Process/Setup Oracle 11i TablesChange(Yes/No) R12 Tables

1 Supplier Workbench PO_VENDORS Yes AP_SUPPLIERS, HZ_PARTIES

2 Supplier Sites PO_VENOR_SITES_ALL Yes

AP_SUPPLIER_SITES_ALL,

HZ_RELATIONSHIPS,

HZ_RELATIONSHIP_TYPES,

HZ_ORG_CONTACTS,

HZ_ORG_CONTACT_ROLES,

HZ_CONTACT_POINTS, HZ_PARTY_SITES,

HZ_ORGANIZATION_PROFILES,

HZ_LOCATIONS

3 Banks and Branches AP_BANK_BRANCHES Yes

HZ_PARTIES,

HZ_ORGANIZATION_PROFILES,

HZ_RELATIONSHIPS,

4 Internal Bank Accounts AP_BANK_ACCOUNTS_ALL Yes

CE_BANK_ACCOUNTS,

CE_GL_ACCOUNTS_CCID,

CE_BANKS_V,CE_BANK_BRANCHES_V

7 Supplier Bank Accounts

AP_BANK_ACCOUNTS_ALL,

AP_BANK_ACCOUNT_USES_ALL Yes

IBY_EXTERNAL_PAYEES_ALL,

IBY_EXT_BANK_ACCOUNTS,

IBY_PMT_INSTR_USES_ALL,

CE_BANK_ACCOUNT_USES_ALL

8 Check Stocks AP_CHECK_STOCKS_ALL Yes

CE_PAYMENT_DOCUMENTS,

IBY_DOCUMENTS_B

9 Check Formats AP_CHECK_FORMATS Yes IBY_FORMATS_B, IBY_FORMATS_TL

10 Payment Methods LOOKUP TABLE Yes IBY_PAYMENT_METHODS_TL

S.No Process/Setup Oracle 11i

Change

(Yes/No)

Oracle R12 (What is the

change)

1 Quick /Manual Check

AP_INV_SELECTION_CRITERIA_ALL,

AP_CHECKS_ALL,

AP_PAYMENT_SCHEDULES_ALL Yes IBY_DOCS_PAYABLE_ALL

2 Payment Batch

AP_INV_SELECTION_CRITERIA_ALL,

AP_CHECKS_ALL,

AP_PAYMENT_SCHEDULES_ALL,

AP_SELECTED_INVOICES_ALL,

AP_SELECTED_CHECKS_ALL Yes

IBY_DOCS_PAYABLE_ALL,IBY_PAYMENTS_

ALL, IBY_PAY_SERVICE_REQUESTS,

IBY_PAY_INSTRUCTIONS_ALL

Payments

Setups


35/35

Conclusion

We have observed that Oracle Release 12 Payments has many benefits in terms of consolidation and

integration. The configuration has changed drastically, with added features for better control and

efficiency. That being said, it is not easy to navigate customization changes, even though Oracle has

standardized the XML Tags and RTF templates. The use of Extensions to achieve further customization

has enriched the development experience altogether. It would be in the best interest of any organization

to spend once some quality time in the development of these customizations/templates and protect them

against future patch applications, migrations, and upgrades.

Overall, the experience of Oracle Payments in Release 12 with regards to configuration and Payment

processing is very promising and is in the right direction of growth.