Skip Headers

Oracle Financials and Oracle Procurement Functional Upgrade Guide: Release 11i to Release 12
Release 12.1
Part Number E13482-03
Go to Table of Contents
Contents
Go to previous page
Previous
Go to next page
Next

Oracle Payments

This chapter covers the following topics:

Overview

In Release 12, the Oracle E-Business Suite introduces Oracle Payments, a highly configurable and robust engine to disburse and receive payments. In addition to new features, Oracle Payments offers functionality previously released as Oracle iPayment, which becomes obsolete with Release 12.

Advanced and Highly Configurable Formatting and Validations Framework

Oracle Payments provides a new formatting solution based on standard XML technology. In previous releases, payment formats required creation in proprietary Oracle reports technology. In Release 12, formats are created as templates in Oracle XML Publisher, and applied to an XML data file produced by Oracle Payments.

the picture is described in the document text

The new formatting and validations framework consists of several key entities:

The upgrade transforms the Release 11i payment formats supported in various Oracle applications into these entities.

Oracle Payables' setup entities related to payment formats have become obsolete, as they are effectively replaced by the new Oracle Payments setup. The following AP entities are obsolete in release 12:

Secure Payment Data Repository

Oracle Payments serves as a payment data repository on top of the Trading Community Architecture (TCA) data model. This common repository for payment data provides improved data security by allowing central encryption management and masking control of payment instrument information.

The upgrade moves party information into TCA. The party’s payment information and all payment instruments (such as credit cards and bank accounts) are moved into Oracle Payments. Party payment information moves from entities like customers, students, and Global Descriptive Flexfields and is created as a payer record in Oracle Payments, linked to the party. Party payment information moves from entities like suppliers and Global Descriptive Flexfields and is created as a payee record in Oracle Payments, again linked to the party. Third party (customer and supplier) bank accounts and credit cards are migrated to Oracle Payments and linked to the owning payer or payee.

In Release 11i, all third-party bank accounts were held in the Payables (AP) bank account data model. In Release 12, the AP bank account model is completely migrated to other entities. The bank account information is migrated as follows:

From AP bank Account Entity To Release 12 Entity
Banks, bank branches, and internal bank accounts Cash Management bank, branch and internal bank account entities
Supplier bank accounts Payments external bank account entity
Customer bank accounts Payments external bank account entity
Customer credit cards Payments payment card entity
Automatic Bank Transmission setup Replaced by Payments’ improved electronic transmission capability

Credit card information held in other Oracle Applications product entities is also migrated to the Payments payment card entity. The following products hold credit card data in Release 11i that is migrated to Oracle Payments in Release 12:

Migrated Third-Party Payment Instruments in Payments

In Release 11i, data in the AP bank account entity was segregated by operating unit. So multiple records were created to record the same payment instrument in the case where different operating units conducted business with the same third party. The new payment instrument repository allows a single representation of a payment instrument to be created and used across operating units.

The upgrade does not merge any payment instruments − rather it adds operating unit information to the data to make it unique. For external bank accounts, the upgrade appends the operating unit to the bank account name. For credit cards, the upgrade appends the operating unit to the Name on Card value. After the upgrade, you may want to review migrated payment instruments and consolidate the data into a single active record.

User Interface for Payment Instruments

In Release 12, the user interface to create, update, and view third-party payment instruments is integrated into the various trading partner user interfaces. For example, supplier bank accounts are created within the supplier user interface. Customer bank accounts and credit cards are also created within the customer user interface.

Changes to Setup

Any Release 11i settings that controlled masking of credit cards or bank accounts (for example, profile options) are obsolete. All masking is centrally controlled in the new Oracle Payments System Security Options setup page.

Any Release 11i entities that held credit card brand information (such as lookup types) are obsolete. Credit card brands are now centrally maintained in the new Oracle Payments Credit Card Brands setup page. This page also provides controls for card brand acceptance and setting of authorization validity periods.

Improved Electronic Transmission Capability

Oracle Payments provides secured electronic payment file and payment message transmission and transmission result processing. This replaces previously existing electronic transmission features in Oracle iPayment, Oracle Payables, and Oracle Globalizations. The transmission feature in Oracle Payables was simply a framework to support a customization, so the automatic upgrade cannot migrate this information. If you are using the AP transmission architecture, you should review Oracle Payments’ electronic transmission capability and plan on replacing your customization.

Oracle Payables Impact

The process to issue payments from Oracle Payables (AP) changes in Release 12 to use the new Oracle Payments funds disbursement process. The changes impact other versions of Payables such as U.S. Federal and country-specific globalizations. The benefit of these changes is to help ensure an implementation that best supports a controlled and efficient disbursement flow, and provide enhancements over the way payment processing was set up in different products.

Some of the key areas of impact are:

The upgrade uses various data from Oracle Payables to create the new Payment Process Profiles. Since this entity is so central to the funds disbursement process, an overview of the upgrade process is provided here.

For each AP payment program that is linked to a format definition, one Oracle XML Publisher template is created and linked to one Oracle Payments format. In Oracle Payables, you can create different format definitions linked to the same payment program. So for each AP format definition, the upgrade creates one Payment Process Profile linked to the Oracle Payments format.

A key part of the payment process profile is the usage rules. Values set here control when a profile can be assigned to a document for routing through the payment process. There are four categories of usage rules. One is the deploying company’s internal bank account from which funds will be disbursed. A bank account is assigned as a usage rule when the upgrade finds the following information. First, it looks at the format definition that was used to create the profile. Next, it finds all payment documents assigned to the format definition. Each internal bank account that is a parent of the payment document is assigned as a usage rule to the profile. First party organization is a second category of usage rule. Values are migrated when they are available, specifically from some globalizations. The third and fourth usage rule categories are payment methods and currencies. The upgrade determines these values based on information within the format itself.

Another important part of the payment process profile is its link to a payment system and its setup. This information is upgraded based on values set in globalizations and should be understood for payment processing in those countries.

Payment Process Flow

Many enhancements have been introduced into the payment processing flow, effective with this release. To understand how to take advantage of the flexible process configuration, refer to the Oracle Payments Implementation Guide.

The following information provides details on how to follow a payment process flow equivalent to the Oracle Payables payment batch process in Release 11i. Oracle Payables provides a new interface, called the Payments Dashboard, for submitting and managing the payment process.

Release 11i Payment Process Release 12 Payment Process Description
Invoice Selection Payment Process Request Invoices are selected for payment by submitting a payment process request in Oracle Payables.
Modify Invoice Selection Payment Process Request: Selected Scheduled Payments. This page is available when the option ‘Stop Process for Review After Scheduled Payment Selection’ is selected when submitting a payment process request. The invoice selection process is now separated from the payment creation process. It is now possible to stop the process after invoice selection to review and modify invoice information.
Build Build Payments program This program is managed by Oracle Payments. It is automatically submitted after the invoice selection process is completed in Payables and the payment process request is passed to Payments.
Preliminary Payment Register Payment Process Request Status Report This new report replaces the Preliminary Payment Register. The report can be set to run automatically when the payment process request is complete. Or it can be submitted later on. Note that the report is provided as an XML Publisher format template, so it can be easily modified or replaced with a different template.
Modify Payments The Review Proposed Payments page is available when the option “Stop Process for Review After Creation of Proposed Payments” is selected when submitting a payment process request. This page is available for review and modification of payments once they have been created and validated. Note that this page, along with the page to review selected scheduled payments, replace the Modify window/step in the AP payment batch.
Format In Release 11i, if you chose Format at the time of your payment batch submission, then in the Processing tab of the Payments Dashboard choose “Automatically Initiate When Payment Process Request is Complete” for the Create Payment Instructions field. Configuration note: if you wish to limit payments in a payment instruction to only those from your single payment process request submission, then you should configure your Payment Process Profiles with this setting: Payment Instruction Creation Rules, Payment Grouping, Payment Process Request enabled. A payment instruction is the equivalent of a completed payment batch. It contains all the payments to be disbursed. New programs can be run or scheduled to create printed or electronic payment instructions. Formatting of the payment instruction occurs automatically, and does not need to be invoked as a separate process.
Print Now Configured on a Payment Process Profile. Oracle Payments offers enhanced printing configuration options on the new payment process profile entity. The equivalent of the Release 11i Print Now option is to set the process profile setting to automatically print after formatting.
Confirm Electronic: configured on a Payment Process Profile as the point to mark payments complete. Printed: occurs when a user records the print status for payments. The process for confirming payments has been enhanced. For an electronic process profile, it is possible to set an automatic confirmation point option, or allow a manual action to mark payments complete. When a payment process results in printed payments, the user is guided to an actions page to record the results of printing. Payments recorded as successfully printed are then marked complete. The process to reprint any payments that failed to print correctly has been separated from the recording process to make it easier to use and secure.
Create Positive Pay File Configured on a Payment Process Profile This is now supported as an XML Publisher format template, so it can be easily modified or replaced with a different template.
Print Final Register Payment Instruction Register − format and submission configured on a Payment Process Profile This new report can be set to run automatically when the payment instruction is complete. Or it can be submitted later on. Note that the report is provided as an XML Publisher format template, so it can be easily modified or replaced with a different template.
Print Remittance Advice Separate Remittance Advice format and settings configured on a Payment Process Profile This format is now supported as an XML Publisher format template, so it can be easily modified or replaced with a different template. Delivery methods can vary and be set per supplier or at the process profile.

Payment Process Request Submission

In Release 11i, there is certain information you specify on the payment batch when submitting the process. There are some important differences to some of this information:

Changes to Setup

Most of the setup related to payment processing has been removed from Payables and replaced in the new central Oracle Payments setup entities. The following table provides a mapping for these changes.

From AP Entity To Release 12 Entity (all Oracle Payments unless otherwise noted)
Financials Options − Payment Method field Payment Method Defaulting Rules
Financials Options − Pay Alone field Disbursement System Options − Pay Each Document Alone field
Payables Options − Bank Account field Replaced by usage rules on a Payment Process Profile
Payables Options − EFT User Number field Payment System required settings
Payables Options − Payment Batch Limit field Payment Process Profile − payment instruction creation payment limits region
Payment documents on internal bank account Cash Management - payment documents on internal bank accounts. Note that in Release 11i a payment document was required on all payments. In Release 12, payment document setup is only required for printed (check) payments. Payment documents are no longer used on electronic payments.

Future-Dated Payments

This feature is renamed to Bills Payable in Release 12. Setup has moved from the payment document on an internal bank account to the payment method in Oracle Payments.

Oracle Receivables Impact

Oracle Receivables (AR) integrates with Oracle Payments for funds capture processing to electronically receive money owed by debtors, such as customers. Oracle Payments works with AR to authorize and capture funds against credit cards, process refunds to credit cards, perform electronic funds transfers from bank accounts, and to format bills receivable. Note that Oracle Receivables retains its existing features for lockbox processing and the electronic upload of remittance messages. Globalization formats and features in this payments area also move to Oracle Payments.

Some of the key areas of impact are:

The upgrade uses various data from Oracle Receivables to create these entities. Since these entities are so central to the funds capture process, an overview of the upgrade process is provided here.

For each of the formats that are upgraded from AR or Globalizations to Oracle Payments, one Oracle XML Publisher template is created and linked to one Oracle Payments format. A Funds Capture Process Profile is created and the format is linked to the profile.

Other entities created by the upgrade are:

The upgrade creates new routing rules from AR setup. Routing rules are created from each receipt class that has an automatic creation method. For each of these receipt classes, the upgrade creates a routing rule for each combination of the receipt class remittance method, its internal bank account, and the organization derived from the bank account.

Bank Account Transfer Processing

The process to create bank account transfer files to debit customer or other third-party payers’ bank accounts has changed in Release 12 as part of the integration with Oracle Payments. The required setup entities are upgraded for you, but it is important for you to understand the new setup and process so you can successfully test the migrated information.

Setup

The setup process starts with creating a format layout in Oracle XML Publisher, and linking it to a format definition in Oracle Payments. Next, a payment system and payment system account must be created in Oracle Payments. The payment system must be set to indicate that it supports the capability for bank account transfers. The supported format/formats must be set here as well. The upgrade automatically provides a single payment system, Global Payment System, which is configured to support the upgraded payment formats.

Other required setup in Oracle Payments is to create a Funds Capture Process Profile. The process profile is linked to the specific payment system account, format, and payment method. Finally, a Payee needs to be created. Much of the Payee configuration is optional and provides support for different payment processes. The one mandatory requirement is the setup of all operating units that will create source transactions to be settled via bank account transfer. Setting the operating units on the Payee replaces the Merchant Ref field that was set on the Receivables Receipt Classes form in Release 11i. Note that the Merchant Ref field was mandatory for credit card processing, but not bank account transfer processing. The Oracle Payments Payee configuration is now mandatory for all automated funds capture processing in Release 12.

Process

The Oracle Receivables Automatic Remittances Creation Program passes settlements to Oracle Payments. The settlements are grouped into settlement batches according to rules configured on the Funds Capture Process Profile. The process profile then controls the rules for formatting and processing the settlement batches.

Payment administrators may want to take advantage of the new Funds Capture Process Manager dashboard provided by Oracle Payments in Release 12.

Oracle iPayment Impact

Oracle iPayment is obsolete in Release 12. Enhanced features in the new Oracle Payments product replace all of its functionality. This section provides additional details about the impact of the changes to iPayment.

The previous section described some of the key entities involved in the funds capture payment process. These entities existed in iPayment with the exception of the Funds Capture Process Profile. This new entity is introduced to hold the processing rules for transactions.

For each iPayment-supported format, the upgrade creates one Oracle XML Publisher template and links it to one Oracle Payments format. A Funds Capture Process Profile is created and the format is linked to the profile. The settings on the process profile are based on various settings in configuration and servlet files.

New seed data is created for the transmission protocols supported by Oracle Payments and the protocols are specified on the payment system setup. This data is also set based on configuration files. The upgrade creates transmission configurations that use the protocols. These transmission configurations are specified on the funds capture process profiles. New payment system accounts are created that hold settings previously held in configuration files. The payment system accounts are also specified on the process profiles.

Moving setup data from technical configuration files to the new setup entities has a benefit of allowing easier review and updates by a business user.

Migrated iPayment Formats

In Release 11i, formatting was handled by Java code in payment system servlets. The following table displays the mapping from the 11i payment system to the new Release 12 Oracle Payments, XML Publisher formats.

Source Release 11i Payment System Release 12 Oracle Payments Format Name (Code)
Citibank Citi Merchant Services Version 3.0 (Batch Specification) (CITI_MERK_SRVCS_BATCH_3_0)
  Citi Merchant Services Version 3.0 (Online Specification) (CITI_MERK_SRVCS_ONLINE_3_0)
  Citibank Direct Debit Message Version 1.8 (CITI_DIRDEB_MSG_1_8)
Concord Concord EFSNet Web Payment Services Version 2.4 Credit Card (CONCORD_EFS_CREDITCARD_2_4)
  Concord EFSNet Web Payment Services Version 2.4 Debit Card (CONCORD_EFS_DEBITCARD_2_4)
  Concord EFSNet Web Payment Services Version 2.4 Query (CONCORD_EFS_QUERY_2_4)
  Concord EFSNet Web Payment Services Version 2.4 Telecheck (CONCORD_EFS_TELECHECK_2_4)
First Data North First Data North ISO 8583 Format Authorization Network Processing Specification for … 10/24/02 (FDN_ISO8583_AUTH_20021024)
  First Data North Magnetic Media and Data Communication Processing Specifications Version 2003.1 (FDN_MAGMEDIA_BATCH_2003_1)
Paymentech Paymentech 120-byte Batch Technical Specification Revision 2.1.0 (PTECH_120BYTE_BATCH_2_1_0)
  Paymentech Online Technical Processing Specification 7.2 (PTECH_ONLINE_7_2)

This table displays the mapping from seeded, Release 11i iPayment, format programs to the new Release 12 Oracle Payments, XML Publisher formats.

Source Release 11i Payment Format (Program) Release 12 Oracle Payments Format Name (Code)
iPayment Bills Receivable Remittance (ARBRIBYFMT) Citibank EDIFACT DIRDEB Remittance Format (IBY_REC_EDI_CITI_DIRDEB)