Pre Upgrade Check List for Oracle Financials

5/21/2018 Pre Upgrade Check List for Oracle Financials

1/49

RELEASE 12

Upgrade Considerationsby Product

(FINANCIALS)

Applications Release: 12

Author: Financials Product Development

Creation Date: January 22, 2009

Last Updated: March 8, 2010

File URL:

Draft / Version: v6.0

Status: Final


2/49

2

Table of Contents

Table of Contents ...............................................................................................................2

Introduction ........................................................................................................................3

Oracle Advanced Collections ............................................................................................4

Oracle Advanced Global Intercompany Systems ...........................................................6

Oracle Assets ....................................................................................................................10

Oracle Cash Management ...............................................................................................13

Oracle General Ledger ....................................................................................................16

Oracle Legal Entity Configurator ..................................................................................21

Oracle Payables ................................................................................................................24

Oracle Payments ..............................................................................................................30

Oracle Receivables ...........................................................................................................34

Oracle Subledger Accounting .........................................................................................39

Oracle E-Business Tax .....................................................................................................43


3/49

3

Introduction

This document is a supplement written by professionals in Oracles Product Development

organization that provides product level considerations to help you understand the issues

that your project team should consider when upgrading to E-Business Suite Release 12. Itdescribes the significant new features available in Release 12 and then gives process

changes, configuration changes and considerations as relevant for each product. It should

be used in conjunction with the published product specific user and implementationguides for Release 12 when planning your upgrade.

Prior to reviewing this document, the reader is advised to be familiar with the following

Release 12 documentation:

Oracle Financials Concepts Guide

Oracle Financials Implementation GuideOracle Financials and Oracle Procurement Functional Upgrade Guide: Release 11i to

Release 12.


4/49

4

Oracle Advanced Collections

Release 12 of Oracle Advanced Collections extends transactional and customer data incollection management processes within and across operating units (OUs). New Multi-Org Access Control security profiles manage each collectors access to operating units to

which they are assigned. This provides them with the visibility to customer data and

balances within or across OUs on their collector work list and specific screens for a morecomplete understanding of each customers collections situation.

Other new features in release 12 Oracle Advanced Collections include:

New Implementation Checklist and Setup Screens

Improved Payment Processing and Customer Funds Capture through

integration with Oracle Payments

Use of Oracle Territory Management to Define Collections TerritoryHierarchies

Finally, the collections workbench in Oracle Receivables has been replaced with

functionality from Oracle Advanced Collections. Details on the collections features

available in Oracle Receivables and Oracle Advanced Collections are provided in Oracle

MetaLink Note 389443.1.

Planning Considerations

If you have used the Collections Workbench in Oracle Receivables you must upgrade toeither Oracle Advanced Collections or the new functionality in Oracle Receivables.Oracle Advanced Collections provides the flexibility and high degree of configurabilityrequired by enterprise collections agents and managers responsible for managing

delinquent customers and collections-related issues. It includes configurable scoring and

strategy management tools, configurable customer metrics, later-stage collectionstracking capability, and is directly integrated to a number of other Oracle EBS products

including Oracle Territory Manager, Oracle Trade Management, Oracle Leasing and

Oracle Loans.

The collections functionality available in Oracle Receivables is intended for AR clerks

who occasionally perform collections activities. Receivables users who have notpurchased a license for Oracle Advanced Collections are not authorized to use the full

feature set of this product. Therefore, your planning team should consider the long-term

operational requirements of your collections group and upgrade to the appropriate

collections management capability that best fits those requirements.


5/49

5

Process Change

Pay heed to the order and frequency in which the concurrent programs that

automate the collections processes are run. For instance, some organizationsrun their scoring or dunning processes in synch with their billing cycles while

others run them more frequently. Based on MOAC security, collections agents will be able to see across

operating units and will need to consider this additional information as they

review and work with customer accounts.

For collections organizations where collectors or collector groups areresponsible for managing specific customers, collections territories can becreated in Oracle Territory Manager to facilitate and manage customer

assignment and customer-related work assignment.

Customer call activity created in Oracle Receivables prior to upgrading to

Release 12 can be viewed from the Collections History tab by selectingReceivables Calls from the Type List of Values.

Configuration Change

Start by using the new Collections Implementation Setup tool to create pre-production collections systems for conference room pilots and testing. Once

you go live, your production collections system settings can be easily

modified with the Setup Tool when changes are needed.

Review and use the pre-configured elements (correspondence templates,scoring models, strategies and work items, and metrics) in pre-production

phases of your upgrade. Then add or adjust those elements as needed.

Aging-based dunning plans in R12 (for either Advanced Collections orReceivables users) include:

o

Configurable dunning letter templates using Oracle BI Publishero Output as email, fax or print

o Optional dunning calls assigned to collector for follow up

Considerations

Collections scoring and collections strategies are not extended to OU level.Highest level for these are still Customer

Dunning plan capability is available for both Advanced Collections andReceivables users. Configurable collections strategy management (which also

supports dunning activities) is available in Oracle Advanced Collections.

New collections scoring models and customer metrics in Oracle AdvancedCollections are best configured by qualified DBAs. New scoring and metrics

are usually created during your upgrade project, prior to going live with the

module.

See Oracle Advanced Collections Implementation Guideand Oracle AdvancedCollections User Guidefor more information.


6/49

6

Oracle Advanced Global Intercompany Systems

Oracle Advanced Global Intercompany Systems is a new product in Release 12,

replacing the Global Intercompany System in earlier releases. It allows companies to

streamline intercompany processing and facilitates intercompany reconciliation.

The key components of the Advanced Global Intercompany System are:

Intercompany Balancing

Manual Intercompany Transactions

Intercompany Invoicing

Intercompany Reconciliation

Intercompany Balancing

Overview:

Intercompany Balancing calculates intercompany accounting when transactions are

entered directly in the Advanced Global Intercompany system, and also whenintercompany transactions occur in Oracle General Ledger and Oracle Subledger

Accounting. Intercompany Balancing uses the same single set of intercompany

accounts and rules for consistent accounting treatment throughout Financials. Duringthe R12 upgrade, GIS data is upgraded to AGIS, and you can then use R12

functionality to: Define all intercompany accounting definitions centrally.

Support true legal entity for intercompany transactions between legal entities.

Maintain separate intracompany accounting for transactions between

balancing segments in the same legal entity.

Track trading partners in a separate optional intercompany segment.

Process Change

Accounting Setup Manager in Release 12 has a separate setup screen forIntercompany / Intracompany accounts.

Release 12 supports legal entity integration with intercompany balancing rulesforintercompany accounts when two legal entities trade. Legal entity

configuration is not needed for intracompany balancing between pairs of

balancing segment values within the same legal entity.

Intercompany balancing supports separate Intercompany Payables and

Intercompany Receivables accounts rather than a single intercompany due

to/due from account.


7/49

7

You can create an optional intercompany segment in your chart of accountsstructure. It will automatically be populated with the balancing segment value

of the trading partner to provide more detail for reporting and reconciliation.

Configuration Change The R12 upgrade converts intercompany accounts created in GIS into

intracompany balancing accounts and 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.

To use intercompany accounting rules, you need to setup legal entities for

transacting subsidiaries, map them either to ledgers or balancing segment

values, and specify them as intercompany organizations. As part of the

upgrade, GIS subsidiaries will be converted to intercompany organizations,

one for one. You need to verify post-upgrade that the correct legal entity hasbeen assigned to the intercompany organization so that it can be used. In some

cases the automatic upgrade may not have been able to identify one and onlyone legal entity to associate to an intercompany organization. In that case theorganization will be inactive and must be updated with the correct legal entity

before it can be used in transactions.

The R12 Grant Based Security Model maps intercompany organizations tousers instead of responsibilities. Security grants are created for the users basedon the subsidiaries assigned to the responsibilities that each user was assigned.

A user may be given access to many different intercompany trading partners

regardless of the responsibility used to log in.

Considerations

SeeOracle Advanced Global Intercompany System Release 12 RoadmapDocument

SeeAdvanced Global Intercompany System White Paper

Manual Intercompany Transactions

Overview

The Manual Intercompany Transaction window facilitates intercompany transactionprocessing between different legal entities under one or more ledgers. During the R12

upgrade, GIS data is upgraded to AGIS, and you can then use R12 functionality to:

Create Intercompany Batches for transactions to multiple recipients (norestriction on COA, currency, calendar), with optional proration of amountsacross recipients.

Maintain intercompany periods to control timing of transactions (eg duringperiod close) and close intercompany periods by transaction type.

Optionally create intercompany invoices between subsidiaries automatically

Use Oracle Approvals Manager for intercompany transaction approvals.

Grant user access to multiple subsidiaries from a single responsibility.


8/49

8

Process Change

New workbench for entering manual intercompany transaction batches.

All GIS new and completed transactions are upgraded as AGIS transaction

batches. Generally, for each GIS transaction a batch is created.


Approvals Manager setup

Optionally create intercompany calendar / periods to control timing of

intercompany transaction entry.

Setup intercompany invoicing options. When GIS transaction types are upgraded,the Allow Invoicing option is set to Not Required. In order to take advantage ofthe new invoicing feature in AGIS, you should manually select the Allow

Invoicing check box for transaction types where invoicing is required.

Considerations

See also configuration changes / considerations for Intercompany Balancing these apply to all intercompany setup (eg setting up legal entities and mapping

them to intercompany organizations, creating intercompany accounts and rules,intercompany function security and data access).

Intercompany Invoicing

Overview

Advanced Global Intercompany System interacts with the subledgers to facilitate creationof a physical invoice for an intercompany transaction in both Receivables and Payables.

Release 12 highlights for Intercompany Invoicing:

Intercompany uses Oracle Receivables to produce invoices for the initiator.

Once the Receivables transaction is completed, the invoice number is then

automatically used to create a consistent mirror-image invoice in Oracle

Payables.

Process Change

Create intercompany invoices automatically where statutory or businesspractices require them.

GIS transaction types are upgraded to the new intercompany system

transaction types. When GIS transaction types are upgraded, the AllowInvoicing option is set to Not Required. In order to take advantage of the new

invoicing feature in AGIS, you should manually select the Allow Invoicingcheck box for transaction types where invoicing is required.


Setup and assign operating units to ledgers (as part of Accounting Setup

Manager) in order to use intercompany invoicing within the subledgers.


9/49

9

Create additional AR customers and AP suppliers to represent yourcompanys subsidiary legal entities.

Map the intercompany organizations that are trading partners to AP Suppliersand AR Customers in TCA.

Considerations

Intercompany invoices are only created for manual intercompany transactions

(i.e. not for intercompany journal entries entered directly in GL).

Creation of additional customer / supplier records and mapping to

intercompany organizations is not done automatically as part of the upgrade.

Intercompany Reconciliation

Overview

Intercompany provides reconciliation tools to sort out any discrepancies in accountingbalances between the intercompany organizations.

Release 12 highlights for Intercompany Reconciliation;

View intercompany out-of-balance accounts and drill down to details of thesubledger accounting and documents.

BI Publisher technology for reconciliation reporting: the layout is fullycustomizable and can be downloaded to desktop tools (eg Excel or Word) for

further analysis.

Process Change

Need to run data extract program to populate XML data before using theintercompany reconciliation report.

Optionally download report output to Excel for additional analysis.


Optional customize BI Publisher report layouts.

SeeOracle Advanced Global Intercompany User Guidefor more information.


10/49

10

Oracle Assets

In release 12, Oracle Assets has introduced several enhancements to improve the

efficiency of key Assets processes like mass additions and period end close.

Subledger Accounting(SLA) Architecture and Inquiries

o Oracle Assets is fully integrated with SLA, which is the common

accounting platform for all E-Business Suite sub ledgers.

o It enables you to comply with multiple legislative, industry or

geography requirements concurrently in a single instance through

configurable rules.

Enhanced Mass Additions for Legacy Conversions:

o Populate depreciation attributes directly in the FA Mass Additions

interface table or via? Web ADI (application desktop integrator),rather than accepting default values from the asset category. This

means complete automation of legacy conversions.

o Asset life, depreciation method, prorate convention, bonus rule ceilingname, depreciation limit are some of the attributes that have been

added to the interface table in Release 12.

Automatic Preparation of Mass Additions

o Default rules and public APIs can be used to populate expense

account, asset category and other required fields to complete the

preparation of mass addition lines automatically.o

Could significantly reduce the overhead associated with manualpreparation of mass addition lines.

Automatic Depreciation Rollback

o Depreciation is rolled back automatically when any transaction isperformed on an asset if the period has not yet been closed.

o No longer required to run depreciation rollback program manually.

o Executed only on select assets as required and not on the entire assetbook; resulting in a faster period close.

Flexible Reporting using XML Publisher

Enhanced Functionality for Energy Industry

Process Change

Prepare Mass Additions process provided in Release 12 automatically

populates all the required information for mass additions lines. Mass


11/49

11

additions data may be optionally verified before posting the mass additions

lines.

New SLA Accounting report and online account inquiry provided. The

Account Drill Down report has been replaced the Account Analysis report.

The Create Journal Entries and Rollback Journal Entries programs are now

obsolete. Create Journal Entries has been replaced by Create Accounting. The Create Deferred Depreciation Journal Entries program is now obsolete.

Users now need to run Calculate Deferred Depreciation followed by CreateAccounting.

During upgrade, 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 ifdepreciation 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.

Prior to Release12, accounting records were not created until after

depreciation had run. For example, if you added an asset and went to theTransaction History form, you would not see any addition accounting lines if

depreciation had not been run. Post upgrade, however, these records wouldappear in the Transaction History form for additions, backdated additions,

backdated transfers and retirements.


New configurable rules for automatic preparation of mass additions.o You can use default rules provided by Oracle where the expense

account is derived from the clearing account by replacing the natural

account segment from the asset category.o In addition, default rules populate the asset category based on the

clearing account from the asset category setup (if there is a one to one

match).

o If the default rules do not satisfy your requirements, you can create

custom logic coded in a public API to pre-populate these values.

Generic Subledger Accounting Architecture configuration has been discussedin a separate section of this document.

In summary, the key setup steps are:

o

Compile the Application Accounting Definition in SLA. Please notethat the pre-seeded account derivation definitions have been providedfor Assets. You can use the seeded account derivation definitions or

modify them as required.

o Complete the Accounting Setup flow in Oracle General Ledger.


12/49

12

Considerations

You may have to look carefully at the clearing account in your categorysetups if you are planning to use default rules for automatic preparation of

mass addition lines. If you have been using the same clearing account acrossdifferent categories, the default rules will not work effectively.

In Release 12, Oracle continues to support Account Generator functionalityfor existing asset books. However, the common SLA platform provides manyopportunities to implement complex accounting rules without customizations.

For instance, some of our customers have requirements where the retirement

account is different based upon the type of retirement (missing, sale, theft,

etc). These accounting rules can be configured in SLA without complexcustomizations on your part.

SeeOracle Assets User Guidefor more information.


13/49

13

Oracle Cash Management

Oracle Cash Management is an enterprise-wide solution for managing liquidity and

controlling cash. In Release 12, Oracle Cash Management starts leveraging severalarchitectural cross-product features such as Multi-Org Access Control and Subledger

Accounting.

The key new features in Release 12 are:

Centralized Internal Bank Account Model

Bank Account Transfers

Bank Account Balances and Interest

Centralized Internal Bank Account Model

OverviewIn Release 12, internal bank accounts for use in Oracle Payables, Oracle Receivables,

Oracle Payroll, Oracle Treasury and Oracle Cash Management are centrally defined and

maintained in Oracle Cash Management.

Process Change

Internal bank account usage in Oracle Payables, Oracle Receivables, OraclePayroll, Oracle Treasury and Oracle Cash Management does not change inRelease 12. Internal bank account maintenance, however, is done differently as

described below.


There is new user interface in Oracle Cash Management for bank, bank branchand bank account maintenance. Windows related to internal bank account

maintenance in Oracle Payables and Oracle Treasury have been made obsolete.

Privileges to maintain bank accounts are granted to a user role by legal entity inthe Oracle User Management security wizard.

Internal bank accounts are owned by legal entities. Any operating unit under the

same legal entity can be granted access to the same bank account.

Bank account reconciliation parameters are now defined at the bank account level.

Before you can enable bank account usage in Oracle Treasury, you will need tolink a bank-counterparty in Treasury to the bank branch in Cash Management,

using Treasurys Counterparty Profiles window.

The system supports country specific validations for the bank account and address

format. When creating new bank accounts, the format and content of the Bank

Number, Branch Number, Account Number and Check Digit will vary according

to the country specific rules. The countries that are supported are Austria,

Belgium, Denmark, Finland, France, Netherlands, Norway, Portugal, Spain,


14/49

14

Brazil, Colombia, Germany, Greece, Iceland, Ireland, Italy, Luxembourg, Poland,

Sweden, Switzerland, United Kingdom, and United States.

Considerations

During the upgrade, existing internal bank accounts defined in Oracle Payables

and Oracle Treasury are migrated one-to-one into the new bank account model inOracle Cash Management. If you previously had to create two separate bankaccount records to represent the same real life bank account because it was used

by two different operating units, after the upgrade you will have the option to

disable the duplicate bank account and allow both operating units to use the singlebank account. This will simplify bank account maintenance and bank

reconciliation.

Bank Account Transfers

Overview

In Release 12, users can create cash transfers between internal bank accounts, settle themthrough Oracle Payments and account for them using Oracle Subledger Accounting.

Process Change

New user interface is available for capturing and, separately authorizing bankaccount transfers.

Bank account transfers can be created intra-company (between two bank accountsbelonging to the same legal entity) or inter-company (between two bank accounts

belonging to two different legal entities).

Reusable bank account transfer templates can be created for accelerated dataentry.


Privileges to create bank account transfers are granted to a user role by legalentity in the Oracle User Management security wizard.

Accounting configuration for bank account transfers is done in subledgeraccounting. Seeded journal line definitions are provided for bank account transferclearing and un-clearing. Users can define additional journal line definitions for

bank account transfer creation and cancelation.

Settlement of bank account transfers is done via Oracle Payments.

If you plan to create inter-company bank account transfers, you will need to

define inter-company accounts in Oracle Advanced Global Intercompany Systemin order to create proper journal entries.

Considerations

Bank account transfers can be created in the system automatically if you have

zero-balance accounts (ZBAs) with your banks.


15/49

15

Bank Account Balances and Interest

OverviewIn Release 12, Oracle Cash Management provides robust functionality for bank account

balance reporting, both online and via concurrent programs with Oracle BI Publisher. In

addition, bank balance interest can be calculated for bank fee or credit verification.

Process Change

There is new bank balance maintenance user interface in Oracle CashManagement. Bank balance maintenance in Oracle Treasury is disabled. The data,however, is replicated between Cash Management and Treasury for bank accounts

used in Treasury, so that the interest accrual and settlement can still be performed

in Treasury.


There is a new user interface to manage interest rate schedules. Before bankbalance interest can be calculated, interest rate schedules have to be defined and

assigned to bank accounts.

Basis, Interest Rounding, Day Count Basis and Interest Includes parameters,previously defined at the bank account balance level in Oracle Treasury, are now

a part of the interest rate schedules in Oracle Cash Management. Portfolio Code,

Pricing Model and Limits, previously defined at the bank account balance level inTreasury, are now a part of the internal bank account definition in Cash

Management.

Considerations Interest amount can be calculated for both standalone bank accounts and notional

cash pools.

For each bank account and balance date, you can keep track of multiple balance

types: ledger, available, value dated, 1-day float, 2-day float, projected month-to-date average, and year-to-date average. It should be noted that the system does not

calculate any of these balance types. They can be populated manually or from the

bank statement.

Projected closing bank account balance can be saved alongside actual bank

account balances using the new button in the Cash Position window.

See Oracle Cash Management User Guidefor more information.


16/49

16

Oracle General Ledger

In Release 12, Oracle General Ledger is significantly enhanced to support multi-national

companies and shared services centers. 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 singleresponsibility.

Release 12 highlights for Oracle General Ledger include;

Centralized Accounting Setup

Data Access Sets

Ledger / Ledger Set Architecture

Replacement for Disabled Accounts

Note: There is also a terminology change between Release 11i and Release 12: Sets ofBooks are upgraded and renamed to Ledgers the upgrade retains all 11i settings.

Centralized Accounting Setup

Overview:In Release 12, the Accounting Setup Manager centralizes the setup and maintenance of

common accounting-related setup that is shared across Oracle Financials applications, for

example:

Definition of legal entities and associated accounting setup to meet different

accounting principles and reporting requirements of multiple countries usingdifferent currencies, charts of accounts and/or calendars.

Secondary ledgers and reporting ledgers to create alternate accountingrepresentations automatically.

Process Change

Accounting Setup Manager is used to create and maintain accounting setups.

An accounting setup defines the accounting context for one or more legalentities or other business entities. The upgrade creates a separate accounting

setup for each primary ledger that is upgraded from a set of books.

o Legal Entities: HR Organizations classified as GRE/LEs in Release

11i will be upgraded legal entities in Release 12. Legal entities can beassigned to a ledger and balancing segment values can optionally be

mapped to legal entities to help identify transactions by legal entity.

o Operating Units: All HR Organizations classified as operating units

will be preserved in Release 12. If operating units are assigned to a setof books, then they will be associated to a primary ledger in an

accounting setup.


17/49

17

o Primary Ledger: Most sets of books in Release 11i will become

primary ledgers in Release 12.

o Secondary Ledgers: Multiple-posting set of books (Global AccountingEngine) will upgrade to secondary ledgers.

o Reporting Currencies: Multiple Reporting Currency (MRC) reporting

sets of books become reporting currencies in Release 12.o Intercompany Accounts: The Release 11i Global Intercompany

System (GIS) will be replaced by Advanced Global Intercompany

System (AGIS) and GIS features will be migrated to the correspondingfeatures in AGIS.

o Subledger Accounting Method: All upgraded ledgers in Release 12

will have a subledger accounting method assigned during the upgrade.

Any reporting currencies assigned to the ledger inherit the subledgeraccounting method from the source ledger. The subledger accounting

method enables Oracle General Ledger to integrate with Oracle

subledgers using Subledger Accounting. All upgraded, non-public-

sector ledgers will have a subledger accounting method assignedcalled Standard Accrual or Standard Cash. All upgraded public sector

ledgers will have a subledger accounting method assigned calledEncumbrance Accrual or Encumbrance Cash. For US Federal

customers, all upgraded ledgers will have the US Federal Accounting

subledger accounting method assigned to them.


Create legal entities and assign them to accounting setups either assigned toledgers or mapped to balancing segment values.

Create primary and secondary ledgers and mappings for alternate accounting

representations from single transaction (replacement for the GlobalAccounting Engine Dual Posting solution in Release 11i).

Considerations

Sequencing is determined by the ledger. Journal entries may have multiplelegal entities (each accounting line may be different), so there is no distinct

legal entity of the journal header.

In Release 11i, users could change settings for certain options on a primary set

of books independently of its reporting set of books. The upgrade will

preserve the Release 11isettings, but in Release 12 these options cannot be

manually updated for reporting currencies because the reporting currency will

inherit its settings from its source ledger. If you modify any of the ledgeroptions for the source ledger after the upgrade, the settings on the reporting

currency will automatically be changed to be synchronized with the source

ledger.

You can run the Accounting Setup Manager Pre-Update Diagnosis Report toview your Release 11i setup for Multiple Reporting Currencies, General

Ledger, Global Accounting Engine, Assets, Payables, and Receivables. This


18/49

18

report identifies potential problem areas where you may want to modify your

setup in order to take advantage of new Release 12 functionality.

Data Access Sets

Overview

Data access sets allow users to access multiple ledgers and ledger sets within General

Ledger from a single responsibility. This allows you to:

Secure user access to data by ledger, balancing segment value or management

segment value.

Grant read-only user access, or read and write access.

Process Change

Process changes do not directly impact users, but rather control GeneralLedger security behind the scenes.

Security allows you to secure users access to data, or portions of data. Privileges allow you to grant users read only or read/write access to specific

Balancing segment values within a ledger, or to specific ledgers.

Data access sets work with crossvalidation rules and flexfield value securityrules. If flexfield value security rules are defined that prevent certain

responsibilities from accessing certain segment values, those rules are

combined with data access set security.


The General Ledger Accounting Setup Program automatically creates a dataaccess set for each ledger and reporting currency (journal level or subledger

level) assigned to a completed accounting setup. The system-generated dataaccess sets created for each ledger and reporting currency provide full read

and write access to the ledger and all of its balancing segment values andmanagement segment values.

(Optional) Manually create data access sets to further control read and writeaccess to ledgers, ledger sets, or specific balancing segment values or

management segment values for a ledger or ledger set. For example, if youhave a shared accounting setup where multiple legal entities share the same

primary ledger, you can limit a user's access to a legal entity's data by creating

a data access set that secures read and write access to specific balancingsegment values or legal entities.

To associate a data access set to a responsibility, you must assign a dataaccess set to the GL: Data Access Set profile option at the Site, Application,

or Responsibility level.

Considerations

All ledgers and ledger sets assigned to a data access set must share the samechart of accounts and accounting calendar/period type combination.


19/49

19

Use data access sets instead of flexfield value security rules to secure read andwrite access to balancing segment values and management segment values.

Flexfield value security rules are still applicable for the other segments of the

accounting flexfield.

If you have read-only access to a ledger, or read and write access only to some

of its balancing segment values and management segment values, you will notbe able to open and close its accounting periods.

FSG report output takes into account data access set security and only shows

the data accessible for your responsibility. You must have at least read access

to the data to view it on a report.

Ledger / Ledger Sets Architecture

OverviewSets of books are upgraded to ledgers in Release 12. Ledger sets allow grouping of

ledgers with the same chart of accounts and calendar / period type, to allow processingacross multiple ledgers simultaneously. They do not have to share the same currency.This allows you to group the primary or secondary ledgers with their associated reporting

currencies to reduce maintenance efforts and streamline processing.

Ledger sets facilitate the following accounting operations across ledgers:

Open / close periods for multiple ledgers simultaneously

Submit concurrent programs for all ledgers in a ledger set

Cross ledger allocations, recurring journals and year-end closing journals

Currency translation for multiple ledgers simultaneously

Financial reporting (FSGs) across ledgers

Account inquiry across ledgers

Process Change

Management of multiple ledgers simultaneously by grouping them into ledgersets


Create ledger sets to group ledgers with the same chart of accounts andcalendar / period type.

Assign ledger sets to data access sets for user access and security. The systemautomatically creates a data access set each time you define a new ledger set.

The system generated data access set provides full read and write access to theledgers in the ledger set. Before you can begin using the ledgers contained in

your ledger set for transaction processing, you must assign the ledger set to

the profile option GL: Data Access Set.

Considerations

The same ledger can belong to multiple ledger sets, and ledger sets cancontain other ledger sets.


20/49

20

Use a ledger set to combine the source ledger with its reporting currencies(journal and subledger levels) to open and close periods across all ledgers

simultaneously. Both the source ledger and its reporting currency must have

the same open periods to prevent problems during posting in the generalledger.

Replacement for Disabled Accounts

OverviewPrevent errors & reduce manual intervention in the journal import process by defining a

replacement account for disabled accounts If specified, the alternate account is used by

the Journal Import process and the Create Accounting program in Subledger Accounting

to replace the original account combination if it is disabled or end-dated.

Process Change

None


Define alternate accounts when creating GL account combinations.

SeeOracle General Ledger Implementation Guide, Oracle General Ledger Reference

GuideandOracle General Ledger User Guidefor more information.


21/49

21

Oracle Legal Entity Configurator

In Release 12, Oracle E-Business Suite is moving from an implicit definition of legal

entities to an explicit one. You will be able to define legal entities to meet differentstatutory principles and reporting requirements of multiple countries and jurisdictions.

The Legal Entity architecture allows you to represent the legal organization structure

separately from the operational business structure. A highlight of Release 12 is the LegalEntity Configurator which guides the user through the LE creation process.

Overview

The Legal Entity Configurator allows you to define legal entities to meet statutoryprinciples and reporting requirements of multiple countries or legal jurisdictions. This

legal entity definition is used in the following business processes:

o Payment runs by legal entity

o

Intercompany (legal entity subsidiaries that trade with each other)

o Tax calculations (legal establishments that are registered with a taxauthority)

o Bank account ownership

o Ownership of subledger transactions (eg in Payables or Receivables)

o Reporting at the legal entity level

Process Change

Subledger transactions are stamped (at header level) with the owning legal

entity in addition to an operating unit.

The legal entity is determined as follows:

o

Each transaction exists within an operating unit and that OU has a

ledger which will account the transactions. If that ledger has more than

one legal entity associated with it, then a hierarchy of LE derivation isused to default an LE. For example in AR the legal entity derivation

hierarchy for transactions is

1. Transaction Type

2. Batch SourceAssigning a LE to a transaction type or batch source is optional and

only the LEs mapped to the ledger associated with the OU are

available to assign.

o Legal entity can also be defaulted from the default legal contextof an

operating unit if no other default exists. For values to show up in the

LOV associated to a default legal context, an LE must be associated tothe ledger that is assigned to the OU.

o If no default legal entity value is found from any other source, the user

must explicitly provide it during transaction entry.

Additional information:


22/49

22

o How do I define my Legal Entities?

http://davidhaimes.wordpress.com/2007/11/21/how-do-i-define-my-

legal-entities/

o Can I assign an operating unit to 2 legal entities?

http://davidhaimes.wordpress.com/2007/12/11/can-i-assign-an-

operating-unit-to-2-legal-entities/o Release 12: Legal Entity Uptake

http://www.oracleappshub.com/release12/release-12-legal-entity-

uptake/


Migration of existing data into legal entities (eg GRE/LEs, AP ReportingEntities, VAT Reporters, Brazilian Companies and Global DescriptiveFlexfields)

Create legal entities and assign them to accounting setups. An organization oftype GRE/LE is used as a source for creating an LE during the R12 upgrade.

But after migration there is no link between an HR organization of type'GRE/LE' and an LE created using the Legal Entity Configurator UIs.

Although it is a source for upgradedlegal entities, HR Organization cannot be

used for creating a newLE in Release 12.

Configure existing organizations to be legal entities or establishments as

appropriate.

Use Legal Entity Associations to maintain the association between businessconstructs (operating units, inventory organizations, inventory locations etc)

and legal constructs (legal entities and establishments).

Assign legal entities to intercompany organizations (if using AGIS).

Considerations There is no Legal Entity uptake in Oracle General Ledger or Oracle Assets

instead the ledger or balancing segment value is used.

Sequencing on transactions is still by ledger, not by legal entity.

If your legal entities share the same ledger attributes (such as chart of

accounts, calendar, accounting method), it is possible for them to use the same

ledger depending upon your business needs. You can also assign balancing

segment values to legal entities that share the same ledger - recommended for

easier identification of transactions and for reporting purposes. Note that

balancing segments are required for intercompany accounting between legal

entities that share the same ledger.

If legal entities differ in any of the 4Cs or require different ledger processingoptions (like average daily balances, journal approval, or sequencing),separate primary ledgers are required. It may be possible to group multiple

ledgers into ledger sets for easier processing if need to setup multiple ledgers

for legal reasons.

In Release 12 there is no direct relationship between an operating unit and alegal entity. One way of determining the operating units associated with a


23/49

23

legal entity is via the ledger associated with both the legal entity and the

operating unit. Note that there may not be a unique relationship between a

legal entity and an operating unit.

See the Oracle Legal Entity Configurator Release 12 Roadmap Documentwhich

describes the published information available for Oracle Legal Entity Configurator,Release 12. Use this document to ensure that you leverage all existing resources to learn

about, install, implement, and use this product in Release 12.


24/49

24

Oracle Payables

In R12, Oracle Payables has made some significant changes in the following areas.

Supplier Representation in TCA (Trading Community Architecture)

Invoice Lines

Payment Process

AP-AR Netting

Supplier Representation in TCA

Overview

Trading Community Architecture is a data model that allows the deploying

company to maintain information about its parties (customers, suppliers, banks etc) andtheir relationships with the deploying company in a centralized place, thereby providing a

single source of truth. It also allows easier cross-product integration.

Process Change

New user interface presents a clear distinction between the supplierscompany details and terms and controls for the trading relationship.

Managing the attributes specific to particular functional areas such as Oracle

Payables, Purchasing and Receiving can be controlled with the use of

Function Security.

Adding new locations or relationships with additional operating units is

streamlined. Each supplier is associated with a party and each supplier site is associated

with a party site.

Addresses can be entered and formatted based on country specification.

Configuration Change:

When new suppliers are created the system creates a TCA party behind thescenes. The information that will be stored in TCA includes supplier name

and legal information, address and contact information. The parties are createdwith a party usage of supplier

Procurement and Payables specific attributes like terms and conditions,

accounts etc. are maintained in the supplier sites tables. Some payment and tax related information is no longer maintained in the

supplier sites tables - it was moved to the appropriate product tables (Oracle

Payments, Oracle E-business tax).

Considerations

Existing suppliers, sites or locations and their contact information are

automatically created in TCA.


25/49

25

Existing tables that hold the supplier information are moved to a new set oftables (AP_SUPPLIERS).

New views, based on the old supplier table names have been added forbackward compatibility.

When a supplier or supplier site is merged, the associated party or party site

does not change. During the supplier merge process, when a supplier site is copied from one

supplier to a different supplier, a new supplier site must be created. Hence, anew party site will also be created.

When merging suppliers, supplier merge should be performed before initiatingthe party merge.

Supplier or supplier site merge does not affect contacts. The contacts arealways transferred to the merged supplier site specified in the supplier mergeform.

Employees that were defined as suppliers in prior releases will not bemigrated, as their information would already exist in TCA.

Supplier open interface processes are enhanced to support the creation of TCAentities while importing suppliers. The creation of supplier bank accounts is

also supported from the supplier open interface.

Invoice Lines

OverviewThe addition of invoice lines allows Oracle Payables to better model the paper or

electronic business document by representing the goods or services, as well as tax, freight

and other charges. The new invoice structure also more accurately models Oracle

Procurements PO shipment, allowing for improved allocation of charges, as well asenhancing the matching function.

Process Change

The new Invoice Workbench now contains a multi-record block to representthe invoice lines. In a separate window, users can enter one or more

distributions for every invoice line.

Redesigned matching windows for PO/Receipt matching can be invoked from

the Invoice Workbench. Invoice lines that were generated by matching will

generate distributions at the time of match.

New windows support price/quantity/invoice corrections.

Freight/miscellaneous lines created automatically via request to the matchingprocess from the matching windows do not automatically generate

distributions at line creation time.

Tax, freight, and miscellaneous type invoice lines can be prorated to all itemlines on an invoice.

Users can enter freight at the invoice header and then prorate it across all itemlines on the invoice.


26/49

26


Users can also do a quick match by entering just the PO number on theinvoice header. In this case, the invoice lines are automatically created.

With the new invoice lines model, the R12 multi-period accounting is realized

at the invoice line level. Once Subledger Accounting is configured for multi-

period accounting, users can specify the deferred accounting period as aparameter for each individual invoice line. To invoke this feature, users checkthe Deferred Option box and specify the deferred period type, start date and

number of periods. Later on, when the accounting records are created for this

invoice line and distribution, a series of accounting records will be generated

reflecting the fact that the invoice expense is first recorded in an accrualaccount then moved into expense account periodically.

Considerations

No new setup steps are required for using Invoice Lines.

The standard upgrade process creates one invoice line for every distribution

existing in the 11i Payables distribution table. Exchange rate variance (ERV) and invoice price variance (IPV) amounts

become separate distributions in the upgrade process and so, are no longerpart of the item distributions.

Charge (tax/freight/miscellaneous) distributions are created at the maximumlevel of detail to represent detailed allocation information.

In prior releases, the allocations were managed by a charge allocation table

which is now obsolete,

Payment Process Enhancements

Overview

The payment process has been significantly enhanced in Release 12. The following aresome of the new enhancements that were made in this release:

More robust and flexible payment processing engine

Improved visibility into payment processing via the centralized Paymentsdashboard

Improved pay run automation

Improved pay run management tools:

o Enhanced cash management report

o Comprehensive selected invoice information

o

Improved online inquiry of selected invoices Process payments for multiple operating units from single responsibility

Process Change

A new Selected Invoices page displays summary and detail information used

to view and analyze invoices selected in a pay run.

Powerful search tools improve online inquiry to invoices that you may want toreview, modify, or remove from a pay run.


27/49

27

Users can now view invoices that were not selected due to various reasons(not validated/approved).

A Payment Dashboard empowers your payment manager to monitor allcurrent pay run processing and gives them visibility to payment processes thatrequire attention.

If payment batch sets were used as a workaround for doing multi-currency payruns in 11ithen, consider combining those pay runs into a single pay run. In

addition a single payment run can process multiple banks that includes bothelectronic and printed payments

The Payment Process Request template enables you to predefine invoice

selection criteria, thereby simplifying payment processing.

Validation errors during the payment build process are automatically handled

based on the options that are specified on the payment process request. For

example, the process may be stopped for review, payments with errors can be

rejected, or all payments may be rejected in the request if errors exist.

Usage rules and validations can be set up for a payment method.

Pay runs can be stopped at two points. Users can choose to pause after theinvoices are selected. At this point, users can review selected payments, add

or remove scheduled payments or change payment and discount amounts. The

second point is after the scheduled payments are built into payments. Here, theuser can see the final amounts of each payment and can choose to drop any

payments.

Scheduled Payment Selection report replaces many portions of thePreliminary Payment register report. It can be used for reviewing the invoicesselected in a pay run, review invoice selection criteria, determine immediate

cash requirements for a pay run etc.

Configuration Change All payment related setup has now been moved to the new Oracle Payments

module. Refer to the Oracle Payments User guide.

In prior releases, Oracle Payables seeded four payment method types (Check,Electronic, Wire, and Clearing). In Release 12, customers can setup their ownpayment methods

Considerations

Scheduled Payment Selection report cannot be run for historical data.

Custom document categories for payments will not be upgraded.

Disbursement type has been made obsolete and hence, it has been removedfrom all reports.

IMPORTANT: All custom payment formats must be migrated to XML in

order to work in R12.

Check Payments and the Electronic Payments document categories have beenretained in Release 12. However, Payables no longer supports the Wire

Payments and Clearing Payments document categories.


28/49

28

AP-AR Netting

OverviewThe AP-AR Netting feature allows you to offset balances in both Oracle Payables and

Oracle Receivables to reduce the outstanding debt owed either from an internal company

or from a customer. It also supports foreign currency netting. Accounting for netting ishandled in the same way as if it had been closed in the subledgers. This feature allows

you to optionally give the trading partner the opportunity to review and approve

transactions before they are posted.

Process Change

A netting batch needs to be created using the Receivables responsibility. It caninclude various parameters like operating unit, netting agreement, settlementdate etc.

Once the batch has been set up, submit the netting batch.

Query the netting batch and view the proposed AP/AR netting amounts

online. Users can view the Receivables and Payables transactions that wereselected for possible netting. In the header portion of the screen users will beable to see the total dollar amounts of the AP and AR transactions selected as

well as the proposed netting amount. Users could also run the proposed

AP/AR netting report.

Optionally, users can review the netting batch. In this process users canreview, remove or add transactions before submitting it.

Submit the netting batch and view the final netting report.


Both customers and suppliers must be setup as a trading partner in TCA.

Here are some of the additional steps that are required:o Create a netting agreement.

o Create a netting bank account.

o Create a netting control account in General Ledger as well as exchange

rate types if using multi-currency netting.

o Establish a paying relationship for the customers in AccountsReceivable.

o Associate the bank account used in the netting agreement with the

AP/AR netting receipt class.

Considerations

An internal dummy bank account will be seeded which will process receiptsgenerated in Oracle Receivables.

When creating a netting agreement, if the (supplier?) site information is left

blank, then the system includes all the sites for the trading partner.

If the option to include trading partner approval is selected, only one approvercan be selected. The approver name list of values is derived from the customer

contact information.

No netting batch information will be upgraded.


29/49

29

Netting agreements will be created for every existing customer and supplierrelationship that is migrated. Agreement name will be created using customer

id and customer name.

Users must review the migrated netting agreement setup to add or correct

upgraded information. Netting upgrade uses dummy values for certain

mandatory information not found in 11i setup. Users must change this to validvalues.

Transaction data residing in interface tables in 11i is not migrated to Release

12. All in-progress netting batches should be closed or completed before

upgrade.

SeeOracle Payables Implementation GuideandOracle Payables User Guidefor more

information.


30/49

30

Oracle Payments

Oracle Payments is a new product introduced in Release 12 that provides a configurable,

robust and centralized engine for disbursing and receiving payments. Oracle Paymentshas changed payment processing within Oracle products:

Fromproprietary Oracle reporting technology tostandardized formatting usingXML.

Frombank accounts stored in multiple products tocentralized bank account setup.

From credit card information stored in multiple product entities toa centralizedcredit card entity within Payments.

From single operating unit restrictions to cross-operating unit transactions..

Fromreceipt remittance through Receivables tocentralized receipt remittance.

Frompayments transmitted by external systemsto native transmissioncapabilities.

The key components of Oracle Payments are:

Funds Disbursement

Funds Capture

Funds Disbursement

Overview:

The funds disbursement features delivered in Oracle Payments simplifies user procedures

for managing complex payment processes that span multiple payment methods, formats,currencies, organizations and bank accounts.

The major features within funds disbursement are:

Funds Disbursement Dashboard that enablespayment administrators tomanage every aspect of the process across multiple organizations from a

central location in the application.

End-to-end electronic payment processingthat includes validation,

aggregation, formatting, and secure transmission of payments to financial

institutions and payment systems.

Remittance advice reportingthat notifies a payee of the remittance detailwhen a payment is made.

Country-specific payment formats and reporting that meet global payment

requirements.


31/49

31

Process Change:

In Release 12, Oracle Payments segregates the process into two majorfunctions: Payment Build process and the Payment process.

o Payment Build processfirst groups documents according to variousrules, such as the payment method and currency.

o

Payment process aggregates payments from multiple documentselections and submissions into payment instruction files, formats thefiles, and handles additional processing, such as printing and

transmission.


All payment related setup has been centralized within Oracle Payments.

Oracle Payments offers flexible setup to configure funds disbursementprocessing. Some of the key areas of impact are:

o Payment Methods:each document to be paid requires a payment methodto indicate how it should be handled in the funds disbursement process.

The upgrade seeds payment methods that existed in Oracle Payables andglobalizations. Payment Methods are now user definable.

o Processing Rules:the payment method on a document links it toprocessing rules configured in Oracle Payments. These setup rules are

held in a key entity called thePayment Process Profile.

o Payment System:a payment system holds information about the thirdparty involved in processing payments.

The upgrade uses various data from Oracle Payables to create the newPayment Process Profiles. See Oracle Payments Implementation Guidefor

more detailed information.

All masking of credit cards, debit cards and bank accounts is centrallycontrolled.

Future Dated Payments are renamed to Bills Payable in release 12. Setup hasmoved from the payment document on an internal bank account to the

payment method in Oracle Payments.

Considerations:

Both theAutomatic Payment ProgramsandPayment Formats (AP entities)are obsolete in release 12. Also, setup entities related to payment formatswithin Oracle Payables are obsolete as they are effectively replaced by the

new Oracle Payments setup.

Oracle Payments secure electronic payment file and payment messagetransmission and transmission result processing replaces previously existingelectronic transmission features in Oracle iPayment, Oracle Payables, and

Oracle Globalizations.


32/49

32

Funds Capture

OverviewFunds capture supports the processes to electronically receive funds owed deploying

companies by debtors, such as customers. Oracle Payments works with AR to authorize

and capture funds against credit cards, process refunds to credit cards, perform electronicfunds transfers from bank accounts, and to format bills receivable.

The major features within funds capture are:

Funds Capture Dashboardprovides payment administrators an overview ofthe payment process status.

Supports multiple payment processing systemsoperating simultaneously forfunds capture transactions.

Supports authorization and settlement of fundsagainst credit cards andPINless debit cards, refunds to credit cards, electronic funds transfers from

bank accounts, and formatting of bills receivable. Supports out-of-the-box integration with leading third party payment systems

such as Citibank, Paymentech, First Data Merchant Services, and Concord

EFS. Other payment systems, such as VeriSign, offer their own out-of-the-box

integrations with Oracle Payments.

Process Change

Oracle Payments has consolidated notification letters from Oracle

Globalizations into an Oracle XML Publisher format.

Oracle Receivables retains the functionality of lockbox processing and

electronic upload of remittance messages.


Centralized, configurable funds capture processing can be setup by Payee,Routing Rules, or Funds Capture Processing Rules. Please refer to Oracle

Payments Implementation Guidefor more details.

Credit card security setup can be easily completed using the Oracle PaymentsPayment Administrator responsibility.

The required setup entities for bank account transfer processing are upgradedfor you, but it is important for you to understand the new setup and process so

you can successfully test the migrated information

Considerations

EFT online validation is only offered for United States ACH and not for allpayment systems. EFT online validation checks whether a bank account existsand that the account is not flagged fraudulent. EFT online validation does not

reserve funds or check if the account has sufficient funds.

Oracle Payments does not support risk management for PINless debit card or

bank account transfer transactions.


33/49

33

Oracle Payments does not automatically reauthorize settlements that arerejected due to expired authorizations.

See Oracle Payments Implementation GuideandOracle Payments User Guidefor more

information. Also seeMetalink Note733537.1 for more details in theFunctionalUpgrade Impacts Document for Oracle Payments (FINANCIALS).


34/49

34

Oracle Receivables

Oracle Receivables streamlines the invoice, receipt and customer deduction processes

while simultaneously improving cash flow, increasing efficiency and optimizingcustomer relationships. In Release 12, significant changes were made in the following

areas:

Revenue Management

Line Level Cash Application

Redesigned Customer User Interface

Bill Presentment Architecture

Revenue Management Enhancements

Overview

Enhancements in the Revenue Management area include the ability to distribute revenuein a more granular fashion which includes full and partial periods. Additionally,

organizations may create their own revenue deferral reasons to ensure revenue is

recognized in accordance with applicable revenue recognition policies.

Process Change

New configurable accounting rules to determine the treatment of revenueallocations for partial periods.

Enhanced event-based revenue management allows users to define revenue

deferral reasons and corresponding revenue recognition events specific totheir business practices.

o Ability to create user defined revenue contingency definitions seededexamples include: cancellation, customer creditworthiness, etc.

New Revenue Manager responsibility that provides the revenue analyst a

central location to set up and maintain revenue policies and rule assignments.

Seeded revenue assignment rules have been replaced by a new window thatenables the user to create process specific revenue assignment rules.

New Contingency tab offers the ability to review and manually managecontingencies from the Revenue Adjustment Manager (RAM) wizard.

New Cost of Goods Sold (COGS) and Revenue Matching feature

synchronizes the recognition of revenue with recognition of associated COGS.


Creation of new accounting rules allows for revenue recognition that meetsaccounting standards and contractual start and end dates.

o Example: Able to create an accounting rule for revenue that will

distribute revenue across identified accounting periods that can include

a partial period (meaning the period does not start or end on the first or


35/49

35

last day of the accounting period). During a partial period, the revenue

amount will be prorated based upon the number of days in the period. The table below provides an example of how the new

accounting rules would prorate revenue accordingly.

GL Date Period Days in

Period

Daily

RevenueRate, All

Periods

Daily

RevenueRate,

Partial

Periods

Fixed

Schedule

Variable

Schedule

January 14 January 18 180 180 225 180

February 14 February 28 280 295 225 240

March 14 March 31 310 295 225 240

April 13 April 13 130 130 225 240

Ability to create user defined Revenue Assignment Rules:o Example: New Rule for Acceptance:

Matching Criteria (must choose from a seeded choice list): Bill

to Customer

Condition: equals ABC Customer

Revenue Contingency: Explicit Acceptance

Result: If a transaction line with Bill to Customer of ABC

Customer meets the criteria of this rule -- Receivables willassign explicit acceptance as the contingency to the transaction

line, and the revenue will be deferred until customer

acceptance is received.

New Application Programming Interface (API) automates revenue & COGSmatching.

Considerations

Oracle costing calls the new Receivables API(AR_match_rev_cogs_grp.populate_cst_tables) that triggers earning and un-

earning of COGS when revenue is recognized or unearned.

COGS and Revenue Matching report has been retired.

No longer necessary to create manual journal entries for revenue & COGS

matching.

Uptake of SLA does not impact timing and amounts for revenue recognition. It

only provides the ability to override the accounts defaulted via auto-accounting. Provides the capability to default contingencies from feeder systems.

o In R12, Order Management (OM) provides this capability for invoicing &

customer acceptance contingencies. User will assign a contingency at

order entry time based on the contingency defaulting API fromReceivables.

o Once this order is imported into Receivables from Order Management, the

Contingency Defaulting API runs again and can default additional


36/49

36

contingencies but will not over-ride the invoicing and/or customer

acceptance contingency created during initial order entry.

o SLA can only be used to override the accounts created via auto-accounting.

The Revenue Policy System Option available in 11i will be obsolete in R12.o The system will automatically apply the credit worthiness contingency,

refund contingency and extended term contingency for all invoices (that

either violate the policy or match the credit worthiness criteria).

o The revenue policy data (which is populated for certain customers) willautomatically show up in the new revenue policy window. The system will

check to see if this revenue policy is populated during the initial set up.

Upgrade script will convert the contingency ID from prior releases to the newcontingency removal event code.

o Only impacts those systems interfacing to Receivables through

AutoInvoice or Invoice API.

o

No User Interface impacts.

Line Level Cash Application

Overview

With the introduction of line level cash application, receipts can be applied against

specific transaction items such as individual lines, group of lines or tax or freight buckets.

Process Change

New cash application tree to choose the appropriate application level.

Receipts can be applied against:o one or more transaction lines

o all transaction lines

o a specific group of transaction lines

o a specific transaction line type such as tax, freight, late charges or anycombination thereof

Ability to un-apply and re-apply receipts. Un-apply and re-apply can be done

against an entire transaction or to a specific transaction line.


None

Considerations

Line level applications apply to manual cash application only.

o However, automated line level application is available via lockbox.

Receipts cannot be applied at the line level against invoices migrated from

Release 11i, as line level balances were not stored prior to R12.

Available only for invoices, debit memos and chargebacks with line details.

Cannot apply against invoices with installments.


37/49

37

Does not use application rule sets.

If necessary, modify the AR profile option Always Default TransactionBalance for Applications profile option.

Balances are now stored at the line level regardless of application.o Ability to set flag on Batch Source window to not store balances at

line level in 12.1.

Customer Standard User Interface (UI) Redesign

OverviewThe new HTML based user interface provides a streamlined and intuitive customer data

management flow. Data quality management tools allow users to maintain the integrity

of customer data.

Process Change

Provides functionality to create a new customer, customer account, customeraccount site, and a business purpose for the customer account site.

Tight integration with TCA allows users to take advantage of the DQM (DataQuality Management) feature. DQM allows the user to perform advanced

searches for parties and customer accounts with user defined criteria. In

addition to the advanced search feature, it can prevent duplicate entries bydetermining if the customer that is being created or updated is a potential

duplicate.

Ability to classify customers based on industry, location, size, creditworthiness, business volume and payment cycles.

Configuration Change The new Customer Standard UI replaces the five functions that used to exist

in prior releases (Customers Standard, Customers Quick, CustomersSummary, Customers Standard View, and Customers Quick View).

o The pages are built using TCA CPUI (Common Party User Interface)

components.

By using TCA components, the cost of maintenance is lowered.

Considerations

The Customer Standard menu item will launch the new HTML customerform.

No data is affected. Display of data has been enhanced to represent the TCA model.


38/49

38

Bill Presentment Architecture

OverviewBill Presentment Architecture (BPA) allows you to retrieve billing data from multiple

sources, including those external to Oracle Receivables. Enhancements were made to the

following features:

Balance Forward Bill Presentment

o More appealing and easier to modify bill layouts

o Ability to view printed bill exactly as the customer sees it

o Rules engine provides the ability to select from unlimited formats

Enhanced Template Assignment

o New attributes provide more flexibility in how templates are assigned

to customers

Attachment Printingo Ability to print PDF attachments for specified document categories

Process Change Balance Forward Bill Presentment:

o Key set up steps include:

Register views

Select template items

Select assignment attributes Create hyperlinks

o Utilize balance forward data source for template assignment.

o Two seeded assignment rules: Default rule for balance forward detail template

Default rule for balance forward summary template

o

Must run the Generate Balance Forward Bills program Enhanced Template Assignment

o Templates can now automatically be assigned by:

Any attribute in the invoice header Seeded attributes like Batch Source, Transaction Type or

Context Reference

Supplementary data sources, like header and footer flexfields

(e.g., Projects interface attributes).

New profile option must be set to take advantage of printing attachments for

printed bills

o AR:BPA Print Attachment Document Category

o

Applies to both internal & external templates

Considerations

Balance Forward Billing replaces Consolidated Billing.

See Oracle Receivables Reference Guide, Oracle Receivables Implementation Guideand

Oracle Receivables User Guidefor more information.


39/49

39

Oracle Subledger Accounting

Oracle Subledger Accounting (SLA) provides a common accounting engine that replaces

the existing accounting processes in the subledger applications. The SLA upgradeinvolves migrating existing accounting data between 11i and Release 12 to ensure a

continuous business operation.

NOTE: Please refer to the Oracle Subledger Accounting Implementation Guidefor more

detailed information and definitions of the terminology used herein.

Oracle Subledger Accounting has changed accounting within Oracle applications:

Fromaccounting setups within each Oracle module toa unified accountingdefinition in Subledger Accounting, with a common posting process to Oracle

General Ledger.

Fromseparate Global Accounting Engine functionality toa common standard forall Oracle subledgers (Receivables, Payables, Assets, Project Accounting) within

SLA.

The key upgrade areas impacted by Oracle Subledger Accounting are:

Accounting Rules

Transaction account builder

Standard reports

Accounting Rules

Overview:Subledger accounting rules define how journal entries can be created from subledger

transactions for both the primary and secondary ledgers. This centralized accounting

setup provides greater flexibility as well as supports more simplified and standardizedaccounting rule creation and maintenance. The intuitive user interface does not require

users to know any programming language or to have developer skills.

Process Change:

In R11i and prior releases, accounting for subledger applications existed

within the individual applications. With Release 12, accounting for all subledger applications is unified under

SLA, with a common posting process to Oracle General Ledger.

Seeded application accounting definitions are provided for all Oraclesubledgers.

If specific requirements are not met by startup accounting definitions, userscan copy and modify the seeded definitions and their assignments.


40/49

40


In Release 12, each subledger application will maintain its existing accountingrules; and Accounting Methods Builder (AMB), delivered within Subledger

Accounting, will work in conjunction with those rules. Implementationteams now have the option to override, modify or use the accounting defined

within the subledger applications as the accounting to be transferred to GL.

Considerations

Standardize your accounting policies by defining a common chart of accountsand accounting method across the enterprise before creating new accounting

rules or replicating your existing rules within the SLA model.

Accounting Class Codes: In R12, the Accounting Class code is similar to theaccounting journal line types in 11i. In 11i, the accounting journal line types

are fixed and can be only modified by development. In R12, the Accounting

Class code is a lookup type owned by Subledger Accounting. Deployingcompanies can seed their own Accounting Class codes and assign them to the

different journal lines. Application Accounting Definitions and Journal Entry Setup: The seed

data includes all the Accounting Derivation rules, Journal Descriptions, and

Journal Line Definitions for Actual Accounting, Encumbrance Accounting,

Federal Accounting, and Oracle Project Encumbrance Accounting.

Test effective-dated changes to accounting rules and verify the impact before

the change is implemented.

Review existing manual or adjustment journal entries to see if accountingrules can be configured to generate journals that eliminate the need for manual

or adjustment journals.

As a best practice, determine whether to enter manual subledger adjusting

journals exclusively in SLA or GL for easier reconciliation. Accounts that appear on the distributions (either manually entered or

generated by account generator mechanisms) of subledger transactions such as

Payables or Receivables invoices are not necessarily the final accounts thatappear in the SLA and GL journal entries. In Release 12, the accounts on the

transaction distributions become the default accounts used by SLA accounting

rules. Users may configure SLA accounting rules to further modify thedefault account by overriding the values for any of the segments in the

account combination. If users define SLA rules to change the default account,

then the SLA and GL journal entries will not match the account stored on thesubledger transaction distribution.

Account generator mechanisms that existed in 11i still exist and provide thesame functionality in R12.


41/49

41

Transaction Account Builder (TAB)

OverviewTransaction Account Builder (TAB) provides a flexible mechanism to derive default

accounts for subledger transactions that is fully integrated with Subledger Accounting

(SLA). TAB is intended only for applications that allow users to modify the defaultaccounts for a transaction before it is committed.

Process Change

Advanced Global Intercompany System (AGIS) has adopted TAB in Release

12

o Additional setup in AGIS is required to use TAB to define default

accounting for transactions.

o Distributed accounts must be defined for each ledger and are generated

as defined in Subledger Accounting Transaction Account Builder

(SLA TAB).


Sources and account derivation rules are shared with Accounting MethodsBuilder (AMB), while transaction account types and transaction account

definitions are introduced by Transaction Account Builder.

Dynamic insertion can be enabled for the chart of accounts so that if thecombination does not exist, a new code combination can be created.

Considerations

If the application does not allow modification of the default accounts for a

transaction before it is accounted, the implementation team must use AMB. Implementation teams may use the seeded transaction account definitions.

They may also create their own definitions either by copying and modifying

seeded definitions, or by creating new ones from scratch.

If implementation teams decide to create new transaction account definitions,

they may need to create new account derivation rules. These rules can bederived by accounting flexfield or by segment and may have a chart of

accounts associated with them.

Standard Reports

Overview

Subledger Accounting owns tables that store all the subledger journal entries and their

associated accounting information. Regardless of which product is used to createaccounting, the results are stored in subledger accounting tables. This information

may then be used by analytical applications for inquiries and/or reporting.

A common data model is designed for efficient inquiry, reporting, andextraction.


42/49

42

Oracle BI Publisher reports and templates offer immediate cost savings,greater efficiency, and improved accuracy and reliability for financial

reporting.

Process Change Oracle BI Publisher is a key reporting tool in Release 12 that enables business

users to create financials reports with familiar desktop products like Microsoft

Word and Excel.

BI Publisher can save reports in many different formats including XML, PDF,RTF, and Excel. It can also publish reports via printer, e-mail, or posting towebsites or portals.

With Release 12, weve made it easier to locate and use reports by classifying

them into three main categories: Journal Reporting Trading Partner Reporting

Account Analysis Reporting

Considerations

Analyze custom reports to map out a plan/approach to migrate existing reportsto Oracle BI Publisher.

Custom reports may need to be modified to extract data from SLA tablesrather than subledger distribution tables.

Open Account Balance Listing Definitions: In R12, to run the TrialBalance Report for a particular liability account, you must create the OpenAccount Balance Listing Definition. Implementers need to create their own

definitions for any new liability accounts they have created. The upgrade

process will create Open Account Balance Listing Definitions for eachexisting liability account per ledger.

See Oracle Subledger Accounting Implementation Guidefor more detailed information.


43/49

43

Oracle E-Business Tax

E-Business Tax is a new product introduced in Release 12 that provides a single point

solution for managing transaction tax requirements across several E-Business Suite

products. E-Business Tax has changed transaction tax handling within Oracle products:

fromfixed rules touser configurable rules

fromsingle product setup tocross product setup

fromsingle organization setup tocross organization setup

frommultiple engines tosingle engine (see caveats in sections below)

frommultiple repositories tounique repository (see caveats in sections below)

The key components of E-Business Tax are:

Configuration Options and Provider Service Subscriptions

Tax Configuration Manager

Tax Determination Services

Tax Reporting Tax Simulator

Configuration Options and Provider Service Subscriptions

OverviewThe configuration subscription model delivered by E-Business Tax optimizes tax setup

and ensures tax rules are consistently applied within the enterprise. There are two

subscription options in Release 12:

Internal (or multi-entity) subscription model to share tax setup across entities,with overriding capabilities at the Legal Entity and Operating Unit levels. The

internal subscription model is based on several key concepts:o Configuration Owner: any Legal Entity or Operating Unit that creates and

maintains specific tax setup data;

o Global Configuration Owner (GCO): enterprise level tax configuration

owner. This is the entity that owns tax setup data that any configurationowner within the enterprise can subscribe to;

o Option to override GCO tax setup data: a subscribing entity can override

the tax setup data to handle specific requirements applicable to that entityonly.

External subscription mode

Pre Upgrade Check List for Oracle Financials

Documents

Transcript of Pre Upgrade Check List for Oracle Financials