Skip Headers

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

Planning for an Upgrade

This chapter covers the following topics:

Overview of the Upgrade

This guide provides a high-level view of an upgrade of Oracle Applications technology stack and products from (supported) Release 11i versions to Release 12.1.1

Supported Upgrade Paths

This release includes a re-packaged Rapid Install that makes it possible to upgrade existing 11.5.9 (base, CU1, CU2), and 11.5.10 (base, CU1, CU2) systems directly to Release 12.1.1.

Oracle E-Business Suite Upgrade Paths

The following table lists the supported upgrade paths for Oracle Applications 11i, including releases that require an interim upgrade step. See Related Documents in the Preface for links to the documentation mentioned in this table, as well as in other sections of this book.

Release level Upgrade path Documentation References
11.0 Release 11.5.10 CU2 > Release 12.1.1 Upgrading Oracle E-Business Suite, Release 11.5.10.2 > Oracle E-Business Suite Upgrade Guide: Release 11i to Release 12.1.1
11.5.1 - 11.5.8 Release 11.5.10 CU2 > Release 12.1.1 Maintenance Pack Installation Notes, Release 11.5.10 CU2 (Doc ID: 289788.1) > Oracle E-Business Suite Upgrade Guide: Release 11i to Release 12.1.1.
11.5.9, or 11.5.10 (base, CU1, CU2) Release 12.1.1 Oracle Applications Upgrade Guide: Release 11i to Release 12.1.1.

Database Upgrade Requirements

To complete the upgrade to Release 12.1.1, you must migrate or upgrade your database to at least Oracle 10g Release 2 (10.2.0).

The following is a summary of the database upgrade requirements:

Note: See Database Preparation Guidelines for an Oracle Applications Release 12.1.1 Upgrade (Doc ID: 761570.1) for more information.

The Upgrade Process

The upgrade process has been enhanced and streamlined. New features have been added to Rapid Install and AutoPatch to increase their capabilities. In addition, an upgrade no longer relies on AutoUpgrade processes. All upgrade functionality has been consolidated into a single unified upgrade driver that performs the upgrade without reliance on the information formerly captured on the AutoUpgrade screens.

Rapid Install provides the most up-to-date, certified version of Oracle E-Business Suite products, along with the certified technology stack components. In an upgrade, it creates the new file system for the application (middle) tier components and the new file system for the database. After the upgrade, you run Rapid Install again to configure servers and start services.

An upgrade also includes various manual steps, including those that direct you to run scripts or apply patches. You rely on AutoPatch to apply all patches, including the unified driver that performs the upgrade to Release 12.1.1.

In order to present a complete picture of the upgrade processes and the resulting system enhancements, this guide has been created in two main sections. The chapters are written for database administrators (DBAs), who are responsible for the technical aspects of a system upgrade. The appendixes are directed at the application specialists, who are responsible to understand and manage the business impact and functional changes inherent in an upgrade.

New in this release, the appendix portion of this guide contains information about functional changes for each product family, suggestions for reducing upgrade downtime, ways to verify data migration and manage data migration that is not automatically performed by the upgrade driver, and information about "by request" upgrade processes, which define specific sets of data that can be upgraded at a later date, or when there is a specific need.

It is very important that your DBA and your functional specialists work together to review this information carefully as a part of upgrade planning. Doing so will help eliminate unexpected holdups during and after the upgrade that could slow the process itself and cause confusion as your system users resume their functional tasks.

Note: A successful upgrade is a collaboration between the DBA and the application specialists. Both should understand and coordinate all aspects of the upgrade as a part of the planning process.

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 (business-related) changes have an impact on the way you use the products as you conduct daily business.

A common data model improves the quality of your data, simplifies its management, and makes it easier for shared service centers to work across worldwide operations and provide information about your business to decision makers.

Coupled with the common data model are enhanced integrations between Oracle Financials and Oracle Procurement products and other applications. Integrated applications enable pre-defined best practices and empower you to standardize your business processes across organizations and geographic regions. Benefits of standardization include common process methodologies and economies of scale.

Functional topics in this guide that pertain to a Release 12.1.1 upgrade include:

General Information and Required Tasks

Before you prepare your system and product data, you should gather information about the upgrade process, the tools required, the number and types of tasks involved, and the way your system and products will look in Release 12.1.1. You can find a documentation roadmap on My Oracle Support. See Oracle Applications Documentation Resources, Release 12.1 (Doc ID: 790942.1). Take special note of the Known Issues section.

Reference Information

It is very important that you read the documentation associated with this release. It is available either in the Oracle E-Business Suite Documentation Resources, Release 12 on My Oracle Support, or from the OracleStore. Appendix H, "Product Documentation List" in this guide contains a list of basic required reading. In addition, you may also find it useful to review any presentation materials on upgrade technology, the Business Intelligence System, white papers on Multi-org, and links to various Consulting services as well as Oracle University training courses.

Application specialists and functional users should pay special attention to the Release Content Documents (RCDs), eTRMs, and Transfer of Information (TOI) documentation for the products that are active in your system. This information describes new features and functionality in Release 12.1.1.

Note: The Maintenance Wizard consolidates instructions from numerous manuals and other documentation and creates a step-by-step set of upgrade instructions. See Maintenance Wizard in this chapter.

Technical Upgrade Tasks

In general, DBAs perform the following tasks in an upgrade:

Functional Upgrade Tasks

In general, application specialists perform the following tasks in an upgrade:

Release 12.1.1 Updates

Completing this upgrade brings your system to the 12.1.1 release update level of Release 12.0. You can continue to apply the latest Release Update Pack (RUP) at any time to keep your system at the most current release level available. Each release update pack is made up of individual product family RUPs, which contain all the patches associated with that family. You can apply the entire release update pack, or you can apply the product family packs individually.

RUPs are released periodically. Each one is cumulative - it delivers error corrections and system updates, not only for the most current release update pack, but also for all the RUPs that preceded it.

You can keep abreast of the latest release information, as well as new RUP announcements and other updates that may affect your upgrade by reviewing the latest version of Oracle Applications Release Notes (Doc ID: 405293.1).

Installed Components and System Requirements

This section lists the certified components supplied by Rapid Install, and the general system requirements for an upgrade. Note that requirements for CPU, memory, and disk space (for log files and backup) are typically much larger during an upgrade than during normal operation.

Technology Stack Components

Rapid Install automatically installs and configures the required technology stack components for both the database tier and the application tier. The database tier technology stack for a new Release 12.1.1 installation is Oracle 11g Release 1 (11.1.0.7)). Upgrades from Release 11i with Oracle 10g Release 2 and Oracle 11g Release 1 are both supported.

The technology stack installed on the application tier includes, among other components:

Software Requirements

Some systems may require platform-specific release maintenance tools, and there are new versions of tools required for Release 12.1.1 for some platforms. Oracle E-Business Suite Installation and Upgrade Notes (for your platform) contains a list of these tools.

The upgrade requires at least Oracle 10g Release 2 (10.2.0) – Oracle 11g Release 1 is also supported. See Database Preparation Guidelines for an Oracle Applications Release 12.1.1 Upgrade (Doc ID: 761570.1) for instructions.

CPU

The CPU requirements for an upgrade depend on many factors, including:

For Example:

A test upgrade of the largest Oracle production system (oraprod) used the following CPUs:

A test upgrade of the Vision database and application tier machine used 4 CPUs (3.05 GHz Intel Xeon).

Note: See Applications Release 12 Upgrade Sizing and Best Practices (Doc ID: 399362.1) for the statistics on these production system upgrades.

Memory

To calculate the memory requirements for an upgrade, consider the following:

For Example

A test upgrade of the largest Oracle production system (oraprod) used the following:

A test upgrade of the Vision database and application tier machine used 6 GB of memory.

Note: See Applications Release 12 Upgrade Sizing and Best Practices (Doc ID: 399362.1) for the statistics on these production system upgrades.

Input/Output (I/O) Subsystem

Performance during an upgrade depends heavily on the speed of the Oracle database system input/output (I/O) subsystem. We recommend an average disk response time (average service time) below 10-15 milliseconds for better performance. Detailed information, including IOPs calculations, is available in Applications Release 12 Upgrade Tablespace Sizing and Best Practices (Doc ID: 399362.1).

To monitor the I/O performance, you should use OS tools like iostat or sar (Unix) during your test upgrade. Use similar tools for other operating systems, for example Performance Monitor for Windows. You can also monitor I/O performance on your production system during peak load to get an idea about your I/O subsystem performance before the upgrade. However, you should note that the I/O load and, therefore, the average service time on existing applications, is different from that of an upgrade.

While you are monitoring the I/O performance, you should focus on the average service time (the average of elapsed time in milliseconds that the disk drive takes to complete an I/O request) and the average wait (the average amount of time requests are left outstanding). Higher averages for these two indicators signal an I/O bottleneck. An average service time longer than 50 milliseconds is reason for concern if it lasts too long and/or it is continuously at a high level. Small intervals of high average service time should not be of concern.

Note: See Oracle Database Performance Tuning Guide 10g Release 2 (10.2) or Oracle Database Performance Tuning Guide 11g Release 1 (11.1).

Database Size

To estimate the increase in required disk space for upgrading, consider the products, the number of languages being installed, and changes in the data model.

For Example

In a test upgrade of the largest Oracle production system (oraprod), the database increased 10-20 percent. In a test upgrade, the Vision database increased 5 percent. For guidelines based on an upgrade of the Oracle production system (oraprod), see Applications Release 12 Upgrade Sizing and Best Practices (Doc ID: 399362.1).

Tablespace Sizing

Make sure you allocate sufficient tablespace. For guidelines based on an upgrade of the Oracle production system (oraprod), see Applications Release 12 Upgrade Sizing and Best Practices (Doc ID: 399362.1).

Block Size

This release requires an RDBMS block size of 8K. In addition to providing significant performance improvement, this setting accommodates the Oracle E-Business Suite indexes that require this block size.

Release 12 Architecture

The upgrade process affects system architecture and the way you use your Applications products after an upgrade. Oracle E-Business Suite Concepts contains a complete discussion of the architecture in this release, including information about the Oracle E-Business Suite multi-tiered architecture, enhancements, language support, file system structure, and the basic data model.

Tablespace Model

This release uses the Oracle Applications Tablespace Model (OATM), which is based on database object type rather than product affiliation. OATM uses 12 locally managed tablespaces for all products, including the temporary tablespace, system tablespace, and system-managed undo (SMU) tablespace. Each database object is mapped to a tablespace based on its input/output characteristics, including object size, life span, access methods, and locking granularity.

Oracle has successfully tested systems with extent sizes of 128 K for small systems (100 GB database) and 4-10 MB for large, multi-terabyte database systems.

We supply scripts in the upgrade process to create the tablespaces for all new products and configure the database for the new tablespace model. Then, the upgrade process creates the new objects. However, your existing objects are not automatically migrated. We strongly recommend that you migrate the existing objects after the upgrade is complete. Use the Tablespace Migration Utility (introduced in Release 11i) to perform this task.

Note: See Oracle E-Business Suite System Administrator’s Guide – Configuration. See also Oracle E-Business Suite Concepts.

Multiple Organizations

Multiple Organizations architecture supports performance improvements across the E-Business Suite, as well as Multiple Organizations Access Control, which enables an Applications responsibility to access multiple operating units if desired. An upgrade requires the conversion of all Single Organization architecture systems to Multiple Organizations. You must define at least one operating unit and assign it to the MO:Operating Unit profile option.

Converting to Multiple Organizations does not require you to use multiple operating units or sets of books, but it does enable you to use these features if you desire. Converting to Multiple Organizations does not produce any noticeable change in behavior - if you do not define multiple operating units and/or sets of books, the conversion is transparent to users.

Note: See Oracle E-Business Suite Multiple Organizations Implementation Guide. See also Use of Multiple Organizations (Multi-Org) in Release 11i (Doc ID: 210193.1)

Subledger Accounting Model

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 different customers.

Note: See Appendix A, "Financials Upgrade Impact" for information the Subledger Accounting upgrade. See also Financials and Procurement Tasks in Appendix G, "Upgrade by Request" for more information about the effect of the SLA upgrade on other products.

Multiple Reporting Currencies

Multiple reporting currency functionality has migrated to Reporting Currency functionality in the Oracle Subledger Accounting model. Oracle Subledger Accounting provides a single repository where you can view amounts in reporting currencies.

Note: See General Ledger and Subledger Accounting in Appendix A, "Financials Upgrade Impact" in this guide for more information.

Scheduling Time for an Upgrade

In an upgrade, critical system downtime refers to the period of time when users cannot log on to the system or use Oracle E-Business Suite. There are several actions you can take to reduce this downtime period. For example, performing certain product-specific tasks before an upgrade can substantially reduce the downtime, as can using the Oracle cloning methodology, and a test file system to upgrade your production system.

This section briefly describes some of the issues that affect the amount of downtime required for an upgrade, and some of the actions we recommend to reduce that downtime.

Backup

We strongly recommend that you back up your entire system before you begin the upgrade.

Database Initialization Parameters

Initialization parameters required at each stage of the upgrade may vary depending on when you upgrade your database. Review the requirements for these parameters before you begin. See Database Initialization Parameters for Oracle Applications Release 12 (Doc ID: 396009.1).

Managing Long-running Processes

Performance of some upgrade scripts can be significantly improved by changing the following database settings for the duration of the upgrade. The parameters in this section should be set as specified, and then (except as noted) can be reset as needed after the upgrade process is complete.

_db_file_multiblock_read_count (init.ora parameter)

Specifies the maximum number of blocks read in one I/O operation during a sequential scan. Remove this parameter permanently from the init.ora file. If it is set to any value, it overrides the _db_file_optimizer_read_count default setting. DO NOT RESTORE THIS PARAMETER AFTER THE UPGRADE.

_db_file_optimizer_read_count (init.ora parameter)

This undocumented parameter is used by the cost-based optimizer. It represents the maximum number of blocks read in one I/O operation during a sequential scan for the purposes of calculating the cost of operations like full table and fast full index scans. The actual number of blocks read in one I/O operation during a sequential scan is independently controlled by this parameter. The default setting is 8. Do not change this parameter.

_job_queue_processes (init.ora parameter)

Specifies the maximum number of processes that can be created for the execution of jobs. Oracle recommends a value equal to the number of CPUs.

parallel_max_servers (init.ora parameter)

Controls the maximum number of parallel query server processes running in the database. Oracle recommends a value equal to 2 times the number of CPUs.

_pga_aggregate_target (init.ora parameter)

See Database Initialization Parameters for Oracle Applications Release 12 (Doc ID: 396009.1) for recommended value.

_pga_max_size (init.ora parameter) - for 11g customers

During the upgrade process to 12.1.1, customers running 11gR1 may encounter the following error:

ORA-04030: out of process memory when trying to allocate 822904 bytes (pga heap,kco buffer)
ORA-07445: exception encountered: core dump [dbgtfdFileWrite()+48] [SIGSEGV] [ADDR:0xFFFFFFFF7FFC1C88] [PC:0x1063BD2D0] [Address not mapped to object] []

This error only affects customers running 11gR1. This error indicates that database process memory is exhausted and the process must be restarted. This error only occurs during large volume index build operations and affects 12.1.1 upgrades only. If you receive this error, then you must set the _pga_max_size parameter to a larger value as follows:

_pga_max_size=104857600

After you set this value, you must restart your database. When a fix is available, the My Oracle Support note number 735276.1 will be updated accordingly.

recyclebin=OFF (init.ora parameter)

Used to control whether the Flashback Drop capability is turned on or off. If the parameter is set to OFF, dropped tables do not go into the recycle bin. If set to ON, dropped tables go into the recycle bin and can be recovered.

Temporary Tablespace

Create tablespace (usually TEMP) as a locally managed tablespace using the temporary file option with a uniform allocation size. If the temporary tablespace is not defined in this way, drop the temporary tablespace and recreate it using the following example as a template:

SQL> drop tablespace TEMP;
SQL> create TEMPORARY tablespace TEMP
			tempfile ’ts_p_temp1.dbf’ size 2048M
			EXTENT MANAGEMENT LOCAL
			UNIFORM SIZE 1M;

To verify that the temporary tablespace has been created, run the following:

SQL> select CONTENTS,EXTENT_MANAGEMENT,ALLOCATION_TYPE
			from dba_tablespaces
			where tablespace_name=’TEMP’;

The query output should be:

Contents EXTENT_MANAGEMENT ALLOCATION_TYPE
TEMPORARY LOCAL UNIFORM

After the upgrade, restore the previous storage parameters for the temporary tablespace and lower the extent size for the temporary tablespace to a value that is less than 1 MB (for example, 128 K).

Note: See Database Initialization Parameters for Oracle Applications Release 12 (Doc ID: 396009.1).

Determining Upgrade Tasks

This section discusses tools you can use to examine your system and determine which upgrade steps apply for your system.

The Upgrade Manual Script (TUMS)

The Upgrade Manual Script (TUMS) examines your current configuration and creates a report that lists upgrade tasks that do not apply to your system. This report contains information that is unique to your system configuration, so its output is relevant to your individual upgrade. Omitting the steps listed in the TUMS report can significantly reduce upgrade downtime.

You create the TUMS report by applying a Release 11i patch, which loads objects into your APPS schema that TUMS uses to examine your Applications configuration. Your current Applications environment is not affected. The patch uses the TUMS Step keys identified in this book to uniquely identify each task. The generated report lists the step keys, in addition to the type of step (for example, pre-upgrade) and step number, for each upgrade task.

You will be instructed to run TUMS when you prepare for the upgrade in Chapter 2.

Maintenance Wizard

The Maintenance Wizard is a tool provided by Oracle Support to guide you through the upgrade and code line maintenance process. It draws on instructions from numerous manuals and other documentation (including this document, the Oracle E-Business Suite Installation Guide: Using Rapid Install, and the Oracle E-Business Suite Release Notes) to provide you with a complete picture of the activities required for an upgrade.

The Maintenance Wizard helps you reduce upgrade tasks by dynamically filtering the necessary steps based on criteria it obtains from your Applications environment. The resulting report is a set of step-by-step instructions of exactly what you need to do to complete your specific upgrade, including any critical patches that your system may require. It can also automatically execute many of the tasks for you, so as to reduce the possibility of errors or accidental omission of vital tasks.

Specifically, the Maintenance Wizard:

Maintenance Mode

To ensure optimal performance and reduce downtime when applying a patch, you must shut down the Workflow Business Events System and set up function security before you initiate an AutoPatch session. This provides the security needed to ensure that no Oracle E-Business Suite functions are available to users while you are applying a patch. The Maintenance Mode feature provides a clear separation between the normal runtime operation of Oracle E-Business Suite and system downtime for maintenance.

Note: See Changing Maintenance Mode in Oracle E-Business Suite Maintenance Utilities. See also Patching Tools in Oracle E-Business Suite Patching Procedures.

Obsolete Columns

During the upgrade process, the Oracle RDBMS DROP COLUMN command marks Oracle E-Business Suite columns as unused in the data dictionary, making it possible for the database administrator to drop the columns and reclaim the associated space. It is a good idea to plan this reclamation ahead of time because the process locks the associated tables. Once the space is reclaimed, the upgraded data model looks more like a fresh install (except for customizations). Note that DROP COLUMN has no effect on custom columns.

Test Upgrade

To provide a baseline for upgrade execution times and an opportunity to work out any upgrade issues ahead of time, we suggest you perform a test upgrade using a copy (clone) of your existing system, and hardware that is similar to what you use for your production system. A test upgrade is especially important if your system has been customized.

User Preferred Time Zone Support

No special upgrade steps are required for those products that support User Preferred Time Zones.

Note: See User Preferred Time Zone Support in the Oracle Applications Release 12 (Doc ID: 402650.1).

Upgrade By Request

For some Oracle E-Business Suite products, upgrade planning includes choosing the most active set of data for upgrade processing. Then, you can upgrade historical data that was omitted from the upgrade at a later date, or when it is needed. For example, you might include only the last fiscal year in the upgrade to Release 12.1.1, and then upgrade the remaining data outside the 12.1.1 downtime window.

Note: See Appendix G for more information.

NLS Upgrade Considerations

This section discusses some important considerations for managing your translations, languages, and character sets during the upgrade.

Languages

Additional space for each non-American English language will be required in the database to complete the upgrade. It is not possible to predict the amount of additional space your system will need, because the space depends on factors such as the database character set, the number of active languages other than American English, and in particular on the volume of customer-created data in the system.

Note that the additional space for languages must be available throughout the upgrade process.

Note: For the recommended minimum space required for each active language in the APPL_TOP, see the Oracle E-Business Suite NLS Release Notes for your release level.

Language Status

You must retain your existing Applications Release 11i language status until the entire upgrade process (including the post-upgrade and finishing steps) is complete. The base language must also remain the same, and new languages cannot be activated.

After the upgrade process is complete, you can change your language status as required, and activate new languages.

Note: See Adding and Maintaining NLS Languages section in Oracle E-Business Suite Maintenance Procedures.

Character Sets

You cannot change the database character set during an upgrade.

Depending on whether your Applications system connects to the database during the upgrade process, you may be able to select a new character set for the Release 12 APPL_TOP on the Rapid Install wizard upgrade screens. However, if you do, the new set must be either identical to, or compatible with, the existing database character set.

Caution: If you change the character set in the APPL_TOP to one that is not compatible with the current database character set, the upgraded system will be corrupted.

Note: See License Manager in Oracle E-Business Suite System Administrator’s Guide – Maintenance. See also Migrating an Applications Installation to a New Character Set (Doc ID: 124721.1).

Customized Environments

Customized environments require special attention during an upgrade. The instructions in this guide assume that you have followed the standards for customizing Oracle E-Business Suite exactly as described in the Oracle E-Business Suite Developer’s Guide and the Oracle E-Business Suite User Interface Standards for Forms-based Products.

Note: See also Preparing Custom Development for the Next Oracle Applications Release (Doc ID: 374398.1)

To preserve customizations and minimize the impact during the upgrade:

Protecting Data in Renamed Files

Because files may be renamed for a variety of reasons, it is good practice to protect them from being accidentally overwritten during the upgrade. Therefore, if you have renamed files using the <filename>old, <filename>new, or any other generic designation, then rename them again, to something meaningful before you begin the upgrade.

Customized Help Files

The help files in this release are in HTML format, making them easy to modify using a commercial Web browser or editor. You cannot reapply previously customized help files to your upgraded system. Therefore, it is important that you save the pre-upgrade customized help files as a reference.

Note: See Customizing Oracle Applications Help in the Oracle E-Business Suite System Administrator’s Guide - Configuration.

Product-specific Considerations

The information in this section applies to specific Applications products in this release. See the Release Content Documents for information about other products that are active in your system.

Note: Appendixes A - D describe changes to Oracle E-Business Suite products in this release. See also Appendix H, "Product Documentation List" for product-specific documentation.

Cross-Product Functionality

Changes to the products described in this section affect many Oracle Applications products. Before you begin the upgrade, your application specialists should have made plans to accommodate the relevant changes.

Legal Entity Configurator

The Oracle Legal Entity Configurator is a new module that was introduced in Release 12. It is populated with data that is migrated from a number of Release 11i sources. Its purpose is to provide a consistent definition of the legal structure of your enterprise and relate it to other structures within Oracle E-Business Suite.

With the Oracle Legal Entity Configurator, you can manage your legal corporate structure and track data from the legal perspective. This enables detailed reporting at the legal entity, establishment, and registration level.

The concept of Legal Entity has an impact on all customers who use the Human Resources model to define legal entities. Legal entities exist as Trading Community Architecture parties with legal information stored in the Legal Entity (XLE) data model. Subsidiaries of the legal entities are defined as establishments, which are also defined as parties with legal information stored in the Legal Entity data model.

Note: See Oracle Financials Concepts for more information. See also Oracle Financials Implementation Guide.

GRE/Legal Entity Migration to Legal Entities in Trading Community Architecture

HRMS organizations with a classification of GRE/Legal Entity and with accounting information (for example, Set of Books) assigned are migrated to the new Legal Entity in this release. For each Legal Entity migrated, an Establishment of type (Main Establishment) is created using the same data.

Upgrade Assumptions for Operating Units and Inventory Organizations

HRMS organizations with an operating unit or inventory organization classification are migrated to Establishments in the new Legal Entity model. No other classification of organization other than operating unit or inventory organization classification is migrated as establishment.

Country-specific Information

For some countries (such as Argentina, Greece, Korea, Chile, Italy, Colombia, and Taiwan), VAT Registration Number was entered in Release 11i through the Human Resources Define Organization form, or a registration number was entered in country specific setup fields. These values are migrated to the Legal Entity Identifying Jurisdiction Registration Number. If no valid registration numbers exist, a dummy value of Sys + <Sequence number> is upgraded as the registration number and associated with the seeded Identifying Jurisdiction.

Note: See the Oracle Financials and Oracle Procurement Upgrade Guide: Release 11i to Release 12 for details.

Legal Associations

To enable tax calculation based on existing parameters, the association between a GRE/Legal Entity and an operating unit, inventory organization, ship to location, bill to location are migrated. After the upgrade, you must maintain these associations through the Legal Entity Configurator.

Multiple Organizations (Multi-Org)

In this release, Multiple Organizations Access Control (MOAC) has made significant enhancements to the Multiple Organizations architecture that was used in Release 11i. If your company has implemented a Shared Services operating model, Multi-Org Access Control allows you to process business transactions more efficiently. You can access, process, and report on data across multiple operating units from a single responsibility without compromising data security or system performance.

Multi-Org Security Profile

The Multi-Org Security Profile allows you to access, process, and report on data for an unlimited number of operating units from a single applications responsibility. To take advantage of Multi-Org Access Control, you should set the following profile options:

The Release 11i MO: Operating Unit profile option setting is preserved, and applies if MO: Security Profile is not set.

Enhanced Cross-Organization Reporting

Cross-organization reporting has been enhanced to be more consistent with the new Multi-Org Access Control. You can run reports across multiple operating units that belong to a user’s security profile that share the same ledger.  You can also run reports for any operating unit that belongs to a user’s security profile.

Setting Up Operating Units

Setting up operating units is more streamlined with the integration with Accounting Setup Manager, a new feature in General Ledger that centralizes the setup and maintenance of common financial components, such as legal entities, operating units, and ledgers within an accounting setup.

All Release 11i HR Organizations classified as Operating Units are preserved during the upgrade. If operating units are assigned to a set of books, they are associated to a primary ledger in an accounting setup. You can now view all operating units assigned to an upgraded primary ledger using Accounting Setup Manager.

Student System and Student Recruiting

Important: Oracle Student System (IGS) and Oracle Student Recruiting (IGR) are not functional in this release. Customers using IGS and IGR should not upgrade to this release. There are no plans to provide an upgrade from Release 11i to Release 12 for IGS and IGR.