Best Practices For Adopting Oracle E-Business Suite, Release 12

Best Practices for Adopting Oracle
E-Business Suite, Release 12

An Oracle White Paper
June 2008
Best Practices for Adopting Oracle E-Business Suite,
Release 12
Introduction ....................................................................................................... 5
Implementing versus Upgrading..................................................................... 5
Best Practices ..................................................................................................... 6
Project Best Practices ................................................................................... 6
Tip #1 – Allocate Enough Time for Your Project ............................. 6
Tip #2 – Determine the Appropriate Project Scope .......................... 6
Tip #3 – Determine Your Upgrade Approach.................................... 7
Tip #4 – Plan for Required Financials Setup Steps ............................ 7
Tip #5 – Look for Opportunities to Simplify Your Project.............. 8
Tip #6 – Inventory Your Customizations and Prioritize Them for
Upgrade ..................................................................................................... 8
Tip #7 – Consider Migrating Your Reports to Business Intelligence
Publisher .................................................................................................... 9
Tip #8 – Assemble a Project Team that Combines Technical and
Functional Skill Sets................................................................................. 9
Tip #9 – Involve Your Business Users at Every Project Phase........ 9
Tip #10 – Keep Your Project Team in Place through Your First
Financial Close........................................................................................ 10
Tip #11 – Reexamine User Roles and Responsibilities and Business
Processes.................................................................................................. 10
Tip #12 – Consider Using Oracle’s Process Documentation and
End User Training Tools ...................................................................... 10
Tip #13 – Acquire Release 12 Knowledge......................................... 11
Tip #14 – Fully Utilize Available Upgrade Documentation............ 12
Tip #15 – Use the Maintenance Wizard............................................. 12
Tip #16 – Stay Current with Latest Code .......................................... 13
Tip #17 – Stay Current with Latest Information .............................. 13
Pre- and Post-Upgrade Best Practices ..................................................... 15
Tip #18 – Clear Your Interfaces and Any Processing Exceptions. 15
Tip #19 – Review your Pending Concurrent Requests.................... 15
Tip #20 – Run Key Reports Before and After Your Upgrade ....... 15
Tip #21 – Review Your Custom Concurrent Program
Incompatibilities ..................................................................................... 15
Best Practices for Adopting Oracle E-Business Suite, Release 12 Page 2

Tip #22 – Review Concurrent Programs to Ensure Proper Multiple
Organizations Access Control Settings............................................... 16
Testing Best Practices................................................................................. 16
Tip #23 – Develop a Robust Testing Strategy .................................. 16
Tip #24 – Test with Upgraded As Well as New Data and at Full
Volumes................................................................................................... 17
Tip #25 – Do Load and Volume Testing........................................... 17
Product-Specific Considerations and Tips .................................................. 17
Payables ........................................................................................................ 18
Overview ................................................................................................. 18
Pre-Upgrade Tips ................................................................................... 19
Setup Tips................................................................................................ 19
Operational Tips..................................................................................... 19
Payments ...................................................................................................... 21
Overview ................................................................................................. 21
Planning Considerations........................................................................ 21
Post-Upgrade Tips ................................................................................. 21
Internet Expenses ....................................................................................... 22
Overview ................................................................................................. 22
Pre-Upgrade Tips ................................................................................... 22
Setup Tips................................................................................................ 23
Receivables................................................................................................... 23
Overview ................................................................................................. 23
Setup Tips................................................................................................ 24
Advanced Collections................................................................................. 26
Overview ................................................................................................. 26
Assets............................................................................................................ 26
Overview ................................................................................................. 26
Advanced Global Intercompany System................................................. 27
Overview ................................................................................................. 27
General Ledger............................................................................................ 28
Overview ................................................................................................. 28
Setup Tips................................................................................................ 28
Global Accounting Engine........................................................................ 30
Overview ................................................................................................. 30
Subledger Accounting ................................................................................ 30

Overview ................................................................................................. 30
E-Business Tax............................................................................................ 32
Overview ................................................................................................. 32
Setup Tips................................................................................................ 33
Troubleshooting Tips ............................................................................ 34
Change Record ............................................................................................ 36

Best Practices for Adopting Oracle E-Business Suite,
Release 12
INTRODUCTION
This white paper describes best practices that can help your enterprise become
successful on Release 12. It offers practical advice from professionals in Oracle’s
Support, Consulting, IT, and Development organizations on how to do a Release
12 implementation or upgrade. Said another way, this paper tells you “things you
wish you knew” before embarking upon your Release 12 project.
This white paper is intended to be a living document. As we gather additional
Release 12 best practice advice, we will revise and re-publish this paper.
Release 12 provides the foundation for IMPLEMENTING VERSUS UPGRADING

over 300 new features, and includes new
Let’s start by distinguishing what we mean by the terms “implementing” and
Oracle Financials accounting and tax
“upgrading.” If you adopt Release 12 by implementing, you install the Release 12
engines as well as multi-organization
capability that many customers want to software and implement it to reflect your enterprise structure and operating
take advantage of. practices. You then load any historical data from your legacy systems into your
freshly-implemented Release 12 system using public interface tables and application
programming interfaces (APIs) that Oracle provides. Generally, you use custom
scripts to transform your historical data into a format that is compatible with those
public interfaces. If the legacy system from which you migrate your historical data
is an earlier release of the E-Business Suite, then your fresh implementation may be
described as a “reimplementation”.
If you adopt Release 12 by upgrading, you install the Release 12 software and use
Oracle-supplied tools and scripts to transform your historical data in place to the
new Release 12 data model. The standard upgrade process converts your existing
setup to Release 12 – reimplementation is not required.
Regardless of how you adopt Release 12, it provides the foundation for over 300
new features, and includes new Oracle Financials accounting and tax engines as
well as multi-organization capability that many customers want to take advantage
of. You can analyze these Release 12 new features and implement them at your
own pace at any time after your upgrade.

BEST PRACTICES
The following sections describe Release 12 best practices for project, pre- and post-
upgrade, and testing activities.
A Financials upgrade to Release 12 Project Best Practices

involves significantly more changes than
This section describes best practices for planning and managing your Release 12
the Financials upgrades between Release
project.
11i point releases, such as 11.5.8 to 11.5.9,
or 11.5.9 to 11.5.10.
Tip #1 – Allocate Enough Time for Your Project
Release 12 is a major new release with significant changes in data model and
functionality, especially in the Financials product area. It introduces centralized
functionality to handle accounting, taxation, and access to data across
organizations, and offers more flexible implementation options than were available
in Release 11i to meet a wider variety of business needs.
Set a clear and realistic schedule for your Release 12 adoption project. A Financials
upgrade to Release 12 involves significantly more changes than the Financials
upgrades between Release 11i point releases, such as 11.5.8 to 11.5.9, or 11.5.9 to
11.5.10.
Tip #2 – Determine the Appropriate Project Scope
You may be thinking about combining your Release 12 adoption with related
systems projects, such as upgrading your hardware or your operating system or
merging multiple instances into a single global instance. Since adopting Release 12
of Financials involves a substantial amount of change, consider whether keeping
your project as simple as possible is the best option for your business.
The standard upgrade moves you from Release 11i to 12 with the same setups and
functionality, plus some additional, default functionality around tax, subledger
accounting, ledgers and payments. You then have the option to implement
additional new functionality either immediately, as part of the same project, or in a
subsequent project.
In general, consider whether to scope your Release 12 adoption as a single project
that fully encompasses all the changes you are targeting, or to divide your adoption
into multiple projects. For example, you could separate an upgrade to your
hardware platform from your upgrade to Release 12. You could further simplify
your project by performing a minimal upgrade, versus upgrading and fully
implementing new features to the target state.
The advantage of phasing your Release 12 adoption across multiple projects is that
you minimize the risk and changes to your business undertaken in any one of those
projects. However, depending on your circumstances, you may want to scope your
adoption to include all the features that support your return on investment as a
single project.

Tip #3 – Determine Your Upgrade Approach
If you are moving from an existing release of Oracle E-Business Suite to Release
12, you should consider whether to perform a standard upgrade versus a
reimplementation. A standard upgrade allows you to take advantage of supported
tools, scripts and documentation to move your existing Release 11i setups and
historical data to Release 12. A reimplementation, on the other hand, allows you
greater flexibility in your setup and in how you migrate your historical data using
supported public interfaces. It is a project that you would generally undertake with
the support of a professional services provider, such as Oracle Consulting. You
would consider doing a reimplementation under circumstances such as:
• You wish to change configurations that are not easily changed, such as your
chart of accounts definition, costing method, or calendar.
• Your enterprise has undergone significant change in the number and
structure of its business units and organizations since your original Oracle
implementation. For example, you have grown through acquisition and you
want to establish a new standard applications setup for all of your business units,
which are currently running disparate application systems. You could freshly
implement Release 12, and then migrate historical data from your existing
businesses, even if some of those businesses were running E-Business Suite.
Some accounting entities (such as taxes, Tip #4 – Plan for Required Financials Setup Steps
banks and suppliers) that were modeled by Even a minimal upgrade requires some setup of the new Financials features that
several Financials products in Release 11i
come by default, such as Trading Community Architecture (TCA) for supplier data,
have moved to a common implementation
Payments and E-Business Tax.
in Release 12.
Some accounting entities (such as taxes, banks and suppliers) that were modeled by
several Financials products in Release 11i have moved to a common
implementation in Release 12. If you have setup inconsistencies among Release 11i
products for setups that are centralized in Release 12, then you should try to resolve
them before you upgrade. For example, since supplier data moves from individual
product tables in Release 11i to common TCA tables in Release 12, you should
review your 11i supplier data and remove any duplicates.
Furthermore, the upgrade scripts that move Release 11i Financials setups to Release
12 are based on assumptions, detailed in the Oracle Financials and Oracle Procurement
Functional Upgrade Guide, of what is appropriate for most business situations. If
those assumptions would lead to an outcome that is inappropriate for your business
situation, plan on modifying your Release 12 Financials setups.
You can run the Accounting Setup Manager Pre-Update Diagnosis Report to view
your Release 11i setup for Multiple Reporting Currencies, General Ledger, Global
Accounting Engine, Assets, Payables, and Receivables. This report identifies setups
that are potentially problematic. While you can upgrade successfully without
running this report and without modifying your setup, you may find it more
difficult to take advantage of new Release 12 functionality.

Tip #5 – Look for Opportunities to Simplify Your Project
Many successful projects have taken the approach of simplifying the project to
reduce risk.
For example, during Oracle’s adoption of Release 12, we completed as many tasks
as we could ahead of the actual upgrade. For example, we reviewed and
standardized our setups, and we eliminated obsolete reports, alerts, responsibilities,
and other data to reduce our testing and upgrade effort.
We replaced custom functionality with standard product while still at the 11i.10
level. For example, we started moving our consulting organization onto the Oracle
Time and Labor module a year before we upgraded to Release 12, finishing the
moves for the last group of countries at the time of the upgrade.
We identified features we could enable prior to Release 12. For example, we
moved Receivables users off of the Collections Workbench and onto the newer
Advanced Collections module. (In Release 12, users assigned to the seeded
Collections menu are automatically redirected to the Advanced Collections forms.)
We also applied the latest 11i family pack for HRMS (Family Pack K, RUP2) a few
months prior to upgrade. While we needed to take HRMS RUP2 while still on 11i
due to mandatory year-end, tax-related changes, a side-benefit of doing so was that
we introduced HRMS functionality close to Release 12, making the upgrade delta
smaller.
Inventory your customizations and Tip #6 – Inventory Your Customizations and Prioritize Them for Upgrade
determine which functions could be
Inventory your customizations and determine which functions could be replaced by
replaced by standard product in Release
standard product in Release 12. For any customizations that remain, validate with
12.
your business users which customizations are most critical to them so that you can
prioritize your upgrade effort. It may be possible to defer the implementation of
some customizations until after the initial upgrade project.
You should review the impact of changes to database objects on your custom code.
In particular, note that with Release 12, the backward-compatible views
RA_CUSTOMERS and RA_ADDRESSES are no longer available, so you should
change any custom code that references them to reference the relevant Trading
Community Architecture (TCA) tables instead. Lists of Release 12 database
changes are included in the Technical Overview documents that are part of the
Release 12 Transfer of Information (TOI) Online Training, accessible from
OracleMetaLink Note 403349.1.
It might be necessary to engage Oracle Consulting or an Oracle partner to execute
a detailed CEMLI (Customization, Extension, Modification, Localization, and
Integration) framework review. This should be done to assist in properly planning
your upgrade program.

Tip #7 – Consider Migrating Your Reports to Business Intelligence Publisher
Oracle Business Intelligence Publisher (Oracle BI Publisher), formerly known as

XML Publisher, is an enterprise reporting solution for authoring, managing and
delivering all types of highly-formatted documents. End users can easily design
report layouts using familiar desktop tools, such as Microsoft Word, Microsoft
Excel, or Adobe Acrobat. BI Publisher can query or accept data from practically
any data source – databases, packaged applications, web services, HTTP feeds, or
file data sources.
BI Publisher was used in Release 11i.10 for high-fidelity formatting of many
external documents. With Release 12, many more standard reports use BI
Publisher. For BI Publisher-based reports, an XML data extract is provided along
with a default layout (template) that you can easily modify.
Custom reports based on Pasta or mod_plsql are not supported in Release 12, and
should be converted to BI Publisher. Consider converting your custom Oracle
Reports reports to BI Publisher, as well. If you move your custom reports to BI
Publisher before upgrading to Release 12, you may need to adjust the queries you
use to produce the report output, but your formatting will remain valid for Release
12.
Involve business users from the start of Tip #8 – Assemble a Project Team that Combines Technical and Functional Skill Sets
your project so that they are prepared for
Consider including the following people on your Release 12 project team:
Release 12 changes in look and process
flow. • A dedicated project manager
• An executive steering committee
• Application business owners – in particular, a tax specialist who knows the
tax policies in regions where you do business
• Technical applications specialists – technical specialists who work closely
with business owners
• Technical team – one or more people who can function as a technical
upgrade specialist, an operating system administrator, a database
administrator, an applications server (middle tier) specialist, a performance
specialist, a change management specialist, and a customization developer
• Testers – both technical and functional. You will also need someone to log
and track service requests (SRs), and a DBA to apply patches.
• A training lead – to assist in the rollout to end users
If you decide to retain outside consultants to provide expertise that is lacking from
your in-house team, prefer consultants with prior Release 12 experience.
Tip #9 – Involve Your Business Users at Every Project Phase
Involve business users from the start of your project so that they are prepared for
Release 12 changes in look and process flow. Identify the functional areas where

users will see the biggest changes and concentrate your training efforts there. For
example, in Oracle Payables, the payments process uses a new Payments
dashboard, and the Invoice workbench is significantly reworked.
Plan to reinforce end user learning even after your production cutover with internal
documentation and job aids.
Keep your Release 12 project team in Tip #10 – Keep Your Project Team in Place through Your First Financial Close
place at least through your first financial
Keep your Release 12 project team in place at least through your first financial
close.
close. Your project team can monitor the health of your system, logging service
requests as needed and notifying end users through broadcast e-mails of any
significant issues. The project team can serve as a backup to the smaller in-house
support team that normally handles end user queries.
Tip #11 – Reexamine User Roles and Responsibilities and Business Processes
You should reexamine user roles and responsibilities due to business process
changes introduced by Release 12. For example, who should be responsible for any
issues related to the new tax and subledger engines? Who will read and interpret
the related exception reports? As part of Oracle’s upgrade project, global process
owners reviewed Release 12 process changes with business users, and redefined
roles and responsibilities accordingly.
Tip #12 – Consider Using Oracle’s Process Documentation and End User Training Tools
Oracle Tutor is a Microsoft Word-based tool for documenting business processes,

policies, and procedures. You can start with the model business processes
delivered with Oracle Tutor and customize them to reflect your Release 12
implementation. With Tutor, you can also generate end user desk manuals and a
variety of job aids.
Oracle User Productivity Kit (UPK) is a valuable tool for training end users on how
to use the system to accomplish your business processes. UPK allows you to
record the flow through application screens, creating UI simulations with which
users can interact.
Oracle offers pre-recorded UPK content modules for Release 12 products. Using
these as a starting point, you can create training on how to use Release 12 to
accomplish your business processes. UPK allows you to train current users on
Release 12, and it facilitates the training of new users at any point after the initial
rollout.

Figure 1: User Productivity Kit
A good roadmap to Release 12 information Tip #13 – Acquire Release 12 Knowledge

is presented in the “Oracle E-Business
A good roadmap to Release 12 information is presented in the “Oracle E-Business
Suite Upgrade Resources” page on
Suite Upgrade Resources” page on OracleMetaLink, Note 461705.1. From there,
OracleMetaLink, Note 461705.1.
you can access the “Oracle Applications Documentation Resources: Release 12”,
Note 394692.1, which indexes the complete Release 12 documentation set.
If you are upgrading from a prior E-Business Suite release, you should review
Release 12 enhancements module by module, understanding new features and
process changes that come by default, along with optional new features that you
may want to implement.
For an overview of new and changed features since Release 11.5.10, see the Oracle
E-Business Suite Release 12: Release Content Documents (RCDs), Note 404152.1.
If you are upgrading from a release earlier than 11.5.10, you can get the intervening
RCDs as well.
Transfer of Information (TOI) online training modules are another source of
“what’s new” information, accessible from OracleMetaLink Note 403349.1.
Organized by application or major feature, TOIs present either functional changes
(setup and use), or technical changes (to database objects, profile options, code
objects, and so on.)
Project team members new to Oracle E-Business Suite or those needing a refresher
should consider enrolling in instructor-led training at an Oracle training facility.
These courses allow you to get hands-on with Release 12 before you start your
project.

Figure 2: Oracle E-Business Suite Upgrade Resources
Tip #14 – Fully Utilize Available Upgrade Documentation
The Oracle Applications Upgrade Guide, Release 11i to Release 12.x, documents
mandatory, recommended and optional tasks you should perform before, during,
and after an upgrade. The appendices in the back of the guide describe data
verification procedures as well as upgrade impacts to existing products. For a more
detailed discussion of Financials and Procurement upgrade impacts, see the Oracle
Financials and Oracle Procurement Functional Upgrade Guide: Release 11i to Release 12.
Tip #15 – Use the Maintenance Wizard
The Maintenance Wizard is a free tool (available on OracleMetaLink via

Note 215527.1) that provides a step-by-step, graphical user interface for performing
upgrade tasks. It consolidates instructions from the upgrade guide with other
relevant documents to present a complete picture of the upgrade process.
The Maintenance Wizard can help you reduce upgrade tasks by filtering out those
that do not apply to you. It also indicates critical patches that your system requires.
It can automatically execute upgrade tasks for you, and maintains a log with status
information for all executed tasks.

Figure 3: Maintenance Wizard
Stay current with Release Update Packs Tip #16 – Stay Current with Latest Code
(RUPs), which consolidate the latest
Take advantage of the latest available Release 12 code. For example, stay current
maintenance fixes for the release.
with Release Update Packs (RUPs), which consolidate the latest maintenance fixes
for the release. It is particularly important for Financials customers to keep current
with latest code. To that end, we publish a document called "EBS: R12 Oracle
Financials Critical Patches", OracleMetaLink Note 557869.1.
Oracle appreciates that customers are sometimes reluctant to apply the latest RUP
or critical patch because they are concerned about the time needed to apply and test
these recommended fixes. Since the alternative may be to cycle through the time-
consuming process of identifying, reporting, qualifying, fixing, and testing fixes for
what ultimately are found to be known issues, customers should consider whether
it is more efficient to proactively apply RUPs and critical patches at their earliest
maintenance opportunity.
Tip #17 – Stay Current with Latest Information
Monitor the E-Business Suite R12 Information Center (on OracleMetaLink, click
the Headlines tab, E-Business Suite sub-tab, E-Business Suite R12 Information
Center button) for the latest information on certifications, Release Update Packs,
diagnostics, documentation resources, and so on.

Figure 4: E-Business Suite R12 Information Center
For proactive notification of changes to information on OracleMetaLink, you have

For proactive notification of changes to
several options:
information on OracleMetaLink, you have
several options. To monitor new or updated articles for a selected product or platform:
1. Log into OracleMetaLink.
2. Under Headlines, scroll to the Knowledge Base region.
3. Click the Edit button.
4. From the Product or Platforms choice lists, select the product or platform
of interest, causing the related notes to be featured under the Knowledge
Base region.
To bookmark an article (or bug or service request) so you can quickly check for any
changes to it:
2. In the Quick Find field, select Knowledge Base, and enter a Note ID.
3. From the search results, select the note of interest.
4. Click the Bookmark link, adding the note to the Bookmarks list that you can
display by clicking Bookmarks at the bottom of any OracleMetaLink page.
To automatically email “My Headlines” to yourself at a specified interval:
2. Under Headlines, click the Edit Page button.
3. Under Headlines Settings, select the frequency in days at which you will be
emailed in the “In each My Headlines section, show entries for the last:”
field; set “Automatically email My Headlines to me:” to Yes.

You can also take advantage of less formal Release 12 information channels, such
as forums.oracle.com, and blogs.oracle.com.
Pre- and Post-Upgrade Best Practices

This section provides best practices for the activities you undertake immediately
before and after your upgrade.
Tip #18 – Clear Your Interfaces and Any Processing Exceptions
Before you upgrade, clear your interfaces and any processing exceptions so that
after the upgrade, your interfaces are clean, with nothing “stuck” in them. For
example, just prior to upgrade:
• Import all invoices from the Payables open interface
• Confirm or cancel all Unconfirmed Payment batches
Pay particular attention to the 11i interface table between Projects Accounting and
General Ledger (PA_GL_INTERFACE) because it becomes obsolete during the
upgrade.
Tip #19 – Review your Pending Concurrent Requests
Review all of your pending concurrent requests prior to the upgrade and decide
which to cancel or put on hold. By preventing concurrent requests from
automatically running after the upgrade completes, you allow yourself a window for
doing setup and validation without interference from production activities.
Cancel any pending concurrent requests that would not be appropriate in Release
12 due to process changes. Place on hold any other valid concurrent requests so
that you can run them at a time you choose after the upgrade. For example, you
may want to run post-upgrade reconciliation reports before allowing any new
transactions to be created.
Tip #20 – Run Key Reports Before and After Your Upgrade
Run key reports just before your upgrade and again just after your upgrade to allow
for data verification and reconciliation. For example, run the Payables Trial
Balance report in Release 11i, and then again in Release 12 for the same period or
month.
Tip #21 – Review Your Custom Concurrent Program Incompatibilities
Review your custom concurrent program incompatibilities after the upgrade to

ensure that they are appropriate. You may need to define new incompatibilities or
eliminate existing ones due to new programs and new program interactions in
Release 12.

Tip #22 – Review Concurrent Programs to Ensure Proper Multiple Organizations Access
Control Settings
With Release 12, Multiple Organizations Access Control (MOAC) allows a single
Applications responsibility to access multiple operating units, if desired. During the
upgrade, some concurrent programs are automatically enabled for MOAC so that
they will run for all organizations. Review your concurrent programs after the
upgrade to verify that any meant to run only for specific organizations are set up to
reflect this.
We cannot over-emphasize the importance Testing Best Practices

of testing to the success of your Release
This section describes best practices for testing Release 12 in your environment.
12 project.
We cannot over-emphasize the importance of testing to the success of your Release
12 project.
Tip #23 – Develop a Robust Testing Strategy
As with any new release, you should formulate a testing strategy that details the
number of test rounds, types of testing, and who will be involved, with an overall
goal of performing end-to-end testing of all business flows and scenarios. In
addition to conference room pilot testing to validate setups, ensure that you do full
functional testing with business users.
Perform multiple rounds of testing, focusing on new and changed functionality.
The number of test rounds and your acceptance criteria should be carefully
considered at the outset of your project, and then reconsidered before and after
each test round.
The timeframe for your testing rounds needs to be clearly stated. Issues and slow
turnaround on resolutions may affect your testing period; make sure you budget
enough time for issue resolution. Agree in advance what types of issues should be
considered as show-stoppers to putting Release 12 into production, or even to
advancing to the next test round.
Your testing should be guided by detailed test scripts that you prepare in advance.
You can start with the test scripts used in your original implementation, updating
them to reflect the new Release 12 functionality and process changes that you
intend to implement.
Well before your go-live, begin performing test upgrades to establish that the
upgrade will fit into your downtime window, and to allow for tuning of upgrade
scripts as needed. Also, track any upgrade impacts on your custom code.
You can use Maintenance Wizard to record the outcome of your various test
upgrades, annotating individual upgrade steps with hints, lessons learned, or advice
that will help you during the actual upgrade. You can even create custom steps at
the appropriate spots in the tool so that custom actions won't be forgotten on
subsequent upgrade attempts. The Maintenance Wizard also keeps logs for each

execution of each step, so you have documentation of what happened, when it
happened and who did it.
Tip #24 – Test with Upgraded As Well as New Data and at Full Volumes
Test all of your business scenarios with documents upgraded from Release 11i as
Test all of your business scenarios with
well as those created in Release 12. Test performing operations in Release 12 on
documents upgraded from Release 11i, as
well as those created in Release 12. documents that were created in Release 11i. For example, test that an invoice
created in Release 11i can have a credit memo issued against it in Release 12 with
matching tax calculations. Or, create a payment in Release 11i, then void it in
Release 12. This would validate that setup differences between Release 11i and 12
do not create inconsistencies in a business document as it completes its flow.
In-progress workflow items should, in general, upgrade smoothly. However,
validate this with testing, especially where you have customized Release 11i pre-
seeded workflow processes or activities. You could consider reducing the number
of in-progress workflow items by turning off applications such as iExpenses and
iProcurement for some interval prior to your upgrade, and encouraging your
managers to respond to pending workflow notifications.
While your initial conference room pilot testing may validate setups based on
sample or demonstration data, it’s critical that you do full, end-to-end testing on the
complete data set that you intend to run in production. Release 12 data validation
is even tighter in than in prior releases, so you need to find whether there are any
data conditions that would fail Release 12 validation. In particular, Oracle
recommends that you test your month-end close and reconciliation with full data
volumes, and that you resolve any exceptions.
Tip #25 – Do Load and Volume Testing
Because new reports and business processes may be sensitive to your data
distribution, and to ensure that your system has the expected performance
characteristics, make sure you do load and volume testing.
PRODUCT-SPECIFIC CONSIDERATIONS AND TIPS

The following section describes Release 12 Financials product-specific changes and
planning considerations. It also provides tips related to pre-upgrade, post-upgrade,
setup, operational, and troubleshooting activities.
This section is by no means a complete treatment of the Financials products or
features; it simply highlights information that you may wish to consider for
planning purposes.
For a complete discussion of Release 12 upgrade impacts to Financials products,
refer to the Oracle Financials and Oracle Procurement Functional Upgrade Guide: Release 11i
to Release 12. For a complete discussion of product-specific implementation and
operation, refer to the standard implementation and user guides. All Release 12

documentation is available via OracleMetaLink Note 394692.1, “Oracle
Applications Documentation Resources: Release 12”.
Release 12 introduces Oracle Subledger Payables

Accounting, Oracle E-Business Tax,
Ledgers, Banks, and other common data Overview
model components that are used by Oracle
Release 12 introduces Oracle Subledger Accounting, Oracle E-Business Tax,
Payables.
Ledgers, Banks, and other common data model components that are used by
Oracle Payables.
The following Payables features are new in Release 12:
• Suppliers are defined as Parties within the Oracle Trading Community
Architecture (TCA).
• Invoice Lines are introduced as an entity between the Invoice Header and
Invoice Distributions to better match the structure of invoice documents and
to improve the flow of information such as manufacturer, model and serial
number from Purchasing through to Assets.
• Banks, bank branches, and internal bank accounts are defined centrally and
are managed in Oracle Cash Management.
• Document sequencing of payments has moved to the Cash Management
bank account setup.
• Payments and all funds disbursement activities are handled by a new
module, Oracle Payments.
• Payment features controlled by Global Descriptive Flexfields (GDF) in
prior releases have been consolidated and migrated into the data models of
Oracle Payables, Oracle Payments, and Oracle Cash Management. The
architecture of this solution moves attributes from the GDFs, which are now
obsolete, to regular fields on the appropriate entity, including the invoice,
payment format and document, supplier site, and bank account. Having a
single code base as opposed to GDFs implemented per country simplifies
global implementations and streamlines transaction processing.
• Oracle Subledger Accounting, a new module in Release 12, handles
accounting definitions and all accounting setup associated with a Ledger. (In
Release 12, Oracle General Ledger has replaced Sets of Books with Ledgers.)
As part of this change, centralized accounting reports are available to all
applications. Additionally, Oracle Payables introduces a new Trial Balance
report.
• Oracle E-Business Tax, a new module in Release 12, manages transaction
tax setup associated with trading partners and tax authorities, as well as
transaction tax processing and reporting across the Oracle E-Business Suite.
Part of the architecture of this solution moves tax attributes from Global

Descriptive Flexfields (GDFs), which are obsolete in Release 12, to regular
fields on the appropriate entities.
• A Responsibility can be associated with multiple Operating Units using
Multiple Organization Access Control (MOAC). Due to this change, all
processing and some reporting in Oracle Payables are available across
Operating Units from a single applications responsibility. Hence you can
isolate your transaction data by operating unit for security and local level
compliance while still enabling shared service center processing.
Pre-Upgrade Tips
Just prior to the upgrade:

• Import all invoices from the Payables open interface.
• Confirm or cancel all Unconfirmed Payment batches.
• Run the Payables Accounting Health Check script (see OracleMetaLink
Note 416699.1) to ensure that there are no inconsistencies in your 11i data.
Setup Tips
• Once you have set options for Automatic Offsets, do not change them.
Doing so would represent a major setup change that does not update past
transactions and would lead to accounting issues. A change in Automatic
Offsets should be considered as a project that includes full testing before
being implemented in your production system. Past transactions must be
cleared before such a change.
• When specifying the Open Balances Definition, include all code
combinations that need to be reconciled (accounts that can be attached at the
Invoice header level.) If automatic offsets are on, include the overlay
accounts that can be generated.
• When defining new bank accounts, ensure that cash clearing and cash
accounts have been provided at the bank accounts control level.
Run the Invoice Validation program on a Operational Tips

regular basis (at least daily) to determine if
there are invoices that are not getting Regular Activities
validated. The best practice is to schedule
• Run the Invoice Validation program on a regular basis (at least daily) to
a concurrent request so that it runs daily
determine if there are invoices that are not getting validated. The best practice
at a time when load is not high.
is to schedule a concurrent request so that it runs daily at a time when load is
not high.
• Run the Create Accounting program on a regular basis (at least daily) to
identify invoices that are not getting accounted.
• When you make manual entries to the General Ledger, ensure that proper
descriptions are provided so that they can be tracked back as required

• For U.S. implementations: Once you begin creating 1099 payment
information for 1099 suppliers, periodically review the information to verify
its accuracy and completeness. Payables provides three standard reports to
help you identify 1099 reporting exceptions:
• 1099 Supplier Exceptions Report - Review this report to identify 1099
supplier exceptions, for example: null, non-standard or duplicate TIN.
Correct any exceptions in the Suppliers form.
• 1099 Invoice Exceptions Report - Review this report to identify and correct
invoices without income tax types for 1099 suppliers, 1099 invoices for a
non-1099 supplier, and 1099 invoices with null or invalid income tax
regions.
• Tax Information Verification Letter - Submit the Tax Information
Verification Letter report for each supplier, requesting name, address,
TIN, and type of organization.
Period Closing-related Activities
• Consider doing a mock closing at least 5 days before your actual close.
Check the exceptions report for any unusual activity, for example: Invoices or
Payments that should have been accounted but are still appearing in the
report, or Invoices that should have been validated but are still appearing in
the report.
Reconciliation-related Activities
• Ensure that accounts used as liability accounts, and that need reconciliation,
are not used for any other purpose. For example, such accounts should not
be used in any other subledger and no manual entries should be made against
them. To ensure this, make these accounts control accounts using a new
feature of Release 12.
• Ensure that accounts used as liability accounts, and that need reconciliation,
are not used as accounts at the distribution level. Otherwise, reconciliation
will become difficult.
• After closing the periods in Payables and General Ledger, please run the
needed reports to balance within Payables. This would typically include the
Trial Balance, Posted Invoice Register, and Posted Payment Register reports.
You’ll also need to run the Account Analysis in General Ledger and reconcile
that to Payables. Ensure that a monthly reconciliation is performed. Track
any unexpected data.

Payments
In Release 12, the Oracle E-Business Suite
introduces Oracle Payments, a Overview
configurable, robust and centralized
engine for disbursing and receiving
In Release 12, the Oracle E-Business Suite introduces Oracle Payments, a
payments. configurable, robust and centralized engine for disbursing and receiving payments.
In addition to new features, Oracle Payments offers functionality previously
released as Oracle iPayment, which becomes obsolete with Release 12.
Oracle Payments provides a new formatting solution based on standard XML
technology. In previous releases, payment formats were created using proprietary
Oracle reports technology. In Release 12, payment formats are created as templates
in Oracle BI Publisher, and are applied to XML data extracts produced by Oracle
Payments.
Planning Considerations
The Release 11i iPayments setup is migrated to the Release 12 Payments module.
All Release 12 payment formats are BI Publisher-based; the 11i payment formats
are obsolete. Oracle seeds payment formats in Release 12 corresponding to those
that were seeded in 11i.
You may need to configure the seeded payment formats using BI Publisher to
satisfy the requirements of your banking partners. This configuration involves
modifying the format files, and then sending them to your banking partners for
validation. You may need to repeat this process a few times before your format
files are validated, so ensure that you allocate enough time. For more information
on upgrading your Release 11i payment formats, see OracleMetaLink
Note 549024.1.
Post-Upgrade Tips
• Dummy Funds Capture setup in Payments is required to perform

Automatic Receipts transactions in Receivables.
• In Release 11i, bank accounts were not centralized and customer bank
accounts were stored in Receivables tables. Oracle iPayment was leveraged
only for credit card transactions. Receipt remittance was done by a format
program within Receivables. In Release 12, Oracle Payments is required
for remitting receipts since bank accounts are centralized in Payments.
Therefore, the minimal Payments setup (for Payee, Payment System,
Funds Capture Process Profile, and so on) is required in Release 12 for the
remittance of receipts.
• A user can create dummy Payments setup per the following OracleMetaLink
notes:
o 471418.1 – Oracle Payments Setup for Funds Capture Processing
o 553614.1 – Funds Capture Setup for Credit Card Processing

Internet Expenses
Overview
Release 12 changes to Oracle Internet Expenses include:

• Itemization – Internet Expenses can represent the parent-child relationship
of an itemized expense line by creating a new parent line with a unique
identifier.
• Integration with Payments – Integration with Oracle Payments takes
advantage of encryption capabilities. Credit card transaction data has been
centralized in Payments’ secure payment data repository.
• Per Diem and Mileage – Per diem and mileage transaction data are not
migrated. However, per diem and mileage setup data is automatically
upgraded.
• Expense Reports – Expense Reports that were created prior to the upgrade
display information in a pre-Oracle Internet Expenses minipack (11i.OIE.K)
format. Newly-created expense reports use the new user interface.
• Integration with Oracle E-Business Tax – The integration with Oracle E-
Business Tax has no direct tax upgrade impact. Tax lines run through Oracle
Payables.
Prior to the upgrade, it’s important to review your catalog data. A recommended
pre-upgrade procedure for identifying and fixing exceptions in your catalog data is
documented in the “Reducing Downtime” appendix of the Oracle Applications
Upgrade Guide: Release 11i to Release 12.0.x.
You should also remove duplicate suppliers and sites from your supplier data prior
to the upgrade to reduce the number of parties created in Trading Community
Architecture (TCA).
Consider implementing Multiple Organization Access Control (MOAC) for those
responsibilities that are new with Release 12 and designed to be MOAC, for
example, the supplier profile administrator for creating and managing suppliers.
Although the Release 11i per diem and mileage schedules are migrated to Release
12, detailed testing is recommended.
With Release 12, entering and viewing project information in Internet Expenses
changes. Be sure to address these changes in your user training.
Pre-Upgrade Tips
• Since the Expense Report Import program is obsolete in Release 12, submit
it just prior to the upgrade to ensure that all intercompany data in Internet
Expenses interface records is imported into Oracle Payables. Fix any
rejections and resubmit until all records are imported.

• In Release 12, the address for the Employee Supplier cannot be changed; it
is the address in HRMS that is used for making payments to employees.
Before you upgrade, make sure that the address for the Employee Supplier is
the same both at the Supplier Site and in the HRMS application.
Post-Upgrade Tips
• In Release 12, tax is always marked as inclusive for the expense report lines
containing a Tax Code. When entering an expense report, a user should
enter an amount that is inclusive of the tax amount for the expense line.
Setup Tips
• The Cost Center segment should be defined as an independent segment to

render the proper value for cost center on an Expense Report.
• To apply advances to an Expense Report, use one of the following
processes:
• If you would like the User / Auditor / Both to apply advances, then set the
profile option “OIE:Enable Advances” to End User / Payables / Both.
• If you would like advances to be automatically applied while exporting
expense reports to Payables, then check the “Apply Advances” checkbox
at the Payables Options > Expense Report tab.
Receivables
Overview
Release 12 changes to Oracle Receivables include:

• Integration with E-Business Tax – Release 12 introduces Oracle E-Business
Tax to manage tax across the E-Business Suite. During the upgrade, system
and customer options used to control tax calculation and tax code defaulting
are migrated from Oracle Receivables into Oracle E-Business Tax entities.
• Integration with Subledger Accounting – Release 12 introduces Subledger
Accounting for managing accounting across subledger transactions.
Receivables no longer creates any accounting entries. Existing Receivables
accounting options and setups remain, and they affect the generation of
accounting distributions in the Receivables data model.
• Centralized Banks and Bank Accounts Definitions – In Release 12, all
internal banks and bank accounts you previously defined for your operations
are migrated to central Cash Management entities. Remittance bank accounts
are owned by a legal entity rather than by an operating unit. However, bank
accounts you defined for your customers are migrated from the Payables
entities to the centralized Payments entities. Oracle Payments centralizes and
secures all payment instrument data, including external bank accounts, credit
cards, and debit cards.

• Integration with Payments for Funds Capture – Release 12 introduces
Oracle Payments, which is used by Oracle Receivables for processing funds
capture.
In Release 12, suppliers are modeled in the Trading Community Architecture

(TCA), and there is a new user interface for maintaining suppliers. Backward-
compatible Receivables views to customer and supplier tables no longer exist, so if
you have custom reports running against those views, plan to modify them to run
against the TCA tables.
Setup Tips
• Model your customer accounts and sites according to the best practices
recommended in the white paper, “Oracle Trading Community Architecture:
Modeling Customer and Prospect Data – TCA Best Practices”,
OracleMetaLink Note 164519.1.
• Submit the Create Accounting program in draft mode and review the
accounting before submitting in final mode and posting to the General
Ledger.
• Run the Create Accounting program on a regular basis (at least daily) to
identify invoices that are not getting accounted.
Operational Tips
Performance-related:
• To process large volumes, run multiple instances of the “Automatic

Receipts Creation Program (API)” program concurrently for all of the
Receipt Class/Payment Methods that have been set up.
• Leverage the “Remittance Parallelization” feature of Receivables to improve
the performance of the remittance program. You can schedule multiple
instances of the “Automatic Remittances Creation Program (API)” program
to run concurrently for as many remittance bank accounts as you have.
• To process large volumes, run multiple instances of the Revenue
Recognition Master program, scheduling each instance by operating unit and
specifying the maximum number of workers per run. This will result in
launching multiple workers per scheduled instance.
• You can run multiple instances of the Late Charges program for specific
operating units. The number of parallel workers can be used to distribute the
processing load for the Late Charges program instance across multiple jobs
or workers, resulting in faster generation of your finance charges.

• You can run multiple instances of the Submit Accounting program by
Ledger and End Date combinations for which a unique set of accounting
events associated with Receivables distributions are selected.
Reconciliation-related:
• Perform the following pre-requisite steps before starting the Receivables to

General Ledger reconciliation:
• Ensure that the Create Accounting program in Receivables has successfully
completed.
• Review the Un-posted Items reports to confirm that all items are posted to
the General Ledger.
• Review the Posting Execution Report to check that journal entries
transferred from Receivables are successfully posted to the General
Ledger. Receivables automatically prints the Posting Execution Report
that displays a summary line for each currency within every category of
transaction that you transfer.
• The following steps are recommended for reconciliation of Receivables with
General Ledger:
• Run the Receivables Reconciliation Report as the first step in the
reconciliation process. It displays summary information consistent with
detailed registers and journal reports. It also displays transactional data in
an Activity column, and accounting data in a Journal column. If any
discrepancies exist, run the following reports for more details:
o Transaction Register versus Sales Journal
o Adjustment Register versus Adjustment Journal
o Applied Receipts Register versus Journal
o Unapplied and Unresolved Receipts Register versus Journal
o Invoice Exception Report
• Run the Potential Reconciling Items Report to view items that might have
accounting setup errors. This report suggests journal items that might
potentially post to General Ledger accounts with unexpected account
types, thus creating reconciliation issues in General Ledger. When a
potential reconciling item is an error, correct the individual transaction as
well as the incorrect setup to prevent future occurrences of the error.
• Run the Ageing - 7 Buckets - By Account OR the Ageing - 4 Buckets report
to view beginning and ending customer balances, and to compare with AR
Reconciliation Report balances.
• Run the Journal Entries Report after completing Create Accounting (Final
Accounting) to show the accounting data transferred to Subledger

Accounting. This should be matched with the AR Reconciliation Report to
ensure that Receivables versus Subledger Accounting reconciliation is
done.
• Run the AR to GL Reconciliation Report to ensure that there are no
differences.
o Run this report after transactions in Receivables are posted to
General Ledger and there are no unposted transactions per the
“Unposted Items” report.
o This report compares the account balances in Receivables to
those in General Ledger and highlights the journal sources where
discrepancies might exist.
The Collections Workbench module in Advanced Collections

Oracle Receivables is obsolete and is
replaced with comparable functionality in Overview
Oracle Advanced Collections.
The Collections Workbench module in Oracle Receivables is obsolete and is
replaced with comparable functionality in Oracle Advanced Collections. This
includes functionality relating to customer interactions and correspondence,
transaction processing, and dunning activities. With Release 12, additional features
such as scoring, collections strategies, enhanced payment and promise processing,
automated promise tracking, and automated collector work assignment are also
available.
Receivables users who have not purchased a license for Advanced Collections are
not authorized to use the full feature set of this product. The Receivables
Collections Workbench has been replaced with a limited version of Oracle
Advanced Collections for Oracle Receivables. Details on the collections features
available in Receivables and the features available in Oracle Advanced Collections
are provided in OracleMetaLink Note 389443.1.
Assets
Overview
In Release 12, Oracle Assets adds Subledger Accounting (SLA) functionality. By

default, transactions in the current fiscal year in Assets books will have their
accounting lines migrated to the Subledger Accounting model. Accounting for
current period depreciation will be upgraded only if depreciation has already run for
the period, and the period remains open. After the upgrade, you can run the SLA
post-upgrade process to update accounting for past transaction data as needed.

Operational Tips
• Important reports such as the transaction diagnostics report and

reconciliation reports should be run before closing the period to ensure that
the accounting entries are reviewed and verified.
• Whenever a Retirement or Reinstatement transaction occurs, the Calculate
Gain and Loss program should be run before the Create Accounting program
is run.
• If you are using multiple asset books that link to the same ledger, ensure
that the natural account segment value of the asset clearing account is unique
for each asset book.
• Once Group Asset Advanced Rules options are defined, you cannot change
them. Review group asset options carefully to determine which ones satisfy
your requirements for accounting and tracking of group and member assets.
Advanced Global Intercompany System
Overview
The Oracle Advanced Global Intercompany System (AGIS) is a new module in

Release 12 that allows companies to streamline intercompany processing and
facilitates the reconciliation of intercompany transactions. It replaces the Global
Intercompany System (GIS) feature provided by General Ledger in Release 11i.
All GIS setup and transaction data are moved to the AGIS data model. It’s a good
idea to review existing 11i intercompany rules and update them as necessary before
the upgrade.
Post-Upgrade Tips
• The Intercompany accounts in GIS are upgraded to AGIS Intra-company

Balancing rules. Auto-Accounting rules in GIS are not upgraded, and need to
be set up as Account Derivation Rules and compiled with the Transaction
Account Builder in Subledger Accounting.
• Creating intercompany organizations in the AGIS module in Release 12 is a
mandatory setup for entering intercompany transactions. Release 11i
subsidiaries are replaced by Release 12 intercompany organizations. For
more information, see OracleMetaLink Note 418649.1.

General Ledger
In Release 12, Oracle General Ledger is
significantly enhanced to support multi- Overview
national companies and shared services
centers. These changes allow you to
In Release 12, Oracle General Ledger is significantly enhanced to support multi-
maximize processing efficiencies while national companies and shared services centers. These changes allow you to
maintaining a high level of information and maximize processing efficiencies while maintaining a high level of information and
setup security. setup security.
You can perform simultaneous accounting for multiple reporting requirements.
You can also gain processing efficiencies by setting up, accessing, and processing
data across multiple ledgers and legal entities from a single responsibility. In
addition, General Ledger definitions - such as Mass Allocations and Financial
Statement Generator (FSG) reports - can be more easily shared and secured across
your organization by allowing you to restrict certain users from viewing or updating
these definitions or from using them in processes.
Many global features that were previously available only in localized versions are
included in Release 12 of General Ledger.
Terminology Changes:
“Sets of books” is replaced by “ledgers”. All sets of books options are now called
ledger options. The upgrade retains all Release 11i settings.
“Multiple Reporting Currencies” (MRC) is replaced by “Reporting Currencies”.
Reporting sets of books are replaced by reporting currencies. Reporting sets of
books assigned to primary sets of books automatically upgrade to reporting
currencies that are assigned to a primary ledger. All conversion options for
Multiple Reporting Currencies are retained as part of the reporting currency
definition.
Setup Tips
• The currency in which you do your local statutory reporting (transaction

based, such as VAT or withholding tax, or accounting) must be the currency
of your primary ledger. Oracle supports local compliance by having local
currency as the Primary Ledger currency.
• Ensure that the date range for your calendar includes the 29th day of
February in leap years. Check the calendar validation report before using the
calendar for setting up ledgers. You can change any of a period's
specifications, except for the period type, so long as the period has not been
used for transaction processing in General Ledger or in the subledgers. You
cannot change a calendar period that is open, closed, future enterable,
permanently closed, or is included in an open budget or encumbrance year.
• To create a document using Web ADI, the functions
BNE_ADI_CREATE_DOCUMENT, BNE_CREATE_DOCUMENT
must be added to the menu.

• Do not freeze the journal source if you intend to correct journals from the
source during import into General Ledger.
• Do not freeze the journal source if you enabled it for auto-reversal.
• Ensure that you are assigning correct balancing segment values to ledgers in
the Accounting Setup Manager. Once you assign them, you can end-date the
assignment, but you cannot un-assign them.
• Ensure that you have defined a Tax Recoverable/Liability account for tax
rates that you plan to use in General Ledger. The system will generate a tax
line only if a Tax Recoverable/Liability account is defined for your ledger for
the tax rate in E-Business Tax.
• Refer to OracleMetaLink Note 367429.1 to resolve FSG performance and
formatting issues.
• Ensure that you disable the legal entity balancing segment value assignment
whenever you disable the legal entity.
• Ensure that the start date of an organization type is set to a valid date before
creating the operating unit in the Accounting Setup Manager.
• Ensure that you run the General Ledger Setup diagnostics test to validate
your overall setup of General Ledger.
Operational Tips
• Run the Segment Value Inheritance Program when changes are made to the
segment qualifiers for segment values of the chart of accounts.
• Before you consolidate your subsidiary ledger to a parent ledger for the first
time, and before you try to run translation from the consolidation
workbench, ensure that you have run translation on the subsidiary ledger at
least once.
• Set the status of the first accounting period in the new fiscal year to “Future
Entry”. Do not open the first period of the new fiscal year until all of the
year-end processing for the last period of the current year has completed.
• Close the period in your subledgers before closing the period in General
Ledger. This will prevent subledgers from posting entries to a closed period.
• If you are using a calendar with an adjusting period that represents the last
day of the fiscal year, close the current period and open the adjusting period.
Create and post adjusting entries and accruals in the adjusting period.
• If Mass Allocation is not creating any journal entries, check for any invalid
or end-dated account combinations used in the Mass Allocation formula. If
yes, either enable the account combinations, or modify the Mass Allocation
formula to exclude them.

• Run the General Ledger Period Closing diagnostics test to verify that a
ledger period is ready to close.
Global Accounting Engine
Overview
In Release 12, Global Accounting Engine functionality is replaced by Oracle

Subledger Accounting, now standard for all feeders (Receivables, Payables, Assets,
Project Accounting.) Related to this change, all secondary and non-MRC posting
Sets of Books in Release 11i are upgraded to secondary ledgers in Release 12, with
automatic posting between the primary ledger and the secondary ledger.
It’s important that all statutory postings are up to date before you upgrade. It is
also important that dual posting from Payables and Receivables be tested
thoroughly.
Oracle Subledger Accounting (SLA) Subledger Accounting

provides a common accounting engine
that replaces the existing accounting Overview
processes in the different subledger
Oracle Subledger Accounting (SLA) provides a common accounting engine that
applications.
replaces the existing accounting processes in the different subledger applications.
The SLA upgrade involves migrating existing accounting data between 11i and
Release 12 to ensure a continuous business operation. Depending upon your
business requirements, “existing accounting data” may have different implications.
For the purposes of this discussion, accounting data is defined as:
“All data that has accounting relevance for the customer, including journal entries,
balances, base transactions that have generated journal entries, and related
information, such as accounting events and setup information.”
While the default accounting continues to be stored in the subledger applications,
the new SLA module is where the true accounting is held. SLA is a behind the
scenes module, largely transparent to end users except when they run the Create
Accounting program to create subledger accounting entries and to transfer journal
entries.
The upgrade team should fully understand SLA functionality and closing processes,
which vary slightly by application.
Receivables’ and Project Accounting’s auto-accounting rules are migrated to
Release 12, where they are represented as default SLA rules. Run transactions
through to confirm that your auto-accounting rules are correctly reflected in the
SLA tables.
Map custom reports, such as custom reconciliation reports, to the new SLA tables.

Upgrading Subledger Accounting Data
During the upgrade, existing accounting data from the subledgers is upgraded into
the new SLA data model. By default, the upgrade updates the data for the current
fiscal year, as well as the necessary periods of the previous fiscal year, to ensure that
at least six periods are included in the upgrade.
You can change the amount of historical accounting data to be upgraded to SLA as
a pre-upgrade step. For example, you can specify that a larger range of periods be
upgraded.
This is an important decision because some SLA functionality relies on the
existence of previous accounting data. For example, if you need to cancel invoices
from two years ago, then you need to upgrade at least two years of accounting data
to SLA.
However, you have the flexibility to limit the amount of subledger data you update
during the upgrade to reduce downtime and save on disk space. If you do not
update all of your accounting data during the upgrade downtime, you can perform
additional updating at a later point, either during daily business operations, or
during a subsequent downtime.
Operational Tips
Review the Period Close Subledger Exception Report
The General Ledger period can be closed even if there are exceptions in the
transfer of journals from Subledger Accounting. Review the Period Close
Subledger Exception report, which is started automatically when General Ledger’s
“Close Period” process is run, to get a clear view of any exceptions.
Run Create Accounting Daily for All Subledger Applications
The Create Accounting program processes eligible accounting events to create

subledger journal entries based on application accounting definitions that are
created in the Accounting Methods Builder (AMB). Create Accounting should be
run for each subledger application every day to avoid dealing with large volumes
and possible data exceptions at month’s end. If you deal with large volumes on a
daily basis, you can run the Create Accounting program more frequently, or you
can run it by category: for example, by receipts or invoices, and by date.
Also on a daily basis, review the Subledger exceptions report, and address any
exceptions, for example, invalid GL account code combinations (CCIDs.) Users
may want to develop a protocol for finding and handling such exceptions. For
example, all of the Subledger teams could meet with the General Ledger team to
determine roles and responsibilities for addressing any issues.
Make Account Code Changes with Care
On certain occasions, you may need to make segment changes that invalidate
account codes (CCIDs) that you have previously used. For example, when a cost

center moves from one line of business to another, you need to reflect the change
in your account code validation rules. In this circumstance, you run the segment
inheritance program to invalidate the CCID so that no new transactions can
reference it.
Different business models will dictate the extent to which account code changes are
made during a month. In general, however, it is a good practice to designate a fixed
day in each month when any necessary chart of accounts changes are made and
communicated. This should reduce the need to make ad hoc changes throughout
the month, and will result in a cleaner close cycle.
Maintain Account Code Consistency across Subledger Accounting and General Ledger
We recommend that you adopt practices to maintain account code consistency

across all of your subledger applications, as well as Subledger Accounting and
General Ledger. This is especially important if your business is subject to frequent
account code changes.
One way to maintain consistency is, for each of the subledgers, to run Create
Accounting on a regular basis (at least daily), and then immediately to run Transfer
to General Ledger so that there is no disabling of account codes before journal
import occurs. If Create Accounting and the Transfer to General Ledger always
run back to back, then the account codes used by SLA and General Ledger should
be in synch.
To address an account code disconnect between SLA and General Ledger, Release
12 provides a new feature in the “GL Accounts” form that allows you to replace an
invalid account code in Subledger Accounting data, which in turn allows General
Ledger to find a valid account code and for import to proceed without error.
Account replacement is also performed for non-Oracle journal sources during the
import process. However, since a retrospective fix to an account code can cause
subledger application data to get of synch with Subledger Accounting and General
Ledger data, it is best to avoid the situation altogether by adopting practices for
maintaining account code consistency.
Oracle E-Business Tax provides the E-Business Tax

infrastructure for transaction tax
knowledge management and delivery Overview
using a global system architecture that is
Oracle E-Business Tax provides the infrastructure for transaction tax knowledge
configurable and scalable for adding
management and delivery using a global system architecture that is configurable and
country-specific tax content.
scalable for adding country-specific tax content. As the single point solution for
managing transaction-based tax, Oracle E-Business Tax uniformly delivers tax
services to all E-Business Suite business flows through one application interface.
Oracle E-Business Tax consists of a tax knowledge base, a variety of tax services
that respond to specific tax events, a set of repositories (for tax content and tax
recording) that allows customers to manage their local tax compliance needs in a
proactive manner, as well as the ability to integrate with external tax providers

through a single integration point. In short, Oracle E-Business Tax is the global
and consistent compliance repository that encapsulates fiscal and tax rules in a
single point solution for tax events that is easy to integrate, extend and implement.
E-Business Tax replaces the following tax solutions available in 11i:
• Order to Cash – Global Tax Engine
• Procure to Pay – Automatic Tax Calculation
• General Ledger – General Ledger Automatic Tax Calculation
In Release 11i, tax setups were defined separately in various products. In Release
12, tax setup and calculation have been centralized. Your tax manager, who knows
your organization’s current and future tax needs, should be responsible for
configuring the tax setup.
During the upgrade, Release 11i tax setups are migrated to Release 12. While you
may not choose to utilize the new/advanced features of E-Business Tax
immediately after your upgrade, Oracle recommends that you familiarize your tax
users with the key E-Business Tax features and start taking advantage of them.
Test tax scenarios for all of your countries after the upgrade. In Payables, ensure
that you test your invoice sources (XML, iSupplier, flat file, and manual) to confirm
that each can automatically derive the correct tax regime-to-rate information. Also,
standardize your Release 11i customer and supplier tax setup before your upgrade,
as this will help to ensure that tax is derived correctly in Release 12.
Post-Upgrade Tips
• After the upgrade, you can still provide the tax codes in transactions and
also use defaulting hierarchies and tax groups in the same manner as you did
in Release 11i without changing your setup. Over time, you can incrementally
update your migrated tax data to gradually move from your Release 11i tax
code model to the E-Business Tax regime-to-rate and tax rules model.
• Group constraints in Receivables are migrated as-is to E-Business Tax.
However, they are migrated as read only and cannot be modified. If you want
to add new conditions, you must use the new E-Business Tax rules
functionality to create rules (expert or guided) with all conditions.
• E-Business Tax provides users the flexibility to share a tax setup across
multiple Operating Units/Legal Entities, or to restrict it to a particular
Operating Unit/Legal Entity. You must decide which setup is appropriate
for your enterprise.
Setup Tips
• On a migrated instance, any new operating unit should be subscribed to the

relevant tax regimes if the subscription of the Legal Entity is not being used.

• Depending on your business requirements, if you want tax to be calculated
based on tax codes (as in 11i), then you need to set up Configuration Owner
Tax Options for the newly-created operating unit and specify the Regime
Determination set as “STCC”.
• If the Configuration Owner tax option is not created or is not active for a
specific combination of application, event class, and first party Legal
Entity/Operating Unit, then the defaults are taken from seeded Event Class
settings.
• Whenever you add a geography, run the “Geography Name Referencing”
program in TCA.
• You can run a transaction in the Tax Simulator to check your tax setup. The
Tax Simulator should be used after any change to your tax setup to test
multiple what-if scenarios without affecting the transaction database.
Troubleshooting Tips
Users may report E-Business Tax problems in the following categories:

• Taxes are not being calculated.
• Tax calculation is erroring out.
• Incorrect tax amounts are being calculated.
Avoid these E-Business Tax problems by following the general, offset tax, and
irreversible options setup tips below:
General:
• Check whether all the required setups are effective on the transaction date.
• Check whether Tax Applicability is checked on the Configuration Owner
Tax Options for all Event Classes.
• In the Configuration Owner Tax Options, confirm that the Regime
Determination is:
• STCC
• Determine Applicable Regimes
• If Party Tax Profile is changed, ensure that the Tax Applicability flag is
checked.
• Ensure that by default or as a rule result, Tax is Applicable.
• Check whether the “Make Tax available for transactions” is enabled at
the Tax level.
• If the user has subscribed the Regime to a Legal Entity, then in the Party
Tax profile for the Operating Unit, the “Allow subscription of Legal Entity

flag” should be checked. This should be carefully done, as it is an irreversible
setting.
• Run the transaction in the Tax Simulator to obtain details of the
rules/defaults that are evaluated.
• Define all the required Tax Accounts based on your tax setup in the Tax
Rate to avoid errors during transactions.
• For any Recovery Rule to be evaluated, check whether users have
associated at least one Recovery Rate Rule in the “Rule Code of Recovery
Rate” field at the Tax Rate Level.
• Check that the Configuration Owner Tax Options for the Event Class
allows for tax exemptions to be considered.
• Check that you have completed the setup for all the required set up tasks
listed in the E-Business Tax Home Page.
• Use the available Diagnostic scripts to identify any tax setup issues.
Offset Tax and Self-Assessed Tax:
Self-Assessed tax is the Release 12 equivalent of Offset Tax in Release 11i.

However, for backward compatibility, Offset taxes can still be configured in
Release 12. Depending upon your business requirements, you can decide which
options to choose:
• Check that “Allow Offset Taxes” is enabled in the Party Tax Profile for
the Offset Taxes.
• Check that “Allow Offset Tax Calculation” is enabled at the
Configuration Owner Tax Options for the Event Class for the Offset Taxes.
Check Offset Tax Basis also.
Irreversible Options:
Note that the following setup changes are irreversible:

• Inactivating the defaulting order in Application Tax Options – Once the
combination of operating unit and application defaulting order is inactivated,
you cannot reactivate the same. Carefully select the appropriate tax
determination method from Oracle E-Business Tax or Latin Tax Engine.
• The “Use Subscription of the Legal Entity” box in the operating unit party
tax profile - This flag should be checked if the Regime is subscribed to the
Legal Entity.
• The “Make Tax available for transactions” option in the Tax, if enabled,
cannot be updated.

Change Record
Date Author Version Change Reference
09-Jun-2008 Anne Carlson 1.0 First published version
11-Jun-2008 Anne Carlson 1.1 Made Globalization edits under General Ledger and Global
Accounting Engine sections

Best Practices for Adopting Oracle E-Business Suite, Release 12
June 2008
Author: Anne Carlson
Contributing Authors: Krithika Bhat, Bill Bounds, George Buzsaki, Robert Farrington, Cliff Godwin, Kevin Hudson, Mazen Khanfar, Adam Lief, Cheryl Ludwig, Amrita Mehrok,
Nirajita Mitra, Anand Naik, Ognjen Pavlovic, Victoria Pickard, Mike Quick, Vasu Rao, Nick Reichenbach, Kirsten Shaw, Nayyar Siddiqui, Murali Subramanian, Terrance Wampler,
Mildred Wang
Oracle Corporation
World Headquarters
500 Oracle Parkway
Redwood Shores, CA 94065
U.S.A.
Worldwide Inquiries:
Phone: +1.650.506.7000
Fax: +1.650.506.7200
oracle.com
Copyright © 2008, Oracle and/or its affiliates. All rights reserved.

This document is provided for information purposes only and the
contents hereof are subject to change without notice.
This document is not warranted to be error-free, nor subject to any
other warranties or conditions, whether expressed orally or implied
in law, including implied warranties and conditions of merchantability
or fitness for a particular purpose. We specifically disclaim any
liability with respect to this document and no contractual obligations
are formed either directly or indirectly by this document. This document
may not be reproduced or transmitted in any form or by any means,
electronic or mechanical, for any purpose, without our prior written permission.
Oracle is a registered trademark of Oracle Corporation and/or its affiliates.
Other names may be trademarks of their respective owners.

Best Practices For Adopting Oracle E-Business Suite, Release 12

Uploaded by

Document Information

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Best Practices For Adopting Oracle E-Business Suite, Release 12

Uploaded by

Copyright:

Available Formats

Best Practices for Adopting Oracle

E-Business Suite, Release 12

Best Practices for Adopting Oracle E-Business Suite, Release 12 Page 2

Best Practices for Adopting Oracle E-Business Suite, Release 12 Page 3

Best Practices for Adopting Oracle E-Business Suite, Release 12 Page 4

Release 12 provides the foundation for IMPLEMENTING VERSUS UPGRADING

Best Practices for Adopting Oracle E-Business Suite, Release 12 Page 5

A Financials upgrade to Release 12 Project Best Practices

Tip #2 – Determine the Appropriate Project Scope

Best Practices for Adopting Oracle E-Business Suite, Release 12 Page 6

Best Practices for Adopting Oracle E-Business Suite, Release 12 Page 7

Best Practices for Adopting Oracle E-Business Suite, Release 12 Page 8

Oracle Business Intelligence Publisher (Oracle BI Publisher), formerly known as

Tip #9 – Involve Your Business Users at Every Project Phase

Best Practices for Adopting Oracle E-Business Suite, Release 12 Page 9

Oracle Tutor is a Microsoft Word-based tool for documenting business processes,

Best Practices for Adopting Oracle E-Business Suite, Release 12 Page 10

A good roadmap to Release 12 information Tip #13 – Acquire Release 12 Knowledge

Best Practices for Adopting Oracle E-Business Suite, Release 12 Page 11

Tip #14 – Fully Utilize Available Upgrade Documentation

Tip #15 – Use the Maintenance Wizard

The Maintenance Wizard is a free tool (available on OracleMetaLink via

Best Practices for Adopting Oracle E-Business Suite, Release 12 Page 12

Tip #17 – Stay Current with Latest Information

Best Practices for Adopting Oracle E-Business Suite, Release 12 Page 13

For proactive notification of changes to information on OracleMetaLink, you have

Best Practices for Adopting Oracle E-Business Suite, Release 12 Page 14

Pre- and Post-Upgrade Best Practices

Tip #18 – Clear Your Interfaces and Any Processing Exceptions

Tip #19 – Review your Pending Concurrent Requests

Tip #21 – Review Your Custom Concurrent Program Incompatibilities

Review your custom concurrent program incompatibilities after the upgrade to

Best Practices for Adopting Oracle E-Business Suite, Release 12 Page 15

We cannot over-emphasize the importance Testing Best Practices

Tip #23 – Develop a Robust Testing Strategy

Best Practices for Adopting Oracle E-Business Suite, Release 12 Page 16

Tip #25 – Do Load and Volume Testing

PRODUCT-SPECIFIC CONSIDERATIONS AND TIPS

Best Practices for Adopting Oracle E-Business Suite, Release 12 Page 17

Release 12 introduces Oracle Subledger Payables

Best Practices for Adopting Oracle E-Business Suite, Release 12 Page 18

Just prior to the upgrade:

Run the Invoice Validation program on a Operational Tips

Best Practices for Adopting Oracle E-Business Suite, Release 12 Page 19

Period Closing-related Activities

Best Practices for Adopting Oracle E-Business Suite, Release 12 Page 20

• Dummy Funds Capture setup in Payments is required to perform

Best Practices for Adopting Oracle E-Business Suite, Release 12 Page 21

Release 12 changes to Oracle Internet Expenses include:

Best Practices for Adopting Oracle E-Business Suite, Release 12 Page 22

• The Cost Center segment should be defined as an independent segment to

Release 12 changes to Oracle Receivables include:

Best Practices for Adopting Oracle E-Business Suite, Release 12 Page 23

In Release 12, suppliers are modeled in the Trading Community Architecture

• To process large volumes, run multiple instances of the “Automatic

Best Practices for Adopting Oracle E-Business Suite, Release 12 Page 24

• Perform the following pre-requisite steps before starting the Receivables to

Best Practices for Adopting Oracle E-Business Suite, Release 12 Page 25

The Collections Workbench module in Advanced Collections

In Release 12, Oracle Assets adds Subledger Accounting (SLA) functionality. By

Best Practices for Adopting Oracle E-Business Suite, Release 12 Page 26

• Important reports such as the transaction diagnostics report and

Advanced Global Intercompany System