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