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 Payables

This chapter covers the following topics:

Overview

In Release 12, the Oracle E-Business Suite introduces Subledger Accounting, E-Business Tax, Ledgers, Banks and other common data model components that are used by Oracle Payables.

The following are new in Release 12:

Suppliers Added to Trading Community Architecture

In Release 12, Suppliers are defined as Trading Community Architecture (TCA) parties. During the upgrade, TCA party records are created and updated for all suppliers, they are linked back to their records in the supplier entities and the payment and banking details are migrated into the Oracle Payments data model. The supplier, supplier site, and supplier contacts tables are obsolete and replaced with views that join information from the old tables with information in TCA.

TCA Party Creation for Suppliers

During the upgrade, Oracle Payables creates new parties in TCA for all suppliers that do not have existing party information. The parties are created with a party usage of supplier. Country and address information is required for parties in the TCA data model, so if there is no country or address line 1 specified for a supplier site, Oracle Payables derives the country based on the most frequently used operating unit of the supplier's historical transactions. E-Business Tax uses the country information when you elect to calculate tax based on ship-from or bill-from location criteria. Please confirm your setup of parties before you elect to use this E-Business Tax feature.

Also during the upgrade, Oracle Payables reviews the supplier sites and determines duplicates, based on the supplier, address, city, county, province, state, country, zip and language. Oracle Payables then creates only one Party Site for each distinct supplier site address.

Suppliers created using Oracle Trade Management, Oracle Transportation Management, and Oracle iSupplier Portal have existing party information. During the upgrade, Oracle Payables updates the existing party in TCA with the Taxpayer ID from the supplier record, if it is different from the one in TCA.

TCA Party Creation for Employees

In prior releases, employees were defined and linked to a supplier record in order for Oracle Payables to create payments for their expense reports. Employees defined in Oracle Human Resources and associated with an Oracle Payables supplier record have existing party information. During the upgrade, Oracle Payables updates the existing party information to have a party usage of supplier. Oracle Payables does not migrate the employee address to the party site in TCA, they remain in Oracle Human Resources for data security reasons.

Migration of Other Supplier Attributes

In Release 11i, you could record the relationship between a franchise or subsidiary and its parent company by recording a value for the Parent Supplier field in the Suppliers window. During the Release 12 upgrade, this information is migrated into the party relationships model of TCA.

Invoice Lines

Invoice Lines are introduced as an entity between the invoice header and invoice distributions in order to better match the structure of real world invoice documents and improve the flow of information in the Oracle E-Business Suite. With the new model, the invoice header remains unchanged, and continues to store information about the supplier who sent the invoice, the invoice attributes and remittance information. Invoice lines represent the goods (direct or indirect materials), service(s) and/or associated tax/freight/miscellaneous charges invoiced. Invoice distributions store the accounting, allocation and other detail information that makes up the invoice line. In prior releases, a charge allocation table managed the allocations, but this entity is obsolete in Release 12.

During the upgrade, Oracle Payables creates one invoice line for every distribution available in the 11i distributions table, except in the case of reversal pairs where Payables creates one line with a zero amount. Other Release 12 features like Subledger Accounting and E-Business Tax integration require that Payables invoice distributions be stored at the maximum level of detail. Oracle Payables makes this transformation of existing invoice distributions during the upgrade. For example, instead of storing the Exchange Rate Variance and Invoice Price Variance as attributes of an invoice distribution, as in prior releases, Oracle Payables will create a distribution for each of those charges.

Centralized Banks and Bank Account Definitions in Oracle Cash Management

In Release 12, the ownership of internal banks and bank accounts will move to Oracle Cash Management for all products in the E-Business Suite. All internal banks and bank accounts you had defined for your operations will be migrated from the Payables entities to the central Cash Management entities. A Legal Entity now owns the bank accounts and their payment documents, rather than being owned by an Operating Unit, as in prior releases.

Also in Release 12, the ownership of supplier bank accounts transitions from Oracle Payables to Oracle Payments. The banks and bank branches will be centralized in Oracle Cash Management entities, as above, however the bank accounts you had defined for your suppliers will be migrated from the Payables entities to the central Payments entities. Oracle Payments centralizes and secures all payment instrument data, including external bank accounts, credit cards, debit cards, and so forth.

Please refer to the Cash Management and Payments sections of this document for more information about the Release 12 Upgrade.

For functional knowledge of Oracle Cash Management, refer to the Oracle Cash Management Users Guide and Oracle Cash Management Implementation Guide.

For functional knowledge of Oracle Payments, refer to the Oracle Payments Users Guide and Oracle Payments Implementation Guide.

Document Sequencing of Payments

If you used document sequencing for payments in Release 11i, your document sequence category has been migrated from the payment document, which is associated with a bank account and hence, legal entity in Release 12, to the bank account uses entity. If you require, you can also specify the document sequence category at the bank account payment method and payment document levels. These changes are necessary to preserve the option of having document sequence categories vary across operating units.

Please refer to the Cash Management and Payments sections of this document for more information about the Release 12 Upgrade.

To gain functional knowledge of Oracle Cash Management, refer to the Oracle Cash Management Users Guide and Implementation Guide.

Integration with Oracle Payments for Funds Disbursement

The process to issue payments from Oracle Payables (AP) changes in Release 12 to use the new Oracle Payments funds disbursement process. 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.

A significant change for Payables users is that Payments uses XML Publisher for payment formatting. During the upgrade, Payments will upgrade the seeded Payables payment formats to Payments formats that can be used with configurable XML Publisher templates. If you have custom payment formats, you need to migrate them to XML Publisher in order to use them in Release 12. Payments continues to use the concept of Payment Methods, as they worked in Payables, however there are some minor enhancements, which are noted below. The Future Dated Payments feature has been renamed to Bills Payable in Release 12 and setup has moved from the payment document on an internal bank account to the payment method in Oracle Payments.

In Release 12, the process of making EDI payments using Oracle e-Commerce Gateway has changed, details are noted below.

In Release 12, the Automatic Bank Transmission and XML Payments features are obsolete, as Oracle Payments provides enhanced features that meet the same requirements.

During the upgrade, payment batches in Payables are upgraded to payment instructions in Oracle Payments. Payments created in those payment batches, however, are not upgraded. Payments remain in Oracle Payables for review and reporting. In Release 12, new payments can be viewed in both Payments and Payables.

Please refer to the Payments section of this document for more information about the Release 12 Upgrade.

For functional knowledge of Oracle Payments, refer to the Oracle Payments Users Guide and Oracle Payments Implementation Guide.

Payment Formats

During the Release 12 Oracle Payments upgrade, one Oracle XML Publisher template is created and linked to one Oracle Payments format for each Oracle Payables (AP) payment program that is linked to a format definition. In 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.

The payment programs that controlled the building and formatting of payments and the programs that created the separate remittance advice documents are obsolete with Release 12 and the integration with Oracle Payments. The following tables display the mapping from seeded 11i AP Payment Formats to the new Release 12 Oracle Payments XML Publisher Formats. Obsolete formats are so noted.

Source 11i Payment Format (Program) Release 12 Oracle Payments Format Name (Code)
Oracle Payables  
Long Check Format (APXPBFEG) External Check Format (IBY_PAY_CHK_STANDARD_2)
Long Check Format; stub after payment (APXPBFEG) External Check Format (IBY_PAY_CHK_STANDARD_2A)
Long Laser Format (APXPBFEL) Laser Check Format (IBY_PAY_CHK_LASER)
Long Laser Format; stub after payment (APXPBFEL) Laser Check Format (Stub After Payment) (IBY_PAY_CHK_LASER_A)
Short Check Format (APXPBFEG) External Check Format (IBY_PAY_CHK_STANDARD_2A)
Short Form Feed Format (APXPBFEF) External Form Feed Check Format (IBY_PAY_CHK_FORM_FEED_2)
Short Form Feed Format; stub after payment (APXPBFEF) External Form Feed Check Format (Stub After Payment) (IBY_PAY_CHK_FORM_FEED_2A)
Standard Check Format (APXPBFOR) Standard Check Format (IBY_PAY_CHK_STANDARD_1)
Standard Check Format; stub after payment (APXPBFOR) Standard Check Format (Stub After Payment) (IBY_PAY_CHK_STANDARD_1A)
US Treasury Check (APXPBFUS) US Treasury Format (IBY_PAY_CHK_TREASURY)
BACS 1/2 Inch Tape (APXPBFBC) UK BACS 1/2 Inch Tape Format (IBY_PAY_EFT_BACS_UK)
EDI Outbound Program (APECEPYO) Obsolete
NACHA Payment Format (APXNACHA) US NACHA CCD Format (IBY_PAY_EFT_NACHA_CCD_US)
XML Payment Format (APXMLPMT) Obsolete
Source 11i Payment Format (Program) Release 12 Oracle Payments Format Name (Code)
Oracle Federal Payables  
BD CCDP format (FVBLCCDP) US Bulk CCDP Format (IBY_PAY_EFT_FED_BULK_CCDP)
BD NCR Format (FVBLNCR) US Bulk NCR Format (IBY_PAY_EFT_FED_BULK_NCR_1)
Bulk PPDP format (FVBLPPDP) US Bulk PPDP Format (IBY_PAY_EFT_FED_BULK_PPDP)
BD Sal/Trv NCR Format (FVBLSLTR) US Bulk Salary and Travel NCR Format (IBY_PAY_EFT_FED_BULK_NCR_2)
Bulk Data CCD+ Consolidated Payment File Program (FVCOCCDP) US CCDP Consolidated Format (IBY_PAY_EFT_FED_CCDP_CONSOL)
CTX Consolidated File Payment Program (FVCONCTX) US PPDP Consolidated Format (IBY_PAY_EFT_FED_PPDP_CONSOL)
Bulk Data PPD+ Consolidated Payment File Program (FVCOPPDP) US CTX Consolidated Format (IBY_PAY_EFT_FED_CTX_CONSOL)
SPS CCD Format (FVSPCCD) US SPS CCD Format (IBY_PAY_EFT_FED_SPS_CCD)
SPS CCDP Format (FVSPCCDP) US SPS CCDP Format (IBY_PAY_EFT_FED_SPS_CCDP)
SPS Check NCR Format (FVSPNCR) US SPS NCR Format (IBY_PAY_EFT_FED_SPS_NCR)
SPS PPD Format (FVSPPPD) US SPS PPD Format (IBY_PAY_EFT_FED_SPS_PPD)
SPS PPDP Format (FVSPPPDP) US SPS PPDP Format (IBY_PAY_EFT_FED_SPS_PPDP)
ECS Check NCR Format (FVTIACHB) US ECS NCR Check Format (IBY_PAY_EFT_FED_ECS_NCR)
ECS CCDP Format (FVTIACHP) US ECS CCDP Format (IBY_PAY_EFT_FED_ECS_CCDP)
CTX Vendor Format (FVTICTX) US CTX Format (IBY_PAY_EFT_FED_CTX)
ECS CCD Format (FVTPCCD) US ECS CCD Format (IBY_PAY_EFT_FED_ECS_CCD)
ECS PPD Format (FVTPPPD) US ECS PPD Format (IBY_PAY_EFT_FED_ECS_PPD)
ECS PPDP Format (FVTPPPDP) US ECS PPDP Format (IBY_PAY_EFT_FED_ECS_PPDP)
Summary Schedules (FVSUMSCH) Obsolete
ECS and SPS Summary Schedules IBY_PAY_EFT_FED_ECS_SUM_SCHED and IBY_PAY_EFT_FED_SPS_SUM_SCHED
Source 11i Payment Format (Program) Release 12 Oracle Payments Format Name (Code)
Argentina  
Argentine Check Format (JLARPCFP) Argentine Check Format (IBY_PAY_CHK_AR)
Austria  
Austrian Foreign EFT (JEATIEFT) Obsolete
Austrian Domestic (JEATREFD) Obsolete
Austrian Transferral 1 (JEATPPF1) Obsolete
Austrian Transferral 2 (JEATPPF2) Obsolete
Austrian Check with Remittance Advice (JEATPPF3) Obsolete
Austrian Check with Remittance Advice FWG (JEATPPF4) Obsolete
Austrian Foreign Transfer Order (JEATPPF5) Obsolete
Belgium  
Belgian Format 1 (JEBEEF01) Belgian EFT Format (IBY_PAY_EFT_DOMESTIC_BE)
Belgian Format 2 (JEBEEF02) Same as above
Brazil  
Brazilian Check Format (JLBRPCFP) Brazilian Check Format (IBY_PAY_CHK_BR)
Brazilian Bordero (JLBRPBOR) Brazilian Bordero Format (IBY_PAY_CHK_OBRDERO_BR)
Chile  
Chilean Check Format (JLCLPCFP) Chilean Check Format (IBY_PAY_CHK_CL)
Colombia  
Colombian Check 1 (JLCOPCF1) Colombian Check 1 Format (IBY_PAY_CHK_1_CO)
Colombian Check 2 (JLCOPCF2) Colombian Check 2 Format (IBY_PAY_CHK_2_CO)
Denmark  
Danish GiroBank Domestic (JEDKEIGO) Obsolete
Danish GiroBank Foreign (JEDKEUGO) Obsolete
Danish Unitel (JEDKEUNI) Obsolete
Finland  
Finnish LMP2 Payment Format (JEFILLMP) Finnish LMP2 EFT Format (IBY_PAY_EFT_LMP2_FI)
Finnish LUM Payment Format (JEFILLUM) Finnish LUM EFT Format (IBY_PAY_EFT_LUM_FI)
Finnish LMP3 Payment Format (JEFILLMP3) Finnish LMP3 EFT Format (IBY_PAY_EFT_LMP3_FI)
Finnish ULMP Payment Format (JEFILULM) Obsolete
France  
Billet a Ordre France (JEFRAP02) (Also referred to as: French PRMSRY Note EUR, French Bill Of Exchange, French Bill of EXCH EUR) French Promissory Note Format (IBY_PAY_PROMISSORY_NOTE_FR)
Cheque Francais (JEFRAP01) French Check Format (IBY_PAY_CHK_FR)
Cheque Francais; stub after payment (JEFRAP01) French Check Format (Stub After Payment) (IBY_PAY_CHK_FR_A)
Virement Francais (AFB) (JEFRAP03) French EFT Format (IBY_PAY_EFT_FR)
Germany  
German Check Print (JEDERDSA) German Check Format (IBY_PAY_CHK_DE)
German Check Print; stub after payment (JEDERDSA) German Check Format (Stub After Payment) (IBY_PAY_CHK_DE_A)
German Domestic (JEDEREFD) German Domestic EFT Format (IBY_PAY_EFT_DOMESTIC_DE)
German International EFT (JEDEDEFI) German International EFT Format (IBY_PAY_EFT_FOREIGN_DE)
German Payables Wire Print (JEDERUEB) German Wire Format (IBY_PAY_WIRE_DE)
Italy  
Italian EFT (JEITPEFT) Italian EFT Format (IBY_PAY_EFT_IT)
Italian Wire Order (JEITAPBT) Italian Wire Format (IBY_PAY_WIRE_IT)
Japan  
Zengin Format (APTZGF) Japanese Zengin Format (IBY_PAY_EFT_ZENGIN_JP)
Netherlands  
Netherlands Domestic (JENLFDOM) Netherlands Domestic EFT Format (IBY_PAY_EFT_DEOMESTIC_NL)
Netherlands Foreign (JENLFFGN) Netherlands Foreign EFT Format (IBY_PAY_EFT_FOREIGN_NL)
Norway  
Norwegian BBS (JENOPBDR) Norwegian BBS Format (IBY_PAY_EFT_BBS_NO)
Norwegian Telepay (JENOPTGN) Forwegian Telepay EFT Format (IBY_PAY_EFT_TELPAY_NO)
Norwegian Datadialog Payment Format (JENOPDDG) Obsolete
Poland  
Polish Pekao Credit Transfers Format (JEPLEFT1) Polish Pekao Credit Transfers Format (IBY_PAY_EFT_CREDIT_TRANS_PL)
Polish Pekao Payments (JEPLEFT2) Polish Pekao Payment Order Format (IBY_PAY_EFT_PAY_ORDER_PL)
Polish Citibank MTMS EFT Format (JEPLEFT3) Polish Citibank MTMS EFT Format (IBY_PAY_EFT_CITI_MTMS_PL)
Portugal  
Portuguese Check (JEPTBFOR) Portuguese Check Format (IBY_PAY_CHK_PT)
Portuguese EFT (JEPTPEFT) Portuguese EFT Format (IBY_PAY_EFT_PT)
Spain  
Spanish EFT (JEESPEFT) Spanish Magnetic Format (IBY_PAY_EFT_ES)
Spanish Cheque (JEESAPCP) Spanish Check Format (IBY_PAY_CHK_ES)
Spanish PRMSRY Note EUR (JEESAPLC) Spanish Bill of Exchange Format (IBY_PAY_CHK_BOE_ES)
Sweden  
Swedish Bankgiro Inland (JESEPBAI) Swedish Domestic Bankgiro Format (IBY_PAY_EFT_BANKGIRO_SE)
Swedish Bankgiro SISU (JESEPBSI) Swedish SISU Bankgiro Format (IBY_PAY_EFT_SISU_BANKGIRO_SE)
Swedish Bankgiro UTLI (JESEPBUT) Swedish UTLI Bankgiro Format (IBY_PAY_EFT_UTLI_BANKGIRO_SE)
Swedish Postgiro Inland (JESEPPOI) Swedish Domestic Postgiro Format (IBY_PAY_EFT_POSTGIRO_SE)
Swedish Postgiro Utland (JESEPPOU) Swedish Foreign Postgiro Format (IBY_PAY_EFT_FOR_POSTGIRO_SE)
Switzerland  
Swiss DTA Payment (JECHRDTA) Swiss DTA Format (IBY_PAY_EFT_DTA_CH)
Swiss SAD Payment (JECHRSAD) Swiss SAD Format (IBY_PAY_EFT_SAD_CH)
Source 11i Separate Remittance Advice Format (Program) Release 12 Oracle Payments Format Name (Code)
Remittance Advice (APXPBSRA) Remittance Advice Format (IBY_PAY_REMIT_ADV)
E-Mail Remittance Advice (APPEWF) Remittance Advice Format (IBY_PAY_REMIT_ADV)
Austrian Separate Remittance Advice (JEATPSRA) Remittance Advice Format (IBY_PAY_REMIT_ADV)
German Payables Separate Payment Letter (JEDEAPPL) Remittance Advice Format (IBY_PAY_REMIT_ADV)
Dutch Payment Specification Report (JENLPPSX) Remittance Advice Format (IBY_PAY_REMIT_ADV)
Portuguese EFT Remittance (JEPTPSRA) Remittance Advice Format (IBY_PAY_REMIT_ADV)
DTA Remittance Advice (APXPBSRA), Switzerland Remittance Advice Format (IBY_PAY_REMIT_ADV)
SAD Remittance Advice (APXPBSRA), Switzerland Remittance Advice Format (IBY_PAY_REMIT_ADV)
Source 11i Disbursement Accompanying Letters (Program) Release 12 Oracle Payments Format Name (Code)
Swiss DTA Accompanying Payment Letter to Bank (JECHRLET) Swiss DTA Accompanying Letter (IBYAL_D_AT)
Swiss SAD Accompanying Payment Letter to Bank (JECHSLET) Swiss SAD Accompanying Letter (IBYAL_S_AT)
German Domestic EFT Letter (JEDERBZD) German Domestic EFT Accompanying Letter (IBYAL_D_DE)
German International EFT Letter (JEDERBZI) German International EFT Accompanying Letter (IBYAL_F_DE)
Austrian EFT Letter (Domestic/International) (JEATRBZD) Obsolete

Payment Methods

The upgrade migrates the seeded payment methods of check, electronic, wire, and clearing from Payables to the new, extensible Oracle Payments payment method entity. Note the following changes:

EDI Payments using Oracle e-Commerce Gateway

The process to create EDI payments using Oracle e-Commerce Gateway has changed in Release 12. The EDI Outbound Program (APECEPYO) is obsolete. Setting the value for the Electronic Processing Channel in the Payment Process Profile setup page controls integration with Oracle e-Commerce Gateway. Release 11i format definitions are upgraded into payment process profiles with the electronic processing channel set appropriately. The format information on the process profile is populated with a seeded format. Actual formatting and transmission is performed by Oracle e-Commerce Gateway.

Certain fields were set in the Suppliers form for EDI payment information. In Release 12, these fields have been consolidated with standard payment details fields entered for a supplier, and the data values are migrated during the upgrade. The following table provides a mapping between the field names for the releases.

Source 11i Entity Release 12 Entity
Suppliers, EDI tab: Payment Method Suppliers, Payment Details: Payment Method
Suppliers, EDI tab: Payment Format Suppliers, Payment Details: Bank Instruction 1
Suppliers, EDI tab: Remittance Method Suppliers, Payment Details: Delivery Channel
Suppliers, EDI tab: Remittance Instruction Suppliers, Payment Details: Payment Text Message 1
Suppliers, EDI tab: Transaction Handling Suppliers, Payment Details: Bank Instruction 2

Payment Configuration Controlled by Global Descriptive Flexfields

Various aspects of payment configuration were controlled by Global Descriptive Flexfields (GDF) in Release 11i and are now implemented in an integrated fashion across core Oracle Payables, Oracle Payments and Oracle Cash Management. This section is organized by functional area and discusses the upgrade impact on Oracle Payables:

For functional knowledge of the Oracle Payments, refer to the Oracle Payments Users Guide and Oracle Payments Implementation Guide.

Bank Charge Bearer Controls

In Release 11i, there are a number of GDFs that support the entry of information in the payment file about who should bear the cost of bank fees for a payment. Presently, this feature is used by the following countries: Austria, Belgium, Denmark, Finland, Germany, Netherlands, Norway, and Sweden. If you are not operating in these countries, you can disregard this section. The Japan Bank Charge feature implemented in Oracle Payables did not change in Release 12.

In Release 11i, GDFs that hold bank-charge-bearer information are held at the supplier site. Denmark is the only country that has GDFs at the bank account level, which then defaults to invoices in both the invoice interface and the invoices tables.

In Release 12, the following Global Descriptive Flexfields are obsolete. During the upgrade, Oracle Payments will migrate the bank-charge-bearer information from the GDFs to bank charge bearer information stored on the payer and payee entities and optionally, the AP invoice:

Bank Information and Instructions

In Release 11i, there are a number of GDFs that support the entry of information about the bank where the disbursement bank account is held as well as payment instruction information specifying when and how the bank should transfer money to the supplier. Presently, this feature is used by the following countries: Finland, Germany, Netherlands, Sweden. If you are not operating in these countries, you can disregard this section.

In Release 11i, GDFs that hold bank information are held at the supplier site and global payment format levels. In Release 12, the following GDFs are obsolete. The bank information is migrated to the central Cash Management bank data model and the bank instructions are migrated to Oracle Payments and stored at the payment process profile and payee setup levels:

Regulatory Reporting Controls

In Release 11i, some GDFs support the reporting of certain information to country governments or central banks. Presently, this feature is used by the following countries: Germany and Netherlands. If you are not operating in these countries, you can disregard this section.

In Release 11i, GDFs that hold central bank reporting information and control fields, like thresholds, are held at the following levels: system payment format, supplier site, bank account, invoices (including invoice interface) and scheduled payments. The Netherlands also used two profile options, JENL: Reporting Threshold and JENL: Validate All Invoices. In Release 12, the following GDFs and profiles are obsolete and regulatory reporting is setup at the payment process profile level in Oracle Payments. Since this feature was redesigned with a fresh perspective based on requirements from all countries, no data will be upgraded from the GDFs.

Regulatory Reporting, Payment Reasons

In Release 11i, there are a number of GDFs that support collecting of information pertaining to why a supplier or invoice is being paid. This information is required by government or central bank reporting. This feature is used by the following countries: Belgium, Denmark, Netherlands, Norway, Poland, and Sweden. If you are not operating in these countries, you can disregard this section.

In Release 11i, GDFs that hold payment reason information are held at the following levels: system payment format, supplier site, bank account, and invoices (including invoice interface). In Release 12, the following GDFs are obsolete and payment reasons are collected at the payee level and defaulted to the invoice. Oracle Payments will not support a system level payment reason in Release 12. During the upgrade, existing values in the country-specific lookups for payment reasons will be migrated to Oracle Payments payment reasons and data in invoice GDFs will be migrated to the new columns on the invoice entities.

Settlement and File Directory Controls

In Release 11i, there are a number of GDFs and profile options that control settlement and various aspects of payment formatting, including file directories. In Release 12, the following GDFs and profiles are obsolete and the features are handled as indicated:

Payment File Information

In Release 11i, there are a number of Global Descriptive Flexfields (GDFs) that support entry of information assigned by a bank or third-party, payment system to the deploying company, also referred to as the first-party payer. The Global Descriptive Flexfields are used to capture this kind of information for implementations in the following countries: Finland, Germany, Netherlands, Norway, Sweden, Switzerland, and Denmark. If you are not operating in these countries, you can disregard this section.

In Release 11i, GDFs that hold this payment file information are held at payment format level and at internal bank account level. You could enter payment format information in two places. The first, used for Germany, Netherlands, Norway, Sweden, and Switzerland, is the EFT System Information window, accessed from the main menu. The second, used by Finland, is a window accessed from the AP Payment Formats window, the Payment Format EFT Details window. Denmark is the only country that has GDFs at the bank account level.

In Release 12, the following Global Descriptive Flexfields are obsolete:

During the upgrade, Oracle Payments will create one Payment System record for each bank and a corresponding Payment System Account and its attributes for values formerly supported by the GDFs.

Payment File Formatting

In Release 11i, some GDFs and profile options for Netherlands and Sweden set a value at implementation time, then include that value in each formatted payment file to the bank. The values are not migrated during the upgrade. There are two options that users have in Release 12:

The following GDFs and profiles are obsolete in Release 12:

Payment Text Messaging

In Release 11i, there are several GDFs that support the entry of text messages to be sent to payees in a payment format. In Release 12, the following GDFs and profiles are obsolete and text message fields are available at Oracle Payments payment process profile and payee setup levels as well as at the invoice level in Oracle Payables:

Not all GDFs will migrate to the new functionality in Oracle Payments. Invoice End Date will be obsolete in Release 12. Users can remove any message text once they do not want it included in the payment file. Amount Header will also become obsolete. The requirement for this field can be met using the EFT format template in Oracle Payments.

Unique Remittance Identifiers

In Release 11i, there are several GDFs that support the entry of reference information that gets passed along with a payment in the payment file to assist in reconciling the payment to its invoices. In Release 12, the following GDFs are obsolete and the unique remittance identifiers, like reference number and check digit, can be entered on the invoice in Oracle Payables:

Data will be migrated from the GDFs to the new fields on the invoice. Country-specific validation for the reference numbers will be migrated into the validation module of Oracle Payments.

Remittance Advice Controls

In Release 11i, there are country-specific tables and profile options that control the frequency and method of creating a remittance advice. In Release 12, the following tables and profiles are obsolete and the remittance advice creation is managed by the payment process profile and its remittance controls:

Oracle Payments provides an XML Publisher template for creating a remittance advice. You can modify this template to meet the requirements of your country.

Settlement Control

In Release 11i, there are several fields that specify the way an invoice should be settled. The fields used for this purpose come in three categories: payment methods, delivery channels (which specify how a bank provides a payment to the payee), and payment formats. These fields include both Oracle Payables functionality and GDFs. In Release 12, the following GDFs, and other entities, are obsolete and the settlement information is handled by Oracle Payments:

During the upgrade, Oracle Payments will migrate payment methods from the Oracle Payables entity to the new Oracle Payments payment methods entity and will upgrade all invoice data. Payments will also migrate default values for payment method, delivery channels and payment formats from the Global/Payables system, supplier, supplier sites and payee setups to the new Oracle Payments solution.

Danish Payment Categories

The form that supports the specification of payment categories is obsolete in Release 12. The functionality that this form supported is partially migrated to new entities in Release 12. Part of the upgrade verification testing for electronic payment processing in Denmark should be to review the migrated data and configure new setup as needed.

Each payment category is upgraded to a payment method in Oracle Payments. As noted in the previous section, the payment means and payment channel associated with the payment category are not upgraded. In Release 12, values for these should be set in the XML Publisher format template associated with the specific payment format. The seeded Danish format templates contain example mappings to help guide you in setting this information.

The payment category setup allows implementers to define the validation of certain invoice fields based on the payment category (for example, a field is required). The upgrade does not automatically migrate these settings to the new Oracle Payments validation model. After the upgrade, the payment methods should be reviewed, and the validations should be configured as user-defined validations set as needed on each payment method.

Settlement Priority

In Release 11i, there are GDFs that control how urgently the bank should handle the fund disbursement. In Release 12, the following GDFs are obsolete and the settlement priority is entered on the invoice and managed by Oracle Payments:

During the upgrade information is migrated from the GDFs into the new columns.

Miscellaneous Obsolete GDFs

The following GDFs are not used in payment formats, and are obsolete:

Integration with Oracle Subledger Accounting

Release 12 introduces a new module, Subledger Accounting (SLA), for managing accounting across subledger transactions. With the introduction of SLA, Payables will no longer create accounting entries, but will instead rely on the central SLA engine to do so. During the upgrade, accounting options and their settings, and the existing accounting entries in the Payables data model are moved to the new SLA accounting data model. Also during the upgrade, Payables sets up SLA to replicate the accounting created by Payables in Release 11i.

The new SLA architecture requires Payables to maintain specific data relating to transactions. SLA uses this data to generate accounting entries. In order to achieve this it was determined that both payment distributions and prepayment application distributions would be introduced into the Payables data model. Unlike invoice distributions that can be entered by the user, payment distributions will be generated automatically and will be associated with each accounted payment.

During the upgrade, all accounting events, headers and lines from the 11i data model are upgraded to the new Subledger Accounting events, headers and lines data model, regardless of the number of periods you specify when submitting the upgrade. If the Global Accounting Engine (AX) is enabled for the set of books associated with a given Operating Unit, then the upgrade migrates the AX accounting events, headers and lines to SLA instead of those in Payables. The payment distributions and prepayment application distributions are upgraded based on time periods you specify during the submission of the upgrade. During the upgrade, Payables creates payment distributions and prepayment application distributions for existing transactions in the periods you specify for upgrade and creates links between these new distributions and the original invoice distributions.

If you have customizations based on the 11i AP accounting tables, you need to transition them to use the SLA data model. Also note, if you use Oracle Projects, Projects uses SLA in Release 12 and creates accounting entries for adjustments rather than using Payables to create those entries as in prior releases. If you have any customizations based on Project adjustments, you will need to transition them to the SLA data model.

The Deferred Expenses feature, supported with Global Descriptive Flexfields at the invoice distribution level in Release 11i, has been replaced by the Multi-Period Accounting feature in SLA.

For more information about the Release 12 Upgrade, refer to the Oracle Subledger Accounting chapter of this guide.

To gain functional knowledge of Oracle Subledger Accounting, refer to the Oracle Subledger Accounting Implementation Guide.

Upgrading Payables Accounting Entries to Subledger Accounting

The following table displays the mapping from 11i entities to new Release 12 entities.

Source 11i Entity Release 12 Entity
AP/AX Accounting Events, Headers, Lines SLA Accounting Events, Headers, Lines
AP Payment History, Invoice Payments and Invoice Distributions AP Payment History and AP Payment Distributions
AP Prepayment History and Invoice Distributions AP Prepayment Application Distributions
AP Accounting Lines and Invoice Distributions AP Distribution Links

Upgrading Payables System Options to SLA

The following table displays the mapping from 11i system option settings to the new accounting setup entities and settings.

Source 11i Window and Field Release 12 Window and Field
Payables Options: Primary Accounting Method GL Accounting Setup: Subledger Accounting Method
Payables Options: Secondary Accounting Method GL Accounting Setup: Subledger Accounting Method
Payables Options: Primary Set of Books GL Accounting Setup: Primary Ledger
Payables Options: Secondary Set of Books GL Accounting Setup: Secondary Ledger
Payables Options: Prevent Prepayment Application Across Balancing Segment Obsolete. Supported by SLA inter-company balancing.
Payables Options: Relieve Future Dated Payment Liability When:
  • Payment is Issued

  • Payment Matures

  • Payment Clears

Obsolete. Supported by Payments bills payable feature.

Creating Payment Distributions and Prepayment Application Distributions

During the upgrade, Payables creates payment distributions for existing payments, links those distributions with the original invoice distributions and adds payment, payment adjustment and payment cancellation information to the payment history records. Since you control the periods that are upgraded (by setting them during the SLA upgrade), Payables also adds an indicator to mark which historical data has been upgraded.

Also during the upgrade, Payables creates prepayment application distributions for existing prepayment invoices, links those distributions with the original prepayment distributions and adds a prepayment history entity to track historical prepayment application and non-application entries. Since you control the periods that are upgraded (by setting them during the SLA upgrade), Payables also adds an indicator to mark which historical data has been upgraded.

After the upgrade, if you find that you need to adjust a historical payment or need to unapply a prepayment application that did not have its data upgraded, you can run the SLA postupgrade process to upgrade the entries for that record. For more details, refer to the Oracle E-Business Suite Upgrade Guide: Release 11i to Release 12 Guide, "Appendix G: Upgrade by Requests," Financials and Procurement Tasks, Subledger Accounting.

Creating Distribution Links

During the upgrade, Payables migrates invoice distribution links, prepayment application distribution links and payment distribution links into the SLA distribution links entity for the data that has been populated in the payment distributions and prepayment application distributions table for the periods you selected to upgrade.

Populating the Initial Balances for the Open Account Balances Listing Report

As part of the Subledger Accounting introduction, a new report, the Open Account Balances Listing, replaces the 11i Payables Trial Balance. During the upgrade, Payables and SLA populate the initial liability balances by ledger, formerly "set of books," based on Payables transactions as of the periods you selected to upgrade.

The following table displays the mapping from 11i standard reports to the new SLA-based reports.

Obsolete 11i Standard Reports Release 12 SLA Report
Accounts Payable Trial Balance Open Account Balances Listing Report
Payables Accounting Entries Report Journal Entries Report (SLA)
Payables Account Analysis Report Account Analysis Report (SLA)

Integration with Oracle E-Business Tax

In Release 12, Oracle E-Business Tax, a new product, will manage transaction tax across the E-Business Suite. In prior releases, the setup, defaulting and calculation of transaction tax for Payables was managed within Payables using tax codes, their associated rates and a hierarchy of defaulting options. This method of managing tax is still available to you in Release 12. During the upgrade, E-Business Tax migrates the tax codes and their rates to corresponding tax rules so that your tax processing can get the same results after the upgrade as it did before. If you choose to use the features of E-Business Tax, you can make the transition at your own pace, incrementally adding E-Business Tax rules to meet your requirements.

In Release 12, there are new fields added to the supplier, invoice, and related entities that track tax attributes used by E-Business Tax. Many of these attributes were implemented with Global Descriptive Flexfields in prior releases and are upgraded to regular fields on these entities.

Also during the upgrade, E-Business Tax takes information from the AP invoice lines and creates summary and detail tax lines in the E-Business Tax repository. The tax lines are upgraded based on the time period you specify during the submission of the upgrade. During the upgrade, Payables creates payment distributions and prepayment application distributions for existing transactions and creates links between these new distributions and the original invoice distributions. After the upgrade, if you adjust a historical transaction that was not upgraded, E-Business Tax automatically upgrades the transaction to the Release 12 entities.

Tax Attributes Controlled by Global Descriptive Flexfields Migrated to Core Payables and E-Business Tax Entities

The following tax attributes were implemented using descriptive flexfields on the invoice entities in Release 11i and are now implemented using named columns. The Invoice Lines upgrade will upgrade the values from the descriptive flexfields segments to the new columns. For more details on the upgrade, refer to the Invoice Lines section of this chapter.

The following are new fields on the invoice header and in the invoice interface:

The following are new fields on the invoice line and in the invoice lines interface:

The following are new fields on the invoice distribution:

For more information about the Release 12 upgrade as it pertains to E-Business Tax, refer to the Oracle E-Business Tax chapter of this guide.

To gain functional knowledge of Oracle E-Business Tax, refer to the Oracle E-Business Tax Users Guide and Oracle E-Business Tax Implementation Guide.

Multiple Organizations Access Control

Multiple Organizations Access Control is an enhancement to the Multiple Organizations feature of Oracle Applications. Multiple Organizations Access Control allows a user to access data from one or many Operating Units while within a given responsibility. Data security is maintained using the Multiple Organizations Security Profile, defined in Oracle HRMS, which specifies a list of operating units and determines the data access privileges for a user.

In Release 12, several controls are moved from the Payables Options or Financials Options forms to a new setup form that is common for Oracle Payables across all operating units, the Payables System Setup form. If the upgrade finds conflicts in the settings across multiple operating units, it will choose the most frequently occurring setting.

Oracle Applications will not automatically create security profiles during the Release 12 upgrade. If you want to use Multiple Organizations Access Control, you will first need to define security profiles, then link them to responsibilities or users.