Oracle Payments

This chapter covers the following topics:

• Overview
• Advanced and Highly Configurable Formatting and Validations Framework
• Secure Payment Data Repository
• Improved Electronic Transmission Capability
• Oracle Payables Impact
• Oracle Receivables Impact
• Oracle iPayment Impact

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 new formatting and validations framework consists of several key entities:

• Oracle XML Publisher Format Template. The template specifies the layout of the formatted output file required by the financial institution or payment system. The format template is applied to the XML data extract of payment information, thus creating the formatted output file.

• Oracle Payments Format. Basic information about the format is held in Oracle Payments. The format is linked to the format template in XML Publisher.

• Format Validations. Prior to this release, logic to validate the formatted data was imbedded in the format programs. Now the validation logic has been separated from the format programs, and is provided as a prepackaged set of validations. The format validations are linked to the format definition in Oracle Payments, and are executed during the payment process.

• Process Profile. This Oracle Payments entity holds all the payment processing rules, including the link to the format definition. The process profile not only determines what format will be used, but handles rules about how data is grouped, transmitted, reported, and so on.

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:

• Automatic Payment Programs

• Payment Formats

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:

• Oracle Payables

• Oracle Order Capture

• Oracle Order Management

• Oracle Service Contracts

• Oracle Student System

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:

• Payment Methods: each document to be paid requires a payment method to indicate how it should be handled in the funds disbursement process. Payment methods can now be defined as broadly or narrowly as appropriate, and are not restricted to the seeded values. Rules can be set for when payment methods can be used on documents. Rules can also be specified to default payment methods on documents when they are created. The upgrade seeds payment methods that existed in Oracle Payables and globalizations.

• Processing Rules: the payment method on a document links it to processing rules configured in Oracle Payments. These setup rules are held in a key entity called the Payment Process Profile. Users can configure as many of these process profiles as they need for their payment processes. Each profile holds rules for how documents should be built into payments, how payments should be aggregated into a payment instruction file, and how the payment file should be formatted. Rules for printing checks, transmitting electronic files, generating separate remittance advice notifications and other options can be easily configured.

• Payment System: a payment system holds information about the third party involved in processing payments. The third party may be a financial institution or clearing house that disburses or settles payments. This entity is defined to hold information about transmission and required settings for communication to the payment system.

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:

• Bank Account - Payables has renamed this field Disbursement Bank Account. In Release 11i, it is a required field on the payment batch. In Release 12, this field is optional. Oracle Payments has features that allow the defaulting or user assignment of the disbursement bank account during the payment process. However, if you wish to select invoices and indicate that they should all be paid from the specified bank account, then you can continue to provide this information at submission.

• Document - Payables has renamed this field Payment Document. In Release 11i, this field is required. In Release 12, a payment document is only required if the payments are to be printed (for example, checks). It is possible to configure a payment process profile for printing, and indicate the payment document to be used with that process profile. When this is done, you can select the Payment Process Profile to use, and the Payment Document value will automatically populate.

• Payment Method - In Release 11i, this field is required. It is only possible to create a payment batch for invoices with the same payment method. In Release 12, this field is now optional and has become an invoice selection criterion.

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:

• Payee Configuration: a payee is defined for each entity in the deploying company that will process payments; typically only one setup is needed for the enterprise. The payee configuration holds various processing options that are used to handle transactions. In Release 11i, AR linked each receipt class with an automatic creation method to the Oracle iPayment Payee. This is changed in Release 12. Now operating units are assigned to the payee. This helps ensure consistent payment processing across the applications. The upgrade assigns operating units to the payee based on existing transactions in AR.

• Payment Methods: each transaction requires a payment method to indicate how it should be handled in the funds capture process. In Oracle Receivables, this payment method is specified on a receipt class defined with an automatic creation method. Note that in the receipt class setup, AR has changed its Release 11i payment method term to be called receipt method.

• Processing Rules: rules for processing electronic funds capture transactions are held in a key entity called the Funds Capture Process Profile. Users can configure as many of these process profiles as they need for their payment processes. Each profile holds the configuration for how to format and transmit authorization messages and settlement files. Rules for aggregating settlements into batches, limiting the number or amount of settlements in a batch, notifying payers of settlements, and processing acknowledgements can be easily configured.

• Payment System: a payment system holds information about the third party involved in processing payments. The third party may be a payment processor or it may be a financial institution. This entity is defined to hold information about transmission and required settings for communication to the payment system.

• Routing Rules: routing rules can be configured to specify how a transaction should be processed. A routing rule applies specified criteria and determines the funds capture process profile and the payment system to use. Routing rules are defined as part of the payee configuration.

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:

• One payee to hold master settings for the funds capture payment process.

• One payment system.

• One payment system account.

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)