PRE-UPGRADE STEPS

Reviewed Oracle documents to capture all pre-upgrade steps and activities

- Compiled an inventory of custom apps, third party apps, interfaces, custom reports,
customizations/extensions, custom.pll, etc.
- Reviewed customizations and extensions to ensure valid business need
- Maximized the use of personalization whenever possible to replace form customizations and
custom.pll code
- Authentication OID was considered, remained with ICX for now
- Authorization - Roles and Responsibilities Roles available in R12; decision by project to
utilize current responsibilities model; roles will be used only if required
- New Roles created for: Concurrent request output sharing (System Profile setting in 11i)
- Users of custom responsibilities to run Application Diagnostics who do not have Oracle
seeded responsibilities
-
Examine without requiring an apps password.

- Custom Reports Concurrent custom reports had to be re-compiled and executed using
Oracle Developer Tools 10g. XML reports were updated and executed in BI Publisher

- Forms Server Upgrade All forms were re-compiled and executed in Oracle Developer Tools
10g. Moved custom and customized forms to correct directory (new APPL_TOP) on the R12
EBS Application server

During the original implementation of Oracle software, any customizations should have been
registered as a custom application using the System Administrator responsibility. A supporting
directory structure on the application server should have also been created at this time. All
customizations registered as custom applications will be protected from being overwritten during
the upgrade process. If a custom application was not used for some or all of the current
customizations, perform this step prior to initiating the upgrade.

All interfaces, form customizations, descriptive flexfields, and customized reports will require
extensive testing to ensure that they have not been affected by changes to tables or APIs in the
upgraded software. Custom responsibilities and menus must be reviewed and potentially
updated as well. In some cases, customizations can be removed following an upgrade if new
features and functionality satisfy the business requirements previously met with the custom
code.

TESTING APPROACH

Multiple SITs but one iteration of UAT Option given to least impacted modules to not participate in the second
SIT

- Excluded all standalone applications (obtained test waivers from stakeholders)
- Analysts worked with SME from user community to put together the UAT test plan
- Number of Target applications included in the UAT program
- Confirmed and logged issues into our Technical Issue List to begin resolution process
- SME either conditionally or unconditionally signed-off on UAT
- Instituted project code freeze (Except for conditional sign-offs)



SIGNIFICANT IMPACT

- What are the least Least impacted modules HCM & ODM (BOM, WIP, QA etc.) and
conversely
- What are the Most impacted areas
Payables
eAM
GL
FND Load


1. PAYABLES

AP re-architected: AP, eBTax and Payments
Significant changes in Suppliers, Invoice Lines, Payments, Taxes, Subledger Accounting (SLA)
New user interface - from Form base to OAF
User defined folders are no longer valid
Performance issue with MASS Addition Create
Internal Banks no longer reside within Payables and are now under Cash Management
Many reports and views needed to be rewritten due to new table structures. Some will work with
old converted data but not with new transactions. This is partially due to some of the old tables
being recreated as a view
- Several new columns were added to the ap_invoice_distributions_all table, including a
conversion of id columns old_distribution_id, old_dist_line_number
- There are several new distribution types: Accrual, AWT, ERV, ICMS, IPI, IPV, Nonrec Tax,
Prepay, Retainage, Retroaccrual, Retroexpense, TIPV, IRV
- Suppliers no longer exist in PO tables. Now a part of Trading Community Architecture
Oracle Trading Community Architecture (TCA) is a data model that allows you to
manage complex information about the parties, or customers, who belong to your
commercial community, including organizations, locations, and the network of
hierarchical relationships among them. This information is maintained in the TCA
Registry, which is the single source of trading community information for Oracle E-
Business Suite applications. TCA provides a single, universal definition of trading
partners across applications and job function.
- Some tables become obsolete and new views are created with the same table names:
-
Obsolete Tables - View name => New Underline Tables
PO_VENDORS AP_SUPPLIERS
PO_VENDOR_SITES_ALL AP_SUPPLIER_SITES_ALL
PO_VENDOR_CONTACTS AP_SUPPLIER_CONTACTS

The key entities in TCA include:
Parties: Entities of type Person or Organization that can enter into business
relationships. Parties can also be of type Relationship. For example, Joe as himself is a
party of type Person, but Joe as a contact for Vision Corporation is a party of type
Relationship. Every party in the TCA Registry has a unique Registry ID.
TCA includes an extensive variety of information for parties, for example party name,
addresses, contacts, and contact points. Joe as a person can have a personal phone
number that differs from the phone number for the relationship of Joe as a contact.
Party sites: Addresses that parties use for specific purposes, or uses.
Customers: Parties with whom you have a selling relationship.
Customer accounts: The business relationships between you and your customers.
Customer account sites: Party sites used in the context of customer accounts for
specific purposes, or uses, for example ship-to and bill-to account sites.
Locations: Geospatial points, usually defined by an address.
Contacts: People who have a contact or employment relationship with an organization
or person.
Contact points: Means of contact, for example, phone and e-mail address


2. FNDLOAD
FNDLOAD - Benefits
FNDLOAD is the Oracle supported method to programmatically load various EBS objects.
FNDLOAD commands can be incorporated into a shell script. This provides the ability to
combine multiple commands into a script that can run with minimal user intervention and easily
manage dependencies within a script by sequencing the commands within the shell script.
The input to FNDLOAD commands is an LDT flat file. This file is generated using an export
from the source system. Once an LDT file is generated, it will be used as input to future object
migrations.
FNDLOAD is the supported tool to migrate the following objects:


Concurrent Programs/Executables => Attachments => Help Configuration
Request Groups/Request Sets => Messages => Document Sequences
Profile Options => Value Sets and Values => Alerts
Key and Descriptive Flexfields => Lookup Types => Concurrent Manager
Schedules
Menus and Responsibilities => Printer Definitions
Forms and Form Functions/Personalizations => FND Dictionary


CEMLIs
C :- Configurations/Customization
E :- Extension
M :- Modification
L :- Localization and
I :- Internationalization and
I :- Integration