trutek little r1213 upgrade essentials 03-15-2013

the little r12.1.3 upgrade essentials

for managers and team members

an overview

from the three primary perspectives:

managerial, functional and technical

by

Mike Swing


2

Copyright 2013 by TruTek

All rights reserved. No part of this document may be reproduced, stored in a retrieval system, or transmitted by any means, electronic, mechanical, photocopying, recording or otherwise without explicit permission from the authors.

Published by TruTek.

TruTek 1740 South Main Street Salt Lake City, UT 84115

Phone 801 486-6655

Last Updated: 3/15/13

http://www.trutek.com

Oracle is a registered trademark of Oracle Corporation.

Other trade and service marks are the property of their respective owners.

Order additional copies at http://www.trutek.com

http://www.trutek.com/


Table of Contents

3

Table of Contents

THE LITTLE R12.1.3 ESSENTIALS FOR MANAGERS AND TEAM

MEMBERS ...................................................................................................... 7

AUDIENCE ..................................................................................................... 7 THE BIG PICTURE .......................................................................................... 7 AVAILABLE REFERENCES .............................................................................. 8 TRUTEK TRAINING ........................................................................................ 8

Release 12.1 New Features Training ....................................................... 8 TruTek Release 12.1.3 First Pass Upgrade Onsite Training ................... 8 Other Training ......................................................................................... 9

TRUTEK CONSULTING ................................................................................... 9 TruTek Release 12.1.3 Technical Upgrade Readiness Assessment .......... 9 Release 11i Extended Support Mandatory Patching Consulting

Engagement .............................................................................................. 9 TruTek Release 12.1.3 Ongoing Technical Support ............................... 10 TruTek Release 12.1.3 Functional Upgrade Readiness Assessment ...... 10 TruTek Functional Upgrade Support ..................................................... 10 TruTek Testing/Quality Assurance Support ........................................... 10

TRUTEK’S RELEASE 12.1 BOOKS ................................................................ 11 OUR PARTNERS ........................................................................................... 13

CHAPTER 1 – PLAN TO UPGRADE ........................................................ 19

FIRST STEPS ................................................................................................ 19 WHY MIGHT A BUSINESS DECIDE – OR HESITATE - TO UPGRADE? ............. 20 DECISION: REIMPLEMENT VS. UPGRADE ..................................................... 21

Upgrade vs. Reimplementation .............................................................. 21 Transform and Upgrade with eprentise ................................................. 22 Oracle’s Reimplementation Tools .......................................................... 30 Other Third Party Tools That Help Reimplementation .......................... 32

CAPABILITY MATURITY MODEL ................................................................. 35 UPGRADE BENEFITS: AN OPPORTUNITY TO OPTIMIZE YOUR HARDWARE

CONFIGURATION ......................................................................................... 36 UPGRADE BENEFITS: IMPROVED ORACLE TOOLS SIMPLIFY THE PROCESS .. 38

Real Application Testing ........................................................................ 38 Database Replay .................................................................................... 38 Maintenance Wizard .............................................................................. 39

UPGRADE BENEFITS: USE SHARED SERVICE CENTERS TO DRIVE COST

SAVINGS AND INCREASE INFORMATION QUALITY ....................................... 40 UPGRADE PROCESS: THE R12 FUNCTIONAL UPGRADE REQUIRES GAP

ANALYSIS .................................................................................................... 41 UPGRADE PROCESS: ASSESSMENTS CAN HELP THE PLANNING PROCESS .... 44

Functional Upgrade Assessment ............................................................ 45 Technical Upgrade Assessment .............................................................. 45 Customization Assessment...................................................................... 46


4

Architecture Assessment .........................................................................46 Hardware Assessment .............................................................................48

UPGRADE PROCESS: UNDERSTAND THE FUNCTIONAL FINANCIAL R12 NEW

FEATURES ....................................................................................................49 Integrated Financials ..............................................................................49 Subledger Architecture ...........................................................................49 Key R12 Modules ....................................................................................49 Subledger Currency Views ......................................................................50 Multi-Org Access Control .......................................................................51

UPGRADE PROCESS: BUILD A STRONG UPGRADE TEAM ..............................52 Dedicated Team Members.......................................................................52 Upgrade Roles and Responsibilities .......................................................53 Technical Upgrade Responsibilities........................................................53 Functional Upgrade Responsibilities ......................................................54 Upgrade Project Manager Responsibilities ............................................54 Steering Committee .................................................................................55

UPGRADE TACTICS .......................................................................................55 SUCCESS FACTORS FOR UPGRADE PROJECT MANAGERS ..............................56

Time and Money ......................................................................................57 Customization Costs ....................................................................................... 58

Skills ........................................................................................................58 Identify Skill Gaps in Your Upgrade Team .................................................... 58

Teamwork ................................................................................................59 Team Obstacles .............................................................................................. 59 Minimize Risk ................................................................................................ 60 The Team Must Recognize Competing Priorities........................................... 60

SUCCESS FACTORS FOR FUNCTIONAL USERS ...............................................61 Gap Analysis ...........................................................................................61 Known Gaps ............................................................................................62

Financial Reporting Gaps ............................................................................... 62 Drill Down Restrictions ................................................................................. 63 Limited Chart of Accounts Access ................................................................. 63 MS Word Becomes the Report Layout Editor ................................................ 63

Recommended Add-on Products .............................................................63 Excel-based Reporting Alternatives ............................................................... 63

Customizations ........................................................................................65 Cumulative Business Value of “Small” Business Productivity

Improvements ..........................................................................................66 Cost - Benefit Analysis for Business Process Improvement for Smaller

Implementations ......................................................................................67 SUCCESS FACTORS FOR TECHNICAL UPGRADE MANAGERS .........................68

Patches ....................................................................................................69 Upgrade Patch Types – Release 12.0 Critical Patch Collections (CPCs),

Oracle E-Business Suite Pre-install Patches, Financials RPCs, Generic

Data Fixes (GDFs), CPUs, PSUs ...........................................................69 Release 12.0 Critical Patch Collections (CPCs) ............................................. 69 Oracle E-Business Suite Pre-install Patches ................................................... 70 Recommended Patch Collections (RPCs) ...................................................... 70

Table of Contents

5

Generic Data Fixes (GDFs) ............................................................................ 71 Critical Patch Updates (CPUs) ....................................................................... 71 Use Patch Wizard from Oracle Application Manager (OAM) ....................... 72

The Patching Process ............................................................................. 74 The Testing Process ............................................................................... 75 Create Custom Development Upgrade Plan .......................................... 75 How to Upgrade Customizations ........................................................... 76 Obsolete Technology Components with Release 12 ............................... 77

mod_plsql....................................................................................................... 77 Oracle Reports Server Reports ....................................................................... 77 Oracle Graphics Integrations with Oracle Forms ........................................... 78 AK Mode ....................................................................................................... 78

JOINING FUNCTIONAL AND TECHNICAL VIEWS ........................................... 79 Upgrade Success Without Customizations ............................................. 80 Tools of Choice for Rooting Out Customizations ................................... 80

CHAPTER 2 – PREPARE TO UPGRADE ................................................ 83

PRACTICE TESTING ...................................................................................... 83 OPTIMIZE THE UPGRADE ............................................................................. 83 MAINTENANCE WIZARD .............................................................................. 83 UPGRADE BY REQUEST ............................................................................... 84 DEFAULT UPGRADE PERIODS - MINIMUM DOWNTIME UPGRADE ................ 84 INSTALL THE SLA PRE-UPGRADE CONCURRENT PROGRAM ....................... 85 RUN THE SLA PRE-UPGRADE CONCURRENT PROGRAM .............................. 85 ADJUSTMENT PERIODS ................................................................................ 87 SLA POST UPGRADE PROCESSING .............................................................. 87

Upgrade by Request ............................................................................... 87 THE UPGRADE IS AN ITERATIVE PROCESS ................................................... 87 MANAGE-EVOLVE-OPTIMIZE ...................................................................... 88

Manage................................................................................................... 88 Evolve ..................................................................................................... 88 Optimize ................................................................................................. 89 Aligning and Improving the Business Processes with R12.1 New

Features is an Iterative Process ............................................................. 89 When Are We Ready? Are We There Yet? .............................................. 89 Technical Upgrade Paths - Release 12.1 Upgrade Paths ...................... 91

RELEASE 12.1 UPGRADE PATHS .................................................................. 92 DATABASE UPGRADE REQUIREMENTS ........................................................ 93 DATABASE UPGRADE STEPS ........................................................................ 94 UPGRADE TIMEFRAME ................................................................................ 94 UPGRADE DOWNTIME WITHOUT THE DATABASE UPGRADE ....................... 96 UPGRADE WEEKEND ................................................................................... 96

CHAPTER 3 – PERFORM THE UPGRADE ............................................ 99

TUNE THE UPGRADE .................................................................................... 99 OPTIMAL NUMBER OF WORKERS .............................................................. 100 OPTIMIZE ADPATCH ................................................................................... 100


6

TIME THE UPGRADE ...................................................................................100 AD_TASK_TIMING ................................................................................101 REDUCING DOWNTIME ...............................................................................102 AUTOCONFIG IN PARALLEL MODE ACROSS MULTIPLE NODES ..................102 AFTER THE UPGRADE DRIVER FINISHES ....................................................103

CHAPTER 4 – FINISH THE UPGRADE .................................................105

THE IMPORTANCE OF TESTING ...................................................................105 TESTING METHODOLOGY ...........................................................................105

Functional Testing ................................................................................106 Load Testing..........................................................................................106 Technical Testing ..................................................................................107

TEST MANAGEMENT ..................................................................................107 TEST ENVIRONMENTS ................................................................................107 FUNCTIONAL TESTING ...............................................................................107

Global Accounting Engine Verification Tasks ......................................108 Run Accounting Reports .............................................................................. 108

E-Business Tax Verification Tasks ........................................................108 Tax Transaction Audit and Reconciliation Reports ...................................... 108 Payables and Receivables Transaction Query .............................................. 108

Payments Verification Tasks .................................................................109 Legal Entity Configurator Verification Tasks .............................................. 109 Trial Balance Reconciliation ........................................................................ 109 Invoice and Payment Processing .................................................................. 109 Accounting Setup and Processing ................................................................ 109 System Security Options .............................................................................. 110 Oracle Payables Impact ................................................................................ 110

CONCLUSION ............................................................................................113

7

the little r12.1.3 essentials for managers and team members

“That which we persist in doing becomes easier, not that the task itself has become easier, but that our ability to perform it has improved.”

Ralph Waldo Emerson (1803 - 1882)

Audience

The intended audience for this handbook is upgrade managers and all team members participating in the upgrade to Release 12. This team may include the following team members: Super Users, DBAs, Developers, Quality Assurance Testers and Hardware Architects.

Team members should be able to understand the basics of all phases of the upgrade. This handbook provides an overview of the upgrade, the transition from an Oracle E-Business Suite Release 11i environment to Release 12.1, from three primary perspectives: technical, functional and managerial. Understanding these perspectives will allow for better communication between the primary groups of upgrade participants. Each point of view has slightly different criteria for success. Team members should understand that success can be claimed only when all the success criteria have been met.

As teams grow larger, the skills required to manage large groups grow as more ideas are expressed. The intimacy of a small group is lost, and the opportunity for misinformation and disruptive rumors grows. Managers may encounter difficulties based on Daglow's Law of Team Dynamics: "Small teams are informed. Big teams infer."

Communication is essential.

The Big Picture

There are four upgrade categories, according to Oracle, and we will follow this convention to be consistent. As you read this book, we devote a chapter to each of these four topics:


8

Available References

Check out our training, our consulting, and our books, and you’ll see we’ve developed a comprehensive approach to upgrading to Release 12.1.3.

TruTek Training

Release 12.1 New Features Training

One could argue that the changes to the E-Business Suite of Applications for Release 12.1 are the most significant part of a Release 12.1 upgrade. Our expert trainers cover new features provided by Release 12.1, including changes to General Ledger, Purchasing, Payables, Fixed Assets, Receivables and Cash Management. Our class also discusses changes to Inventory, Order Management, Projects, iExpense, iSuppler, iProcurement, iReceivables, and TCA. We can also tailor the class to cover just the modules that you plan to use, and if we’re assisting with your upgrade, our trainers also do the consulting work, so they can tailor classes to your unique environment.

TruTek Release 12.1.3 First Pass Upgrade Onsite Training

If you’re ready to upgrade and want to run against your own data, rather than a Vision instance, we now offer a special consulting engagement called the Release 12.1.3 First Pass Upgrade. We come to you for this upgrade, and we lead your technical staff through the upgrade in a two to three week engagement. We provide step by step guidance and our detailed problem solving skills, while your technical staff performs the upgrade. During the engagement, we work with your staff to monitor activities overnight and on the weekends, and we inevitably hit issues that we haven’t seen at other clients. We document the workarounds and provide each client with an updated version of the little r12.1.3 upgrade guide that includes a list of patches that are specific to their environment. We would expect a normal first pass upgrade to take 1 – 3 months, but because we’ve been through the upgrade process so many times in our

1. Plan to Upgrade

2. Prepare to Upgrade

3. Perform the Upgrade

4. Finish the Upgrade


9

classes and consulting engagements, we can streamline the first pass to two to three weeks. So if you’re ready, give us a call.

Other Training

Our Oracle E-Business Suite R11i to R12 Technical Upgrade class takes students through a full upgrade of the Vision instance for Oracle customers who aren’t ready to establish a test environment for our onsite upgrade class. We also offer DBA classes that include Oracle R12 Applications DBA Concepts and Admin, 11g DBA Boot Camp I and 11g DBA Boot Camp II.

TruTek Consulting

TruTek Release 12.1.3 Technical Upgrade Readiness Assessment

Before you start your upgrade to Release 12.1.3, we strongly recommend a Release 12.1.3 Upgrade Readiness Assessment. We send you a questionnaire and list of scripts to run, and then we come onsite and evaluate your environment to help you decide if you’re ready to upgrade. Our detailed report covers your environment and describes issues that you need to address before you start your upgrade. Do you have the right hardware to support Release 12.1.3? Do you have the right skillsets to support Release 12.1.3? Do you have the right patches in place to support your Release 11i environment while you are preparing to upgrade to Release 12.1.3? We look at those questions and more to help you prepare.

Release 11i Extended Support Mandatory Patching Consulting Engagement

This onerous task requires comparing which modules you’ve licensed and the current status of patching of those licensed modules with Oracle’s MOS Doc. ID: 883202.1, which includes a list of dozens of patches that may need to be applied to your environment in order to receive support from Oracle now that Release 11i is in Extended Support. If you plan to upgrade to Release 12.1.3, we believe you should get your E-Business Suite Release 11i environment in order so that your staff can focus on the Release 12.1.3 upgrade rather than potential support issues with your current environment. Doing so requires a thorough review of your environment, as well as a meticulous review of Oracle’s Release 11i Extended Support Mandatory Patches, including reading all the Readmes, searching for pre-requisite patches and post patches, building a


10

spreadsheet of all the required patches, and then applying and testing them. TruTek has been down this road a few times and would be happy to assist.

TruTek Release 12.1.3 Ongoing Technical Support

Most of our clients require assistance on their Second Pass Upgrade. The flurry of issues that arise during the First Pass Upgrade often take attention away from establishing total comfort with the upgrade process. We can provide support either onsite or remotely for the Second Pass, and we’re happy to continue to provide support for additional passes until everyone is comfortable with the process. We can also provide ongoing support by keeping your DBA informed as we head to new clients and discover new issues and patches. We can also provide onsite support during your final upgrade weekend. We highly recommend production upgrade support – during the full court press, it helps to have an experienced partner helping to check and double check that the final upgrade goes smoothly.

TruTek Release 12.1.3 Functional Upgrade Readiness Assessment

TruTek’s Functional Upgrade Readiness Assessment is best performed shortly after the TruTek Release 12.1.3 First Pass Upgrade. Your users will need guidance to perform the gap analysis between the existing Release 11i environment and the Release 12.1.3 environment. This Assessment begins the process of determining new features, as well as determining what customizations have been done, and whether they should be maintained or eliminated.

TruTek Functional Upgrade Support

TruTek’s functional consultants understand the nuances of Release 12.1.3 and can work with you to build a test plan, resolve issues with functionality, and help drive the customization review process.

TruTek Testing/Quality Assurance Support

TruTek partnered with Original Software to provide a unique solution for Application Quality Management to unite all aspects of the software quality lifecycle from requirements to test planning, test case design, test execution and defect tracking, all with full traceability.

TruTek consultants will guide you in implementing the Original Software Qualify products, including TestBench, TestDriver, and TestSmart, to


11

build on your quality processes and ease into full quality automation. We will work with your functional subject matter experts to create manual tests in TestDrive for Oracle Application web pages and forms, or customers can take advantage of TruTek’s repository of Oracle Application test scripts.

TestDriver test scripts can then be used with TestDrive Assist to facilitate full-blown test automation. TestSmart can be used to populate your test scripts with different data on each test run, allowing you to create many business scenarios with one script. TestBench can be used to manage your test environment, provide intelligent data extraction with obfuscation techniques, compare test runs, and implement database undo to return data to a prior state, thus allowing multiple test runs to quickly fix defects for successful test results.

TruTek consultants will help you configure Qualify to fit your organizational quality methodology whether you use Agile, waterfall, or a hybrid approach. We will show you how to take advantage of Qualify’s many features, such as drill down dashboards for access to instant information by all users including functional, technical or management, cross project resource management, integrated workflows, email integration, role-based access control, and built-in and customized reporting.

TruTek’s Release 12.1 Books

TruTek now offers two sets of books, those published externally about the E-Business Suite for anyone interested in upgrading to Release 12.1, and tailored books (we call them the blue books) written for each of our customers or classes as part of an upgrade project or training class. We’ve made this change because each customer’s patches will be different depending on their operating system, database, Applications patches and E-Business Suite modules. For some of the books, reflecting those differences is critical to upgrade success.

You can buy our books and DVDs online at: http://www.shop.trutek.com/category.sc?categoryId=30

If you’d like to take a training class with us or bring us in to consult, give us a call at:

801 486-6655.

http://www.shop.trutek.com/category.sc?categoryId=30


12

TruTek is a national leader in technical and functional Oracle training and consulting. We specialize in Oracle database and Oracle E-Business Suite technical and functional consulting. TruTek offers a full range of Oracle training classes.

You can sign up for TruTek’s monthly TruTalk Newsletter at: www.trutek.com


http://visitor.constantcontact.com/d.jsp?m=1102170980254&p=oi

http://archive.constantcontact.com/fs036/1102170980254/archive/1102267128888.html



13

Our Partners

We’ve come to the conclusion that a successful upgrade requires the best tools and the best partners. As we’ve worked through the Release 12 Upgrade process, we’ve concluded that there are five areas that require special attention:

Testing – What everyone hates and what no one can avoid! Inadequate

testing of your Oracle Application implementation or upgrade can result in an over budget project with an unpredictable extended timeline, negatively impacting your organization’s business processes and putting your upgrade at risk.

Original Software’s Qualify product, including TestBench, TestDrive, TestSmart, and TestDrive-Assist, can bring organization, improved project control and visibility and quality testing to your upgrade, while enhancing collaboration between management, functional and technical project members.

Original software’s easy to use test solutions include a project management

platform with manual testing that can be transformed into full test automation without requiring programming skills. Subject matter experts are empowered to define and execute sophisticated testing scripts to use on updated Oracle Applications development and test environments. Defects can be detected and changes automatically incorporated into updated test scripts. Original Software ensures test data privacy with obfuscation techniques for audit compliance, database checkpoint and rollback functionality for errors to be identified, corrected and tests quickly repeated. Not only is Original Software technology easy to use, but it accelerates the quality process, allowing for faster delivery of business critical Oracle Projects.


14

Eleven Reasons to Use Original Software for EBS Testing

Original Software products provide these features:

Qualify

1 Full project management, planning, estimating, assigning, and tracking capability

2 Project workflow, design custom workflows for your company

3 Effective project collaboration for management, functional, and technical users

4 Issue tracking system for managing your upgrade tasks, testing, and SRs

TestDrive

5 Training made easy with Fast-Track test scripts; teach as you test!

6 Manual system and user acceptance testing with screen capture and test steps

7 Code free and self-healing test script technology

8 Performance, server, and browser statistics

TestBench

9 Manual to full automation

TestSmart

10 Smart data creation

Fast-Start Test Packs for EBS

11 R12.1 test scripts for Financials, Procurement, and Inventory


15

Reimplementation – not! There are several reasons why you might

consider reimplementing, which means, essentially, starting over with the E-Business Suite, but with the advantage of having used the applications for a number of years. Reimplementing is considered more costly than upgrading because you really do have to go through all the setups and make decisions about what their values should be for your environment.

Sometimes reimplementation is the only way to go. Our TruTek consultants can help you decide if reimplementing is unavoidable, or we can talk about a tool from eprentise that solves many of the common issues – including changes to the Chart of Accounts. With software available since 2007 from eprentise, an Oracle Partner, now it is possible to upgrade from Release 11i even if you need to change the Chart of Accounts, reorganize operating units, adopt a different calendar, leave behind corrupt data, or consolidate multiple instances into a single global production instance.

Customizations – tracking down those extra reports that you’ve

placed under $CUSTOM_TOP is one thing, but what about all those changes that you’ve made over the years to menus, value sets, and profile options? We think that Rookery Software has the best solution available, called ConfigSnapshot. We use ConfigSnapshot to take a snapshot of the current environment. Then we perform the upgrade and take a second snapshot and use the ConfigSnapshot tools to root out the differences – changes made by users, as well as those made by Oracle with the new release.

ConfigSnapshot also includes customization code impact analysis, enabling you to automatically search through any custom code you have, to identify where you have referenced objects that have changed between


16

versions. This frees up technical resources to focus on deciding how the code should be modified to work correctly in the upgraded environment, rather than spending significant time trying to manually locate which of the thousands of modified objects may be included somewhere in each item of custom code.

Reporting - Excel4apps’ GL Wand is an award-winning, Excel-based

financial reporting solution for finance professionals using Oracle e-Business Suite 11i or 12. As an Oracle Validated Integration solution, GL Wand enables highly efficient and secure financial reporting, shorter month ends, and faster refreshes with ad-hoc inquiry and drill downs.

Like all Excel4apps solutions, GL Wand leverages your existing Oracle security settings and provides reports with drill-down capabilities that are refreshable on demand, yet preserve formatting and Excel formula. Without middleware or data warehouse requirements, you can install and utilize Excel4apps solutions in minutes – so there’s less reliance on IT support and greater power given to the individual user.

GL Wand Benefits

Live Oracle data in Excel

Effective replacement for Client ADI reporting

Accelerate month end processing

No need for data warehousing

Automate sharing and distribution of reports

Leverage existing Oracle security

Ease your upgrade to Oracle R12

Quick to install, fast performance and easy to use

Mass reporting and distribution

HTTP connection

FSG converter


17

Performance Tuning - Confio’s Ignite 8 is a comprehensive

performance solution that you can use with your E-Business Suite environment. Ignite focuses on measuring response time, and adds server resources, expert advice, and trends ranging from one second to one year.

Confio’s Alarm Trail leads you right to the root cause, simply by clicking on the alarm icons to navigate. Only Ignite leads you on a path directly to the problem.

Ignite includes correlation of all metrics including response time, server health, real time sessions, and query statistics. Only Ignite correlates all the server health indicators with response time data from wait events.

If you’d like to learn more about our partners, contact us at www.trutek.com, or call us at 1 801 486-6655.


19

1. Plan to Upgrade




Chapter 1 – Plan to Upgrade

“A man that does not plan ahead, will find trouble at his door.”

Confucius

First Steps

There are three main perspectives for the upgrade: functional, technical and managerial. We will show how these points of view work together, especially when customizations are present. With each point of view comes a definition of upgrade success. Each point of view must succeed in order for the whole upgrade to succeed. The following steps are the starting point for the upgrade plan:

First, organize executive sponsors and superusers into a Steering Committee. Have the Steering Committee identify and prioritize the reasons to upgrade. Special consideration should be paid to implementing new R12 functional features and achieving more efficient processing. De-support dates by Oracle should also be considered.

Before making the decision to upgrade using Oracle’s upgrade process or reimplement from scratch, identify the current issues. Some issues may be resolved by new functionality, others may require new customizations. Broken processes are very likely to exist after the upgrade.

Purge unnecessary data and clean up interface tables. Data cleanup should be an on-going process, but becomes a priority during upgrades because of the additional processing required during the upgrade downtime.

Deciding whether to reimplement or upgrade depends on a number of factors. Doing a fresh implementation will likely take much more time and be more disruptive to your business. Most Oracle professionals prefer to upgrade if at all possible.


20

Understand the Hardware Requirements and the Upgrade Path. Significant cost savings can be achieved by simplifying and standardizing hardware.

Procure Upgrade Hardware. The upgrade hardware in most cases should be newer and faster than the current production environment. This will allow a seamless cutover from the old production environment to the new upgraded environment on upgrade weekend. Because the upgrade occurs on the new upgrade machine, if the upgrade fails, production doesn’t need to be recovered.

Establish the Upgrade Team. The Steering Committee should select an upgrade project manager, who in turn selects the upgrade team.

Train the Functional Users on the New Features of Release 12. The new features should be integrated into the upgrade plan to replace customizations, when possible, and improve efficiencies.

Create an Upgraded Instance for Gap Analysis. Once trained, functional users will want to understand how the upgrade affects their data and their processes. This should include the most important customizations.

Why Might a Business Decide – or Hesitate - to Upgrade?

The best reasons to upgrade are to take advantage of new functionality, to decrease costs, and to provide your business with a competitive advantage. De-support of your current version of software is not one of the best reasons, but it is compelling. Not staying current also has significant security implications.

Why is waiting until Oracle is ready to “pull the plug” compelling? Because:

it costs so much to upgrade, although it is much less expensive than reimplementing

higher levels of management need a compelling reason

nobody wants to run the latest release, especially .0 releases

the upgrade impact is unpredictable

if you have lost track of customizations, it is a lot of work to review them

if you can’t upgrade your customizations, delaying the inevitable is tempting

if the business processes seem too complex to map to R12, you may want to wait for as long as possible before making the change


21

Decision: Reimplement vs. Upgrade

The decision to reimplement versus upgrade is simple: Do everything possible to upgrade. Don’t reimplement unless you explore all alternatives and find that none work. If you have a relatively uncomplicated environment, and there are no fundamental configuration changes you need to make, then upgrade. Most of this guide is about these straightforward upgrades. This section is for if you need to make significant changes and have considered reimplementation.

If there are complications or you want to change fundamental implementation-time setups in Oracle, you will evaluate each change and see whether you can transform your instance prior to upgrading, so that you can use the standard upgrade from Oracle. But first, note that since Oracle offers no way to change these fundamental configurations, they often suggest reimplementation, without regard for the implications in the customer’s environment.

As frustration and costs mount, many companies – faced with continuing business changes and a need to upgrade to Oracle E-Business Suite (EBS) Release R12 - have to make a decision with their outdated EBS configurations: 1) live with it, 2) reimplement or 3) upgrade. There are many reasons to do a technical upgrade, including lower costs, less risk, better results, and a shorter time-period. Why, then, do many customers feel that a reimplementation is the only option? The answer is easy: they don’t know that commercially-available software options are available to change their existing E-Business Suite configurations and structures, or to consolidate multiple instances. When Oracle first released R12, they guided customers to reimplement if the customer needed to change any obsolete core configurations or to consolidate multiple production instances. Oracle’s R12 documentation acknowledged that reimplementation is more difficult, complex and resource intensive compared to an upgrade. “It is a project that you would generally undertake with the support of a professional services provider, such as Oracle Consulting”.

Upgrade vs. Reimplementation

Let’s first examine the differences between an upgrade and a reimplementation. An Upgrade utilizes Oracle-provided scripts to “convert” the data from the current R11.5.10 Oracle E-Business Suite to R12. The scripts are well-documented and supported by Oracle


22

Support. With an upgrade, all of the data (configuration, master data, and transactions) is available for use after the upgrade, and has been converted into the format required by R12 (i.e., sets of books become ledgers, a Legal Entity is associated with a balancing segment value, etc.). There are minor setups such as secondary ledgers or subledger accounting that need to be configured to take advantage of new R12 functionality. For a Reimplementation, a new R12 environment is installed and the customer (usually with the assistance of a consulting firm or system integrator) configures all of the setups for every module. Then, decisions must be made on how much history to convert and what to do with open items. The consulting organization writes custom scripts (which are not supported by Oracle) to migrate the master data (customers, suppliers, employees, etc.) to the newly configured R12 environment. Then structures (such as charts of accounts, other key flexfields, calendars, and organization structures) need to be converted to the new environment. This usually involves custom scripts (again not supported by Oracle) to extract the structure, transform it into the new structure, and load it into the R12 instance. Finally, all the open transactions, and usually about a year’s worth of history, must be migrated along with beginning balances. Did we mention that these are all done by custom scripts that are not supported by Oracle, or that if there is a chart of accounts change, every transaction must be converted to the new chart of accounts? Did we discuss the reconciliation process between the R11 environment and the new, reimplemented R12 instance?

Transform and Upgrade with eprentise

Now there is an alternative to a reimplementation that addresses the need for change and allows the business to be agile and maintain data integrity while retaining all history.

An Oracle Partner, eprentise, offers software that allows Oracle E-Business Suite users to Remodel their existing Oracle E-Business Suite instance without a reimplementation:

Consolidate multiple production instances.

Change existing configurations like charts of accounts, other key flexfields, calendars, and currency.

Merge, split or move all structures including business groups, sets of books, legal entities, operating units, and inventories.

Retain all history


23

The following tables show the pros and cons of a reimplementation effort versus a technical upgrade with eprentise remodeling:

Traditional Migration Approach (Reimplementation)

Remodeling Approach (eprentise software + Technical Upgrade)

Pros Cons Pros Cons

Common approach, often recommended by consulting organizations and system integrators (Author Comment - who may get compensated based on billable hours and utilization).

No standard extract/transform scripts. Very similar to a custom development project requiring a more formal development and testing methodology including documentation, error handling, and development standards. Requires reconciliation from old structures, configuration to new structures, configuration.

Shorter project duration with fewer resources translates to lower costs. Project can easily be completed in 3-8 months That means that the savings of a single instance are available sooner.

Not widely understood among Oracle professionals or system integrators. Customer needs strong sponsor.


24



No need to upgrade Current 11i to New R12 due to straight data migration into an R12 instance.

More risk in creating extract, transform, and load (ETL) that will not be supported by Oracle.

Only testing that is required is functional testing.

For consolidation, instances need to be at the same version/patch level since eprentise software only works at the database tier.



Cons Pros

Requires technical knowledge of all tables and usage in the E-Business Suite.

Repeatable results, reusable as requirements change. As requirements change, only need to add/change rules, a step that is usually done by a functional user on a specially designed user interface in the software In a very short time.

APIs do not exist for all tables. There is a risk of compromising the data integrity by extracting and loading data incorrectly. Oracle Support not available.

All data integrity is maintained because the code is automatically generated. Oracle will support customer after eprentise software is used.


25



History is generally not converted. Generally a sunset instance is required for reporting, reconciliation, business intelligence, and audits. Every time the sunset instance is accessed, data must be transformed to align with the R12 instance. This access and transformation process is very, very expensive.

All history is converted so there is no need to maintain a sunset instance for reporting, reconciliation, etc. No need to derive landing balances or reconcile between old and new environments. All the data is complete and consistent.

Need to configure R12 instance No need to configure R12 instance

Scripts are written for the current state of the data. Any changes require re-writing of the scripts.

Full documentation of existing instance and changes made including comparison of instances

12-24 months duration 6-9 months duration


26

Ten Reasons to Upgrade

1. Reduced schedule and technical risk. Upgrade relies on

commercial EBS conversion software from Oracle and independent software vendors, rather than reimplementation’s technical analysts and data conversion programmers.

2. You can change your chart of accounts. Upgrade uses remodeling software to change one or more COA’s segments and values so you can adopt a single global COA.

3. You test new EBS setups in familiar 11i. Upgrade uses remodeling software to change any fundamental EBS setup you have postponed until reimplementation. The common setups Oracle says are “not easily changed” include: Legal Entities, Sets of Books (Ledgers), Operating Units, Key Flexfields, Calendars, Costing Methods, Inventory Organizations, and Asset Categories.

4. Transaction data will be changed, too. Upgrade uses remodeling Software to convert all 11i data to reflect all COA and fundamental setup changes.

5. Your history matters. Upgrade uses Oracle upgrade to convert all 11i data to R12. Business users are happier with all EBS history and current data in a single R12 instance, rather than distributed between legacy and active instances.

6. Avoid custom data conversion. With reimplementation, you are on your own to create extract and load scripts to convert and migrate your 11i data into R12. Unless you load everything, compromises lead to complexity, delays, and continuing expense.

7. True single instance for past and future data. With upgrade the result is a single R12 instance, whereas with reimplementation you will have R12 plus the legacy 11i instance in read-only mode as a reference to history and the prior business structures.

8. Avoid multiple custom conversions and legacy instances. For multi-national organizations with multiple EBS 11i instances, reimplementation requires data migrations from each legacy 11i instance into the single R12 instance. You will also retain all legacy 11i read-only instances.

9. Upgrade offers the most direct path and shortest time to single instance R12 business value. The most powerful upgrade advantage for multi-nationals is consolidation to a single global instance with standard business processes and all history data prior to the Oracle upgrade to R12.

10. Upgrades cost less. EBS customers pay for Oracle upgrade software even if they select reimplementation. Why leave money on the table and pay extra to do it yourself?


27

A technical upgrade and a remodeling effort can circumvent all of the “justifications” previously given for a reimplementation.

You need a new Chart of Accounts, have multiple COAs and would like to consolidate to one global COA or have a single COA that needs to split into multiple COAs.

An organization structure that was planned for growth but is now outdated and is some cases obsolete because of unanticipated changes.

Or an organization structure that has experienced a merger/acquisition or a divestiture.

Currently have multiple instances and need or want to consolidate into a single instance.

Want to upgrade to R12 to take advantage of new functionality but existing structure doesn’t seem to support an upgrade.

Up to now, reimplementation and a potentially costly multi-year project with a staff of consultants manually making the necessary changes seemed the only option.

Years of history are often left behind in order to speed up the project and reduce cost.

Reimplementation Consequences

Here are some reimplementation consequences in the areas of implementation, data history, handling of the Release 11i instance, reporting and business intelligence.

You have to implement a fresh installation of R12. Enter all setups from scratch or with Oracle’s Reimplementation tools and utilities.

Consolidation software from eprentise enabled a leading automotive distributor to consolidate two regional production instances into a single global instance within 7 months and at a cost of under $1,000,000, including their technical upgrade to R12. The automotive distributor used only 5 full-time- equivalent (FTE) resources during the entire project and brought over all their history. This compares to similar projects costing between $12,000,000 and $15,000,000 and utilizing over 250 consultants over an18 month project duration.


28

You are on you own to get your open transactions and historical data from the legacy Release 11i into R12. Oracle Support can’t help if the data is incompatible once it is in the R12 environment or if it breaks the E-Business Suite database integrity constraints.

You have to decide what history to load and what to do with the remainder. You will need a policy for each different type of data. The usual choices include most recent and current fiscal year, current year and only open transactions. Dealing with data history will be a significant part of your reimplementation project. It will cost money and require several iterations to get it right.

You may need to keep the Release 11i instance in legacy mode. Some call this a “sunset” instance. It must be frozen and restricted to read-only access. You will not have a single global instance. You will have to keep it available for external regulatory data retention purposes as well as operational analyses.

You will need to devise reporting mechanisms to span the legacy Release 11i and operational R12 instances. This includes translations, reconciliations, mappings and external reporting environments.

If you have a business intelligence environment or data warehouse, you will need to make changes to incorporate the frozen legacy Release 11i and R12 environments.

The following diagram shows the reimplementation approach. Customers following this path usually end up with the two instances (one Release 11i and R12) and keep workaround mechanisms in place to handle the instances or to make adjustments in a downstream business intelligence environment.


29

11i

Not

Upgradable

Implement New

E-Business SuiteR12 Fresh

Implementation

R1211i Data

R12 Data

• Seeded

• Configured

R12 Data• Seeded

• Configured

• History [partial]

Customer Extract

& Transform

Selected 11i Data

11i Data History

[partial?]

Customer Load

11i Data HistoryVia Public API

& Interface

Tables

Custom SQL &

DB Utilities

11iHistory

Restricted

Access

11i Data• Read-Only

• History

Clone R12 empty instance before history load

Create “sunset” instance – read-only restricted access

• Two instances, one active

• Historical data spans both,

but different formats

Reimplementation = Customer Implementation

+ Data Migration

Path from one 11i instance to a single global

R12 instance plus legacy instance

11i

Not

Upgradable

Implement New

E-Business SuiteR12 Fresh

Implementation

R1211i Data

R12 Data

• Seeded

• Configured

R12 Data• Seeded

• Configured

• History [partial]

Customer Extract

& Transform

Selected 11i Data

11i Data History

[partial?]

Customer Load

11i Data HistoryVia Public API

& Interface

Tables

Custom SQL &

DB Utilities

11iHistory

Restricted

Access

11i Data• Read-Only

• History

Clone R12 empty instance before history load

Create “sunset” instance – read-only restricted access

• Two instances, one active

• Historical data spans both,

but different formats

Reimplementation = Customer Implementation

+ Data Migration

Path from one 11i instance to a single global

R12 instance plus legacy instance

The reimplementation environment gets even more complicated if there are multiple Release 11i instances, multiple custom extract, transform and load operations, ending up with multiple Release 11i sunset instances.

This diagram describes the upgrade process:

eprentise

Transformation

11i

Upgradable

Oracle 11i

R12 UpgradeR12

11i DataTransformed

R12 DataTransformed &

R12 formats

11i

Obsolete

Setups

11i Data

11i

Obsolete

Setups

11i

Obsolete

Setups

11i Data

• Instance you always wished for, AND

it’s upgradable.

• Use it as long as you want, until you

need the valued-added R12 features.

11i Data

• Business process changes

• Business structure changes, incl. OUs

• COA changes

• Clean data, compliant with standards

• Shared service centers

• Instance consolidation

Upgrade enables R12 Features

• Centralized accounting architecture

• Global tax engine

• New ledger and ledger

set architecture

• Multi-org access control features

• Centralized banking model

• Advanced global intercompany

system

No data loss No data loss

Upgrade = eprentise Transformation

+ Oracle Upgrade• Single Global Instance

• Lowest future cost

structure

• Highest business value

Path from one or more EBS 11i instances to a

single global R12 instance

eprentise

Transformation

11i

Upgradable

Oracle 11i

R12 UpgradeR12

11i DataTransformed

R12 DataTransformed &

R12 formats

11i

Obsolete

Setups

11i Data

11i

Obsolete

Setups

11i

Obsolete

Setups

11i Data

• Instance you always wished for, AND

it’s upgradable.

• Use it as long as you want, until you

need the valued-added R12 features.

11i Data

• Business process changes

• Business structure changes, incl. OUs

• COA changes

• Clean data, compliant with standards

• Shared service centers

• Instance consolidation

Upgrade enables R12 Features

• Centralized accounting architecture

• Global tax engine

• New ledger and ledger

set architecture

• Multi-org access control features

• Centralized banking model

• Advanced global intercompany

system

No data loss No data loss

Upgrade = eprentise Transformation

+ Oracle Upgrade• Single Global Instance

• Lowest future cost

structure

• Highest business value

Path from one or more EBS 11i instances to a

single global R12 instance


30

Transformation Benefits

Shorter project duration with fewer resources translates to lower costs.

Repeatable results, reusable as requirements change.

Requires less than half the time and resources of consulting efforts.

Accurate, consistent results (no need to worry about different coding styles, standards, skill levels, corrupting database, differences in different versions).

Eliminates need to “qualify” consultants on technical skills.

Maintains database integrity.

Retains all history.

Avoids reimplementation.

Reduces risk.

No Oracle Application software is changed or customized.

No need for external mapping, data warehouse or reporting to reconcile different businesses.

Make the most of existing resources.

An eprentise Reimplementation Success Story

A global leader in the mining industry needed to consolidate over 25 different charts of accounts into a single global chart of accounts.

They used eprentise FlexField software to percolate changed accounting flexfield code combinations to each subledger of E-Business Suite for setup data and all transactions. All code combinations were changed and there was no on-going reconciliation between old and new charts of accounts.

The results were a standard global chart of accounts, consistent reporting and a simplified financial consolidation process. All historical transactions were changed to reflect the new chart of accounts resulting in operations and reporting that looked as if the company had always been doing business using its new global chart of accounts.

Oracle’s Reimplementation Tools

Oracle provides a number of tools that can help with reimplementation:

iSetup - can migrate functional setups from one E-Business Suite instance to another. During migration, setups can be extracted selectively using filters on setup attributes. Extracted data can be optionally transformed before loading into a target instance.


31

fndload – see the paper, Customization Survival Guide: How to Use E-Business Utilities to Migrate Your Custom Code, by Brad Simmons and Donna Campbell. FNDLOAD can be used to:

transfer Request Groups, move Concurrent Programs, and download and upload Forms Personalizations

migrate Key FlexFields, Descriptive Flexfields, Responsibilities and almost every other FND entity

transfer value set definitions

exp/imp – Oracle’s original export and import utility.

Datapump - For RDBMS Versions 10g and 11g, you can use DataPump’s expdp and impdp utility. This tool is much faster than Oracle’s older exp/imp utility.

DataLoad - DataLoad will load data into any application and contains extra functionality for loading data and setup into Oracle E-Business Suite. A number of loading technologies are provided so that the most appropriate approach can be chosen for the target application. DataLoad will load data via an application's forms, which may be browser-based Self Service forms or core/professional forms, or data can be loaded directly into a database.

SQL Plus - SQL*Plus, the primary interface to the Oracle Database server, provides a powerful yet easy-to-use environment for querying, defining, and controlling data. SQL*Plus delivers a full implementation of Oracle SQL and PL/SQL, along with a rich set of extensions.

Open Interfaces - Open Interfaces refers to a programming interface, usually a database table, that automates the execution of Oracle APIs. You can use the Oracle Integration Repository (iRep) to view all the interfaces in the E-Business Suite in one place.

The E-Business Suite Plug-in - this is an added cost set of tools that supports security, cloning, customization, patching and setup for the E-Business Suite. These tools provide a framework around tools like iSetup, but also offer new functionality, including the ability to document your customizations.


32

Other Third Party Tools That Help Reimplementation

ConfigSnapshot provides several capabilities to assist organizations when reimplementing, including:

Quickly document your existing implementations setups to enable functional teams to determine which configurations should be retained and which are no longer applicable.

ConfigSnapshot’s planning capability enables organizations to design their configurations prior to deploying them to a new environment. Far more flexible than relying on manual documentation methods, it allows you to report flexibly on your plan and also to ensure that the planned setups are correctly configured in the environment itself.


33

ConfigSnapshot’s migration capabilities allow customers to migrate setups across environments/entities.

ConfigSnapshot’s comparison capabilities enable you to ensure that all setups are correctly deployed across environments as the project progresses.


34

Baselines enable you to capture setup at key stages of the project; allowing you to control the changes made during each phase.

Comprehensive security reporting, including segregation of duties, allows you to ensure that users have only the required access to perform their duties


35

Capability Maturity Model

Use the Capability Maturity Model as a framework to simplify and standardize your business processes and hardware.

The Capability Maturity Model (CMM) is trademarked by Carnegie Mellon University and refers to a development model derived from data collected by the U.S. Department of Defense. The model is based on observation rather than on theory.

The CMM provides an effective method to improve the software development process. Eventually, the CMM was applied more generally to business processes.

For this book, our goals can be summarized with the Capability Maturity Model to simplify and standardize business processes using a framework to achieve efficiencies and cost savings. Actually achieving costs savings through Business Process Improvement (BPI) requires hard work to understand the new functionality and the existing business process model. Following this model, technology and process convergence lead to simplification, standardization and shared services.


36

Upgrade Benefits: An Opportunity to Optimize Your Hardware Configuration

Probably the least invasive time to implement a new hardware upgrade is during a software upgrade. You’ll need to test how the operating system works with the new E-Business Suite software anyway, so why not take advantage of some of these benefits:

Migrate to more cost-effective 64-bit Linux servers

Migrate Application Servers to 64-bit hardware to support more users with more addressable memory

Utilize Virtualization to help standardize hardware and software

Implement a SAN with block virtualization capabilities, aka “snapshots” to dramatically improve cloning and backup performance

Take advantage of the “Space-Time Continuum”: If we make copies of completed Apps Tiers before and after the upgrade, and if we have plenty of space to make a backup of the database that we can quickly restore, we can shortcut the iterative process of identifying the patches and patch order, thereby saving significant amounts of time. So, if we have more space, we can save time.

Implement a simplified the Architecture where possible. With a 64 bit database server with 64 bit addressable memory and faster CPUs, there are fewer reasons to require more than one web, forms, and Concurrent Manager server; they can all reside on one box instead of two or three applications servers.


37


38

Upgrade Benefits: Improved Oracle Tools Simplify the Process

Oracle provides a number of tools that simplify upgrading the Applications, including: Real Application Testing, Database Replay, and Maintenance Wizard.

Real Application Testing

Oracle Database 11g introduced Database Replay and SQL Performance Analyzer as part of the Real Application Testing option to enable businesses to identify issues with system changes before production deployment

The Oracle Real Application Testing option includes two solutions to test the effect of system changes on real-world applications, Database Replay and SQL Performance Analyzer (SPA). Database Replay enables you to effectively test system changes in test environments by replaying a full production workload on the test system, to help determine the overall impact of the change. With the SPA, you can assess the impact of system changes on SQL performance by identifying any variation in SQL executions plans and performance statistics resulting from the change.

Database Replay

Database Replay makes it possible to capture a workload on a production system with negligible performance overhead, and replay it on a test system with the exact timing, concurrency, and transaction characteristics of the original workload The Database Replay process can be broken down into the four steps described below: 1. Workload Capture

When workload capture is enabled, all external client requests directed to the Oracle server are stored into compact capture files on the database host file system, while incurring negligible overhead. These files contain all relevant information about the call needed for replay, such as SQL text, bind values, wall clock time, SCN, etc. The workload capture start and end time, as well as criteria for targeted capture (e.g., by user, service, action, etc.) can be specified by the user. The workload captured on Oracle Database Release 9.2.0.8 and higher can be replayed on an Oracle Database 11g release. Workload capture and replay in shared-server environment is also supported.


39

2. Workload Processing

Once the workload has been captured, the information in the capture files has to be processed, preferably on the test system. This processing transforms the captured data and creates all necessary metadata needed for replaying the workload.

3. Workload Replay

Before performing workload replay, the test system has the intended system change applied and database restored to the point in time before the capture started, using various mechanisms such as RMAN backups, Oracle Database 11g Snapshot Standby, Datapump export/import, etc. The replay can be configured appropriately to re-map connection strings, database links, and directory objects to that of the test system. Once replay is initiated, a special client program called the replay client replays the workload from the processed files. It submits calls to the database with the exact same timing and concurrency as in the capture system and puts the exact same load on the system as seen in the production environment. The replay driver automatically re-maps physical locators and preserves sequence numbers or GUIDS during replay. The replay driver is client-agnostic and uses a scalable multi-threaded architecture with support for client estimation and running on multiple hosts. There are various options that are available to control the behavior of the replay, such as to scale up or down the think and login times, and maintain commit synchronization. These are useful for throttling the user call rate to the database.

4. Analysis and Reporting

Extensive reports that encompass both high-level summary and detailed drill-down information in terms of errors, performance and data divergence are provided to help understand how the replay fared in comparison to capture or other replays.

Maintenance Wizard

Maintenance Wizard guides you through the Applications upgrade and code line maintenance process. It helps you reduce upgrade tasks by dynamically filtering the necessary steps based on criteria it obtains from your Applications environment. The result 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.


40

With the Maintenance Wizard, you can:

Automate Patching and Provisioning

Automate Diagnostics and Tuning with the Diagnostics and Tuning Packs for OEM

Automate Change and Configuration Management with the Change Management Pack for OEM

Upgrade Benefits: Use Shared Service Centers to Drive Cost Savings and Increase Information Quality

Where possible, you should consolidate non-revenue generating, administrative tasks into Shared Service Centers. With Shared Service Centers, you can:

Eliminate redundant processes

Utilize self-service

Automate processes

Standardize common business practices to reduce costs

Help create a consolidated view of essential global decision-making information

Enhance the timeliness and accuracy of data. With consistent business processes throughout the enterprise, information can be gathered uniformly, with consistent quality

Services can be shared at many different levels, and shared service centers can exist for different reasons:

General Ledger Centers

Receiving Centers

Inventory Management Centers

Procurement Centers

Many of these centers may be combined into one center.


41

Upgrade Process: The R12 Functional Upgrade Requires Gap Analysis

The R12 Upgrade is not just a technical upgrade, it is a functional upgrade. The functional upgrade consists of mapping new business requirements with new functionality in R12 and determining the differences. This is called gap analysis.

Gap analysis requires superusers/functional analysts to understand the new features of R12 and understand the existing customizations. Gap analysis is the process of aligning the business process with Oracle Applications. The “gap” can be resolved by changing the business process to use the Oracle Applications process or providing a customization to fill the “gap’ between the existing business process and the functionality that Oracle Applications provides.

Filling the “gap” is another term for aligning the business processes with Oracle Applications.

You should align the Business with the Process, and align the Process with Oracle Applications by considering the following:

Application

How has R12 changed?

Is there new functionality that could improve the process model?

Should we change our process to align with Oracle Applications processes?

Do we understand Oracle’s long term strategy?


42

Process

Integrate business changes with Oracle Applications new functionality

Develop new process models. Retire/modify customizations that are replaced by new functionality

Business

Has my business changed?

What are the new business requirements?

What is the long term strategy for the business?

Does the long term business model align with Oracle Applications long term strategy?

Identify business areas that should adopt best practices that may differ from current business practices

Align the Business Model with the Process Model and Oracle Applications

Aligning the business with Oracle Applications can be accomplished by modifying the business to match the process and customizing Oracle Applications to match the process. Most businesses are reluctant to change, and instead prefer to bring the process and applications into alignment with the business, as shown in the following diagram.

Align the process and Oracle Applications to match the business


43

One of the best options is to convince the business to adopt “vanilla” processing and change the business and process to match the functionality provided by Oracle Applications. This works best for small and medium sized businesses, as large business may significantly benefit from customizations.


44

Upgrade Process: Assessments Can Help the Planning Process

In order to better plan for the upgrade, assessments can help estimate the impact and scope of work. There are four major types of upgrade assessments:

Functional – align the business with Oracle Applications

Technical – review patches, tech stack versions, the upgrade path, and performance issues

Customization – review customizations to ensure that they are adequately documented, and to find customizations that can be eliminated as a result of new functionality introduced with an upgrade

Architecture – review hardware and capacity requirements

TruTek detailed assessments typically have three phases: Audit, Investigate, and Report:

The Audit phase of the functional assessment identifies the current issues, documents the “AS IS” processes and documents the “TO BE” processes.

The Investigate phase of a functional assessment is more detailed than the Audit phase and includes functional application tuning and a review of setups, since they can affect performance. The primary goal of the investigate phase is to improve functional processes and to review user defined functions and fast formulas, if present.

The Report phase of the assessment defines the issues, recommends solutions and summarizes process improvements.


45

Functional Upgrade Assessment

The Functional Upgrade Assessment documents the modules in use and modules that are to be implemented as part of the upgrade. This type of assessment identifies business issues and prioritizes business goals to clearly define and set measurable performance targets and prioritize goals.

The Functional Upgrade Assessment should identify the gaps between the current release and the latest certified R12 release to determine the functional, platform, network and operating system gaps. Functional experts must map custom processes from Release 11i to R12. Because of new functionality in R12, existing custom processes may be replaced by new functionality in R12.

This assessment should review application reporting and interface transition issues, and evaluate management controls required, including timing, resources and training issues. Finally, this assessment should recommend an overall upgrade approach (upgrade vs. Reimplementation, the appropriate upgrade path, etc.)

Technical Upgrade Assessment

The technical assessment investigates future capacity requirements, tech stack version compatibility, and patch levels, including CPUs, current issues from log files, current unresolved service requests, and potential issues with the R12.1 upgrade.


46

Customization Assessment

Start by identifying all customizations. In some environments the customizations aren’t well documented and some customizations may have been lost due to previous patching. Check-in all customizations into configuration management. Customizations are easier to customize if you can find them and have some version control.

Determine the customizations that are replaced by new R12 functionality. This requires an analyst that knows the new functionality of R12 and understands the customizations.

Finally, determine the customizations that need to be fixed or added to the upgrade to preserve or extend the process alignment.

Architecture Assessment

The Architecture Assessment investigates the implementation of more advanced configurations, depending on the requirements, including the following:

Shared Disk – SAN, NAS, NFS

Shared disk is required for RAC, for each node to access the same disks. This is also required for a Shared Apps Tier and distributed AD. Shared disks come in three primary flavors: SAN, NAS and NFS.

RAC

Many companies require continuous database operations, and Real Application Clusters (RAC) is a possible solution. RAC can also be used for companies that need to scale quickly. With RAC, you can add another server to the cluster relatively quickly.

The performance issue with RAC is pinging, not the classic disk block pings, but cache block pings across the inter-connect. While cache pings are roughly 100 times faster than disk pings, large volumes of pings can create database waits, queuing, and degraded performance. The best method to resolve this issue is to partition the application, so the data is mostly used in the cache of one server.

RAC is not free and the maintenance of RAC is not free. The necessary hardware environment will have shared disks, probably a SAN; backups and clones must use RMAN.

Shared Application Tier with Distributed Processing

If there are four applications servers connected to shared disks and we run adpatch in distributed mode, each application server can be


47

assigned a range of workers that run patch jobs in parallel, while each server accesses the same files on shared disk. For example,

Start 5 workers on each machine, by running the following command on each application server:

adpatch localworkers=5 workers=20

The following diagram illustrates four application servers, each running 5 adpatch workers. This allows the patch to be applied simultaneously on each application server, and to run the patch more quickly because the workers are run in parallel.

Without shared disk, each patch must be applied separately on each application server. The shared disk will have a path to the software that includes the <CONTEXT_NAME>, the combination of machine name and instance name.

• Parallel Concurrent Processing

Parallel concurrent processing allows distribution of concurrent managers across multiple nodes. Benefits are better: performance, availability and scalability (load balancing).

With parallel concurrent processing implemented with GSM, the Internal Concurrent Manager (ICM) tries to assign valid nodes for concurrent managers and other service instances. When one node is not available, the managers that are defined with PCP fail over to another machine.


48

Most users don’t know how to restart a failed job. Therefore, if a concurrent manager is not set up with PCP, it will terminate running jobs upon failure. Users will see that their jobs have failed and call to request assistance in restarting the job.

With PCP, when a failure occurs, the system can use PCP to automatically restart the concurrent managers that are defined to fail over to another machine. This avoids calls to the help desk and the system administrator.

Hardware Assessment

If the upgrade plan includes buying new hardware, consider migrating from the current 32-bit platform to a 64-bit platform. Reasons to migrate to a 64-bit environment include:

Release 11i doesn’t support running the Application Tier on a 64-bit hardware platform; however, Release 12 does support 64-bit architectures for the Application Tier.

Release R12 supports running the database on a 64-bit operating system, in a split or mixed architecture

There are five hardware platforms supported for Release 12, and all of the platforms support a 64 bit version

There are less memory restrictions on a 64-bit machine because of additional addressable memory

Because of more addressable memory, more users can be supported on each Application Tier


49

MRP and other programs run much more quickly in a 64-bit database

Upgrade Process: Understand the Functional Financial R12 New Features

Integrated Financials

The new bank account and disbursement models facilitate the payment of invoices and other payables out of different operating units, from an appropriate bank account, and with the appropriate intercompany handling.

Intercompany processing is dramatically revised by enhancements in both Financial’s intercompany management and Supply Chain Management’s Enhanced Drop Shipments.

Rather than a GL only system, Financials now links into Receivables and Payables to generate matching and tied documents (configurable though Bill Presentment) and a new reconciliation scheme.

Related SCM products provide transfer pricing modeling and enforcement, inventory consignment (at subsidiaries or otherwise), and tracking of profit in inventory.

Subledger Architecture

A Set of Books (Release 11i) becomes a Ledger with its own Ledger Set, in Release 12.

SLA will return the same accounting as the earlier accounting engine did.

If the MO:Operating Unit was defined in Release 11i, after the upgrade MO:Operating Unit will be set the same.

Key R12 Modules

Modules and new features that are key to the operation of R12 include: Approvals Management, (AME), User Management (UMX), Sub Ledger Accounting (SLA), Governance and Risk (GRC), Multiple Organization Access Control and Advanced Global Intercompany processing.


50

Benefits include the new Subledger Accounting model, XML publishing applied to reports, additional DBI portlets and pages, AR-AP netting, and gross margin analytics in AR.

Subledger Currency Views

Accounting for subledger transactions at the event in a standard manner with a single accounting engine allows us to provide multiple accounting representations for a single event.

A purchase can be simultaneously accounted for an increment to inventory for your US GAAP or IAS/IFRS accounting, and as a debit to the P&L for your national compliance accounting.

The accounting entity involved can maintain multiple ledgers, each complying with a different set of accounting principles – we call them ‘accounting methods’, and, of course, the transactions and ledgers can be valued and denominated in different currencies.

You can now generate currency views of a ledger at the subledger transaction, general ledger transaction, general ledger balance, or consolidation workplace levels.


51

Multi-Org Access Control

Multi-Org Access Control (MOAC) enables companies with a Shared Services operating model to efficiently process business transactions by allowing them to access, process and report on data for an unlimited number of operating units within a single applications responsibility. This increases the productivity of Shared Service Centers, as users and processes no longer have to switch applications responsibilities when processing transactions for multiple operating units at a time.

Data security and access privileges are still maintained using security profiles that now support a list of operating units.

The MOAC feature primarily uses two features namely 'Fine-Grained Access control' and 'Application Context'. Combined known as Virtual Private Database (VPD). Fine-grained access control allows you to build applications that enforce security policies at a low level of granularity (such rows/columns in table). Application Context provides a way to define, set, and access attributes that an application can use to enforce access control specifically, fine-grained access control . Please note Multi-Org Access Control replaces usage of CLIENT_INFO(Org Context) function in Multi-Org Architecture.

Steps to Setup MOAC (from My Oracle Support Note 414003.1):

Define Operating Units(Optional) (Using form function 'Define Organizations')

Define Security Profile (Using form function 'Define Global Security Profile')

Assign MO: Security Profile

If both 'MO: Security Profile' and 'MO: Operating Unit' are defined at a responsibility level, then 'MO: Operating Unit' will be ignored and 'MO: Security Profile' will be effective. MO:Operating Unit is preserved through the upgrade, so if it was set in the previous release, it will be set in Release 12.

If you don’t want to implement MOAC features in Release 12, no additional setups are required.


52

Responsibility-level profile options will apply to all OUs of the security profile.

Other new features include improvements in Multiple Reporting Currencies, E-Business Tax and the Payments modules.

Upgrade Process: Build a Strong Upgrade Team

The Upgrade Team is not a democracy.

The upgrade project management should not be shared. The upgrade team is composed of functional and technical representatives from the business and report to the upgrade project manager.

Dedicated Team Members

The Upgrade Team should be independent from daily operations. Team Members should be selected from the business by the upgrade project manager.


53

Upgrade Roles and Responsibilities

Technical Upgrade Responsibilities

The DBAs and Developers are in charge of technical testing and should try to improve the technical foundation of the hardware and software.

The DBAs perform the technical upgrade and the developers modify and implement the new customizations and extensions.

Developers should work with the functional analysts to understand the existing customizations. The functional users should work with the developers to help them understand how new requirements affect the existing customizations.

Much of the developer’s work, coding and testing, is done in advance of the upgrade weekend. During the upgrade weekend the developers have 4-6 hours to implement and test customizations. Developers may need to practice rapidly implementing the customizations.

DBAs, Developers, Functional Analysts and Testers should all try to reduce downtime.

Consider having two upgrade DBAs for the project; 1 to handle cloning, and 1 to handle customizations. While you don't need all these DBAs during the whole upgrade project, they need to be proficient at their section of the work. Cloning can be complex and may have cloning tasks that are specific to your environment. If you are working with consultants on the upgrade, it is best if one of your internal employees handles this part of the work.


54

If you have customizations, usually the developers can't (and probably shouldn’t, for separation of duty reasons) implement customizations; they need a DBA to handle this. On upgrade weekend, dealing with customizations is a significant task. When the DBAs are at the end of their rope, you need someone awake and responsive to handle the customization tasks. Otherwise, an overworked, overtired DBA may make mistakes.

Finally, you need two DBAs that can tag team effectively during the upgrade and keep the upgrade running. Often, one DBA will be tasked with email and communications while the other DBA works through the upgrade tasks. Sometimes, they may even get some sleep.

Functional Upgrade Responsibilities

Functional responsibilities include testing the business use of Oracle Applications. In order to be an effective functional analyst, you must understand the “AS IS” business process model and the “TO BE” process model.

Functional analysts should document the gap between the business process and the Oracle Applications processes, and:

align the business and Oracle Applications

understand existing customizations

understand how new requirements affect the customizations

investigate, improve and implement setups

train the users – for example, iProcurement

reduce downtime

verify the upgrade

Upgrade Project Manager Responsibilities

Manage the following managers:

Development Manager – Customizations

DBA Manager – Technical Upgrade

Systems Manager – Hardware Upgrade

Functional Superusers – Develop Process Alignment

Functional Business Process Experts


55

Testing Manager

Report progress of priorities as established by the Steering Committee

Steering Committee

The Steering Committee is quite often established as a democracy with the CIO and CFO having veto power.

The Steering Committee has some very important responsibilities: maintain executive support, supervise the gathering of user requirements, document upgrade success factors, and prioritize goals/issues. The Steering Committee should also measure progress against user success factors and report to the executive team.

The Test Manager can work with the Steering Committee to organize users to execute test scripts, and document user’s issues.

Upgrade Tactics

Release 12.1 upgrades are complex, long running exercises filled with thousands of tasks that must be done consistently each time. Because of the massive opportunities to make mistakes, a strategy that minimizes backup/restore time is absolutely necessary. You need to minimize the amount of time and risk required to restore the old database and application tiers. You also need to simplify the tasks and minimize the time required to implement customizations.

As you plan your upgrade, you should assume 5-10 iterations of the upgrade will be necessary to fix the issues encountered. As you approach the upgrade, consider these tactics:


56

1. Minimize the time for each upgrade for everyone involved.

2. Simplify the R12.1 upgrade tools, data, project management, and architecture.

3. Consider the R12.1 upgrade to be an iterative process: measure, evolve, and optimize as you iterate, tracking changes carefully as they are made.

4. Build a strong foundation for the technical team:

o Maximize IO bandwidth and minimize IO latency.

o Use a machine that is faster than the current production system. Use another machine for testing and training.

o Avoid doing an “in place” upgrade.

o Give the Applications Tier and the Database Tier a large amount of disk space.

5. Build a strong foundation for the functional team:

o Ensure adequate testing – develop and execute test plans.

o Consider your testing methodology for the R12.1 upgrade. Do you need Technical, Functional, and Load Testing?

o Include training both before and after the upgrade, and provide exposure to an R12 system and tools early in the upgrade process.

Success Factors for Upgrade Project Managers


57

Project managers can feel some satisfaction, when they allocate the money and time required for the upgrade. However, without the right skills the upgrade will probably fail. Even with all the right skills, issues with teamwork can cripple the upgrade.

Time and Money

Companies whose staff is experienced with upgrades and has an efficient testing process may be able to complete the upgrade in as few as three months. Typically, upgrades take six to nine months and very large upgrades (number of users and number of customizations) may take longer than one year.

An upgrade might cost:

$1000 per user + $500 per iUser with $150K minimum

(an iUser is a user of iExpense, iProc, OTL, etc)

20 full users + 400 iUsers = $220,000

Upgrade costs vary drastically depending on the number and type of customizations. This estimate typically includes customizations.

This estimate does not include implementing new modules, hardware migration, etc.

Categories and Range of the Percentage of the Total Budget

Budget Average Budget Typical $400,000 Upgrade Budget

Training 10% - 20% 10% $40,000

Functional Analysis 20% - 40% 25% $100,000

Technical Upgrade 10% - 30% 25% $100,000

Customizations 0% - 50% 20% $80,000

Testing 15% - 30% 20% $80,000

The range of values is to allow for different levels of proficiency that may exist in an organization before the upgrade begins. For example, if the testing process in your company is well established and accurate, the minimum percentage of 15% of the budget should be acceptable.


58

Customization Costs

Customization costs can inflate the lifecycle effort cost by at least 70%, when compared to non-customized systems. The actual complexity and required effort cost may be much higher

Skills

Organizations and their employees understand their business processes better than most external consultants. However, companies usually upgrade and/or consider business process changes relatively infrequently, for example, every five years.

Consultants that focus on upgrades and implementations may not understand the detail of your business processes as well as your functional superusers, but they understand the new features of Release 12 and the resulting consequences for your business. They can work with your experts to efficiently identify existing and future functional gaps between your business process and the process Oracle Applications uses. Good consultants have exposure to many clients and can use this knowledge to suggest best practices based on similar clients.

Identify Skill Gaps in Your Upgrade Team

Your upgrade team should be capable and experienced with upgrades and should understand the new functionality of R12.1. The following four primary skills are critical to the success of your team:

1. Testing

2. Functional Analysis

3. Customizations

4. Technical Upgrade

If your team lacks expertise in these skills, often the best way to get through an upgrade is to supplement your staff with upgrade experts; consultants who have been through several upgrades who can fill gaps in expertise and mentor and guide your teams to use established best practices. Upgrade experts understand the R12.1 new functionality and they can efficiently integrate your company’s business processes and customizations with R12 and can help improve your testing processes and increase the probability of success for your upgrade.

An additional way to fill gaps in expertise is to have functional consultants conduct formal training on-site, using client specific environments. This can reduces redundant learning curves that result


59

from multiple consultants providing new features training separately from the consultants that are providing the R12.1 gap analysis.

Teamwork

The upgrade will not succeed without TEAMWORK.

Communication is essential.

The upgrade team is not intended to be a democracy, but unwilling team members can slow down and cripple otherwise viable upgrades. The upgrade manager is responsible for “picking” the team members. He is also responsible for firing disruptive team members and replacing them with the best available team member. If the Steering Committee can’t find a mutually agreeable internal candidate, sometimes a neutral external consultant can be the best choice.

Teamwork is the concept of people working together cooperatively, as in a sports team. Many large, ambitious projects require that people work together, so teamwork has become an important concept in organizations. Industry has seen increasing efforts through training and cross-training to help people to work together more effectively and to accomplish shared goals, whether colleagues are present or absent.

Team Obstacles

There are a number of issues that can decrease a team’s effectiveness:

Infighting - Effective teams don't have to be made up of people who like each other, but there must be mutual respect. Without respect, misdirected energy can turn to bickering and undermining colleagues. Team members must be willing to set aside petty differences

Shirking Responsibilities - When members avoid taking responsibility for both running of a group and for specific assignments, a team becomes a "pseudo team"; i.e., a team in name that consistently underperforms.

Lack of Trust - If trust is lacking, members are unable to depend on each other.

Critical Skill Gaps - When skills are lacking, teams flounder, members have trouble communicating with each other, destructive conflicts result, decisions aren't made, and technical problems overcome the group.


60

Minimize Risk

There are a number of steps that a team can take to minimize risk:

Improve Testing Proficiency - Test scripts should be run after each patch or clone in order to ensure accurate patching or cloning steps. If testing is not efficient, practice testing more often until critical tests can usually be completed in 4-6 hours.

Enable Fast Backup and Restore - with block virtualization or snapshots. The key to fast, efficient upgrades is to do several upgrade iterations to identify and resolve critical issues. Cloning can become a major bottleneck during test upgrades, and especially during the production upgrade. The ability to restore in a few minutes saves time and money when compared to 4-8 hour restore times.

Independent DBA and Developer Instances - Let the DBAs and Developers practice their piece of the upgrade in independent environments, separate from DEV or TEST.

Reduce Scope - Decouple other projects from the upgrade: new modules, fix customizations, hardware migration, and new business processes.

Load Test - to avoid career limiting, “Go Live” capacity issues, perform load testing if there is any question about system capacity. For example, if the upgrade includes implementing Oracle Time and Labor for a large number of employees - more than 1000 - then load testing is highly recommended.

The Team Must Recognize Competing Priorities

An upgrade is rarely just an upgrade… it is tempting to pile on additional changes in order to accomplish as much as possible. Your team may have to decide about whether to include hardware migrations, data cleanup and data archival, new modules, and customizations in the upgrade plan.

Hardware Migrations are generally outside the scope of normal upgrades, however, if well planned, hardware migrations can be accomplished with a little extra time and without too many extra testing cycles. Hardware migrations, depending on the size and whether disk “snapshots” are in use, can be completed with one extra day.

Data cleanup and data archival are two tasks that should be on-going. It is especially important, in order to reduce the downtime, to perform data cleanup and data archival before the upgrade begins. Data errors


61

discovered during the upgrade should be investigated for possible bad processes and resolved.

Implement new modules either before or after the upgrade as separate projects. In some cases, it makes sense to implement new modules during the upgrade.

Customizations that have changed because of an upgrade must be migrated. When possible, use a separate project before the upgrade to investigate the feasibility of migrating customizations to a Service Oriented Architecture.

Success Factors for Functional Users

Functional users of Oracle Applications may have a different view of success than the managers and technical staff. The functional staff may declare upgrade success even though from the management or technical point of view that upgrade may not have been a complete success. This is because the functional, technical and managerial success criteria may not be the same. Functional users should expect to gauge their success on their ability to accurately determine the gap analysis, and work with developers to make sure the customizations appropriately address the functional gap. The following diagram illustrates the functional view of success.

Gap Analysis

Gap analysis requires superusers/functional analysts that understand the new features of R12.1 and understand the existing customizations. Gap


62

analysis is the process of aligning the business process with Oracle Applications. The “gap” can be resolved by changing the business process to use the Oracle Applications process or providing a customization to fill the “gap’ between the existing business process and the functionality that Oracle Applications provides.

Further investigate the functional gap by examining the following:

Reasons for the change and areas that benefit from new functionality

Functionality that is temporarily disabled or has been made obsolete

Changes to user interfaces, terminology or concepts, and menu options

Known Gaps

In our experience, the following gaps are encountered in typical R12 upgrades. By raising awareness of these gaps, planning for them, and proposing cost effective add-ons, a painful upgrade experience can be avoided entirely.

Financial Reporting Gaps

With an R12 upgrade, Client ADI is replaced by Report Manager for the publishing of FSGs into Excel. Client ADI used to allow users to produce ad-hoc FSG reports, but the new Report Manager was designed for storing point-in-time reports. Report Manager was not designed as an ad-hoc enquiry tool and does not allow users to easily define or modify reports. Users submit ad-hoc FSG or standard reports from the Report Manager, but they must re-create each template in a special editor before its first use.

Also, while FSG reports are still published to Excel, HTML, PDF and text formats, submitting an FSG report from R12 becomes a five-step process, which increases report submission time compared with Client ADI. For complex reports, users relate that R12 submission takes up to five times longer per report than with Client ADI. Reports must be saved in a repository, where chronological instead of alphabetical storage makes access to recent reports difficult and counterintuitive. Clearing out reports is also time consuming and requires running a batch job to delete old reports.


63

Drill Down Restrictions

Client ADI used to allow drill down to transactions for amounts in an FSG report published to Excel. The drill down feature displays journal entries associated with the amount queried and supports further drilling to related sub-ledger transaction details.

R12 only supports account analysis and drill down for reports published through the “Account Analysis and Drilldown” function in Report Manager. Many users have found this function cumbersome and report an increase in time required for viewing data. Sorting and searching data are also time consuming and limited in scope.

Limited Chart of Accounts Access

With Client ADI, users had a graphical view of the chart of accounts (COA) hierarchy. This feature allowed users to understand and traverse the structure of each segment in the COA, which was especially useful for new employees.

The graphical COA was replaced by a Java-based form in the R12 GL module that is now only accessible by system administrators and designated business analysts. For the feature to be accessible to all users, the form must be moved to an unrestricted area within the GL menu.

MS Word Becomes the Report Layout Editor

To produce ad-hoc reports without Report Manager, Oracle users can submit a “Publish FSG Report” request via the standard request submission form. While this method does allow users to produce any FSG report, the report layout templates used are built with Microsoft Word and do not offer the same flexibility as an Excel editor. Another complication is that all templates built using an Excel editor must be rebuilt in Word to use this report creation method.

Recommended Add-on Products

Excel-based Reporting Alternatives

To fill the Reporting Gap from losing Client ADI with R12, organizations have turned to Excel-based reporting tools like GL Wand from Excel4apps. An Oracle Validated Integration solution, GL Wand delivers real-time GL data via direct link between Oracle and an Excel front end, which cuts many steps from the report creation process – even beyond Client ADI. Companies using Client ADI have found that


64

Excel-based GL Wand makes an attractive option, both from a price and user acceptance standpoint.

Because finance users have strong Excel skills, they easily create and modify ad-hoc reports in just minutes through the familiar Excel interface in GL Wand, without programming support. Reports are similar to those they are accustomed to from Client ADI, yet the process is much faster that with either Client ADI or the new Report Manager.

GL Wand’s real-time results are obtained more quickly than with FSGs or boxed Oracle reports, allowing users to work more efficiently. With this Excel-based reporting tool, users can access up-to-the-minute GL data.

Finance users can also drill into subledger transaction details in just a mouse click with GL Wand, which utilizes Oracle’s security settings to maintain appropriate data accessibility. They can quickly view set-up information relating to the GL, including the COA and its hierarchies. Users report that submitting ad-hoc reports that took 15 minutes with Client ADI and 45 minutes with Report Manager take less than five minutes with GL Wand, leaving more time for valuable analysis and less time for frustration.

The IT staff also benefits from GL Wand on many levels. The software installs quickly with minimal IT intervention, and users typically perform upgrades. IT is also less burdened with programming required for reports, because finance users are self-sufficient in running their own queries and creating their own reports. For organizations already invested in customized FSG reports, a GL Wand conversion tool easily converts existing reports into Excel.

Overall, it is important for users to take into account the effects of an Oracle EBS R12 upgrade, or even reimplementation, on the GL reporting process. Understanding these effects and identifying available solutions like GL Wand can not only satisfy the GL reporting requirements of finance users without impacting IT, but also improve financial reporting processes altogether. An intuitive product like GL Wand can easily be trialed with minimal effort during an upgrade project, validating the expected benefits prior to purchase.


65

Customizations

Customizations and Modifications can help align the business with Oracle Applications.

Customizations can save the business money by filling critical gaps in functionality and allowing the business to function more efficiently. However, the design, implementation, maintenance and upgrade of customizations are neither cheap nor painless.

In many cases, new functionality that is standard in a newer release of Oracle Applications may replace some customizations. It is primarily the responsibility of the functional analyst to identify, document and eliminate customizations that are replaced by seeded functionality.

All customizations should be identified and documented. Some customizations may be able to be migrated to Service Oriented Architecture (SOA) and provided as a web service.

There are two basic flavors of Oracle Applications:

1. Out Of The Box, OOTB or non-customized, also known as Vanilla. Vanilla assumes that OOTB processes will work at least 80% of the time. Vanilla can be effective because the focus is on the true gaps that require customization. Gap analysis is more effective because the scope is narrower and scope creep will be less.


66

2. Customized Oracle Applications. There are 19 different types of customizations, modifications, and extensions. Vanilla Applications may have modifications and extensions but will have very few customizations (objects that may be replaced during upgrades or patching).

Customized Oracle Applications assumes that more than 20% of the code will be custom. This requires analysts that understand the current and future business processes. This can require significant time spent understanding current process flows. Abstract thinking required for detailed gap analysis can be difficult for inexperienced upgrade analysts and lead to excessive scope creep.

Simplification and alignment are more difficult without Customizations.

Cumulative Business Value of “Small” Business Productivity Improvements

Even small improvements in business process performance can yield large business savings over a 5-year period.

This example illustrates how 1,000 employees over a 5-year period with a 2% improvement per worker results in $8 million in savings over 5 years. This equates to $400 million in labor costs.

Assumptions

Number of employees 1,000

Avg. Annual Fully Burdened Cost/Employee $80,000

Employee Hours Worked per Year 2,000

Time Frame (Years) 5

Small improvements can yield large dividends over time. However, as the size of the operation decreases, the percentage improvement must increase in order to make the customization worth creating and maintaining.


67

Cost - Benefit Analysis for Business Process Improvement for Smaller Implementations

In the following example of a small implementation, the initial implementation cost is $300,000. With annual operating costs of $1 million, the business was able to implement business process improvements that lowered operating costs by 10%. Over five years the business saved $500,000.

The customizations cost an additional $60,000 per year to maintain, because of patches that affect the customizations.

In the fifth year the business completed an upgrade. The five year total costs are $250,000 for the customizations.

However, in this scenario the business was able to implement business process improvements that lowered operating costs by 20%. Over five years the business saved 1,000,000.

The customizations cost an additional $60,000 per year to maintain, because of patches that affect the customizations.

In the fifth year the business completed an upgrade. The five year total cost savings are $250,000.

Annual Operation Costs 1,000,000:


68

While cost savings is relative, this example illustrates the value of customizations in organizations that can effectively design and implement business process improvement and integrate those improvements with Oracle Application by using customizations.

Success Factors for Technical Upgrade Managers

The technical view of success depends on applying the correct patches in the right order, installing and configuring new hardware, and


69

implementing customizations that satisfy the functional gap requirements.

Patches

Getting the right list of patches in the right order for compatible hardware is one of the more important tasks. the little r12.1.3 upgrade guide and the little r12.1.3 project plan have a list of all the patches that we’ve encountered in our upgrade classes and consulting engagements, in the order they should be applied . The following section explains the new upgrade patch types that have been introduced since Release 11.5.10.2.

Upgrade Patch Types – Release 12.0 Critical Patch Collections (CPCs), Oracle E-Business Suite Pre-install Patches, Financials RPCs, Generic Data Fixes (GDFs), CPUs, PSUs

Release 12.0 Critical Patch Collections (CPCs)

Oracle Financials Release 12.0 Critical Patch Collections (CPCs) are consolidated critical patches that all Release 12.0 Oracle Financials customers must apply to ensure proper operations of their systems. CPCs are specifically targeted for Oracle Payables and Receivables, and include dependent fixes for Subledger Accounting, Tax, and Payments. See MOS Doc. ID: 557869.1, EBS: R12 Oracle Financials Critical Patches for links to the latest Critical Patch Collections (CPCs).

Advantages of applying CPCs over one-off fixes and RUPs are as follows:

CPCs are fully quality assured against current RUP levels. Individual one-off patches are not.

CPCs are consolidated and only contain critical patches that apply to broad customer usages. They are smaller in footprint and therefore much easier to apply and uptake than RUPs.

CPC Readmes have detailed business and functional information about the fixes included. Customers can leverage the Readmes to determine impact and testing required for specific process flows and software components involved.

For the Release 12.1.3 upgrade, the CPCs are applied after you install Release 12.1.1 with RapidWiz.


70

Oracle E-Business Suite Pre-install Patches

According to MOS Doc. ID: 1448102.1, Oracle E-Business Suite Pre-install Patches Report [Video], “The Oracle E-Business Suite Pre-install Patches Report provides a list of essential patches that you must apply in pre-install mode before upgrading from Release 11i to Release 12.1. This report serves as a single point of reference for upgrade-related patches that can ONLY be applied prior to running the main upgrade driver for Release 12.1. These pre-install patches help you avoid certain upgrade script failures, upgrade performance issues, and data corruption and upgrade integrity issues.”

These patches are merged with the R12.1 EBS Consolidated Upgrade Patch 1 (CUP1), Patch 7303029. The patchlist may be updated monthly by Oracle, so you should re-check the list periodically during an upgrade.

Recommended Patch Collections (RPCs)

See MOS Doc. ID: 954704.1, EBS: R12.1 Oracle Financials Recommended Patch Collection (RPC) for links to the latest recommended patches by Oracle Development after the EBS 12.1 was released.

Oracle E-Business Financials Recommended Patch Collections (RPC) for R12.1.3 are consolidated critical patches that all Release 12.1 Oracle Financials customers must apply to ensure proper operations of their systems. CPCs are specifically targeted for Cash Management, Collections, E-Business Tax, Financials for India, Fixed Assets, General Ledger, Internet Expenses, iReceivables, Loans, Payables, Payments, Receivables, and Subledger Accounting.

According to MOS Doc. ID: 954704.1, the RPCs are created with the following goals:

Stability: Address issues that occur often and interfere with the normal completion of crucial business processes, such as period close--as observed by Oracle Development and Global Customer Support.

Root Cause Fixes: Deliver a root cause fix for data corruption issues that delay period close, normal transaction flow actions, performance, and other issues.

Compact: While bundling a large number of important corrections, we have kept the file footprint as small as possible to facilitate uptake and minimize testing.


71

Reliable: Reliable code with multiple customer downloads and comprehensive testing by QA, Support and Proactive Support.

If a RPC becomes available after you complete your upgrade, you should research the RPC and consider implementing it at some point to your environment.

Generic Data Fixes (GDFs)

Generic Data Fixes (GDFs) are patches created by Oracle Development to fix data issues caused by Bugs/Issues in the Application Code. See MOS Doc. ID: 1360390.1, R12: Master GDF Diagnostic to Validate Data Related to Invoices, Payments, Accounting and Suppliers [Video]. Also see MOS Doc. ID: 874903.1, What is a Generic Datafix Patch (GDF) and what GDFs are available for Payables? [Video].

Note that Oracle includes an important point in MOS Doc. ID: 1360390.1, R12: Master GDF Diagnostic (MGD) to Validate Data Related to Invoices, Payments, Accounting, Suppliers and EBTax [VIDEO]:

IMPORTANT: In conjunction with the diagnostic described in this note, R12.1 customers should review the notes indicated below which describe the Recommended Patch Collections (RPC) for related products. The vast majority of the data integrity issues detected by this diagnostic could be proactively avoided by applying the RPC's for these products:

Doc ID 1397581.1: R12.1: Payables Recommended Patch Collection (AP RPC)

Doc ID 1481235.1: R12.1: E-Business Tax Recommended Patch Collection (ZX RPC)

Doc ID 1481221.1: R12.1: Payments Recommended Patch Collection (IBY RPC)

Doc ID 1481222.1: R12.1: Sub Ledger Accounting (SLA) Recommended Patch Collection (XLA RPC)

Note that the list of MOS documents may change as RPCs evolve, so check MOS Doc. ID: 954704.1, EBS: R12.1 Oracle Financials Recommended Patch Collection (RPC) to track the RPCs.

Critical Patch Updates (CPUs)

A Critical Patch Update (CPU) is a collection of patches that address multiple security vulnerabilities. It also includes non-security fixes that are required (because of interdependencies) by those security patches. Critical Patch Updates are cumulative, except as noted, but each advisory describes only the security fixes added since the previous Critical Patch Update. Thus, prior Critical Patch Update Advisories

https://support.oracle.com/epmos/faces/ui/km/DocumentDisplay.jspx?id=1397581.1





72

should be reviewed for information regarding earlier accumulated security fixes.

Critical Patch Upgrades (CPUs) are released quarterly. When you upgrade to Release 12.1, you should plan to apply the latest available CPU. You should look for the latest CPU on My Oracle Support and add it to your upgrade plan. We recommend applying the CPU patches on another weekend following the upgrade. However, if time allows on the R12.1 upgrade weekend, it is possible to apply the latest CPU.

Patch Set Updates (PSUs) - Patch Set Updates (PSUs) are database patches. The PSU strategy is to deliver low-risk, high value content that has a limited scope and is thoroughly tested. This new type of patch collection was introduced in July, 2009. See My Oracle Support Knowledge Document 854428.1, Intro to Patch Set Updates (PSU) for more details about PSUs.

According to My Oracle Support Knowledge Document 854428.1, Intro to Patch Set Updates (PSU):

Patch Set Updates (PSUs) are proactive cumulative patches containing recommended bug fixes that are released on a regular and predictable schedule. PSUs are on the same quarterly schedule as the Critical Patch Updates (CPU), specifically the Tuesday closest to the 15th of January, April, July, and October.

The Patch Set Updates include a Cluster Ready Services (CRS) patch. Like the Database server patch, the CRS patch is a well-tested, low-risk patch of recommended fixes.

Use Patch Wizard from Oracle Application Manager (OAM)

The E-Business Suite includes a tool called Patch Wizard that is part of Oracle Application Manager (OAM). You can use Patch Wizard to help you determine if there are available recommended E-Business Suite patches. Patch Wizard will even automatically download them, which is easier than locating the patches through My Oracle Support and downloading them from there. While Patch Wizard does have its flaws – it does not currently, for example, locate prerequisite patches – it does make the research effort less painful and does find a good percentage of patches.

We use Patch Wizard in two critical areas of the upgrade, for the Release 11i Mandatory Extended Support Patching Exercise, and after upgrading to Release 12.1.3, to find additional patches that have yet to be uncovered.


73

Use Patch Wizard for the Release 11i Mandatory Extended Support Patching Exercise

As part of the preparation for upgrading to Release 12, we recommend that E-Business Suite clients bring their Release 11i environments up to the standards documented in My Oracle Support Doc. ID: 883202.1. This document describes a substantial collection of patches needed to ensure that Oracle Support will provide Extended Support for your Release 11i environment while you are working to upgrade it to Release 12.

Meeting the Extended Support requirements is no small feat – most customers have to apply dozens of patches, many of them with daunting pre-requisites and post application steps. If you’ve lagged behind on maintaining your Release 11.5.10.2 environment, the Mandatory Extended Support patching effort will take several weeks, and will require considerable testing.

There are two ways to figure out what patches to apply – you can build a spreadsheet and use MOS Doc. ID 883202.1, which tells you all the patches that need to be applied across all modules, or you can use Patch Wizard to tell you what it thinks you should apply. We’ve covered the details in our other book, the little r12.1.3 upgrade guide, about how to set up Patch Wizard so it limits its recommendations to just those modules that you have licensed, rather than all 200+ modules.

We’ve applied the Release 11i Mandatory Extended Support Patches both ways, using the MOS document and using Patch Wizard, and we’ve concluded that we prefer using Patch Wizard. The tool is not as streamlined for Release 11i as it is for Release 12, but it still gets the job done.

Use Patch Wizard After You’ve Upgraded to Release 12 and Think You’re Done, But, Sadly, Find That You are Not

We recommend that when you finish your upgrade to what you believe is the latest version of 12.1.3, with all the patches and Family Packs identified from patchsets.sh, our other book, the little r12.1.3 upgrade guide, and your own research, you should run Patch Wizard again to see if additional patches are found. When we ran a Vision upgrade in February, 2011, Patch Wizard identified 78 more patches above and beyond everything we found for 12.1.3.

Note that Patch Wizard may require patches for both Release 11i and Release 12.


74

Other Patching Reports

As well as the patching reports provided with Patch Wizard you can use enhanced reports provided by other vendors. For example, ConfigSnapshot includes reports that show the functional name for affected components, such as forms and reports, making it easier for the team to determine which areas should be the focus of testing.

The Patching Process

The patching process can be time consuming, because of the time it takes to perform backups, restores and clones. Applications patches are generally not reversible; a restore from a backup is usually the only viable mechanism to fix a problem with the system after a patch has been applied. Therefore, before patching, backup the environment.

Cloning is another process that can be time consuming. The beginning of every upgrade should start with a clone from the production system to the new upgrade hardware. If cloning takes 16 hours, it will be a long weekend. Hopefully, your clone will only take two to four hours to complete.


75

The Testing Process

The testing process extensively uses backups, restores and clones to recreate test environments from upgraded instances.

Create Custom Development Upgrade Plan

Customizations that exist in the current system need to be documented. Upgrade developers should define steps to re-apply the customizations in the new Release 12.1 system. Some customizations, such as reports, may more easily be created in XML Publisher rather than Oracle Reports. Developers may need additional training in new technologies.

Technology components that may have customizations:

Workflow

Forms

OA Framework - JDeveloper

Reports

XML Publisher

Tasks to be included in the development upgrade plan:

Remove old obsolete code before the upgrade

Check invalid objects for source of old code


76

Identify columns that become obsolete during the upgrade

Create a script to remove obsolete columns

Developers may need to enhance their skills with OA Framework and XML Publisher to stay current with the technology changes in Release 12.

How to Upgrade Customizations

Customizations are sometimes referred to as CEMLIs, the software framework for Customizations, Extensions, Modifications, Internationalizations, Localizations, and Integration. There are 19 classes of extensions and Oracle has published guidelines for developing and implementing custom extensions to Oracle Applications.

The CEMLI Upgrade includes determining the technical impact of Oracle E-Business Suite Release 12.1 on CEMLIs, upgrading CEMLIs to the new technology stack, and retrofitting CEMLIs for compatibility and usability with Oracle E-Business Suite Release 12.1. The steps to the CEMLI Upgrade are:

Identify all customizations

Check-in all customizations into configuration management

Determine customizations that are replaced by new R12.1 functionality

Re-code customizations

Prepare Customization Upgrade Implementation Plan

Prepare Customization Configuration Management

Modifications are defined as customizations that survive upgrades.. Personalizations are an example of a modification. Extensions include reports and interfaces that are not replaced by new code from the upgrade, because these extensions are custom and not named the same as any seeded object.

Extensions and Modifications usually survive an upgrade, but changes to underlying tables and objects will certainly affect this custom code.

Customizations are defined as custom code objects that will be replaced by new objects during the upgrade. Custom workflows are a good example of code that will usually be replaced during an upgrade.


77

Personalizations are an example of modifications that should not be replaced or altered by the upgrade, but again, if a table upon which they rely is changed, the personalizations will likely have to be revisited.

The diagram below illustrates the relationship of customizations, modifications and extensions to the upgrade.

Obsolete Technology Components with Release 12

Another consideration as you plan your upgrade is that several technology components that were used by the Applications are now obsolete. Your developers will need to determine if any of the following components are currently being used, whether their functionality is needed in Release 12, and then determine how to work without them. This may require additional customizations.

mod_plsql

If you have custom development on mod_plsql, you should migrate your Web pages to Oracle Application Framework.

Oracle Reports Server Reports

Convert the reports to Oracle XML Publisher.

Convert the reports to Oracle Application Framework.


78

Run the reports through the Concurrent Manager.

Oracle Graphics Integrations with Oracle Forms

Convert both the form and the chart to an Oracle Application Framework-based application.

Convert the chart to an Oracle Application Framework-based page that can be launched from Oracle Forms.

AK Mode

If OA Framework-based pages have personalizations in the AK repository, then during the upgrade from Release 11i to Release 12, all custom personalizations will automatically be migrated from AK to MDS, if the AK and MDS repositories are in the same database instance.

If AK/ICX Web Inquiries were used in Release 11i, use the Oracle Application Framework Search feature to recreate personalizable search regions.


79

Joining Functional and Technical Views

If we join the functional and technical views of the upgrade below on customizations, we get the following unified view of the upgrade:

Since the customizations the functional users have defined is the code implemented by developers, we should be able to superimpose the customization object to illustrate the relationships between the three primary perspectives.


80

Upgrade Success Without Customizations

It’s obvious that upgrades without customizations are easier. The area of the intersections is greater in the following example without customizations, than in the earlier example that has customizations. This illustrates that the upgrade has a higher probability of success without customizations.

Tools of Choice for Rooting Out Customizations

One of the hot topics at every E-Business Suite conference that we attend has to do with customizations. The process of determining what customizations have been made and then deciding what to do about them is a challenging one. We looked at the E-Business Suite to see if there were tools that might help with customizations, and found a few, and we also looked at third party vendors to see if they had any options.

One tool that we like is Oracle’s EBS Data Model Comparison Report, which is described in Steven Chan’s Identifying Data Model Changes Between EBS 12.1.3 and Prior EBS Releases and in MOS Doc. ID: 1290886.1, EBS Data Model Comparison Report Overview. For those of you who are upgrading from Release 11.5.10.2 to Release 12.1.3, this tool will list the database object definition changes between the two versions.

Of course, if you’ve been consistent in keeping your customized reports and forms in a $CUSTOM_TOP area, then that will help. But there are other types of customizations that are not so easy to discover. Can you

http://blogs.oracle.com/stevenChan/2011/02/ebs_data_model_1213.html

http://blogs.oracle.com/stevenChan/2011/02/ebs_data_model_1213.html


81

determine if your menus have been customized? How about your responsibilities, your profile options, or your value sets? To help in that area, we’re now using 2e2’s ConfigSnapshot.

ConfigSnapshot identifies and documents configurations and configuration differences in the E-Business Suite – over time, across instances, entities and even versions. Key features include:

Ability to automatically generate BR100 style configuration documents (modules and technical development work)

Configuration baselines and built in planning capability allow you to manage the introduction of enhancements and the setup of mandatory new features

Clearly identify your configuration settings separately from the Oracle seeded values

Directly compare configuration settings of the Oracle modules and technical components across environments, operating units, sets of books, inventory orgs, etc.

View patch impact, which makes it easy to focus testing on actual changes introduced

Identify upgrade impact – reduce risk and uncertainty (shows any effect to your existing setups, new/obsolete data fields, new seeded data, table changes, etc.)

Review and track key Oracle licence compliance metrics

Identify and track customizations

Audit & Compliance support – user access control/ visibility, configuration change tracking, etc.

Easy to install (5 minutes) and intuitive to use

Cost effective

ConfigSnapshot provides the capability to automatically detect the majority of customization types. In addition, it provides a Customization Impact Analysis process that will check every identified customization for references to objects that Oracle has indicated have changed between versions; this is based on Oracle’s EBS Data Model Comparison Report. Rather than having to manually review all of your code searching for changed objects, this can now be done automatically. As well as listing the affected objects it has found, the impact analysis will even show you where in the code you have included the objects.


82

This allows technical resources to focus straight away on how the code should be updated to function correctly in the upgraded environment.

Last of all, we recommend research on My Oracle Support, and training. TruTek offers classes that describe the new features of Release 12. Our instructors particularly enjoy working through students’ real life examples, and have commented that oftentimes E-Business Suite Release 11i customers are using workarounds and customizations for functionality that is already available as part of Release 11i. We can also bring our instructors onsite for consulting engagements, where they can help your functional users determine if a customization really is needed in the Release 12 world.

83

1. Plan to Upgrade




Chapter 2 – Prepare to Upgrade

“Failure is nature’s plan to prepare you for great responsibilities”

Napolean Hilll

Practice Testing

To prepare for testing, the test manager should review the test scripts with the superusers. Periodically, after clones or large patches, the superusers should run the test scripts to ensure they are efficient at executing them.

Testing resources should be dedicated to the upgrade projects. Upgrade testers should be the most knowledgeable users and the most likely to find issues. Sometimes it’s not possible to get the best personnel to be dedicated to the upgrade project. In this case, it is OK to borrow them, but they should not be your primary testing resources.

Optimize the Upgrade

Use TUMS to eliminate the tasks that are not relevant for your system

Use Shared file system and Distributed AD for Multi-node application tiers.

Estimate tablespace sizes for test upgrade using Note: 399362.1

Maintenance Wizard

The Maintenance Wizard provides a step-by-step, graphical user interface for performing upgrade tasks, and consolidates instructions from multiple sources to present a comprehensive upgrade picture. It reduces upgrade tasks by filtering out those that do not apply to you (using TUMS) and indicates critical patches that your system requires. The Maintenance Wizard can automatically execute upgrade tasks for you

If possible, complete the following prior to the R12.1 upgrade weekend:


84

Upgrade the Database to 11.2.0.3

Migrate to OATM

Install the R12.1 software

Run pre-upgrade Downtime Reducing steps

Run pre-upgrade verification steps

Upgrade by Request

You can, if you choose, upgrade the most important data - the last fiscal year or other periods - during the upgrade downtime, and upgrade the rest of the historical data later for some of the E-Business Suite modules. The products that use Upgrade by Request are:

Customer Relationship Management (CRM)

Financials and Procurement

Projects

Supply Chain Management

See My Oracle Support Knowledge Document 604893.1, R12: FAQ for the SLA Upgrade: SLA Pre-Upgrade, Post-Upgrade, and Hot Patch.

A historical data upgrade depends on the product. For some products, only SLA data will be upgraded, and for others, both transactions and accounting data will be upgraded.

Implementation is a two step process:

1. Set the range of periods of the historical data to be upgraded before the R12 Upgrade and run the pre-upgrade concurrent programs

2. Run the SLA post upgrade (upgrade by request option) after the R12 upgrade

Review Appendix G in Oracle’s R12 Upgrade Manual for more details

Default Upgrade Periods - Minimum Downtime Upgrade

During the upgrade, existing accounting data from the subledgers (AR, AP, GL) is upgraded into the new Oracle Subledger Accounting (SLA) data model.

By default, the upgrade migrates data for the current fiscal year and the periods of the previous fiscal year that are necessary to ensure there are at


85

least six periods in the upgrade (if the upgrade is performed in the first half of the fiscal year).

Install the SLA Pre-Upgrade Concurrent Program

To change the default number of periods of historic data to be upgraded:

Apply Patch 5233248 to your Release 11i APPL_TOP

Submit the SLA Pre-Upgrade Concurrent Program

Run the SLA Pre-Upgrade Concurrent Program

When submitting this program, enter the following parameters:

Migrate all Sets of Books:

• Yes (SLA Pre-Upgrade program updates the periods in all Sets of Books) or

• No (SLA Pre-Upgrade program updates the periods that belong to the selected Set of Books).

Set of Books: Set of Books to be upgraded where you have selected to upgrade one Set of Books.

Start Date: Date used to determine the first period to be upgraded. The first period is the first period the Start Date falls in; it does not have to be the starting date of the first period.

The start date can be changed to a date earlier than the 6 months minimum, but not shortened to less than the default.

You may need to run the SLA Pre-Upgrade program if you are using Oracle General Ledger and at least one of the following subledgers:

Assets

Cost Management

Payables

Receivables


86

Purchasing

Project Accounting

This optional program allows you to change the default number of periods of historic data to be upgraded.

The Release 12 SLA Pre-Upgrade program considers the following modules:

Payables

Receivables

Purchasing

Project Accounting

Inventory/Costing

Fixed Assets (Fixed Assets uses GL periods)

The SLA Pre-Upgrade program uses the GL_PERIOD_STATUSES table. The MIGRATION_STATUS_CODE column indicates the status of the record in the GL_PERIOD_STATUSES table:

P = Pending Upgrade - The system is preparing to upgrade the accounting periods in this table that have a status P. The accounting transactions in these corresponding accounting periods will be upgraded from Release 11i to Release 12 by the Subledger products (i.e, AR, AP etc).

U = Upgraded - The accounting records have been upgraded from Release 11i to Release 12

N = New - Only used by GL

<blank> = These records do not meet any of the criterion mentioned and will therefore not be considered in the upgrade.

The parameters for the SLA Pre-Upgrade program are:

Upgrade all Sets of Books, or

The specific Set of Books and the Start Date.

The Release 12 SLA Pre-Upgrade Program tags the accounting periods in the GL_PERIOD_STATUSES table with P for pending upgrade when the records are for AP, AR, Project Accounting, FA, Inventory/Costing and PO products only.

No other products are considered by this pre-upgrade program


87

Adjustment Periods

The accounting period under consideration must be a NON-Adjustment period.

Adjustment periods are not upgraded because the upgrade that was designed by the Subledger Product teams (AP, AR etc) caters to the transactions created by those products and posted to GL.

Typically, the Subledger Product teams do not generate transactions that post into adjusting periods. Given that adjusting periods overlap dates with non-adjusting periods, the logic for mapping a transaction into an accounting period is to take the GL date and figure out which non-adjusting period it falls into.

The period has a status of closed, open, future, and never opened.

Note: Never opened is only applicable to the Inventory/Costing product.

SLA Post Upgrade Processing

Upgrade by Request

If you do not perform a complete upgrade of the accounting data, Oracle Subledger Accounting allows you to perform an additional upgrade of the data by running the SLA post-upgrade process Concurrent Program whenever the missing data is required.

The Upgrade is an Iterative Process

The following diagram illustrates the iterative process of upgrading Oracle Applications. The further you deviate from a vanilla install of Oracle Applications, the greater the chance that you will experience a problem that Oracle can’t replicate and therefore will never be regression tested. Oracle does extensive regression testing based on “vanilla” installs and the related upgrades to ensure that most upgrade paths are free of errors.

The upgrade can take a few iterations to resolve new issues. Each patch can introduce new code that can cause customizations to fail and existing processes to become obsolete. Because of these changes, it is up to your organization to Evolve as new functionality is introduced, Manage the changes and align the business processes, and Optimize the upgrade.


88

Manage-Evolve-Optimize

Manage

Managing the upgrade consists of setting expectations for the Steering Committee, including time, money, and perceived benefits, and communicating these expectations across the upgrade team. Providing training to the superusers, users and technical staff is also part of the upgrade management responsibilities.

One of the primary responsibilities of the Upgrade Project Manager is to align the business processes with Oracle Applications R12.1 and to control the subsequent scope creep. The project manager should also encourage the Steering Committee to allow the developers to migrate the customizations to a Service Oriented Architecture (SOA) when possible.

Another goal of the Upgrade Project should be to implement comprehensive business reporting. While this may not be part of the upgrade, comprehensive reporting will improve the effectiveness of any release of Oracle Applications.

Evolve

To evolve, we must change and adapt, so as to not become extinct. In order to evolve, we must incorporate R12.1 new functionality and seek to replace customizations with existing R12 new functionality. Business process gap analysis should be a continuous process if you hope to evolve.


89

Optimize

One of the most important goals of the optimize phase of the upgrade is to reduce the downtime of the upgrade. Optimization affects post-upgrade tasks and should improve uptime and improve the reporting capabilities, while improving the response time and reducing costs. Optimization improves the visibility and productivity of the overall system.

Aligning and Improving the Business Processes with R12.1 New Features is an Iterative Process

The iterative process of improving the business processes is dependent on improving the technology foundation, aligning the technology with business processes, creating or modifying customizations and, finally, the stage is set to improve the business process and realize cost savings.

When Are We Ready? Are We There Yet?

We are ready when business processes align with Oracle Applications, customizations support the business processes, users are familiar with the new functionality and have been trained, and testing indicates all processes are functioning.

The following diagram illustrates four test upgrade iterations executed before no new issues are identified.

The first iteration is a test iteration, to copy the software from the DVDs to the hard drives of the test machine, install the new Release 12.1 software with Rapid Install (aka rapidwiz), and execute the upgrade. We


90

recommend for this first iteration installing and then upgrading Oracle’s Vision instance, as it provides a seeded database that will allow technical team members to experience the different issues that occur with the installation and upgrade, and gives functional users an environment with all features implemented for experimenting with new functionality. Even with the best planning, this iteration usually has errors. See the little r12.1.3 Upgrade Guide for a complete walkthrough of this upgrade, with solutions to many of the issues that occur.

The next iteration, labeled the 1st Pass, is the first iteration that includes customizations based on functional gap analysis. The 1st Pass also includes solutions, called “fixes”. These are the “fixes” for some or all of the issues identified in the Test iteration. This is the 1st iteration that is visible to the developers and functional analysts

The second pass uses the customizations from the 1st Pass and any new customizations, plus “fixes” from the 1st Pass all added to the objects that are installed by rapidwiz.

When there are no New Fixes, use the timings from the upgrade to predict the downtime foe “upgrade weekend”.

When there are No New Issues, use the timings from the “performance” upgrade to measure downtimes and more accurately plan for the production upgrade.


91

Technical Upgrade Paths - Release 12.1 Upgrade Paths

Path A DB 9iR2, 10gR2 Apps 11.5.7 or 11.5.8

DB Upgrade & Apps Upgrade need to be completed during the same downtime window.

Path B If the DB already at 11gR2, Apps 11.5.9.2 or 11.5.10.2

Only upgrade the Apps Stack

Path C Upgrade the DB & Apps in different phases

Technical Upgrade Flow

This guide assumes we start with Release 11.5.10.2, but the following upgrade paths show how to upgrade from earlier versions of Release 11i. Implement OATM and upgrade the database to the highest compatible level.


92

Release 12.1 Upgrade Paths

Initial Release Interim Release Final Release R12

Patch

11.0, 11.5.1 - 11.5.6 Release 11.5.10

CU2 Release 12.0.0 4440000

11.5.7. 11.5.8, 11.5.9* or

11.5.10* Release 12.0.0 4440000

11.5.7, 11.5.8, 11.5.9.2,

11.5.10.2 Release 12.0.4 6394500

11.5.9*, 11.5.10*, 12.0** Release 12.1 6678700

12.1.1 Release 12.1.2 7303033

12.1.1 Release 12.1.3 9239095

* includes CU1 and CU2 (consolidated update) ** use Release 12.1 CUP 1 The highlighted section indicates that a direct upgrade path exists from Release 11.5.7 to Release 12.0.0.

The database version must be compatible with the old and new versions of Oracle Applications as shown above.

If upgrading from a release prior to 11.5.7, the upgrade path may require an interim upgrade to Release 11.5.10.2.

Because of the significant downtime required to upgrade from Release 11.0 to Release 12.1, it may be more feasible to first upgrade to Release 11.5.10.2 and then some time later upgrade to Release 12.1. This requires the functional users to learn Release 11.5.10.2, and perform all the testing for another upgrade. The amount of work necessary to perform two rounds of system acceptance testing may justify another day or two of downtime, so that the upgrade from Release 11.0 to Release 12.1 can be completed in one longer period of downtime.

The bubbles in the following diagram show the primary upgrade paths between versions of Oracle Applications. Most EBS customers are


93

running Release 11.5.10.2. In order to upgrade to Release 12.1.3, first upgrade to 12.1.1 and then apply the 12.1.3 patch. Notice that Release 11.0 customers must first upgrade to Release 11.5.10.2 before upgrading to 12.1.1 and then 12.1.3.

Upgrade Paths for Oracle Application Versions

Database Upgrade Requirements

Release Certified Database Versions on Solaris

12.1 10gR2, 11gR2 and the 64 bit versions

12.0 10gR2, 11gR2 and the 64 bit versions

11.5.10.2 10gR2 or 11gR2 and the 64 bit versions

11.5.9.2 10gR2 and the 64 bit versions

11.5.7 8.1.7, 9.0.1 9.2, and 9.2-64 bit

There is no database version that is certified with both Release 11.5.7 and Release 12.1. Therefore, we can’t do the database upgrade separately from the application upgrade.


94

The database installed by the 11.5.10.2 RapidWiz is Version 9.2.0.6. This database version does not support Daylight Savings Time (DST). Therefore, we have two choices:

Upgrade the database to Version 9.2.0.8, which has support for DST, and then upgrade to Version 11.2.0.3, or

Upgrade the database to Version 10.2.0.3, using the database Oracle Home provided with the 12.0.4 EBS install, and then upgrade to 11.2.0.3.

Since we require an interim step, and we already have the 12.0.4 DVDs staged, it is easier to use the 10.2.0.3 Oracle Home than to download the 9.2.0.8 patch and apply all the E-Business Suite-specific database patches.

Database Upgrade Steps

Upgrade Timeframe

Typically, the upgrade to Release 12.1 from 11.5.10.2 will require a 3 to 4 day weekend for downtime, starting at the close of business on Wednesday or Thursday, for a 3 or 4 day downtime window.

Four day weekends usually are the best time to upgrade because the extra day of downtime has less effect on the business. The first weekend of the month is usually not a good weekend, because month-end close just occurred and month-end close processing probably hasn’t finished. Similarly, during the last weekend of the month, functional analysts are getting ready to close the books. The middle two weeks of the month


95

present the best opportunities. In 2010, Memorial Day is observed on a Monday, July 4th is on a Monday, Labor Day is on Monday, Columbus Day is on a Monday, Thanksgiving is on a Thursday with business operations on-hold on Friday during the upgrade. Christmas and New Years are horrible times to do the upgrade, primarily because of mandatory year-end processing.

The database upgrade generally takes 8 to 12 hours. If the database upgrade is complete prior to upgrade weekend, it is possible to do a 2 day applications upgrade from Release 11.5.10.2. The database upgrade can be completed independently of the Release 12.1 applications upgrade. If possible, the database upgrade should be completed weeks or months before the Release 12.1.1 Upgrade.

The Applications portion of the upgrade will take 14 to 32 hours depending on the speed of the server and the amount of data to upgrade. Testing will take 8-12 hours after the upgrade is complete.

Backups can be time consuming and recovery should be tested before the upgrade weekend.

Upgrade Downtime with the Database Upgrade

If you need to upgrade your database in the downtime window, you’ll need to add an extra day to your schedule. This will require the downtime to begin Thursday night.


96

Upgrade Downtime Without the Database Upgrade

Upgrade Weekend

This is a typical plan for upgrade weekend and shows the approximate times for each phase.

Start the Upgrade on Friday Afternoon

Clone Upgrade instance from PROD – 2 hours (In many environments that can take 16 hours or longer. Get a SAN!)

Plan to Upgrade

Perform Category 1 Steps – 4 hours

These steps can be completed in PROD in advance of upgrade weekend

Prepare to Upgrade


These steps can be completed in PROD in advance of upgrade weekend

Perform the Upgrade


Finish the Upgrade


Customizations – 4 hours

Setups – 4 hours

iSupplier / SSL – 4 hours



97

Developer Testing – 2 hours

Backup the Upgraded instance – 2 hours

User Acceptance Testing – 8 hours

Restore the Backup if Testing was destructive


98

99

1. Plan to Upgrade




Chapter 3 – Perform the Upgrade

"Resolve to perform what you ought; perform without fail what you resolve." Stonewall Jackson 1824 - 1863

Performing the Upgrade should not be iterative. The production upgrade should work predictably.

What happens if the upgrade fails? Do you fire the consultants? Whose fault was it? Usually, the fault lies with inadequate testing, not enough communication about changes to the system, or possibly one of the steps on the checklist was missed.

If the Upgrade fails, you haven’t practiced enough. Look at failed upgrades as forced practice. There are many reasons the upgrade can fail; the trick is to be able to identify the issue and prepare for another upgrade weekend. If the failed upgrade was on the second weekend of the month, the third weekend may also be a good upgrade weekend, assuming everyone is confident that all the issues were resolved. Usually, it takes a month to regain confidence and proceed with the next upgrade weekend. Management should be aware that a secondary upgrade weekend should be part of the overall upgrade plan.

Tune the Upgrade

Gather statistics before the upgrade

Use Gather Auto option

Record timing for each step during the test upgrade

Drop MRC schema before the R12 upgrade

Add the PL/SQL no compile option in R12 upgrade driver to save time during upgrade


100

Add “extension plsql_no compile yes” line in the upgrade driver file to enable the PL/SQL no compile option

Optimal Number of Workers

At TruTek, our upgrade machines use 4 CPUs. With timing data from more than 30 upgrades, the times were measured and the number of workers was varied from 2 to 16. The fastest upgrade times were for 3 workers. We recommend setting the number of workers to CPUs – 1. For a machine with 16 CPUs, then, we would use 15 workers.

My reasoning for this rule is as follows:

Patches run jobs that have dependencies. When too many jobs are running in parallel, it is easier to get the jobs out of order, and more jobs will be deferred. Deferring jobs causes more management overhead.

Therefore, by running one less worker than the number of CPUs, the operating system CPU requirements and other CPU usage attributed to overhead for deferrals are free to run on the available CPU and should not disturb the running workers.

Oracle recommends the following considerations in choosing the optimal number of workers:

Between 1*CPUs and 1.5*CPUs

Average IO response times below 10-15 milliseconds

Average CPU usage below 100%

Optimize adpatch

Choose the proper batchsize

Batchsize=10000

Choose the proper number of workers

# of workers = CPUs - 1

Time the Upgrade

You can’t manage something unless you can measure it. The following is an example of the Unix command “time” with adpatch running in non-interactive mode using a defaultsfile.

time adpatch defaultsfile=$APPL_TOP/admin/VIS/adalldefaults.txt logfile=adpatch.log patchtop=$AU_TOP/patch/115/driver workers=3 interactive=yes options=novalidate, nocopyportion, nogenerateportion

Chapter 3 –Perform the Upgrade

101

The software installed by RapidWiz includes all the application tier file-system changes; therefore, the copy portion and the generate portion of the adpatch process are not required. These changes should be applied to the database by running the patch with the nocopyportion and nogenerateportion options.

Other possible options to reduce downtime include nocompiledb, nocompilejsp, and noautoconfig.

Use the AD_TASK_TIMING table to gather timing information. The elapsed time is in fractions of a day. Multiply the elapsed time by 24 hours per day to get the units in hours. The following diagram shows the most time consuming jobs in the upgrade. Compiling objects always takes the longest, followed by statistics and parallel compiles. Use this table to find jobs that have large elapsed times. Some long running jobs have scripts that can be run before upgrade weekend to reduce the processing required during upgrade weekend.

AD_TASK_TIMING

The following is an example of the rows in the ad_task_timing table that have the largest elapsed time. The time to run each job is recorded in this table. The most time consuming jobs are jobs that compile invalid objects. By keeping track of the times, it’s possible to identify jobs that have encountered some new problem. Large amounts of data will cause some jobs to run for a long time. Some of these jobs can be run in advance, as mentioned in the next section, Reducing Downtime.

JOB_NAME PRODUCT PROGRAM PHASE elapsed time –hrs

adobjcmp.sql ad AutoPatch 27 5.652222222


adsstats.sql ad AutoPatch 346 1.908888889

adstatrp.sql ad AutoPatch 346 1.908888889

adpcpcmp.pls ad AutoUpgrade 12 1.842222222




invmenu.ldt inv AutoPatch 41 1.288333333


102

Reducing Downtime


facpupg.sql FA AutoPatch 245 0.005277778

glrsgup2.sql GL AutoPatch 244 0.010833333

Fixed Assets has a potentially long running sql script, facpupg.sql. The script is run by AutoPatch (adpatch) and takes about 19 seconds to run in our upgrade. The script takes so little time to run that it should be run during the downtime window and would not save a significant amount of downtime if run in advance. You, on the other hand, may have a very large Fixed Assets environment, so as part of the testing you should look at how long programs take to run to decide if any downtime reducing steps are worth trying.

AutoConfig has large elapsed times during the upgrade and can be run after the upgrade in parallel mode in order to further reduce downtime.

AutoConfig in Parallel Mode Across Multiple Nodes

The ability to run AutoConfig in parallel across multiple nodes was introduced in the TXK 12.1.1 Consolidated Patch. This feature reduces maintenance downtime.

AutoConfig can be run in parallel mode by issuing the following command:

On the Applications tier:


ontmenu.ldt ont AutoPatch 41 0.978888889

afoamadmmenu.ldt fnd AutoPatch 41 0.870555556

ozfmenu.ldt ozf AutoPatch 41 0.806111111

akdatsb1.drv ak AutoUpgrade 20 0.802222222

oksmenu.ldt oks AutoPatch 41 0.783055556

fndwfusermenu.ldt fnd AutoPatch 41 0.598333333

iexmenus.ldt iex AutoPatch 41 0.523055556

systemadministratormenu.ldt fnd AutoPatch 41 0.4675

fem_xdmi.odf fem AutoPatch 25 0.419166667

oamdiagbasemenu.ldt fnd AutoPatch 41 0.419166667

bermind.sql ben AutoPatch 2 0.412222222

Chapter 3 –Perform the Upgrade

103

perl <AD_TOP>/bin/adconfig.pl contextfile=<CONTEXT_FILE> [product=<product_top>] –parallel

On the Database tier:

perl <ORACLE_HOME>/appsutil/bin/adconfig.pl contextfile=<CONTEXT_FILE> –parallel

When running AutoConfig simultaneously on multiple nodes, the -parallel option must be specified while starting AutoConfig on every node. Otherwise, the execution of AutoConfig processes on individual nodes will not be synchronized, and may result in an inconsistent file system or database.

After the Upgrade Driver Finishes

Make sure you reset the following init.ora parameters after completion of the R12 upgrade driver:

recyclebin

parallel_max_servers

job_queue_processes

Merge all the NLS patches and apply them as single merged patch

Isolate post upgrade concurrent programs to a separate manager queue as mentioned in the best practices MOS Doc. ID: 399362.1.


104

105

1. Plan to Upgrade




Chapter 4 – Finish the Upgrade

“We rate ability in men by what they finish, not by what they attempt”

Anonymous

The Importance of Testing

Without adequate testing of both Oracle’s Application code and especially your custom code, including your use of Oracle’s built-ins, you run a high risk of your Oracle Application processes not working in your newly upgraded environment. You MUST test; there is really no way around it. Even if you have little or no customizations, there is no guarantee that the newly delivered Oracle Application code will work with your organizational processes. Unit and system testing can take a significant portion of time, and therefore are often skipped, only to end up extending the overall project timeline because of the need to redo and retest.

Consider using an automated testing approach to radically improve testing productivity and provide a quality driven process. 100% automation may not be achievable but testing automation can significantly reduce the normal testing bottleneck most companies run into, and in the long run save a significant amount of time and money.

Testing Methodology

Testing is the basis of success for upgrades. Testing requires practice. Testing requires management. Testing requires the best and most knowledgeable users.

There are three types of testing: Functional, Technical and Load Testing:


106

Functional Testing

Functional testing is one of the most important skills to develop within your internal staff. After a clone or a large patch, technical tests are executed to confirm the availability of technical components. Functional testing should then be performed to confirm the availability of key functionality.

Functional test scripts take time to develop and really should be a continuous effort to improve the test scripts. Test scripts should be run often enough that users are proficient with the execution of the test scripts, and know what test results to expect. Typical steps in testing include:

Develop test scripts

Execute test scripts

Perform unit and integration tests

Test customizations

Be sure to test Release 11i existing data in R12 - functional testing usually is centered on entering new R12 transactions. Make sure transactions that were entered in Release 11i can still be used in R12.

Load Testing

Identify the primary workload

Chapter 4 –Finish the Upgrade

107

Characterize the workload

Identify bottlenecks

Improve performance

Technical Testing

Identify potential issues

Understand the R12 Architecture

Apply patches or customize to correct issues

Test Management

The lack of effective testing is the single most frequent cause of failure to “Go Live”. Testing is a dedicated job. Most companies only lend one resource to a test initiative. The Test Manager should be a dedicated resource.

The Test Manager’s tasks include mentoring the testers, stressing the importance of testing to the organization, ensuring adequate testing, monitoring and improving the Test Development process, and coordinating testing with the technical and functional staff.

Test Environments

The following R12 test instances may be required:

A Development instance for the developers

A Test instance for each new module being implemented

A Patch instance for the DBA

A Training instance for training

Too many instances can lead to cloning nightmares.

Functional Testing

Functional Testing includes updating existing E-Business Suite test scripts to reflect valid navigation paths for Release 12, developing new Oracle E-Business Suite Release 12 test scripts, incorporating any customizations, and performing regression testing.

Release 12 introduced functional verification tasks to help identify issues before making a “Go Live” decision. In addition to tests your users should run to verify day to day operations, they should also run the verifications tasks listed in Appendix F of the Oracle E-Business Suite


108

Upgrade Guide, Release 11i to 12.1.3, Part No. E16342-03. The following verification tasks are to verify GL and Payables:

Global Accounting Engine Verification Tasks

Run Accounting Reports

You should run the Global Accounting Engine accounting reports before the upgrade and the corresponding Subledger accounting reports after the upgrade to ensure that you have a proper audit trail of the upgraded accounting data. The reports are as follows:

Global Accounting Engine Subledger Accounting

Daily Journal Book Daily Journal Report

Account Ledger by Account Account Analysis Report

Supplier and Customer Subledger Third Party Balances Summary by Account

Supplier and Customer Balance Third Party Detail and Balances by Account Report

E-Business Tax Verification Tasks

Tax Transaction Audit and Reconciliation Reports

To ensure that transaction tax information has been correctly upgraded, run the Payables Tax Audit Trail report and the Receivables Tax Reconciliation report for the current tax period before the upgrade to set a benchmark of transaction information. Then immediately after the upgrade, run the same reports in the new environment for the same period and compare the results to ensure that the tax values are still the same.

Payables and Receivables Transaction Query

For a sample of Payables and Receivables transactions, record the details of the associated tax for these transactions before migration, and then query them again after the upgrade to ensure that the tax has been correctly upgraded. Duplicate the same transactions and re-trigger to ensure that the new E-Business Tax-based calculation is consistent with the previous calculation.


109

Payments Verification Tasks

Legal Entity Configurator Verification Tasks

You should perform a review of all legal entities and establishments in your system after the upgrade is complete to ensure that the correct legal structure is in place. You can access this information by using the Search Page in the Legal Entity Configurator.

Refer to the Oracle Financials and Oracle Procurement Functional Upgrade Guide: Release 11i to Release 12.

If you need to create or upgrade legal entities and establishments, then see the Oracle Financials Implementation Guide for instructions.

Trial Balance Reconciliation

In your Release 11i environment, run the Accounts Payable Trial Balance, Posted Invoice Register, and Posted Payment Register reports. After the upgrade, run the Open Account Balances Listing Report, Posted Invoice Register, and Posted Payment Register in your upgraded environment and compare the results.

The reports run for a ledger or a ledger set, not within the context of a single operating unit. The Release 11i Trial Balance and Posted Invoice and Payment Registers run within a single operating unit. Depending on your system configuration, you may need to sum several of the Release 11i reports to tie to the new versions.

Invoice and Payment Processing

To verify the integration with Oracle Payments and the upgrade of existing invoices, submit a payment batch with limited selection criteria in order to pay a few invoices.

Accounting Setup and Processing

Query an invoice that was not validated prior to the upgrade, then submit accounting for that invoice. Query an invoice that was accounted before the upgrade, cancel it, pay it, and then account for the payment. Also see Global Accounting Engine.

These tasks apply only to Oracle Payments. In general, your planning for upgrade verification should involve testing in the two payment process areas:


110

Funds Disbursement

If you used Oracle Payables for issuing payments in Release 11i, you should plan to test the funds disbursement processes equivalent to the former payment batch flow to ensure that your upgraded data correctly reflects your business process.

Funds Capture

If you used Oracle Receivables for electronic payment processing such as direct debits or bills receivable remittances, you should plan on testing these areas to ensure that your upgraded data correctly reflects your business process.

If you used Oracle iPayment for capture of funds from credit cards or bank account debits, you should plan on testing these processes to ensure that the upgraded data results in the process you expect

System Security Options

Oracle Payments provides this new page where system-level settings for encryption, masking, and credit card security can be controlled. When your upgrade is complete, you should plan on reviewing the seeded settings in this page to ensure they meet your business needs.

For example, in Release 11i masking of credit card values is controlled in different ways throughout the applications. In this release, the central setting in this page controls all masking. You will want to review the setting in this page and modify it if needed.

Oracle Payables Impact

You may want to run reports for use in your upgrade verification testing.

For example, you may want to use the Suppliers Report in Oracle Payables to verify the data upgrade for payment details and bank accounts on the payees created in Oracle Payments.

You can use any reports that you ran before the upgrade to help verify upgraded data.

In addition, there are some key setup entities that should be reviewed and used in testing payment processing.

Payment Process Profiles - You should plan on reviewing the settings for the seeded profiles created by the upgrade. These settings come from a variety of sources, and since the profile drives the entire funds disbursement flow it is important to verify that the setup supports your business process. You should pay special attention to


111

the usage rules set on the seeded profiles as these can be changed if the upgraded values do not align with your needs. It is recommended that you run a test payment process with each profile that you plan to use in production.

Payment Methods - A new setup page is provided where payment methods can be created or updated. You should plan on reviewing the payment methods seeded by Oracle Payments to ensure that they meet your business needs.

Payment Systems and Accounts - You should plan to verify these entities after the upgrade, and in particular the required settings, values, and their links to the payment process profiles. This setup controls important parts of the funds disbursement process such as payment file transmission, so you should test this area to be sure that the process is working as you expect.

113

Conclusion

“Don't cry because it's over. Smile because it happened.”

Dr. Seuss

That’s right, when all is said and done, you should have an upgraded system, an exhausted staff ready to celebrate, and, perhaps, some follow-on work. “Follow-on work?” you say. Yes, the work of the E-Business Suite Upgrade Team is never really done. Oracle will continue to publish fixes for problems you didn’t even know you had. There will continue to be evil n’er do wells out there, trying to break into databases, so you will continue to have to apply and test the quarterly Critical Update Patches (CPUs). New functionality will surely come about, as will performance patches and patches that your company simply can’t live without. Take it in stride, and remember that we at TruTek are a hardworking band of consultants and trainers who understand what you’re going through and would be happy to help you work through the details.

www.trutek.com 801-486-6655


trutek little r1213 upgrade essentials 03-15-2013

Documents