Skip Headers

Oracle E-Business Suite Upgrade Guide
Release 11i to 12.1.1
Part Number E16342-06
Go to Table of Contents
Go to previous page
Go to next page

Financials Upgrade Impact

This appendix describes the way the upgrade affects your existing Financials and Procurement products, and highlights the impact of these functional changes on your day-to-day business. It is arranged by products in the Financials and Procurement product family.

This appendix covers the following topics:

About Business Impact and Functional Changes

An Applications upgrade alters both the technical and functional aspects of your Oracle E-Business Suite system. In addition to changes to the technology stack and file system, an upgrade also initiates specific changes that affect the way your existing products work after the upgrade and the way they look and feel. These functional changes have an impact on the way you use the products as you conduct your daily business.

Note: This appendix describes some of the ways the upgrade changes your existing products. We assume that you have read about the new features and products delivered in this release, which is included in the product-specific Release Content Documents (RCDs) and TOI, on My Oracle Support.

The discussions of the functional aspects of the upgrade in this chapter are arranged by products within the Financials and Procurement product family.

Note: See Oracle Financials and Oracle Procurement Functional Upgrade Guide: Release 11i to Release 12 for more information about upgrading your Financials and Procurement products.

Financials and Procurement Products

Changes to the products in this section affect Financials and Procurement products. Before you begin the upgrade, your Financials and Procurement application specialists should have made plans to accommodate the relevant changes.

Advanced Collections

Changes to Oracle Advanced Collections in the upgrade are described in this section.

Note: See Oracle Advanced Collections Implementation Guide for more information.

Administrator UI Redesign

This release introduces a new user interface for entering and maintaining Advanced Collections setup data.

Territory Management Collection Usage

This release introduces a collection usage in the Territory Management application specifically for Advanced Collections. A manual territory migration script has been created to move collection "sales usage" territories to collection "collection usage" territories. This migration is mandatory if you want to assign collection agents/groups to customers using Territory Management.

The IEX: Territory Assignment concurrent program has been rewritten to accommodate the new collection usage. See the Oracle Territory Management User Guide and the Oracle Advanced Collections Implementation Guide for further details.

Collector Migration

This release displays Advanced Collection menus in the Receivables navigator. An automated script runs during the upgrade to create resources from collectors. In some cases, where the script cannot determine an appropriate resource, it does not create one. If you find that the Collector Navigator menu pages do not work after the upgrade, create the resource manually.


Changes to Oracle Assets in the upgrade are described in this section.

Subledger Accounting

The new Subledger Accounting Architecture upgrade changes Oracle Assets in the following way.

Note: See Oracle Subledger Accounting Implementation Guide and Oracle Financials Implementation Guide.

Invoice Distributions from Oracle Payables

Invoice distributions from Oracle Payables that interface to Assets are upgraded to display the Invoice Line Number.

Global Descriptive Flexfield Migration for Greece

Information stored in descriptive flexfields for Greece that are commitment and investment law is upgraded to named fields in the Asset Workbench.

Cash Management

Cash Management changes in the upgrade are described in this section. See Legal Entity Configurator under Cross-Product Functionality in Chapter 1 for more information.

Centralized Banks and Accounts

The new centralized bank account model provides a single point for defining and managing internal bank accounts for Oracle Payables, Oracle Receivables, Oracle Payroll, Oracle Cash Management, and Oracle Treasury. A single legal entity is granted ownership of each internal bank account, and one or more organizations are granted usage rights. In addition, banks and branches are migrated to the Oracle Trading Community Architecture (TCA) and defined as parties.

Banks are merged if the following attributes are the same:

During the upgrade, Cash Management grants ownership of each internal bank account to one legal entity. The owning legal entity is derived from the organization that owns it in Release 11i.

Internal Bank Account Security

In Release 11i, bank accounts were used by a single operating unit, and operating unit security was used to control the maintenance of these accounts. In the new model, bank accounts can be accessed by multiple operating units, but are owned by a single legal entity. Therefore, the bank account maintenance security, which secures the create and update of bank accounts, was moved to the legal entity level. Using the new security wizard, you can grant each responsibility access to create and modify bank accounts owned by one or more legal entities.

During the upgrade, Cash Management sets the Bank Account Maintenance security for each responsibility that had access to the bank account forms in Release 11i. For each of these responsibilities, a legal entity is derived from the organization that the responsibility had access to in Release 11i. The responsibility is then granted bank account maintenance security for this legal entity.

System Parameters

In order to provide more flexibility and control over the reconciliation process, many of the options that used to be defined as system parameters at the system level (operating unit) have been moved to the bank account level. By placing these controls at the bank account level, both the manual and automatic reconciliation processes can be configured depending on the bank account and its uses. In addition, the remaining system parameter options and controls from Release 11i are defined at the legal entity level in this release.

E-Business Tax

Oracle E-Business Tax covers “standard” procure to pay and order to cash transaction taxes, with the exception of withholding taxes, India taxes, and those taxes handled by the Latin Tax Engine solution. It is based on a single-point solution for managing transaction-based tax, which uniformly delivers tax services to all E-Business Suite business flows through one application interface.

E-Business Tax replaces the following Oracle Release 11i tax solutions:

This fully automated upgrade ensures that your current investment in Release 11i Tax Setup is not lost, and you can implement new features at a pace that best suits your business. Additional data is automatically created using a predefined naming strategy.

Note: See Oracle Financials and Oracle Procurement Functional Upgrade Guide: Release 11i to Release 12.

In current applications, tax functions are typically executed by the operational application, for example, the Accounts Payable clerks perform the definition of tax rules in Payables. In this release, the responsibility of tax setup should be shifted to the tax manager. All transactions and events where a respective tax rule is relevant are serviced by Oracle E-Business Tax.

See the following product sections for more information on product-specific impact on E-Business Tax upgrade:

Financials for the Americas

Changes to Oracle Financials for the Americas are included in this section.

Receivables Bank Transfer

The Latin American Receivables Bank Transfer feature stores amounts for additional accounting entries over standard Oracle Receivables accounting. These amounts are stored at the time the documents are sent to a bank for collection and when the bank sends information about the collection from the customers. Subledger Accounting, bank consolidation and legal entity key initiatives also impact this feature.

Several forms have been modified to include the Operating Unit field. The global descriptive flexfields on the Bank Branches and Bank Accounts forms are available as standard fields on the Global Receipt Method Accounts form.

In this release, to create account data in Subledger Accounting, you execute a concurrent program (Create Accounting) from the Standard Request Submission (SRS) request screen using the Receivables responsibility. It creates subledger accounting for all Receivables transactions, including the Bank Transfer collection documents. You can view and transfer data to General Ledger from the Receivables responsibility.

Latin Tax Engine

E-Business Tax in does not replace the Latin Tax Engine. However, the Release 11i Latin Tax Engine is upgraded to use some of the E-Business Tax and Trading Community Architecture setup.

These options are upgraded to E-Business Tax under the Product Options page flow: Tax System Options in the Receivables System Options window (Tax Method, Tax Code, Inclusive Tax Used flag), and Tax System Options / Rounding Options (Reporting Currency, Precision, Minimum Accountable Unit, Allow Override, and Rounding Rule).

In Release 11i, a default Tax Code and Tax Rounding Rule can be assigned to customers, customer accounts, and customer account site uses in Trading Community Architecture. The setup at the customer level has been moved to Oracle E-Business Tax’s Party Tax Profile page flow, which is linked to the Customers page flow. The setup at customer accounts and account site uses levels have been preserved for backward compatibility purposes.

The Latin Tax engine setup forms for Latin Locations, Tax Exceptions by Fiscal Classification, and Tax Exceptions by Items now use the new Trading Community Architecture geography model for picking and showing the location elements instead of the lookup codes.

An Item Category set (FISCAL CLASSIFICATION) is created in Inventory and the values of the Global Descriptive Flexfield (GDF) attribute Fiscal Classification on inventory items are upgraded as a category assignment to the items.

The GDF attribute (Fiscal Classification Code) on the Memo Lines form is disabled and the value is migrated to the Product Category attribute on the same form.

Tax Regime Code, Tax, and Tax Status code fields are added in the Tax Codes form. The Latin Tax Engine’s Tax Category attribute value is now the value of the Tax attribute on the Tax Codes form.

Withholding Agent

The Latin American Extended Withholding has a setup step called Company Withholding Applicability, where existing legal entity (or entities) can be selected and defined as the withholding agent for one or more withholding types. In Release 11i, HR Locations were displayed for selection. In this release, legal entities upgraded and/or defined in the new legal entity flow are displayed for selection on the Latin American Company Applicability form. This change has very little impact on setting up Company Withholding.

Brazilian Receivables Interest

Multiple Organizations Access Control requires the Latin American profile option JLBR_PAYMENT_ACTION to be upgraded to a named column, which has an impact on the Oracle Receivables interest solution for Brazil. This profile option value has moved to the Payment Action GDF attribute on the System Options form in Receivables.

Colombian NIT

The GDF attribute Third Party ID value on the Enter Journals form is upgraded to the attribute Third Party on the same form.

Chilean Reporting

The GDF Document Type attribute value on the Payables Invoice Workbench form is upgraded to the attribute Intended Use on the same form.

Obsolete Features

The following features are obsolete:

Financials for Asia/Pacific

Changes to Oracle Financials for the Asia/Pacific are included in this section.

Legal Entity for Korea, Singapore, and Taiwan

Legal entity information such as name and tax registration number that are defined as Human Resources (HR) locations associated to HR organizations in Release 11i are created in the centralized legal entity model in this release using the same legal entity definition. To define new legal entity information, or to modify definitions created after the upgrade, you must use the new Legal Entity Configurator.

Tax Setup for Korea, Singapore, and Taiwan (non-withholding)

Non-withholding tax codes setup (for example, Value Added Tax (VAT), Goods and Services Tax (GST), Input and Output taxes) defined in Payables Tax Codes and/or Receivables VAT Taxes windows, are upgraded to the Oracle E-Business Tax model. To define new taxes or modify the upgraded ones, you must use the new Regime to Rates.

Korean Withholding Taxes

Business locations and respective tax registration numbers that are not legal addresses can still be defined as HR locations for tax reporting purposes. Withholding tax codes continue to be defined through the Tax Codes window in Oracle Payables.

Taiwanese Government Uniform Invoices

Government Uniform Invoice Type is upgraded to the Document Subtype classification model in Oracle E-Business Tax. Document Subtype can be entered through the Payables Invoice Workbench and Receivables Transaction Workbench using the Tax window. The Source and Types Relationships window is obsolete.

China Accounting Software Data Interface Standard (CNAO)

The following changes apply to the China Accounting Software Date Interface Standard solution for Release 12.1.1.

Financials Common Country Features

Changes to Oracle Financials Common Country Features are described in this section.

Contra Charges

The Contra charges feature is obsolete in this release. It is being replaced by the new Netting solution introduced in the Oracle Financials Common Modules product. The upgrade migrates the setup, but not the transactions to the new solution.

Note: See Financials Common Modules in this appendix for more information.

Interest Invoices

The Interest Invoices feature is obsolete in this release. The new Late Charges feature introduced in the Oracle Receivables product replaces it.

Note: See Receivables in this appendix for more information.

Financials Common Modules

Advanced Global Intercompany System

Oracle Advanced Global Intercompany System (AGIS) is a new module that allows companies to streamline intercompany processing and facilitates the reconciliation of intercompany transactions. It replaces the Global Intercompany System (GIS) feature provided by General Ledger in Release 11i.

All setup and transaction data is moved to a new data model, and all Oracle forms in the Global Intercompany System are replaced by browser-based user interface pages.

Changes include:

Payables and Receivables Netting

In Release 11i Oracle Financials had three netting solutions: Single Third Party in Oracle Public Sector Financials International Contra Charging in Oracle Financials for Europe, and Receivables and Payables Netting in Oracle U.S. Federal Financials. These are all replaced in this release with the Netting functionality of the Oracle Financials Common Modules.

Setup related to Contra Charging and Receivables and Payables Netting features in Release 11i is migrated in the following way:

Financials for Europe

Changes to Oracle Financials for Europe are included in this section.

EMEA VAT Reporting

The EMEA Value Added Tax (VAT) Reporting feature migrates VAT reporting solutions for EMEA in Release 11i to this release. This migration eliminates any existing country specific restriction with improvement wherever possible.

Consolidation of Country-specific Reports

There are many country-specific reports in Release 11i that are very similar in their data requirements. EMEA VAT reporting consolidates such reports to retrieve the required data from a single extract implementing XML Publisher technology. All reports are converted into templates and, therefore, allow more flexibility for specific formatting requirements.

E-Business Tax-based Reporting

The basics of tax definition change from Release 11i with the introduction of Oracle E-Business Tax. EMEA VAT reporting now includes E-Business Tax for the reporting requirements.

The attribute Tax Registration Number (TRN) for legal establishment becomes very significant for tax reporting with E-Business Tax. A central reporting configuration by TRN consolidates definition of allocation rules, VAT register, and other configuration attributes into a single setup, referred to as the legal reporting entities.

This release also provides the option of reporting by ledger or balancing segment to support proper reporting of historical transactions. To use this reporting by accounting entities option, you must map the entities to a TRN in order to derive VAT related setups that may apply.

Architecture Changes

As a result of the upgrade, you can move from an accounting setup that includes only one GRE/legal entity to an accounting setup with multiple GRE/legal entities by assigning additional legal entities at any time. If you add additional legal entities to an upgraded accounting setup during a reporting period (for example, calendar year for tax report), reports run by a legal entity parameter do not return complete history for legal entities. Reporting by legal entities helps report the set of transactions in these scenarios.

This release introduces a single Financials Common Country (JG) table for storing tax-related data retrieved from the Tax Reporting Ledger (TRL) and other core tables. This entity gets its data through the selection process, which is the only process to access TRL. Extracts retrieve their data from this JG entity. This enhances the performance of each extract and encapsulates all business logic around TRL only in the selection process.

There are a few extracts that report non-tax details of transactions along with the tax details. They are based directly on the Payables and Receivables core application tables, as TRL processes only tax details. However, these non-JG (non-TRL) extracts are still based on the setup configuration to derive the right data.

Reporting Process Changes

Allocation is an independent process. It encapsulates the Release 11i business logic around Belgium and Portugal allocation.

Final reporting is also an independent process. After final reporting, data in the single JG table cannot be modified. This has an interface with E-Business Tax, through which transactions are updated as finally reported in the E-Business Tax repository. This process along with the JG tax entity provides the framework for preliminary and final reporting. This process encompasses the declaration functionality of Release 11i.

Financials for India

The following descriptive flexfields have been replaced with alternate approaches:

General Ledger

Oracle General Ledger has made significant enhancements to support multi-national companies and shared service centers. These changes allow companies to maximize processing efficiencies while maintaining a high level of information and setup security.

You can perform simultaneous accounting for multiple reporting requirements. Companies can also gain processing efficiencies by being able to set up, access, and process data across multiple ledgers and legal entities from a single responsibility. In addition, General Ledger definitions and setup definitions, such as MassAllocations and Financial Statement Generator (FSG) reports, can be more easily shared and secured across your organization by allowing you to restrict certain users from viewing or updating those definitions or using them in processes.

Many global features that were only available in localized versions have been included in General Ledger to allow more customers to take advantage of these features.

Terminology Changes

Note the following changes in the terminology related to General Ledger.

Centralized Accounting Setup

The new Accounting Setup Manager simplifies and centralizes accounting-related setup for common financial components that are shared across financial applications. From a central location, you can define your legal entities and their accounting context, such as the ledgers and reporting currencies that perform the accounting for your legal entities.

Accounting Setup Manager allows global companies that operate in different localities to meet multiple reporting requirements through the use of multiple ledgers and reporting currencies.

Sets of Books

Multiple Reporting Currency

Some Release 11i options for reporting sets of books have been moved to the reporting currency definition. For example, many MRC profile options have been moved to the reporting currency definition.

Many options for a set of books that were independently defined for the primary and reporting sets of books have been streamlined. In addition, many of the ledger options for the reporting currency default from the primary ledger. The upgrade for MRC sets of books varies depending on the current configuration and conversion options you specify.

Global Accounting Engine

Single posting sets of books with multiple main sets of books upgrade to multiple primary ledgers that share the same secondary ledger.

Period Rates Replaced by Daily Rates

Period rates are replaced with daily rates.


General Ledger modifies revaluation templates to use corresponding daily rates for those that used period rates prior to the upgrade. No user interaction is required.

Revaluation sets are now usable across ledgers that share a common chart of accounts. In some cases, you may need to enter the secondary tracking segment for revaluation sets involving a secondary tracking segment before running revaluations with upgraded templates.

STAT Report-level Currency for Financial Statement Generator Reports

The report-level and runtime currencies for Financial Statement Generator reports now need to represent the ledger currency. If you need to report on statistical balances, modify report definitions to use the STAT currency at the row-level or column-level or use currency control values for the STAT currency.

Global Accounting Engine

In this release, Oracle Global Accounting Engine functionality is obsolete. Both the existing setup options and all the accounting data of Global Accounting is migrated to Oracle Subledger Accounting.

Internet Expenses

Changes to Oracle Internet Expenses are described in this section.


Internet Expenses can represent the parent-child relationship of an itemized expense line by creating a new parent line with a unique parent identifier.

Integration with Payments

Integration with Oracle Payments takes advantage of encryption capabilities. Credit card transaction data has been moved to Payment’s secure data payment central repository. See Payments in this appendix for more information.

Per Diem and Mileage

Per diem and mileage transaction data is not migrated. However, data that existed before the upgrade remains intact. Mileage and per diem setup data is automatically upgraded.

Expense reports that were created prior to the upgrade display information in a pre-Oracle Internet Expenses minipack (11i.OIE.K) format. Newly created expense reports use the new user interface.

Integration with E-Business Tax

The integration with Oracle E-Business Tax has no direct tax upgrade impact. Tax lines run through Oracle Payables. See Oracle Payments documentation for details.


Oracle iPayment is obsolete In this release, and is replaced by Oracle Payments. See Payments in this appendix for more information.


Changes to Oracle iProcurement are described in this section.

Catalog Management

Oracle iProcurement provides catalog administrators online authoring capability for content stored in global blanket agreements (GBPA). The existing batch upload process continues to be optimized for handling large catalog data file uploads. It is also available for buyers (from the new Buyer’s Work Center) and for suppliers (from the iSupplier Portal).

Bulk-loaded items in iProcurement are migrated to newly created GBPAs. The extractor is obsolete, and the catalog content is updated in real time.

Note: We recommend that you complete the approval process for any agreement pending approval before you begin the catalog upgrade. The content of the approved agreements is available on the iProcurement search page after the upgrade.

Content Security

Release 11i functionality for Realms, Stores, and Catalogs has been combined and is collectively referred to as enhancements in Content Security. In this release, Content Zones have replaced Catalogs.

Catalog administrators can partition local catalog content into Local Content Zones based on items’ supplier, supplier site, item category, and browsing category information. Once defined, Content Zones may be made accessible to users with specific responsibilities or operating units. Content Zones may be assigned to multiple stores, and stores may contain multiple Content Zones.

iSupplier Portal

In Releases 11.5.9 and 11.5.10, iSupplier Portal used Trading Community Architecture to store pending change requests in supplier address and supplier contacts. In this release, these pending change requests are moved into a set of iSupplier Portal tables.

See the iSupplier Portal section in Oracle Financials and Oracle Procurement Functional Upgrade Guide: Release 11i to Release 12 for the assumptions made during the upgrade.

Leasing and Finance Management

Improved Legal Entity Definition

Derivation of Legal Entity from Operating Unit

This release introduces Legal Entity to be defined and used in the transactions. Legal entity is associated with the Operating Unit. During the transaction entry, Legal entity is derived based on the operating unit. However, you are provided with the option to change as needed.

During the upgrade:

Simplify Statutory Compliance for Taxes

This release introduces changes to the Leasing and Finance Management tax engine, setup, and its integration to eBTax.

Upgrade Tax Setup

User-defined Fiscal Classification and Tax Basis Override setup steps are upgraded to use the ‘Sales Quote’ transaction type in place of the ‘Quoting’ transaction type.

Upgrade tax source to include tax attributes. Upgrade tax lines - additional attributes are added to tax lines such as TAX_LINE_NUMBER, TAX_REGIME_CODE, TAX, TAX_JURISDICTION_TYPE, TAX_JURISDICTION set the values for these columns.

Migrate Transaction Business Category definitions setup data to new entity OKL_TAX_ATTRIBUTE_DEFINITIONS.

Upgrade Contracts and Transactions

Upgrade existing contracts to assign default value for ‘Tax Schedule Applies’ Flag. The value is defaulted from system options setup defined for contract’s Operating Unit.

Cancel all Rebook transactions that have not been completed. Cancel all termination quotes in draft, rejected, and submitted status.

Set TAX_INVOICE_YN flag on the transaction types table to 'Y' for the following transaction types:

Upgrade existing pre-booking transactions for contracts that have not been booked. Try_id for such transactions is changed to try_id of ‘Booking’ transaction.

Upgrade status of existing Asset Location Change transactions from ‘Entered’ to ‘Processed’.

Upgrade Asset Location Change transactions Lines table. Tal_type for Asset Location Change transactions is upgraded from ‘CFA’ to ‘AGL’ and dnz_cle_id of okl_txl_inst_items is upgraded to appropriate value for relevant Asset Location Change transactions.

Upgrade Asset Location Change Transaction header table. Transaction type of header table is updated from ‘CFA’ to ‘ALG’ and truncates date transaction occured for relevant Asset Location Change transactions.

For each Asset Location Change transaction, a request is created in the transaction requests table and Asset Location Change transaction is updated with the corresponding request id.

Integration with eBTax

Include existing values of ‘Usage of Equipment’ field under Sales and Authoring to eBTax Source for ‘Intended Use’. Upgrade ‘Intended Use for Tax” field in Sales, with existing value of ‘Usage of Equipment’.

Migrate the following upfront tax lines to eBTax:

Enhanced Accounting

Integration with Subledger Accounting (SLA)

This release introduces Oracle Subledger Accounting (SLA) to manage accounting across subledger transactions. Leasing and Finance Management no longer creates accounting entries. Existing Leasing and Finance Management accounting options and setup remains, and affects the generation of accounting distributions in the Leasing and Finance Management data model. However, the accounting distributions are now simply one of many sources for the generation of final accounting in the Subledger Accounting module.

During the upgrade:

Consistent Accounting Transaction Status

In order to achieve consistency and ensure data integrity between accounting events and accounting transactions, the specific loss provision, general loss provision, miscellaneous and accrual accounting transactions are upgraded with the transaction status of Processed from Entered.

In this release, Leasing and Finance Management introduces separation between the termination accounting transaction status and the termination process status. During the upgrade, the termination process status is set to Processed if accounting entries have been generated for the termination transaction. If accounting entries are not generated, then the termination process status is migrated and set with the appropriate intermediate existing status.

Centralized Accounting Transaction Repository

In this release, all Asset Disposition accounting transactions are automatically migrated to the central accounting transactions entity.

Account Derivation Accounting System Option

This release introduces the Account Derivation accounting system option which is used by Leasing and Finance Management to determine if General Ledger account codes must be defined on the accounting template lines. The Account Derivation accounting system option governs whether the account codes, if defined in Leasing and Finance Management on the accounting template lines, are supplied as additional accounting sources for generation of final accounting in the Subledger Accounting module.

During the upgrade, Leasing and Finance Management sets the value of the Account Derivation accounting system option as Accounting Template Set.

Improved Disbursements and Payables

Leasing and Finance Management Disbursement transaction tables must be upgraded - if amounts were negative, invoice type would be Credit Memo.

This release introduces new consolidation tables which need to be populated with consolidation data based on existing data in transaction tables and Oracle Payables invoice header and lines. The link between transaction tables and Oracle Payables invoice header and line tables must also be upgraded. Additionally, Oracle Payables internal transaction tables are upgraded to maintain a new link between transaction tables and AR invoice.

Manage Shared Services Efficiently

Multiple Organization Access Control (MOAC)

This release allows multiple operating units for a responsibility. This is achieved by attaching allowed operating units to a security policy and further attach to a responsibility. New synonyms were created and secured by the security policy. This has resulted in changes to many objects.

During the upgrade, the following scripts are used to achieve this:

View Leasing Information on Payable Invoices and Vendor Disbursement Details and Support Supplier Merge into TCA

Upgrade of Payable Bank Accounts

In this release, payable maintained bank accounts are obsolete. Bank accounts are distributed between Cash Management (CE) and Oracle Payments (IBY). Cash Management maintains Internal Bank Accounts. Oracle Payments maintains External Bank Accounts, Contract Party, T&C, VPA, IA, and Billing Setup for Asset. Same Rule reference is used LABACC, IBY upgrade instance.

Leasing uses external bank accounts (maintained by Oracle Payables) only. Queries to retrieve bank account information must be modified to join with IBY tables to retrieve correct information.

Improved Document Creation with XML Publisher

In this release, XML publisher is used for sending documents. The process template associations already created by the customer for one-to-one fulfillment must be upgraded to be used by XML Publisher. This is achieved by upgrading the Process Templates table. Upgrade the value of the XML_TMPLT_CODE to the corresponding seeded Template Code of the process. RECIPIENT_TYPE will be updated to LESSEE for every record.

Improved Customer Billing

Invoices created in Oracle Receivables through Leasing and Finance Management must be upgraded to the new architecture by stamping the Leasing Transaction ID on the invoices. With the Leasing and Finance Management Advance Receipts made obsolete, the existing and unutilized stream allocations in Leasing and Finance Management will be migrated as on-account applications for the corresponding receipt in Oracle Receivables.

Transaction tables will be upgraded to add additional columns, currently hosted in the consolidation and external tables. The data for these additional columns in the transaction tables will be populated from the equivalent records in the Leasing and Finance Management consolidation and external tables. Two level billing transactions are upgraded to three level billing transactions by creating an entry in details table for all records in lines table.

Automatic Multi-GAAP

Secondary Representation Method Accounting System Option

This release introduces the Secondary Representation Method accounting system option which is used by Leasing and Finance Management to determine whether to generate secondary representation accounting transactions and accounting distributions, or not.

During the upgrade, Leasing and Finance Management sets the value of the Secondary Representation Method accounting system option, if not already set to Automated Accounting during the 11i pre-upgrade step, as follows:

Representation Type Transaction Attribute

In this release, Leasing and Finance Management introduces the Representation Type attribute on the accounting transactions entity. Leasing and Finance Management uses the Representation Type attribute while displaying accounting transactions on the Accounting Transactions user interface to identify the accounting transactions belonging to the selected representation.

During the upgrade, Leasing and Finance Management sets the value of the Representation Type attribute to Primary for all accounting transaction headers.

Accrued Stream Elements Indicator

During the upgrade, Leasing and Finance Management sets the value of the Accrued Yes/No stream element indicator on the stream element entity to Yes, up to the date until which the contract’s local product stream elements are accrued. The stream elements which are upgraded, are those:


During the upgrade, Oracle Loans accounting functionality is migrated automatically to Subledger Accounting, and other common data model components.

Integration with Payables and Payments for Loan Disbursement

This release introduces Oracle Payments. It is used by Oracle Payables and Oracle Loans for processing loan payments. Loans creates a payment request in Payables, which, in turn, disburses funds through Oracle Payments.

Integration with Subledger Accounting

This release introduces Subledger Accounting for managing accounting across subledger transactions. Oracle Loans no longer creates any accounting entries. During the upgrade, accounting options and their settings, and the existing accounting entries in the loans data model, are moved to the new accounting data model to ensure a continuous business operation between the two releases. All Loans accounting lines related to the transactions are also migrated.

In Release 11i, accounting entries were created in the General Ledger Interface when a loan was approved. The process remains the same, except that the accounting events are created for Subledger Accounting to process. You must run the Create Accounting concurrent program manually or on a scheduled basis to generate journal entries and to transfer them to Oracle General Ledger. Accounting on individual loans can also be created real time from the Loan Accounting Tab.

Loan Types and Products

The Release 11i Loan Type lookup is obsolete. In this release, you can use Loan Types, along with loan products, to streamline the loan agents’ application process while enforcing company policy across agents and applicants.

Some of the defaulting parameters are:

In the upgrade, seeded loan types are migrated to the loan types entity. You must set up product(s) as per the deploying company’s organization with the upgraded loan types, based on your company requirements.

The Loan Type lookup is obsolete. For verification, query loan types in the loan types user interface from the loan administration responsibility.


This release introduces Oracle Subledger Accounting, E-Business Tax, Ledgers, Banks, and other common data model components that are used by Oracle Payables.

Suppliers in Trading Community Architecture

Suppliers are now defined as TCA Parties. During the upgrade, TCA Party records are created/updated for all suppliers, they are linked to their records in the existing supplier entities, and the payment and banking details are migrated into the Oracle Payments data model. Although the underlying data model has changed, you still enter and manage suppliers in the Suppliers windows.

Invoice Lines

Oracle Payables introduces invoice lines as an entity between the invoice header and invoice distributions. 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. The charge allocation table used in prior releases to manage accounting allocations is obsolete.

During the upgrade, Oracle Payables creates invoice lines for all existing invoices, creating one line for every distribution available in the Release 11i distributions table, except in the case of reversal pairs. In those cases, Payables creates one line with a zero amount.

Centralized Banks and Bank Accounts Definitions

All internal banks and bank accounts that you had defined in Release 11i are automatically migrated to the central Cash Management entities. The bank accounts and their payment documents are owned by a legal entity rather than by an operating unit. See Cash Management in this appendix for more information.

Also, the banks and bank branches are centralized in Cash Management entities as described in the preceding paragraph. However, the bank accounts you had defined for your suppliers are migrated from the Payables entities to the central Payments entities. Payments centralizes and secures all payment instrument data, including external bank accounts, credit cards, and debit cards. See Payments in this appendix for more information.

Payment Document Sequencing

If you used document sequencing for payment documents in Release 11i, then your document sequence category is migrated from the payment document, which is associated with a bank account and, hence a legal entity, to the bank account uses entity. This change preserves the option of having document sequence categories vary across operating units.

Integration with Payments for Funds Disbursements

Oracle Payments can be used by Oracle Payables for processing invoice payments. See Payments in this appendix for more information.

Payment Features Controlled by Global Descriptive Flexfields

Many European payment features that were implemented using global descriptive flexfields in Release 11i are migrated to the Oracle Payables, Oracle Payments, and Oracle Cash Management data models.

Integration with Subledger Accounting (SLA)

This release introduces Oracle Subledger Accounting (SLA) to manage accounting across subledger transactions. Payables no longer creates any accounting entries. 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 to ensure a continuous business operation between the two releases.

During the upgrade, all accounting events, headers, and lines from the Release 11i data model are upgraded to the new Subledger Accounting events, headers, and lines data model, regardless of the period range you set for the upgrade.

Integration with E-Business Tax

Oracle E-Business Tax manages tax across the E-Business Suite. In prior releases, the setup, defaulting, and calculation of tax for Payables was managed within Payables using tax codes, their associated rates, and a hierarchy of defaulting options. This method is still available in this release. During the upgrade, E-Business Tax migrates the tax codes as appropriate within E-Business Tax so that your tax processing can work the same way after the upgrade as it did before.

New fields are added to the supplier, invoice, and invoice lines entities to 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.


In this release, 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 is now obsolete.

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 this release, formats are created as templates in Oracle XML Publisher, and applied to an XML data file produced by Oracle Payments.

The upgrade transforms each payment format that Oracle Payments supports into two entities: an XML Publisher template and a Payments seeded format. The seeded format is linked to the template. Logic to validate the formatted data has been separated from the format programs, and is upgraded to a prepackaged library of validations. These validations are linked to the seeded Payments format, and are executed during the payment process.

Secure Payment Data Repository

Oracle Payments serves as a payment data repository on top of the Trading Community Architecture 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 Oracle Trading Community Architecture. 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 such as customers, students, and Global Descriptive Flexfields and is created as a payer record in Oracle Payments and linked to the party. Party payment information moves from entities such as 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 held in the Oracle Payables bank account model are migrated to Oracle Payments and linked to the owning payer or payee. Third-party credit card detail is migrated from the Payables data model and applications such as Order Management into Oracle Payments’ data repository.

Credit card data held in the following products in Release 11i is migrated to Oracle Payments:

Improved Electronic Transmission Capability

Oracle Payments provides secured electronic payment file and payment message transmission and transmission result processing, replacing previously existing electronic transmission features in Oracle iPayment, Oracle Payables, and 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 Payables transmission architecture, you should review Oracle Payments’ electronic transmission capability and plan on replacing your customization.

Payables Impact

The process to issue payments from Oracle Payables changes in this release to use the new Oracle Payments funds disbursement process. The changes impact other versions of Payables such as U.S. Federal Financials and country-specific globalizations.

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 Payables 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 Payables 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:

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.

Receivables Impact

Oracle Receivables integrates with Oracle Payments for funds capture processing to electronically receive money owed by debtors, such as customers. Oracle Payments works with Receivables 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 Receivables 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 are created by the upgrade: 1) one payee to hold master settings for the funds capture payment process; 2) one payment system; and 3) one payment system account.

The upgrade creates new routing rules from Receivables 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.

iPayment Impact

Oracle iPayment is obsolete In this release, and is replaced by the Oracle Payments architecture. Some of the key entities described in the previous section are used in the funds capture process. They existed in iPayment with the exception of the Funds Capture Process Profile. It holds 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.

Profitability Manager

Remove (Import) From Migrated Condition Component Display Names

Each time you migrated a Mapping Rule in previous releases, the value; (Import) was prefixed to the version display name of the rule. This occurred for the following rule types:

As a result, (Import) was prefixed multiple times in the display name of the rule (e.g. "(Import)(Import)(Import)").

The Rule Migration feature limits the number of (Import) values prefixed to a Mapping Rule name to one value, and eliminates the (Import) values from the dimension component names.

Applying this release runs a script to clean up the version display names for Mapping Rules, Conditions, Dimension Components, and Data Components that were imported and contained multiple "(Import)" prefixes. For Mapping Rules and Conditions, the new display names will include one "(Import)" substring prefix. For Dimension Components and Data Components, the display names will not contain the "(Import)" substring.

Note: The display names will not be updated for rule versions where the shortened version display name results in a duplicate name. In such cases, users will need to manually update the version display names via the user interface.

Local Conditions Replaced with Global Conditions

In Release 12.0.3, the concept of a local condition in a mapping rule has been eliminated. The patch installation process upgrades all local conditions to global conditions. The resulting global conditions are created in the same folder as the parent mapping rule.

The resulting condition name will be: LOCAL MAPPING 99999:<Parent Rule Name>.

Profitability Analytics are also impacted. Prior to the release of Profitability Manager 12.0.3, mapping rules allowed for local conditions. The Where Used dashboard provides several answers to help users identify where these local conditions are used.

Post Profitability Manager 12.0.3 no longer has the option to create a local condition. All conditions are considered global to rules. Therefore, the local condition answers do not display any data and should be removed from the dashboard.

Public Sector Financials

Changes to Oracle Public Sector Financials are described in this section.

Integration with Subledger Accounting

This release introduces Subledger Accounting for managing accounting across subledger transactions. The subledger’s accounting entries are generated and stored in a centralized repository. In Release 11i they were created separately by subledgers and General Ledger

Subledger Accounting is delivered with seeded Subledger Accounting Methods and Account Derivation Rules that generate the accounting entries from subledger transactions. The seeded Subledger Accounting Methods for Public Sector customers include Encumbrance Accrual and Encumbrance Cash. These rules derive the appropriate accounting entries specific for Public Sector customers. For example, Oracle Receivables generates Multi Fund Accounting entries and the seeded Subledger Accounting Methods contain Journal Line Definitions and the Account Derivation Rules to generate Multi Fund Accounting Entries.

During the upgrade, the subledger accounting method is determined based on the encumbrance settings in your subledger applications, such as Receivables and Payables. Public Sector sets the correct subledger accounting method for each Primary and Secondary Ledger in General Ledger. Reporting Currencies inherit the same subledger accounting method as their source ledger.


Changes to Oracle Purchasing are described in this section.

Local Contract Purchase Agreements upgrade to Global Contract Purchase Agreements

In this release, the distinction between Global and Local distinction for Contract Purchase Agreements no longer exists. All Contract Purchase Agreements can now be enabled for use across multiple operating units. All existing Contract Purchase Agreements are upgraded to have a single organization assignment. In this assignment, the values of Requesting and Purchasing operating units are that of the operating unit that owned the Local Contract Purchase Agreement, and the value of the Purchasing Site is the Supplier Site on the Local Contract Purchase Agreement.

Unified Catalog for Purchasing and iProcurement

Prior to this release, iProcurement and Purchasing maintained separate catalogs. In this release, these catalogs are combined together in Purchasing. During the upgrade, the items that were bulk-loaded into iProcurement are migrated to Global Blanket Agreements in Purchasing. If you have implemented iProcurement, you may notice new Global Blanket Agreements in Purchasing. See iProcurement in this appendix for more details.

Integration with E-Business Tax

A fully automated E-Business Tax upgrade migrates setups related to Oracle Purchasing. This ensures that tax-related functions in Purchasing continue to work as before. With the new tax solution, you have the option to centrally manage tax rules and configure them to support local requirements.

All common tax setups are performed through the E-Business Tax module. Tax Defaulting Hierarchy in Purchasing Options is migrated to E-Business Tax.

The Tax Details and Tax Code Summary forms are obsolete. This information is now displayed on the Manage Tax page (accessible through menu options). In addition, the Tax Code field on the Enter Purchase Order, Release, and Requisition forms is obsolete. Tax Code is now referred to as Tax Classification, which you can specify on the Additional Tax Information page (from the Manage Tax page).

The profile options Tax: Allow Override of Tax Code and Tax: Allow Override of Tax Recovery Rate are migrated to eBTax: Allow Override of Tax Classification Code and eBTax: Allow Override of Tax Recovery Rate, respectively.


Changes to Oracle Receivables are described in this section.

Integration with E-Business Tax

This release introduces Oracle E-Business Tax to manage tax across the E-Business Suite. During the upgrade, system and customer options used to control tax calculation and tax code defaulting are migrated from Oracle Receivables into Oracle E-Business Tax entities. See E-Business Tax in this appendix for further details.

Integration with Subledger Accounting

This release introduces Subledger Accounting for managing accounting across subledger transactions. Receivables no longer creates any accounting entries. Existing Receivables accounting options and setups remain and affect the generation of accounting distributions in the Receivables data model. However, the accounting distributions are now simply one of many sources for generation of final accounting in the Subledger Accounting module.

Release 11i customizations to Receivables accounting tables still work after the upgrade, provided you do not use any of the new features of Subledger Accounting. Once you use Subledger Accounting to update an accounting rule, or any other aspect of accounting, you must transition your customizations to reference the Subledger Accounting data model.

Transactional data is upgraded for a user-specified number of fiscal years. If you need to run reports or query transactions that are outside the specified upgrade period, you have to launch the upgrade of additional periods. See Subledger Accounting in this appendix for further details.

Centralized Banks and Bank Accounts Definitions

In this release, all internal banks and bank accounts you had defined for your operations are automatically migrated to the central Cash Management entities. Remittance bank accounts are owned by a legal entity rather than by an operating unit.

Banks and bank branches are centralized in Oracle Cash Management entities, as described in the preceding paragraph. However, bank accounts you had defined for your customers are 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, and debit cards. See Cash Management in this appendix for further details.

Integration with Payments for Funds Capture

This release introduces Oracle Payments, which is used by Oracle Receivables for processing funds capture. See Payments in this appendix for further details.

Balance Forward Billing

The Release 11i Consolidated Billing Invoices functionality has been enhanced to include more flexible billing cycles, to consolidate invoices at site or account level, and to present Balance Forward Bills using the user-configurable Bill Presentment Architecture. If you are using Consolidated Billing Invoices in Release 11i, your setup is automatically migrated to Balance Forward Billing enabled at the customer site level.

Late Charges Enhancements

The Receivables Late Charges feature has been enhanced to incorporate the Global Interest Invoice setups, charge calculation logic, and charge generation processes. Charges for delinquent payments can now be generated as adjustments, debit memos, or interest invoices. The Interest Invoice Global Descriptive Flexfield is obsolete. Release 11i finance charge setup attributes are automatically upgraded to late charge setups at the account and account site levels.

Customer UI Redesign

This release introduces a new HTML user interface for entering and maintaining customer data. See the Oracle Receivables User Guide for further details.

Process Changes

The following features are obsolete:


Changes to Oracle Sourcing are described in this section.

Price Factors Upgrade to Cost Factors

In this release, Price Factors is renamed to Cost Factors. Additionally, Cost Factors can now be a Supplier or Buyer type. Depending on the type, buyers or suppliers provide a value for the Cost Factor.

If you are upgrading from base Release 11i.10 or previous version of Oracle Sourcing, then all cost factors are marked as supplier cost factors. If you are upgrading from Oracle Sourcing Rollup J (also known as Oracle Sourcing minipack 11i.PON.J) or a later version of the product, there should be no effect. Price elements, available in Oracle Sourcing Release 11.5.10 and earlier, are now called Supplier Price Factors.

Negotiation Header Attributes Upgrade to Negotiation Requirements

Oracle Sourcing has significantly improved negotiation header attributes. Buyers can now automatically score the supplier responses and designate teams of scorers to evaluate the bids. The feature has also been renamed to better represent its meaning. Header Attributes is now called Requirements. Header attribute group is now called Section.

The lookup code to create reusable sections is now called Sourcing Requirement Sections. Changes to the predefined section names are not reflected on old documents. For negotiations created before the upgrade, the old header attributes are represented in a hierarchical view grouped by sections.

Auction AutoExtend

Buyers can now specify the lowest bid rank that can trigger AutoExtend. As part of the upgrade process, all existing negotiations are modified to set this rank to first, in order to replicate the previous behavior.

In addition, this release gives buyers increased flexibility to specify the maximum number of automatic extensions by entering any number between 1 and 9999, or choosing unlimited extensions. Auctions created before the upgrade keep the value for the number of extensions after the upgrade.

Online Discussion

Collaboration team members can now exchange messages through online discussions. Additionally, team members with full access can exchange messages with suppliers. In previous releases, only negotiation creators could send messages to external parties.

Collaboration team member access privilege remains the same after the upgrade - team members who have the "View only" check box selected continue to have view-only access, and team members who do not have view-only access have full access.

For supplier messages sent before the upgrade, the supplier company name and user’s name are displayed. Suppliers see the buyer enterprise name instead of the individual buyer’s name (from the buying organization) on buyer messages sent before the upgrade.

Template Migration

Each template has an owning Operating Unit associated with it. When creating a template, you must specify which operating unit it belongs to. The template is applied to negotiations created within the owning operating unit. It can also be marked as a global template, which can be applied to any negotiation of any operating unit.

There is a new field for Operating Unit on the template creation page. All existing templates created before the upgrade have the default value for this field from profile option “MO:Operating Unit” at the site level. There is also a new check box for Global Template. Existing templates have this check box selected after the upgrade, allowing you to use the template on negotiations created within any operating unit.

Two Stage Evaluation of RFP

Buyers can now create Two Stage RFQ's. The Two-Stage RFQ process is used by organizations in the public sector or by government enterprises and the negotiation process typically follows submission of quotes by suppliers in two parts - the technical quote and the commercial quote. All draft RFQ's after upgrade will have a checkbox and Two-Stage RFQ displayed on the header page. This check box enables 2 stage bidding process. All RFQ's that were published before upgrade will display an unchecked read only check box with Two-Stage RFQ displayed on the View RFQ page.

Quantity Based Price Tiers

Suppliers have flexibility to offer different unit prices depending on the volume of business that the buyer is willing to commit for a given product or service. Typically, a supplier will provide preferential pricing for a larger volume purchase. Quantity based price tiers allow buyers to specify different price points for each quantity range on negotiations with standard purchase order, blanket or contract purchase agreement outcomes. Suppliers can respond to the tier structure defined by the buyer, or they can provide their own price tiers.

For negotiations and templates with Blanket Purchase Agreement or Contract Purchase Agreement outcome prior to the upgrade, the Price Tiers field will be marked as Price Breaks. For negotiations and templates with Standard Purchase Order outcome prior to the upgrade, the Price Tiers field will be marked as None. (This change is applicable for customers who have not applied Oracle Sourcing J Rollup 2 before upgrading to Release 12)

Cost Factor Enhancements

For negotiations that have fixed amount cost factors prior to the upgrade, the new Award Price column will be shown on the Award Summary page with the award price set to the bid/quote price for all the awarded lines. (This change is applicable for customers who have not applied Oracle Sourcing J Rollup 2 before upgrading to Release 12)

Cost factors allow buyers to model the total cost of a product or service. Cost factors operate under one of these three pricing basis: (1) per unit cost (2) percentage of the unit price (3) fixed amount for the line.

This enhancement improves the calculation of the per unit total cost when fixed amount cost factors are used and the buyer awards a supplier a quantity that is either lower or higher than the response quantity. Whereas before Oracle Sourcing used the response quantity to calculate the per unit total cost, the new formula utilizes the award quantity to distribute the fixed amount cost factor resulting in a more accurate award amount calculation.

Sourcing Optimization Enhancements

Sourcing Optimization has several enhancements to assist buyers in making optimal award decisions. Buyers can now determine a constraint priority for award optimization by indicating the importance of a given constraint. All existing constraints before upgrade will display a priority list beside them with a priority of 1 indicating Mandatory.

Subledger Accounting

Oracle Subledger Accounting provides a common accounting engine that replaces the existing accounting processes in the different subledgers. Consequently, the Subledger Accounting upgrade consists of migrating the existing accounting data to ensure a continuous business operation between the two releases. Depending on the business and the specific requirements, "existing accounting data" may have different implications for each customer.

In this sense, and for the purposes of the present documentation, accounting data is defined as:

As part of the continuous business operation, the Subledger Accounting upgrade also takes into account the reports and inquiries that are necessary for the daily user activities. In this sense, some other pieces of information must be upgraded to the new instance:

Trading Community Architecture

Changes to Oracle Trading Community Architecture are described in this section.

New Trading Community Members

New data appears in user interfaces. It reflects changes related to Trading Community Architecture organization and person parties and contacts.

Address Validation

Trading Community Architecture validates address information based on data stored in the Trading Community Architecture Geography Model. This model replaces the validation previously performed by Release 11i betas. Upgrading does not affect address entry and maintenance in Trading Community Architecture. User-defined rules determine how to respond when an invalid address is entered.

Note: See E-Business Tax in Oracle Financials and Oracle Procurement Functional Upgrade Guide: Release 11i to Release 12 for more information.

DQM Enhancements

The Data Quality Management (DQM) tool delivers enhanced administration interfaces providing a new level of audit detail and maximized out-of-the box performance. A new overview page provides relevant and timely information about the status of important DQM processes and setups, while more consistent attributes and transformations naming conventions improve the user’s experience.

D&B passwords are now managed under the Adapters section of the Administration tab and not by profile options. Current D&B passwords migrate during upgrade.

Forms to HTML User Interface Changes

New HTML pages are added for managing roles in Resource Manager. These pages do not replace the existing Forms for the same functionality, but are offered as an alternative to Forms.

Resources, Groups, and Roles JTT pages are obsolete and replaced with equivalent HTML pages. No setup is required, as the HTML pages use the same profile options to render pages. Additional functionality is available, including a small menu change on the Oracle Customers Online Employees tab.

Merge Dictionary and Attributes and Transformations, Word Replacements, and Match Rules setup is managed in the HTML pages of the Administration Tab, and have been removed for DQM setup. The Customer Standard form has been replaced with a streamlined HTML.

Note: See Oracle Receivables User’s Guide for details.


Changes to Oracle Treasury are described in this section.

Bank Account Migration to Cash Management

Prior to this release, you had to define an internal bank account separately in each application that used it (such as Treasury and Payables), even if the account was the same. This created fragmented data and made bank account maintenance complicated and labor-intensive.

In this release, Cash Management provides a common data model and common user interface for creation and maintenance of banks, bank branches, and internal bank accounts. An internal bank account intended for use by different applications can be created just once - in the centralized Cash Management function - and then used in any application or a select group of applications (that you specify).

To accommodate these changes, all existing company and subsidiary bank account information is upgraded as follows:

Bank Account Balance Migration to Cash Management

Prior to this release, bank account balance maintenance and interest calculation was only available to Treasury bank accounts. In this release, this feature is available to all bank accounts defined in Cash Management.

Existing bank account balance information is managed as follows during the upgrade:

U.S. Federal Financials

Oracle U.S. Federal Financials interacts with several products within the Oracle Financials product family (Oracle Payables, Oracle Payments, Oracle General Ledger, Oracle Subledger Accounting, Oracle Receivables, Oracle Purchasing, and Oracle Cash Management). Refer to the appropriate sections of this appendix to understand the high-level impact for these products on U.S. Federal Financials users.

Integration with Subledger Accounting

This release introduces Subledger Accounting for managing accounting across subledger transactions. You no longer need to enter transaction codes for a transaction to create the desired accounting. Instead, Subledger Accounting seeds account derivation rules that use attributes from transactions to determine the correct accounting.

In Release 11i, journals in General Ledger were kept in detail, so no transaction code journals are moved into Subledger Accounting. All accounting reports show combined General Ledger and Subledger Accounting data. During normal processing, the Subledger Accounting code detects whether the journal exists in Subledger Accounting or General Ledger (upgrade case or not) and uses the appropriate Subledger Accounting rule to create the accounting.

Integration with General Ledger

All U.S. Federal Financials sets of books are upgraded to ledgers in an accounting setup. Upgraded ledgers can be viewed using General Ledger’s Accounting Setup Manager. The upgrade creates data access sets for each upgraded ledger that are assigned to the U.S. Federal Financials user responsibilities, which ensures only the appropriate users gain access to ledger-based setup windows within U.S. Federal Financials.

Implementation of Payables and Receivables Netting

In Release 11i, Oracle Financials had three netting solutions – Single Third Party in Oracle Public Sector Financials International, Contra Charging in Oracle Financials for Europe, and AR/AP Netting in U.S. Federal Financials. While these solutions provided netting functionality, each addressed a different specific need.

The new Payables and Receivables Netting solution in Oracle Financials Common Modules provides one total netting solution built into the standard applications. Therefore, the U.S. Federal Financial AR/AP Netting solution is obsolete. The setup data used by the AR/AP Netting solution in U.S. Federal Financials is migrated to the new Payables and Receivables Netting solution.

Summary Schedules and Consolidated Files

With the introduction of Oracle Payments, consolidated payment files for U.S. Federal Financials are now generated directly in Oracle Payments.

Summary Schedules still exist in U.S. Federal Financials after the upgrade. Any Release 11i payment batch that is associated with a summary schedule, or a consolidated payment file that has not been generated, must be voided and recreated through Oracle Payments. You can avoid this situation by generating these payment files in Release 11i in the Summary Schedule and Consolidated Files window in U.S. Federal Financials.