R12.1 finpreupgradesetupopstips

Oracle E-Business Suite
R12.1 Financials Pre-Upgrade,
Setup and Operational Tips
An Oracle White Paper
Sep 2010


Product-Specific Considerations and Tips .......................................... 4
Payables ............................................................................................ 5
Overview ...................................................................................... 5
Pre-Upgrade Tips ......................................................................... 6
Setup Tips ..................................................................................... 6
Operational Tips ........................................................................... 6
Payments .......................................................................................... 8
Overview ...................................................................................... 8
Planning Considerations .............................................................. 8
Post-Upgrade Tips........................................................................ 8
Internet Expenses ............................................................................ 9
Overview ...................................................................................... 9
Planning Considerations .............................................................. 9
Pre-Upgrade Tips ......................................................................... 9
Post-Upgrade Tips.......................................................................10
Setup Tips ....................................................................................10
Receivables......................................................................................10
Overview .....................................................................................10
Planning Considerations ............................................................. 11
Setup Tips .................................................................................... 11
Operational Tips .......................................................................... 11
Advanced Collections ..................................................................... 13
Overview ..................................................................................... 13
Assets............................................................................................... 13
Overview ..................................................................................... 13
Operational Tips ..........................................................................14
Advanced Global Intercompany System .......................................14
Overview .....................................................................................14
Planning Considerations .............................................................14

Oracle E-Business Suite R12.1 Financials Pre-Upgrade, Setup and Operational Tips Page 2

Post-Upgrade Tips.......................................................................14
General Ledger ................................................................................ 15
Overview ..................................................................................... 15
Setup Tips .................................................................................... 15
Global Accounting Engine .............................................................. 17
Overview ..................................................................................... 17
Subledger Accounting .................................................................... 17
Overview ..................................................................................... 17
E-Business Tax .................................................................................19
Overview .....................................................................................19
Planning Considerations ............................................................ 20
Post-Upgrade Tips...................................................................... 20
Setup Tips .................................................................................... 21
Troubleshooting Tips .................................................................. 21
Change Record ............................................................................... 23



PRODUCT-SPECIFIC CONSIDERATIONS AND TIPS
This document describes Release 12.1 Financials product-specific changes and
planning considerations. It also provides tips related to pre-upgrade, post-upgrade,
setup, operational, and troubleshooting activities. Many of the changes listed here
were first introduced in Release 12.0. You should use this document in conjunction
with the following documents:

• Planning Your Oracle E-Business Suite Upgrade from Release 11i to
Release 12.1 – Doc ID 987516.1

- Offers upgrade planning tips for the E-Business Suite.

• R12 Upgrade Considerations by Product: Financials – Doc ID 889733.1

- Provides planning considerations, process change, and configuration changes for the
R12.1 Financial products.

• R12.1 Financials Recommended Patches – Doc ID 954704.1

- Review this document for the latest Financials recommended patches released after the
R12.1.x EBS suite-wide release.

• R12.1 Oracle Financials Pre-Upgrade Patch, supplemental patch list for the
R12.1 EBS Consolidated Patch Update (CUP) - Doc ID 1127593.1

- The pre-upgrade patches listed in this document are crucial for
assuring a successful upgrade from 11i to R12.1.x.

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.1 documentation is available via the E-Business Suite Product
Information Center – refer to My Oracle Support Doc ID 806555.1.

Payables
Release 12 introduces
Oracle Subledger Overview
Accounting, Oracle E-
Release 12 introduced Oracle Subledger Accounting, Oracle E-Business Tax,
Business Tax, Ledgers,
Banks, and other common Ledgers, Banks, and other common data model components that are used by
data model components Oracle Payables.
that are used by Oracle
The following Payables features are new as of Release 12:
Payables.
• 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.

• A new module called Oracle Payments now handles payments and all
funds disbursement activities.

• 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 the term 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 (My Oracle Support Doc
ID 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.

Operational Tips
Run the Invoice Validation
program on a regular basis (at Regular Activities
least daily) to determine if there
are invoices that are not getting • Run the Invoice Validation program on a regular basis (at least daily) to
validated. The best practice is to determine if there are invoices that are not getting validated. The best
schedule a concurrent request so practice is to schedule a concurrent request so that it runs daily at a time
that it runs daily at a time when when load is not high.
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:

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

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

o 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 Overview
Payments, a configurable, robust In Release 12, the Oracle E-Business Suite introduced Oracle Payments, a
and centralized engine for
configurable, robust and centralized engine for disbursing and receiving payments.
disbursing and receiving
payments. In addition to new features, Oracle Payments offers functionality previously
released as Oracle iPayment, which becomes obsolete starting 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; therefore, 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 My Oracle Support Doc ID
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. The Receipt remittance is
done by a format program in Oracle 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 My Oracle
Support articles:
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 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:

o If you would like the User / Auditor / Both to apply advances,
then set the profile option “OIE: Enable Advances” to End User /
Payables / Both.

o 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”,
My Oracle Support Doc ID 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.

Advanced Collections
The Collections Workbench
module in Oracle Receivables is Overview
obsolete and is replaced with
comparable functionality in Oracle The Collections Workbench module in Oracle Receivables is obsolete and is
Advanced Collections. 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 My Oracle Support Doc ID 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 My Oracle Support
Doc ID 418649.1.


General Ledger
In Release 12, Oracle General
Ledger is significantly enhanced to Overview
support multi-national companies In Release 12, Oracle General Ledger is significantly enhanced to support multi-
and shared services centers.
national companies and shared services centers. These changes allow you to
These changes allow you to
maximize processing efficiencies maximize processing efficiencies while maintaining a high level of information and
while maintaining a high level of setup security.
information and 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.
th
• Ensure that the date range for your calendar includes the 29 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 My Oracle Support Doc ID 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.

Subledger Accounting
Oracle Subledger Accounting (SLA)
provides a common accounting Overview
engine that replaces the existing
accounting processes in the Oracle Subledger Accounting (SLA) provides a common accounting engine that
different Subledger 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. Review the document called R12: FAQ for the SLA
Upgrade: SLA Pre-Upgrade, Post-Upgrade, and Hot Patch -- Doc ID 604893.1, for
more information about the SLA Pre-Upgrade, Post-Upgrade, and Hot Patch.

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.

E-Business Tax
Oracle E-Business Tax provides the
infrastructure for transaction tax Overview
knowledge management and
delivery using a global system Oracle E-Business Tax provides the infrastructure for transaction tax knowledge
architecture that is configurable management and delivery using a global system architecture that is configurable
and scalable for adding country- and scalable for adding country-specific tax content. As the single point solution
specific tax content. 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 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
17-May-2010 Anne Carlson Created Financials-specific excerpt for Chris Cianciolo to use as the
basis for Support Note containing R12.1 Financials Upgrade
Considerations
01-Jun-2010 Chris Cianciolo 1.2 Changed Title from Planning Your Oracle EBS Financials Upgrade
from 11i to R12.1 to Oracle EBS R12.1 Financials Pre-Upgrade, Setup
and Operational Tips
29-Sep-2010 Chris Cianciolo 1.3 Highlight the Financials Pre-Upgrade Patches listed in Doc 1127593.1


Author: Financials Product Development
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
Document Owner: Chris Cianciolo

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.

R12.1 finpreupgradesetupopstips

Recomendados

Recomendados

Mais conteúdo relacionado

Mais procurados

Mais procurados (17)

Semelhante a R12.1 finpreupgradesetupopstips

Semelhante a R12.1 finpreupgradesetupopstips (20)

Último

Último (20)

R12.1 finpreupgradesetupopstips