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:
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.
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.
Changes to Oracle Advanced Collections in the upgrade are described in this section.
Note: See Oracle Advanced Collections Implementation Guide for more information.
This release introduces a new user interface for entering and maintaining Advanced Collections setup data.
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.
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.
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.
Transactions in Assets books and accounting lines related to these transactions are migrated to Subledger Accounting for a user-specified number of periods during the upgrade. Accounting for current period depreciation is upgraded only if depreciation is already run for the period and the period remains open. After the upgrade, you can run the SLA post-upgrade process to upgrade accounting for the past year’s transaction data. See Assets in Appendix G for more information.
The value for the new profile option FA: Use Workflow Account Generation is set to Yes during the upgrade. You should analyze current customizations in the workflow setup. There are two options if you need to use the rules in workflow to generate code combinations for asset transactions:
Re-implement the custom rules in Subledger Accounting account derivation rules and set the profile option value to No.
Use the workflow rules as they are (default).
If you do not have customizations to Workflow-based Account Generator and wish to use Subledger Accounting account derivation rules for generating code combinations, set the profile option value to No after the upgrade.
Create Journal Entries is replaced by Create Accounting.
The Account Drill Down report is replaced by the new Subledger Accounting report, Account Analysis.
Journal Source and Journal Category setups are no longer on the Book Controls setup form, and the setup is now located in Subledger Accounting.
Depreciation Expense Account and the Bonus Expense Account for all category and book combinations in the Asset Category setup form are upgraded from a single segment account value to entire account combinations.
The intercompany account setup in the Book Controls form is replaced by Intercompany/Intracompany setup in accounting setups. You should review the migrated setups for relevant ledgers upon the upgrade.
The FA: Include Nonrecoverable Tax in Mass Addition profile option is obsolete. It has been replaced by Post Accounting Programs under Subledger Accounting. These programs manage the setup for all eligible lines from Payables to Assets for the Mass Additions Create program.
Invoice distributions from Oracle Payables that interface to Assets are upgraded to display the Invoice Line Number.
Information stored in descriptive flexfields for Greece that are commitment and investment law is upgraded to named fields in the Asset Workbench.
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.
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:
Bank number
Institution type
Country (w/default country setting for null)
Bank administrator’s email
Bank name
Alternative bank name
Taxpayer identifier
Tax reference
Description
Active date
End date
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.
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.
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.
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:
Order to Cash - Global Tax Engine
Procure to Pay - Automatic Tax Calculation
Procure to Pay - Brazilian Payables/Purchasing
General Ledger - General Ledger Automatic Tax Calculation
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:
Changes to Oracle Financials for the Americas are included in this section.
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.
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.
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.
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.
The GDF attribute Third Party ID value on the Enter Journals form is upgraded to the attribute Third Party on the same form.
The GDF Document Type attribute value on the Payables Invoice Workbench form is upgraded to the attribute Intended Use on the same form.
The following features are obsolete:
Brazilian Company Information - The Brazilian Companies defined using the Company form are upgraded as establishments under the legal entity of the operating unit, making this form obsolete. Use the Legal Entity Configurator introduced in this release to define the establishments.
Brazilian JLBR Automatically Populate Payment Batch Name Profile (and related logic) - In this release, the payment batch concept has changed. Moreover, there is no legal requirement to name payment batches sequentially and automatically.
Chilean Bills of Exchange - You should make use of the standard Bill of Receivables feature in Receivables.
Changes to Oracle Financials for the Asia/Pacific are included in this section.
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.
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.
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.
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.
The following changes apply to the China Accounting Software Date Interface Standard solution for Release 12.1.1.
The process of assigning specific balancing segment values to each legal entity in the System Option window in Release 11i has been removed from Release 12.1.1. You must use the Accounting Setup Manager to perform the same assignment for balancing segment values to legal entities.
A new descriptive flexfield item; Enter Journals: Lines is added to the Descriptive Flexfield Assignment window in Release 12.1.1. Use this to specify the context and attribute column for the descriptive flexfield; Enter Journals: Lines that will be used to mark cash flow items on journal lines.
In Release 11i, the Cash Flow Item Mapping window is used to map Payables invoice categories, Receivable transaction types, and Receivable activities with the corresponding cash flow items. In Release 12.1.1, the functionality of the Cash Flow Item Mapping window has been changed to defining the mapping between supporting reference values and cash flow items.
Changes to Oracle Financials Common Country Features are described in this section.
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.
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.
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:
Subsidiaries are replaced by intercompany organizations. They represent trading partners and can be used as initiators and recipients of Advanced Global Intercompany System transactions.
As part of the Grant-based Security Model, intercompany trading partners are mapped to users instead of responsibilities. A user may be given access to many different intercompany trading partners regardless of the responsibility used to log in.
The GIS transaction types are upgraded to the new Intercompany system transaction types.
The Intercompany accounts set up in GIS are upgraded as the new Intracompany Balancing rules. Autoaccounting rules set up in GIS are not upgraded and need to be set up in the new Subledger Accounting Transaction Account Builder.
All GIS new and completed transactions are upgraded as AGIS transaction batches. Generally, for each GIS transaction, a batch is created.
Release 11i GIS profile options are obsolete and are not upgraded. All options are available on the AGIS System Options page.
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:
Preserves existing customer and supplier relationships and creates new entities known as agreements.
Preserves existing customer and supplier relationships and creates new entities known as agreements.
Changes to Oracle Financials for Europe are included in this section.
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.
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.
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.
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.
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.
The following descriptive flexfields have been replaced with alternate approaches:
India Items
India Block of Assets
India Receipts
India RMA Receipts
India Return to Vendor
Additional Line Attribute Information
India Payment Information
India Organization Information
India Distributions
India VAT
India Lookup Codes
India Original Invoice for TDS
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.
Note the following changes in the terminology related to General Ledger.
Sets of books is replaced by ledgers
This is simply a terminology change. All set of books options are now called ledger options. The upgrade retains all Release 11i settings.
Multiple Reporting Currencies is replaced by Reporting Currencies
Reporting sets of books are replaced by reporting currencies. Reporting sets of books assigned to primary sets of books automatically upgrade to reporting currencies that are assigned to a primary ledger. All conversion options for Multiple Reporting Currencies are retained as part of the reporting currency definition.
Global Intercompany System (GIS) is replaced by Advanced Global Intercompany System (AGIS)
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.
All sets of books upgrade to ledgers in an accounting setup.
The upgrade creates data access sets for upgraded ledgers to facilitate the creation of advanced data access and data security policies.
A subledger accounting method, such as Standard Accrual, is automatically assigned to all upgraded ledgers.
A subledger accounting method allows General Ledger to integrate with subledgers via Subledger Accounting.
The secondary tracking option for revaluation and closing and translation has been streamlined.
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.
Single posting sets of books with multiple main sets of books upgrade to multiple primary ledgers that share the same secondary ledger.
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.
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.
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.
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 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 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.
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.
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.
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.
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.
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:
Legal Entity is derived from an operating unit. All transactions that have an operating unit context use the GRE/LE as Legal Entity.
As part of the upgrade for Legal Entity functionality, the modified objects are upgraded with the Legal Entity value.
GRE/LE associated to OU is upgraded as the default legal context. The Default Legal Context (DLC) associated with the OU is the value for the upgrade.
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:
Release Billing
Release Credit Memo
Rollover Billing
Rollover Credit Memo
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:
Booking / Rebook Upfront Tax Lines for contracts in status ‘Passed’, ‘Complete’ and 'Approved’ are migrated from Leasing and Finance Management data structures to eBTax with Reportable flag = ‘N’.
Booking / Rebook Upfront Tax Lines for contracts in status ‘Booked’ are migrated from Leasing and Finance Management data structures to eBTax with reportable flag = ‘Y’.
Asset Location Change Tax Lines are migrated from Leasing and Finance Management data structures to eBTax with reportable flag = ’Y’.
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:
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.
The identifiers of the accounting transaction headers, lines and distributions are re-keyed using a sequence to facilitate integration with the Subledger Accounting module.
The Representation Code and Representation Name accounting source values for all accounting transactions are set to the primary ledger short code and primary ledger name respectively.
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.
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.
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:
OKLTBRNM.sql - Script to rename tables
OKLSECSM.sql - Script to create synonym and add security policy
OKLORUPG.sql - Script to upgrade the org_id data for the following tables:
OKL_CURE_REPORTS
OKL_SERVICE_FEES
OKL_TXL_RCPT_APPS_ALL_B
OKLPRFUPG.sql - This script identifies the profile values for a specific ORG and updates the value set for the profile in the system parameters table. If it does not find any value for ORG in the System Parameter Table it inserts those values in the table.
OKLPRODEL.sql - This script deletes the profiles from all necessary tables
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.
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.
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.
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:
If the operating unit is not a Multi-GAAP operating unit in 11i, then the secondary representation method value is set to Not Applicable.
If the operating unit is a Multi-GAAP operating unit in 11i, then the secondary representation method value is set to Report.
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:
That are reporting stream elements belonging to Multi-GAAP contracts
That belong to an operating unit whose Secondary Representation Method value is set to Automated Accounting
For which the stream types are defined on the reporting product as accruable
During the upgrade, Oracle Loans accounting functionality is migrated automatically to Subledger Accounting, and other common data model components.
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.
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.
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:
Whether a loan has multiple disbursements
Whether a construction loan can convert to a term loan
Whether a credit review is required
Range for the loan requested amount and term
Rate type
Floating frequency for variable rate loans
Payment frequency
Collateral required and loan-to-value ratio
Conditions for approval or conversion
Mandatory fees
Disbursement schedule for loans with multiple disbursements
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 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.
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.
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.
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.
Oracle Payments can be used by Oracle Payables for processing invoice payments. See Payments in this appendix for more information.
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.
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.
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.
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.
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:
Oracle Payables
Oracle Order Capture
Oracle Order Management
Oracle Service Contracts
Oracle Student System
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.
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:
Payment Methods: Each document to be paid requires a payment method to indicate how it should be handled in the funds disbursement process. Payment methods can now be defined as broadly or narrowly as appropriate, and are not restricted to the seeded values. Rules can be set for when payment methods can be used on documents. Rules can also be specified to default payment methods on documents when they are created. The upgrade seeds payment methods that existed in Oracle Payables and globalizations.
Processing Rules: The payment method on a document links it to processing rules configured in Oracle Payments. These setup rules are held in a key entity called the Payment Process Profile. You can configure as many of these process profiles as you need for payment processes. Each profile holds rules for how documents should be built into payments, how payments should be aggregated into a payment instruction file, and how the payment file should be formatted. Rules for printing checks, transmitting electronic files, generating separate remittance advice notifications, and other options can be easily configured.
Payment System: A payment system holds information about the third party involved in processing payments. The third party may be a financial institution or clearing house that disburses or settles payments. This entity is defined to hold information about transmission and required settings for communication to the payment system.
The upgrade uses various data from Oracle Payables to create the new Payment Process Profiles. Since this entity is so central to the funds disbursement process, an overview of the upgrade process is provided here.
For each 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:
Deploying company’s internal bank account - the account from which funds will be disbursed. A bank account is assigned as a usage rule when the upgrade finds the appropriate information. First, it looks at the format definition that was used to create the profile. Then, it finds all payment documents assigned to the format definition. Each internal bank account that is a parent of the payment document is assigned as a usage rule to the profile.
First party organization - values are migrated when they are available, specifically from some globalizations.
Payment methods and currencies - the upgrade determines these values based on information within the format itself.
Another important part of the payment process profile is its link to a payment system and its setup. This information is upgraded based on values set in globalizations and should be understood for payment processing in those countries.
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:
Payee Configuration: A payee is defined for each entity in the deploying company that will process payments; typically only one setup is needed for the enterprise. The payee configuration holds various processing options that are used to handle transactions. In Release 11i, Receivables linked each receipt class with an automatic creation method to the Oracle iPayment Payee. Now operating units are assigned to the payee. This helps ensure consistent payment processing across the applications. The upgrade assigns operating units to the payee based on existing transactions in Receivables.
Payment Methods: Each transaction requires a payment method to indicate how it should be handled in the funds capture process. In Oracle Receivables, this payment method is specified on a receipt class defined with an automatic creation method. Note that in the receipt class setup, Receivables has changed its Release 11i payment method term to be called receipt method.
Processing Rules: Rules for processing electronic funds capture transactions are held in a key entity called the Funds Capture Process Profile. Users can configure as many of these process profiles as they need for their payment processes. Each profile holds the configuration for how to format and transmit authorization messages and settlement files. Rules for aggregating settlements into batches, limiting the number or amount of settlements in a batch, notifying payers of settlements, and processing acknowledgements can be easily configured.
Payment System: A payment system holds information about the third party involved in processing payments. The third party may be a payment processor or it may be a financial institution. This entity is defined to hold information about transmission and required settings for communication to the payment system.
Routing Rules: Routing rules can be configured to specify how a transaction should be processed. A routing rule applies specified criteria and determines the funds capture process profile and the payment system to use. Routing rules are defined as part of the payee configuration.
The upgrade uses various data from Oracle Receivables to create these entities. Since these entities are so central to the funds capture process, an overview of the upgrade process is provided here.
For each of the formats that are upgraded from 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.
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.
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:
Mapping Rule
Condition
Condition Dimension Component
Condition Data Component
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.
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.
Changes to Oracle Public Sector Financials are described in this section.
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.
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.
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.
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.
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.
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.
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.
This release introduces Oracle Payments, which is used by Oracle Receivables for processing funds capture. See Payments in this appendix for further details.
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.
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.
This release introduces a new HTML user interface for entering and maintaining customer data. See the Oracle Receivables User Guide for further details.
The following features are obsolete:
Collections Workbench - The Oracle Advanced Collections module delivers similar functionality. See the Collections Migration white paper and the Oracle Advanced Collections User Guide for further details.
Trade Accounting - Similar functionality is delivered by integration with the Oracle Trade Management module. Trade Management integration is available in Release 11i.
Bill of Exchange - This functionality has been replaced with the Bills Receivable feature. Bills Receivables is available in Release 11i.
Changes to Oracle Sourcing are described in this section.
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.
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.
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.
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.
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.
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.
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)
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 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.
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:
All the data that has accounting relevance for the customer. This includes the journal entries, balances, base transactions that have generated journal entries, and related information, such as accounting events and setup information.
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:
Data that supports queries and drill down between different products
Reports and queries
Changes to Oracle Trading Community Architecture are described in this section.
New data appears in user interfaces. It reflects changes related to Trading Community Architecture organization and person parties and contacts.
Suppliers and Supplier Contacts
Banks, Bank Branches, Clearing Houses, and Clearing House Branches
Legal Entities
Intercompany Organizations
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.
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.
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.
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:
All company bank accounts are automatically migrated one-to-one to the new centralized data model.
All subsidiary bank accounts are automatically migrated one-to-one to the new centralized data model. Please note, however, that although such accounts now reside in the centralized data model, unlike company bank accounts, they will not be visible in the new user interface. They still have to be managed in the Counterparty Profiles form.
All counterparties that are used as banks before this release in Company or Subsidiary bank accounts are automatically migrated into Banks and Bank Branches in the centralized data mode. Each such counterparty will be upgraded into one Bank and one Bank Branch belonging to this Bank.
Note: While the setup of Treasury bank accounts has changed, there are no changes to the way you use the Treasury bank accounts.
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:
All existing bank account balance data and the rates at the balance level are automatically migrated to the new centralized data model.
Default interest rate setup for bank account balances are not migrated.
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.
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.
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.
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.
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.