TruTek r12.1.3UpgradeEssentials

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

the little r12.1.3 upgrade essentials

2

Copyright 2011 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
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.shop.trutek.com/category.sc?categoryId=30
Table of Contents

3
Table of Contents
THE LITTLE R12.1.3 ESSENTIALS FOR MANAGERS AND TEAM
MEMBERS ...................................................................................................... 7
AUDIENCE ..................................................................................................... 7
AVAILABLE REFERENCES .............................................................................. 8
OUR PARTNERS ........................................................................................... 11
THE BIG PICTURE ........................................................................................ 13
CHAPTER 1 PLAN TO UPGRADE ........................................................ 15
FIRST STEPS ................................................................................................ 15
WHY MIGHT A BUSINESS DECIDE OR HESITATE - TO UPGRADE? ............. 16
DECISION: REIMPLEMENT VS. UPGRADE ..................................................... 17
Reimplementation Consequences ........................................................... 17
Transform and Upgrade with eprentise ................................................. 19
The Functional Business Analysis .......................................................... 20
Other Obstacles to Upgrading ............................................................... 21
Process to Re-implement ........................................................................ 21
Oracles Re-implementation Tools ......................................................... 21
CAPABILITY MATURITY MODEL ................................................................. 22
UPGRADE BENEFITS: AN OPPORTUNITY TO IMPROVE YOUR HARDWARE
CONFIGURATION ......................................................................................... 23
UPGRADE BENEFITS: IMPROVED TOOLS SIMPLIFY THE PROCESS ................ 23
Real Application Testing ........................................................................ 23
Database Replay .................................................................................... 24
Maintenance Wizard .............................................................................. 25
UPGRADE BENEFITS: USE SHARED SERVICE CENTERS TO DRIVE COST
SAVINGS AND INCREASE INFORMATION QUALITY ....................................... 26
UPGRADE PROCESS: THE R12 FUNCTIONAL UPGRADE REQUIRES GAP
ANALYSIS .................................................................................................... 26
UPGRADE PROCESS: ASSESSMENTS CAN HELP THE PLANNING PROCESS .... 29
Functional Upgrade Assessment ............................................................ 30
Technical Upgrade Assessment .............................................................. 30
Customization Assessment ..................................................................... 31
Architecture Assessment ......................................................................... 31
Hardware Assessment ............................................................................ 33
UPGRADE PROCESS: UNDERSTAND THE FUNCTIONAL FINANCIAL R12 NEW
FEATURES ................................................................................................... 34
Integrated Financials ............................................................................. 34
Subledger Architecture ........................................................................... 34
Key R12 Modules ................................................................................... 34
Subledger Currency Views ..................................................................... 35
Multi-Org Access Control ...................................................................... 36
UPGRADE PROCESS: BUILD A STRONG UPGRADE TEAM .............................. 37
Dedicated Team Members ...................................................................... 37

4
Upgrade Roles and Responsibilities ...................................................... 38
Technical Upgrade Responsibilities ...................................................... 38
Functional Upgrade Responsibilities ..................................................... 38
Upgrade Project Manager Responsibilities ........................................... 39
Steering Committee ................................................................................ 40
SUCCESS FACTORS FOR UPGRADE PROJECT MANAGERS ............................. 40
Time and Money ..................................................................................... 40
Customization Costs ....................................................................................... 41
Skills ....................................................................................................... 41
Identify Skill Gaps in Your Upgrade Team .................................................... 42
Teamwork ............................................................................................... 42
Team Obstacles .............................................................................................. 43
Minimize Risk ................................................................................................ 43
The Team Must Recognize Competing Priorities........................................... 44
SUCCESS FACTORS FOR FUNCTIONAL USERS .............................................. 44
Gap Analysis .......................................................................................... 45
Customizations ....................................................................................... 46
Cumulative Business Value of Small Business Productivity
Improvements ......................................................................................... 47
Cost - Benefit Analysis for Business Process Improvement for Smaller
Implementations ..................................................................................... 48
SUCCESS FACTORS FOR TECHNICAL UPGRADE MANAGERS ........................ 49
Patches ................................................................................................... 50
Upgrade Patch Types - CPCs, UPCs, CPUs, PSUs ........................................ 50
Use Patch Wizard from Oracle Application Manager (OAM) ....................... 52
The Patching Process ..................................................................................... 53
The Testing Process ....................................................................................... 54
Create Custom Development Upgrade Plan ................................................... 55
How to Upgrade Customizations ........................................................... 55
Obsolete Technology Components with Release 12 ............................... 57
mod_plsql ....................................................................................................... 57
Oracle Reports Server Reports ....................................................................... 57
Oracle Graphics Integrations with Oracle Forms ........................................... 57
AK Mode ....................................................................................................... 57
JOINING FUNCTIONAL AND TECHNICAL VIEWS ........................................... 57
Upgrade Success Without Customizations ............................................. 58
Tools of Choice for Rooting Out Customizations ................................... 59
CHAPTER 2 PREPARE TO UPGRADE ................................................ 61
PRACTICE TESTING ..................................................................................... 61
OPTIMIZE THE UPGRADE ............................................................................. 61
MAINTENANCE WIZARD.............................................................................. 61
UPGRADE BY REQUEST ............................................................................... 62
DEFAULT UPGRADE PERIODS - MINIMUM DOWNTIME UPGRADE ................ 62
INSTALL THE SLA PRE-UPGRADE CONCURRENT PROGRAM ....................... 63
RUN THE SLA PRE-UPGRADE CONCURRENT PROGRAM.............................. 63
ADJUSTMENT PERIODS ................................................................................ 65
SLA POST UPGRADE PROCESSING .............................................................. 65
Table of Contents

5
Upgrade by Request ............................................................................... 65
THE UPGRADE IS AN ITERATIVE PROCESS ................................................... 65
MANAGE-EVOLVE-OPTIMIZE ...................................................................... 66
Manage .................................................................................................. 66
Evolve ..................................................................................................... 66
Optimize ................................................................................................. 67
Aligning and Improving the Business Processes with R12.1 New
Features is an Iterative Process ............................................................. 67
When Are We Ready? Are We There Yet? .............................................. 67
Technical Upgrade Paths - Release 12.1 Upgrade Paths ...................... 69
RELEASE 12.1 UPGRADE PATHS .................................................................. 70
DATABASE UPGRADE REQUIREMENTS ........................................................ 71
DATABASE UPGRADE STEPS ........................................................................ 72
UPGRADE TIMEFRAME ................................................................................ 72
UPGRADE DOWNTIME WITHOUT THE DATABASE UPGRADE ....................... 74
UPGRADE WEEKEND ................................................................................... 74
CHAPTER 3 PERFORM THE UPGRADE ............................................ 77
TUNE THE UPGRADE .................................................................................... 77
OPTIMAL NUMBER OF WORKERS ................................................................ 78
OPTIMIZE ADPATCH ..................................................................................... 78
TIME THE UPGRADE .................................................................................... 78
AD_TASK_TIMING ................................................................................. 79
REDUCING DOWNTIME ................................................................................ 80
AUTOCONFIG IN PARALLEL MODE ACROSS MULTIPLE NODES ................... 80
AFTER THE UPGRADE DRIVER FINISHES ...................................................... 81
CHAPTER 4 FINISH THE UPGRADE .................................................. 83
TESTING METHODOLOGY ............................................................................ 83
Functional Testing ................................................................................. 83
Load Testing ........................................................................................... 84
Technical Testing ................................................................................... 84
TEST MANAGEMENT ................................................................................... 84
TEST ENVIRONMENTS ................................................................................. 85
FUNCTIONAL TESTING ................................................................................. 85
Global Accounting Engine Verification Tasks ....................................... 85
Run Accounting Reports ................................................................................ 85
E-Business Tax Verification Tasks ......................................................... 86
Tax Transaction Audit and Reconciliation Reports........................................ 86
Payables and Receivables Transaction Query ................................................ 86
Payments Verification Tasks .................................................................. 86
Legal Entity Configurator Verification Tasks ................................................ 86
Trial Balance Reconciliation .......................................................................... 86
Invoice and Payment Processing .................................................................... 87
Accounting Setup and Processing .................................................................. 87
System Security Options ................................................................................ 87
Oracle Payables Impact .................................................................................. 88

6
CONCLUSION ............................................................................................. 89
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.

8
Available References

PLAN PREPARE PERFORM
In addition to this upgrade essentials guide, TruTek has also published a
project plan CD called the little r12.1.3 project plan that we use to perform
the upgrade in our upgrade class.
Weve also documented step by step everything that our TruTek E-Business
Suite R11i to R12 Technical Upgrade class goes through when they upgrade a
Release 11i Vision Instance to the latest version of Release 12 in our book
the little r12.1.3 upgrade guide. Topics include:
A comparison of the Release 11i and Release 12 architectures
A list of the 125+ patches that we apply to upgrade to Release 12.1.3
of the E-Business Suite with Version 11.2.0.1 of the RDBMS
A list of the 100+ My Oracle Support Notes that we read through to
decide how to successfully perform the upgrade
Gotchas Every time we hold a class, theres a new opportunity to
break the upgrade. Weve included warnings of what not to do to
avoid having to start over.
The details for upgrading from RDBMS 9i to 10g to 11gR2, including
modifications to initialization parameters
Sections and Appendices that show how to use Oracles tools,
including AD Merge Patch, Applying Database Patches with opatch,
and Oracle Patch Application Assistant (admsi.pl)
The intricacies of Critical Patch Collections (CPCs), Consolidated
Upgrade Patches (CUPs), Critical Patch Updates (CPUs), Patch Set
Updates (PSUs), TUMS, and OATM, as well as a detailed upgrade
guide that includes step-by-step details about how to do the upgrade.

9
While the TruTek E-Business Suite R11i to R12 Technical Upgrade class offers
a one-week intensive opportunity to upgrade Oracles test Vision instance,
we have other clients who want to practice the upgrade with their own
data. We now offer a special upgrade experience, the TruTek Release 12
First Pass Upgrade. For the First Pass Upgrade, we start with a TruTek
Release 12 Upgrade Readiness Assessment, where we send a list of questions
and scripts to run against your production environment. We take the
results and meet with the you to ask more questions and dig deeper into
the current environment, and we prepare a lengthy document (around
250-300 pages) that describes the current state of the E-Business Suite
environment, and where we see issues that need to be addressed to
upgrade to Release 12.
After this one week Assessment engagement, we schedule the TruTek First
Pass Upgrade. For that, we come onsite and work with your technical staff
to run through the Release 12 Upgrade against a clone of your production
environment. We work through issues, we document problems, and we
add what we learn to the little r12.1.3 upgrade guide. We also provide a
separate document of the patches and workarounds that were specific to
your environment.
The TruTek First Pass Upgrade lasts two weeks, including nights and
weekends. We can only do this upgrade for clients with a strong DBA and
a robust hardware environment. If you want to do your upgrade testing
on your grandmas first computer, then the First Pass Upgrade may not
be for you. Because we believe that working through the functionality
issues is much more important in the beginning than the performance
issues, we now offer an added-cost First Pass Upgrade where we bring in
our own equipment and use the clients data.
You can buy our books and DVDs online at:
http://www.shop.trutek.com/category.sc?categoryId=30
and if youd like to take a training class with us
or bring us in to consult, give us a call at:
801 486-6655.

Remember, your upgrade is bound to be hard, but if you train and
practice, it doesnt have to be awful.

10

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 TruTeks monthly TruTalk Newsletter at:
www.trutek.com

11
Our Partners
Weve come to the conclusion that a successful upgrade requires the best
tools and the best partners. As weve worked through the Release 12
Upgrade process, weve concluded that there are four areas that require
special attention:

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 that make it
necessary to decide if you need to reimplement. 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 youve placed
under $CUSTOM_TOP is one thing, but what about all those changes
that youve made over the years to menus, value sets, and profile options?
We think that 2e2 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.
12

Security security is often the last thing Oracle customers take the time to
look at, but our friends at Integrigy have tools and wisdom that we think
is superior and grounded. When we do a TruTek Release 12 Upgrade
Readiness Assessment, Integrigy provides a tool that looks for some of
the most common security issues for the E-Business Suite. Integrigy
analyzes the output for inclusion in your Assessment report. They can
also provide additional services using their tools, AppSentry and
AppDefend, for a much more thorough review of your security situation
and defense of environments data.

Confios 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.
Confios 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 youd like to learn more about our partners, contact us at
www.trutek.com, or call us at 1 801 486-6655.

13
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:

1. Plan to Upgrade
2. Prepare to Upgrade
3. Perform the Upgrade
4. Finish the Upgrade
15
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 Oracles upgrade process or
re-implement 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 re-implement 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.
Understand the Hardware Requirements and the Upgrade Path.
Significant cost savings can be achieved by simplifying and standardizing
hardware.
16
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 doesnt 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 than re-
implementing
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 cant 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

17
Decision: Reimplement vs. Upgrade
The decision to re-implement versus upgrade is simple do everything
possible to upgrade. Dont reimplement unless you explore all alternatives
and find 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
customers environment. The customer usually looks for alternatives
from Oracle Partner independent software vendors, system integrators,
and consultants.
When Oracle first released R12, they guided customers to reimplement if
the customer needed to change any obsolete fundamental setup
configurations or to consolidate multiple production instances. Oracles
R12 documentation conceded 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."
Reimplementation Consequences
Here are some reimplementation consequences in the areas of
implementation, data history, disposition 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 the tools and utilities mentioned in the section
below on reimplementation tools.
You are on your own to get your open transactions and historical data
from the legacy Release 11i instance into R12. Oracle Support cant
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.
18
The usual choices include most recent and current fiscal year, current
year, and only open transactions.
Even though data conversion tools these days are powerful, and
programmers in global data centers can be inexpensive, 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
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. That includes translations,
reconciliations, mappings, and external reporting environments.
If you have a business intelligence environment or data warehouse,
you will make need to make changes to incorporate the frozen legacy
Release 11i and operational R12 environments.
11i
Not
Upgradable
Implement New
E-Business Suite
R12 Fresh
Implementation
R12
11i 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 History
Via Public API
& Interface
Tables
Custom SQL &
DB Utilities
11i
History
Restricted
Access
11i Data
Read-Only
History
C
lon
e R
12
e
m
p
ty in
stan
ce be
fore
h
isto
ry lo
ad
C
reate 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 Suite
R12 Fresh
Implementation
R12
11i 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 History
Via Public API
& Interface
Tables
Custom SQL &
DB Utilities
11i
History
Restricted
Access
11i Data
Read-Only
History
C
lon
e R
12
e
m
p
ty in
stan
ce be
fore
h
isto
ry lo
ad
C
reate 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

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

19
The reimplementation environment gets even more complex if there are
multiple Release 11i instances, multiple custom extract, transform and
load operations, and you end up with multiple Release 11i sunset
instances.
Transform and Upgrade with eprentise
An Oracle Partner, eprentise, offers software to transform fundamental
setups in Oracle EBS such as the Chart Of Accounts (Accounting
Flexfield), calendar, organizations, all other key flexfields, and sets of
books. eprentise software can be used to eliminate or fix corrupt data.
You can consolidate multiple instances. You can remove all data related
to sold or inactive business units. If you want to make these major
changes, use the eprentise software to transform your Release 11i instance
so it can be upgraded. Consolidate your Release 11i instances so you can
have a single upgrade process and get to a single R12 instance.
You can use eprentise software to:
Transform the fundamental setups of your Release 11i instance(s) to
reflect how you need your business to run now.
Adjust or re-do any unsatisfactory or obsolete setups.
Consolidate Release 11i instances as required so there is only one
instance to upgrade.
Close seemingly huge functional alignment gaps between Release 11i
and R12.
Minimize the downtime for the upgrade.
Then you run the Oracle upgrade. Heres a diagram that describes the
process.
20
eprentise
Transformation
11i
Upgradable
Oracle 11i
R12 Upgrade
R12
11i Data
Transformed
R12 Data
Transformed &
R12 formats
11i
Obsolete
Setups
11i Data
11i
Obsolete
Setups
11i
Obsolete
Setups
11i Data
Instance you always wished for, AND
its 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 Upgrade
R12
11i Data
Transformed
R12 Data
Transformed &
R12 formats
11i
Obsolete
Setups
11i Data
11i
Obsolete
Setups
11i
Obsolete
Setups
11i Data
Instance you always wished for, AND
its 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

The Functional Business Analysis
It is important to keep the upgrade vs. reimplement discussion in the
context of the overall transition to R12. First understand what the R12
target needs to be. Compare that to the Release 11i instance(s). Itemize
and inventory all the gaps everything that needs to change. Then
consider how you would make each change.
If the Oracle upgrade and standard setup capability is all you need,
this is the best case. You do not need any further upgrade vs.
reimplement discussion.
You could use eprentise Transformation software and then do the
Oracle upgrade.
You could reimplement (implement R12 fresh and migrate your
historical data).
A parallel analysis considers everything in the Release 11i instance(s) that
does not need to change on the path to R12. What do you not need to
touch if you upgrade? What do you need to replicate anew if you
Reimplement? What extra historical data that is supposed to be
unchanged must be managed and migrated if you reimplement?
Oracle provides useful documents, including The R12 Adoption Best
Practices and Upgrade Considerations by Product. These supplement each
module or product familys implementation guide.

21
When you have this inventory of items that either need transformation or
reimplementation, check with eprentise to find out if the transformation
would be practical for your situation. If not, then look at
reimplementation.
Other Obstacles to Upgrading
If any of the following obstacles to upgrading apply, ones the eprentise
transformation software does not directly address, we suggest you contact
experts in that area. The analysis may be a complex exercise, and the
experts may be able to help you avoid reimplementation:

1. If you need to simplify NLS, MLS, and currency configurations.
2. When the upgrade path is too complex, for example, if you need to
perform a Release 10.6 to 12.1 upgrade with forms customizations.
3. If you need to completely replace old EBS application modules. This
will depend on the gaps between the older EBS module and the R12
one, and the specific changes youre looking to make.
Process to Re-implement
This section is for if you have explored all the upgrade options and still decide to
reimplement. First, set up the applications, migrate the data, and install the
customizations. It is possible to go live with a subset of the original data and
convert the remaining data in phases.
Oracles Re-implementation Tools
Oracle provides a number of tools that can help with re-implementation:
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.
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
22
exp/imp Oracles export and import utility.
Datapump - For RDBMS Version 10g and 11g you can use
DataPumps expdp and impdp 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.
Oracle Application Management Pack (AMP) and Application Change
Management Pack (ACP) are additional cost toolsets provided by Oracle
that provide a framework around tools like iSetup, but also offer new
functionality, including the ability to document your customizations.
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.

23
Following this model, technology and process convergence lead to
simplification, standardization and shared services.
Upgrade Benefits: An Opportunity to Improve Your
Hardware Configuration
Probably the least invasive time to implement a new hardware upgrade is
during a software upgrade. Youll 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
Upgrade Benefits: Improved 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.
24
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.

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

25
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.

The Maintenance Wizard contains the following:
Upgrade Assistant: 11i to 12 [version 2.x]
Applications Database Upgrade Assistant: 8i, 9i to 10g [version 2.x]
Maintenance Pack Assistant: 11i to 11.5.10 [version 1.x]
Upgrade Assistant: 10.7, 11.0.3 to 11.5.10 [version 1.x]
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
26
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.
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.

27
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 Oracles long term strategy?
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
28

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

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.

29

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.
30
The Report phase of the assessment defines the issues, recommends
solutions and summarizes process improvements.

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. re-implementation,
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

31
issues from log files, current unresolved service requests, and potential
issues with the R12.1 upgrade.
Customization Assessment
Start by identifying all customizations. In some environments the
customizations arent 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.
32
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
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.

33

Most users dont know how to restart a failed job. Therefore, the
failure of a concurrent manager that is not set up with PCP will
terminate running jobs. 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 doesnt 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
34
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
Financials intercompany management and Supply Chain Managements
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.


35

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.
36
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
previous release, it will be set in 12.
If you dont want to implement MOAC features in Release 12, no
additional setups are required.

37
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.
38
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: 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 developers 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.
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:

39
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
Testing Manager
Report progress of priorities as established by the Steering Committee

40
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 users issues.
Success Factors for Upgrade Project Managers

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:

41
$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.
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
42
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 companys 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 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 cant 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.

43
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 teams 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., team in name but consistently underperforming.
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.
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, 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
44
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
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.

45

Gap Analysis
Gap analysis requires superusers/functional analysts that understand the
new features of R12.1 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.
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
46

Customizations and Modifications can help align the business with Oracle
Applications.
Customizations
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.


47
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.
48
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

49

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

50
The technical view of success depends on applying the correct patches in
the right order, installing and configuring new hardware, and
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 weve 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 - CPCs, UPCs, CPUs, PSUs
See My Oracle Support Knowledge Document 557869.1, EBS: R12 Oracle
Financials Critical Patches for links to the latest Critical Patch Collections
(CPCs) and Upgrade Patch Collections (UPCs).
A new type of patch collection was introduced in July, 2009 called Patch
Set Updates (PSUs). See My Oracle Support Knowledge Document
854428.1, Intro to Patch Set Updates (PSU) for more details about PSUs.
Oracle also releases quarterly Critical Patch Upgrades (CPUs) that should
be applied as they become available.
Critical Patch Collections (CPCs) - Oracle Financials Release 12.0
Critical Patch Collections (CPC) 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.
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.

51
If a CPC becomes available after you complete your upgrade, you should
research the CPC and consider implementing it at some point to your
environment.
Release 12.1 Financials Upgrade Patch Collection (UPC) - The latest
Release 12.1 Financials Upgrade Patch Collection (UPC) contains Release
12.1 Upgrade patches for the following products:
Payables
Receivables
Tax
Subledger Accounting
Intercompany
Financials for India
The Release 12.1 Financials Upgrade Patch Collection is created
specifically for customers who have yet to upgrade their product
environment to Release 12.1. This UPC contains improvements to the
upgrade process to Release 12.1. These fixes are not required to be
applied to environments that have already been upgraded to Release 12.1.
These patches are critical to the upgrade process and it is essential that
they are applied to your Applications Code Tree (APPL_TOP) prior to
running the R12.1 Upgrade Driver. You should look for the latest UPC
on My Oracle Support and add it to your upgrade plan.
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 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.
52
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 free 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 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, to find additional patches that have yet to be uncovered.
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 youve 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

53
patches that need to be applied across all modules, or you can use Patch
Wizard to tell you what it thinks you should apply. Weve 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.
Weve applied the Release 11i Mandatory Extended Support Patches both
ways, using the MOS document and using Patch Wizard, and weve
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 Youve Upgraded to Release 12 and Think
Youre 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.
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.
54

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


55
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
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
56
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.
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.


57
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.
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
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:
58

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.

Upgrade Success Without Customizations
Its 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.

59

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 Oracles EBS Data Model Comparison Report,
which is described in Steven Chans 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 youve 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
determine if your menus have been customized? How about your
responsibilities, your profile options, or your value sets? To help in that
area, were now using 2e2s ConfigSnapshot.
ConfigSnapshot identifies and documents configuration and configuration
differences in the E-Business Suite over time, across instances, entities
and even versions. Key features include:
60
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 customisations
Audit & Compliance support user access control/ visibility,
configuration change tracking, etc.
Easy to install (5 minutes) and intuitive to use
Cost effective
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.

61
1. Plan to Upgrade
Chapter 2 Prepare to Upgrade

Failure is natures plan to prepare you for great responsibilities
Napolean Hilll

Practice 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 its 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:
62
Upgrade the Database to 11.2.0.1
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 migrate 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 Oracles 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

63
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
64
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

65
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 cant 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 use 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.
66

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.

67
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, we
have set the stage 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
68
software with Rapid Install (aka rapidwiz), and execute the upgrade. We
recommend for this first iteration installing and then upgrading Oracles
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 1
st
Pass, is the first iteration that includes
customizations based on functional gap analysis. The 1
st
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 1
st
iteration that is visible to the
developers and functional analysts
The second pass uses the customizations from the 1
st
Pass and any new
customizations, plus fixes from the 1
st
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.

69
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 upgrade paths
below show how to upgrade from earlier versions of Release 11i.
Implement OATM and upgrade the database to the highest compatible
level.
70
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 diagram below show the primary upgrade paths
between versions of Oracle Applications. Most EBS customers are
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.

71

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 cant do the database upgrade separately from
the application upgrade.
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:
72
Upgrade the database to Version 9.2.0.8, which has support for DST,
and then upgrade to Version 11.2.0.1, 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.1.
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 affect 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 hasnt finished.
Similarly, the last weekend of the month, functional analysts are getting
ready to close the books. The middle two weeks of the month present the
best opportunities. In 2010, Memorial Day is observed on a Monday, July
4
th
is on a Monday, Labor Day is on Monday, Columbus Day is on a
Monday, Thanksgiving obviously in on Thursday with business operations
on-hold on Friday during the upgrade. Christmas and New Years are

73
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, youll
need to add an extra day to your schedule. This will require the downtime
to begin Thursday night.

74
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

75
Developer Testing 2 hours
Backup the Upgraded instance 2 hours
User Acceptance Testing 8 hours
Restore the Backup if Testing was destructive
76

77
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 havent 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 upgrade
Use Gather Auto option of 10g
Record timing for each step during the test upgrade
Drop MRC schema before R12 upgrade
Add the PL/SQL no compile option in R12 upgrade driver to save
time during upgrade
78
Add extension plsql_no compile yes line in the upgrade driver file
to enable PL/SQL no compile option
Optimal Number of Workers
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.
Set 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 Optimal Number of Workers
To determine optimal number of workers, test with the following goals:
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 cant 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

79
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: nocompiledb,
nocompilejsp, 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, its 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
80

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:
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

81
On the Applications tier:
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 My Oracle Support Knowledge
Document: 399362.1
82

83
1. Plan to Upgrade
Chapter 4 Finish the Upgrade

We rate ability in men by what they finish, not by what they
attempt
Anonymous
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:

Functional Testing
Functional testing is probably 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
84
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:
Develop Test Scripts
Execute Test Scripts
Perform Unit and Integration Tests
Test Customizations
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
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 Managers 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.

85
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 Applications Upgrade
Guide, Release 11i to 12.1.1, Part No. E14010-01. 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
86
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.
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

87
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:
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
88
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
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.
89
Conclusion
Don't cry because it's over. Smile because it happened.
Dr. Seuss

Thats 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 didnt even know you had. There will continue to
be evil ner 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 cant live without. Take it
in stride, and remember that we at TruTek are a hardworking band of
consultants and trainers who understand what youre going through and
would be happy to help you work through the details.

www.trutek.com 801-486-6655

TruTek r12.1.3UpgradeEssentials

Cargado por

Información del documento

Derechos de autor

Formatos disponibles

Compartir este documento

Compartir o incrustar documentos

Opciones para compartir

¿Le pareció útil este documento?

¿Este contenido es inapropiado?

Copyright:

Formatos disponibles

TruTek r12.1.3UpgradeEssentials

Cargado por

Copyright:

Formatos disponibles

the little r12.1.

También podría gustarte