This appendix discusses tasks that you can perform in advance of the upgrade. By completing these optional tasks in advance of the actual upgrade, you may be able to substantially reduce the amount of time that your system is offline during the upgrade process.
This appendix covers the following topics:
The steps in this section are suggested only if you are using Customer Relationship Management products in your system.
Completing these tasks for Leads Management could substantially reduce the downtime required for the upgrade.
If you use Leads Management and are currently running Release 11.5.9 or Leads Manager minipack A, review the strategies outlined in Leads Management 11.5.10 Data Migration (Doc ID: 365367.1) to determine how to best migrate your Leads Management data.
The steps in this section are appropriate only if you are using Financials and Procurement products in your system.
Completing these tasks could substantially reduce the downtime required for your upgrade.
If you have a large volume of depreciation data in the current open period in the books that are in use, and you are experiencing a long running time with facpupg.sql, consider running depreciation with or without closing the current period as permitted by business prior to the upgrade. Doing so can potentially reduce downtime by processing additions, back-dated transfers, and pending retirements and reinstatements in the current open periods in the books that are in use.
If you have a large volume of pending mass addition lines from Payables and Projects that are for books in Assets with reporting books, and you are experiencing a long running time with faumamcr.sql, you can substantially reduce downtime by preparing and posting these pending Mass Addition lines before the upgrade.
Completing these tasks could substantially reduce the downtime required for your upgrade.
TUMS Step Key: GL_CREATE_JE_SEGVALS
Review this section if you use General Ledger with a large number of posted journals and you are experiencing a substantial running time when running glrsgup2.sql.
The General Ledger Journal Entries Pre-Upgrade is an optional program that can reduce the duration of downtime while upgrading. It upgrades posted General Ledger journal entries before the planned downtime, leaving only unposted journals and newly posted journals to upgrade during downtime.
The GL Journals Entries Pre-Upgrade consists of the Program - Prepare Posted Journals Before Upgrade concurrent program, which you run from the Standard Request Submission form. Since this program is resource-intensive, it should be scheduled to run during non-peak times, such as evenings or weekends. It can, however, be terminated at any point, and, when restarted, it resumes from the point where it left off. Even after the program is complete, you can run it again at a later time. It processes only journal entries posted after the last time it was run.
In order to install the functionality necessary to run the Program - Prepare Posted Journals Before Upgrade concurrent program, apply patch 4685497.
By setting the country code in your Release 11i environment before you upgrade to Release 12.1, you will prevent Form errors. This step is necessary to assure that your legal entities (which are defined in HR and used by EBS Subledgers) are upgraded from Release 11i to Release 12.1.
Navigate to the Locations window to query the location record and set the country code. Go to: Setup > Organization > Locations. Query the location record and set the country code.
Completing these tasks could substantially reduce the downtime required for your upgrade.
TUMS Step Key: ICX_CATALOG_MIG
This pre-upgrade process is strongly recommended if you are upgrading iProcurement from 11.5.9 or 11.5.10. It pre-processes bulk-loaded content to reduce the actual time required for the upgrade and to ensure the upgrade process runs smoothly. You can run it multiple times. If exceptions are found, make corrections and re-run the program until no exceptions are noted. Running this program does not require your users to log off the system.
Note: Exceptions noted and not fixed before the upgrade will not be available in the iProcurement Catalog.
Specifically, this program shortens the time it takes to run these upgrade scripts:
icxr12in.sql: general setup upgrade script needed for iProcurement
poxujpoh.sql: updates PO_HEADERS_ALL (for example, create_language)
poxukpol.sql: updates PO_LINES_ALL (for example, ip_category_id)
poxukrt.sql: updates PO_REQEXPRESS_LINES_ALL (for example, ip_catetory_id)
icxr12rt.sql: populates the requisition templates in iProcurement intermedia index tables
icxr12pd.sql: populates the Purchasing documents in iProcurement intermedia index tables: blanket purchase agreements (BPAs), global blanket agreements (GBPAs), and quotes
icxr12mi.sql: populates the master items in iProcurement intermedia index tables
poxukfi.sql: purchasing script to approve the GBPAs created during iProcurement migration
icxr12fi.sql: final upgrade script, which upgrades favorite lists, purges the BPAs and GBPAs that are not approved, and creates the intermedia index
To run the pre-upgrade, perform the following steps:
Run the extractor to ensure that the iProcurement extracted catalog data is updated.
Apply the pre-upgrade patch (4914492). It inserts a new entry in the eContent Manager menu called Release 12 Data Migration, which you can use to run the data exceptions report and/or the pre-upgrade.
Run the exceptions report prior to the pre-upgrade. The report lists data that cannot be automatically upgraded and must be fixed before the upgrade. The pre-upgrade processes the catalog data to the new data model to reduce upgrade downtime. If there are still exceptions, it also updates the exceptions report.
The exceptions report divides exceptions into two categories: those to be fixed using an XML file and reloaded into the catalog, and those to be fixed by correcting system default values.
Whenever possible, an XML file is provided to help you fix the catalog data. You can download the XML file, fix data issues, and reload data back into the catalog using the loader feature in eContent Manager. Examples of these exceptions are:
Bulk-loaded items without Supplier Site - prior to this release, you could load items in bulk without a supplier site. In order for the pre-upgrade/upgrade to move bulk-loaded items to GBPAs, you must provide a supplier site.
Bulk-loaded items assigned to "all buyers" - prior to this release, you could load items in bulk without a supplier site. To re-load these items after the upgrade, you must provide the operating unit in the loader options user interface. You load the same file into multiple operating units, if necessary.
Bulk-loaded items with invalid data such as category, category mapping, or unit of measure (UOM).
The following table lists exceptions for which you can download an XML file. It also indicates the file Type - price or item. The Delete? column indicates whether a delete file is provided to eliminate old data.
| Exception | Type | Delete? | Instructions for Fixing Data |
|---|---|---|---|
| Currency code is invalid or disabled in the currency setup | Price | Y | Fix the Currency definition or download the file and re-load it, providing a valid currency. |
| Supplier site is invalid, disabled, on hold, or missing | Price | Y | Fix the Supplier Site definition or download the file and re-load it, providing Site in the file or in the load options user interface. |
| Supplier site is invalid due to expired Central Contractor Registration (CCR) supplier registration | Price | Y | Fix the Supplier Site definition in Purchasing or download the file and re-load, providing Site in the file or in the load options interface. |
| "All buyers" option is deprecated | Item | Y | Download the file and re-load, providing Operating Unit, Supplier, and Supplier Site in the file or in the load options user interface. |
| Supplier invalid or missing | Item | Y | Fix Supplier definition or download the file and re-load, providing Supplier and Supplier Site in the file or in the load options user interface. |
| Operating Unit invalid | Item | Y | Fix the Operating Unit definition or download the file and re-load it, providing Operating Unit, Supplier, and Supplier Site in the load options interface. |
| UOM code is invalid in the setup, or missing | Price | N | Fix the UOM definition or download the file and re-load it, providing a valid UOM. |
| No Purchasing category that maps to the iProcurement category in the catalog | Item | N | Map the iProcurement category to a valid Purchasing category or download the file and re-load it, providing an iProcurement category mapped to a valid Purchasing category. |
| Purchasing category is invalid | Item | N | Fix the Purchasing category definition, or map the iProcurement category to a valid Purchasing category. Or, download the file and re-load it, providing an iProcurement category mapped to a valid Purchasing category. |
To fix exceptions using the XML files, perform the following steps:
Download the XML file.
The download link provides a compressed file called ItemException.zip for each supplier/supplier site/contract/language combination. This file contains two XML files: one for the SYNC and the other the DELETE action. There may be multiple SYNC files (for multiple languages), but there will always be only one DELETE file.
SYNC files are named ItemException_Language_SYNC.xml. They are in Release 11.5.9 or 11.5.10 format, which allows you to later re-load these items (after the SYNC action). The DELETE file is named ItemException_DELETE.xml. It is also in Release 11.5.9 or 11.5.10 format that deletes the old file from the system (DELETE action).
Note: In Release 11.5.9 and 11.5.10, there are two types of files: item and price. The language applies only to the item file.
Fix the data. Refer to the table to see the appropriate changes in the SYNC file.
Re-load the data. First, re-upload the items using the SYNC file.
Delete old data. Use the DELETE file, if provided.
Run data exceptions report. Re-run the data exceptions report to verify that the fix was successful. Repeat the process until no exceptions are noted.
In order to create GPBAs, you must fix other exceptions that are due to invalid default values. In these cases, you fix the system setup. The exceptions should not be listed when you re-run the pre-upgrade or data exceptions report.
The following table lists these default value exceptions:
| Attribute | Exception | Error Message |
|---|---|---|
| Rate |
|
|
| Buyer |
|
|
| Ship to location |
|
|
| Bill to location |
|
|
| Terms and conditions | Terms and conditions invalid. | Default payment terms is inactive or invalid. |
| Shipping options |
|
|
The following rules govern the way the migration process defaults values to the new GBPA attributes listed in the preceding table.
The migration uses the CPA information as default for the new GBPA.
The migration relies on Oracle Purchasing to default values for Rate, Ship/Bill to Location, Terms and Conditions, and Shipping Options. For more details, see the Oracle Purchasing Guide.
For the buyer in the GBPA header, the migration tries to source a document to obtain a buyer. It looks for the most recently created document in any status in the following order. Matching is based on Supplier, Supplier Site, Currency, and Operating Unit.
Matching BPA/GBPA
Matching CPA
Matching purchase order
Matching Release
If no document matches from the operating unit, obtains the last created active buyer for the business group
The agreement summary provides a list of all newly created agreements for bulk-loaded items. There is one table for agreements that refer to contract purchase agreements and another for agreements that do not refer to any CPA. In the first case, the system uses CPA information to create the GBPA. In the second case, it uses Oracle Purchasing defaults to create the GBPA. You do not have access to the newly created GBPAs until the upgrade is complete.
The steps in this section are suggested only if you are using Oracle Supply Chain Management products in your system.
Completing these tasks for Oracle Service Contracts could substantially reduce the downtime required for the upgrade.
Applies to 11i release level: All releases prior to 11.5.10
TUMS step key: OKS_R12_MIGRATE
Oracle Service Contracts (OKS) architecture eliminates the generic data structure for rules and time values by storing the relevant attributes in specific OKS/OKC tables. If OKS is registered in your system and you are upgrading from a release prior to 11.5.10, the rules and time values are migrated to the new architecture during the upgrade.
If you want to significantly reduce downtime, then perform the main part of the migration now, before the upgrade. See Service Contracts Release 12 Migration (Doc ID: 372469.1) for instructions.