R12 Upgrade Considerations by Product v6.0-1

RELEASE 12
Upgrade Considerations
by 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
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
2
Introduction
This document is a supplement written by professionals in Oracle’s 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. It
describes 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 implementation
guides 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 Guide
Oracle Financials and Oracle Procurement Functional Upgrade Guide: Release 11i to
Release 12.
3
Oracle Advanced Collections
Release 12 of Oracle Advanced Collections extends transactional and customer data in

collection management processes within and across operating units (OUs). New Multi-
Org Access Control security profiles manage each collector’s 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 more
complete understanding of each customer’s 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 Territory
Hierarchies
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 to
either Oracle Advanced Collections or the new functionality in Oracle Receivables.
Oracle Advanced Collections provides the flexibility and high degree of configurability
required 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 collections
tracking 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 not
purchased 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.
4
Process Change
• Pay heed to the order and frequency in which the concurrent programs that
automate the collections processes are run. For instance, some organizations
run 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 are
responsible for managing specific customers, collections territories can be
created 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 selecting
“Receivables 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 or
Receivables users) include:
o Configurable dunning letter templates using Oracle BI Publisher
o 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 and
Receivables 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 Advanced
Collections 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 Guide and Oracle Advanced

Collections User Guide for more information.
5
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 when
intercompany 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. During
the 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 for
Intercompany / Intracompany accounts.
• Release 12 supports legal entity integration with intercompany balancing rules
for intercompany 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.
6
• You can create an optional intercompany segment in your chart of accounts
structure. It will automatically be populated with the balancing segment value
of the trading partner to provide more detail for reporting and reconciliation.
• 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 has
been 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 only
one legal entity to associate to an intercompany organization. In that case the
organization 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 to
users instead of responsibilities. Security grants are created for the users based
on 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
• See Oracle Advanced Global Intercompany System Release 12 Roadmap
Document
• See Advanced Global Intercompany System White Paper
Manual Intercompany Transactions
Overview
The Manual Intercompany Transaction window facilitates intercompany transaction
processing 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 (no
restriction on COA, currency, calendar), with optional proration of amounts
across recipients.
• Maintain intercompany periods to control timing of transactions (eg during
period 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.
7
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 of
the 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 creation
of 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 business
practices require them.
• GIS transaction types are upgraded to the new intercompany system
transaction types. When GIS transaction types are upgraded, the Allow
Invoicing option is set to Not Required. In order to take advantage of the new
invoicing feature in AGIS, you should manually select the Allow Invoicing
check 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.
8
• Create additional AR customers and AP suppliers to represent your
company’s subsidiary legal entities.
• Map the intercompany organizations that are trading partners to AP Suppliers
and 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 accounting
balances between the intercompany organizations.
Release 12 highlights for Intercompany Reconciliation;

• View intercompany out-of-balance accounts and drill down to details of the
subledger accounting and documents.
• BI Publisher technology for reconciliation reporting: the layout is fully
customizable 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 the
intercompany reconciliation report.
• Optionally download report output to Excel for additional analysis.
• Optional – customize BI Publisher report layouts.
See Oracle Advanced Global Intercompany User Guide for more information.
9
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 ceiling
name, 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 manual
preparation of mass addition lines.
• Automatic Depreciation Rollback

o Depreciation is rolled back automatically when any transaction is
performed 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 asset
book; 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
10
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 Create
Accounting.
• 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 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.
• Prior to Release12, accounting records were not created until after
depreciation had run. For example, if you added an asset and went to the
Transaction History form, you would not see any addition accounting lines if
depreciation had not been run. Post upgrade, however, these records would
appear 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 discussed

in a separate section of this document.
In summary, the key setup steps are:

o Compile the Application Accounting Definition in SLA. Please note
that the pre-seeded account derivation definitions have been provided
for Assets. You can use the seeded account derivation definitions or
modify them as required.
o Complete the Accounting Setup flow in Oracle General Ledger.
11
Considerations
• You may have to look carefully at the clearing account in your category
setups if you are planning to use default rules for automatic preparation of
mass addition lines. If you have been using the same clearing account across
different categories, the default rules will not work effectively.
• In Release 12, Oracle continues to support Account Generator functionality
for existing asset books. However, the common SLA platform provides many
opportunities 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 complex
customizations on your part.
See Oracle Assets User Guide for more information.
12
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 several
architectural 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
Overview
In 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, Oracle
Payroll, Oracle Treasury and Oracle Cash Management does not change in
Release 12. Internal bank account maintenance, however, is done differently as
described below.
• There is new user interface in Oracle Cash Management for bank, bank branch
and 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 in
the 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 to
link a bank-counterparty in Treasury to the bank branch in Cash Management,
using Treasury’s 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,
13
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 in
Oracle Cash Management. If you previously had to create two separate bank
account 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 single
bank 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 them
through Oracle Payments and account for them using Oracle Subledger Accounting.
Process Change
• New user interface is available for capturing and, separately authorizing bank
account transfers.
• Bank account transfers can be created intra-company (between two bank accounts
belonging 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 data
entry.
• Privileges to create bank account transfers are granted to a user role by legal
entity in the Oracle User Management security wizard.
• Accounting configuration for bank account transfers is done in subledger
accounting. Seeded journal line definitions are provided for bank account transfer
clearing 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 System
in 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.
14
Bank Account Balances and Interest
Overview
In 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 Cash
Management. 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 bank
balance 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 in
Treasury, 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 Guide for more information.
15
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 single
responsibility.
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 of
Books 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 using
different currencies, charts of accounts and/or calendars.
• Secondary ledgers and reporting ledgers to create alternate accounting
representations 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 legal
entities 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 be
assigned 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 set
of books, then they will be associated to a primary ledger in an
accounting setup.
16
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 Accounting
Engine) 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 corresponding
features 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 subledger
accounting 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 assigned
called Standard Accrual or Standard Cash. All upgraded public sector
ledgers will have a subledger accounting method assigned called
Encumbrance 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 to
ledgers or mapped to balancing segment values.
• Create primary and secondary ledgers and mappings for alternate accounting
representations from single transaction (replacement for the Global
Accounting Engine Dual Posting solution in Release 11i).
Considerations
• Sequencing is determined by the ledger. Journal entries may have multiple
legal 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 11i settings, 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 ledger
options 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 to
view your Release 11i setup for Multiple Reporting Currencies, General
Ledger, Global Accounting Engine, Assets, Payables, and Receivables. This
17
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 General
Ledger 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 cross–validation rules and flexfield value security
rules. 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 data
access set for each ledger and reporting currency (journal level or subledger
level) assigned to a completed accounting setup. The system-generated data
access sets created for each ledger and reporting currency provide full read
and write access to the ledger and all of its balancing segment values and
management segment values.
• (Optional) Manually create data access sets to further control read and write
access to ledgers, ledger sets, or specific balancing segment values or
management segment values for a ledger or ledger set. For example, if you
have 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 balancing
segment values or legal entities.
• To associate a data access set to a responsibility, you must assign a data
access 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 same
chart of accounts and accounting calendar/period type combination.
18
• Use data access sets instead of flexfield value security rules to secure read and
write 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 not
be 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
Overview
Sets 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 processing
across 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 ledger
sets
• Create ledger sets to group ledgers with the same chart of accounts and
calendar / period type.
• Assign ledger sets to data access sets for user access and security. The system
automatically 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 the
ledgers 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 can
contain other ledger sets.
19
• 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 general
ledger.
Replacement for Disabled Accounts
Overview
Prevent 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.
See Oracle General Ledger Implementation Guide, Oracle General Ledger Reference
Guide and Oracle General Ledger User Guide for more information.
20
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 different
statutory 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 Legal
Entity Configurator which guides the user through the LE creation process.
Overview
The Legal Entity Configurator allows you to define legal entities to meet statutory
principles 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 tax
authority)
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 is
used to default an LE. For example in AR the legal entity derivation
hierarchy for transactions is
1. Transaction Type
2. Batch Source
Assigning a LE to a transaction type or batch source is optional and
only the LE’s mapped to the ledger associated with the OU are
available to assign.
o Legal entity can also be defaulted from the default legal context of 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 to
the 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:
21
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 Reporting
Entities, VAT Reporters, Brazilian Companies and Global Descriptive
Flexfields)
• Create legal entities and assign them to accounting setups. An organization of
type 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 upgraded legal entities, HR Organization cannot be
used for creating a new LE in Release 12.
• Configure existing organizations to be legal entities or establishments as
appropriate.
• Use Legal Entity Associations to maintain the association between business
constructs (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 processing
options (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 a
legal entity. One way of determining the operating units associated with a
22
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 Document which
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.
23
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) and
their 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 supplier’s
company 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 the
scenes. The information that will be stored in TCA includes supplier name
and legal information, address and contact information. The parties are created
with 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.
24
• Existing tables that hold the supplier information are moved to a new set of
tables (AP_SUPPLIERS).
• New views, based on the old supplier table names have been added for
backward 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, a
new party site will also be created.
• When merging suppliers, supplier merge should be performed before initiating
the party merge.
• Supplier or supplier site merge does not affect contacts. The contacts are
always transferred to the merged supplier site specified in the supplier merge
form.
• Employees that were defined as suppliers in prior releases will not be
migrated, as their information would already exist in TCA.
• Supplier open interface processes are enhanced to support the creation of TCA
entities while importing suppliers. The creation of supplier bank accounts is
also supported from the supplier open interface.
Invoice Lines
Overview
The 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 as
enhancing the matching function.
Process Change
• The new Invoice Workbench now contains a multi-record block to represent
the 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 matching
process 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 item
lines on an invoice.
• Users can enter freight at the invoice header and then prorate it across all item
lines on the invoice.
25
• Users can also do a quick match by entering just the PO number on the
invoice 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 a
parameter for each individual invoice line. To invoke this feature, users check
the “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 accrual
account 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 longer
part of the item distributions.
• Charge (tax/freight/miscellaneous) distributions are created at the maximum
level 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 are
some 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 Payments
dashboard
• 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 to
review, modify, or remove from a pay run.
26
• 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 all
current pay run processing and gives them visibility to payment processes that
require attention.
• If payment batch sets were used as a workaround for doing multi-currency pay
runs in 11i then, consider combining those pay runs into a single pay run. In
addition a single payment run can process multiple banks that includes both
electronic 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 the
invoices 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, the
user can see the final amounts of each payment and can choose to drop any
payments.
• Scheduled Payment Selection report replaces many portions of the
Preliminary Payment register report. It can be used for reviewing the invoices
selected in a pay run, review invoice selection criteria, determine immediate
cash requirements for a pay run etc.
• 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 own
payment 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 removed
from 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 been
retained in Release 12. However, Payables no longer supports the Wire
Payments and Clearing Payments document categories.
27
AP-AR Netting
Overview
The 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 is
handled 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 can
include various parameters like operating unit, netting agreement, settlement
date 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 were
selected for possible netting. In the header portion of the screen users will be
able 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 can
review, 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 Accounts
Receivable.
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 receipts
generated 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 approver
can be selected. The approver name list of values is derived from the customer
contact information.
• No netting batch information will be upgraded.
28
• Netting agreements will be created for every existing customer and supplier
relationship 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 valid
values.
• 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.
See Oracle Payables Implementation Guide and Oracle Payables User Guide for more
information.
29
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 Payments
has changed payment processing within Oracle products:
• From proprietary Oracle reporting technology to standardized formatting using

XML.
• From bank accounts stored in multiple products to centralized bank account setup.
• From credit card information stored in multiple product entities to a centralized
credit card entity within Payments.
• From single operating unit restrictions to cross-operating unit transactions..
• From receipt remittance through Receivables to centralized receipt remittance.
• From payments transmitted by external systems to native transmission
capabilities.
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 enables payment administrators to

manage every aspect of the process across multiple organizations from a
central location in the application.
• End-to-end electronic payment processing that includes validation,
aggregation, formatting, and secure transmission of payments to financial
institutions and payment systems.
• Remittance advice reporting that notifies a payee of the remittance detail
when a payment is made.
• Country-specific payment formats and reporting that meet global payment
requirements.
30
Process Change:
• In Release 12, Oracle Payments segregates the process into two major
functions: Payment Build process and the Payment process.
o Payment Build process first groups documents according to various
rules, such as the payment method and currency.
o Payment process aggregates payments from multiple document
selections and submissions into payment instruction files, formats the
files, 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 disbursement
processing. Some of the key areas of impact are:
o Payment Methods: each document to be paid requires a payment method
to indicate how it should be handled in the funds disbursement process.
The upgrade seeds payment methods that existed in Oracle Payables and
globalizations. Payment Methods are now user definable.
o Processing Rules: the payment method on a document links it to
processing rules configured in Oracle Payments. These setup rules are
held in a key entity called the Payment Process Profile.
o Payment System: a payment system holds information about the third
party involved in processing payments.
• The upgrade uses various data from Oracle Payables to create the new
Payment Process Profiles. See Oracle Payments Implementation Guide for
more detailed information.
• All masking of credit cards, debit cards and bank accounts is centrally
controlled.
• Future Dated Payments are renamed to Bills Payable in release 12. Setup has
moved from the payment document on an internal bank account to the
payment method in Oracle Payments.
Considerations:
• Both the Automatic Payment Programs and Payment Formats (AP entities)
are obsolete in release 12. Also, setup entities related to payment formats
within Oracle Payables are obsolete as they are effectively replaced by the
new Oracle Payments setup.
• Oracle Payments’ secure electronic payment file and payment message
transmission and transmission result processing replaces previously existing
electronic transmission features in Oracle iPayment, Oracle Payables, and
Oracle Globalizations.
31
Funds Capture
Overview
Funds 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 electronic
funds transfers from bank accounts, and to format bills receivable.
The major features within funds capture are:
• Funds Capture Dashboard provides payment administrators an overview of

the payment process status.
• Supports multiple payment processing systems operating simultaneously for
funds capture transactions.
• Supports authorization and settlement of funds against credit cards and
PINless 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 Guide for more details.
• Credit card security setup can be easily completed using the Oracle Payments
Payment Administrator responsibility.
• The required setup entities for bank account transfer processing are upgraded
for 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 all
payment systems. EFT online validation checks whether a bank account exists
and 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.
32
• Oracle Payments does not automatically reauthorize settlements that are
rejected due to expired authorizations.
See Oracle Payments Implementation Guide and Oracle Payments User Guide for more
information. Also see Metalink Note733537.1 for more details in the Functional
Upgrade Impacts Document for Oracle Payments (FINANCIALS).
33
Oracle Receivables
Oracle Receivables streamlines the invoice, receipt and customer deduction processes
while simultaneously improving cash flow, increasing efficiency and optimizing
customer 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 revenue
in 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 revenue
allocations for partial periods.
• Enhanced event-based revenue management allows users to define revenue
deferral reasons and corresponding revenue recognition events specific to
their business practices.
o Ability to create user defined revenue contingency definitions seeded
examples 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 that
enables the user to create process specific revenue assignment rules.
• New Contingency tab offers the ability to review and manually manage
contingencies 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 meets
accounting 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
34
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 Daily Daily Fixed Variable

Period Revenue Revenue Schedule Schedule
Rate, All Rate,
Periods Partial
Periods
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 will
assign 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 & COGS
matching.
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 from
Receivables.
o Once this order is imported into Receivables from Order Management, the
Contingency Defaulting API runs again and can default additional
35
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) will
automatically 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 new
contingency 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 any
combination 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.
36
• Does not use application rule sets.
• If necessary, modify the AR profile option “Always Default Transaction
Balance” 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
Overview
The 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, customer
account site, and a business purpose for the customer account site.
• Tight integration with TCA allows users to take advantage of the DQM (Data
Quality 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 by
determining if the customer that is being created or updated is a potential
duplicate.
• Ability to classify customers based on industry, location, size, credit
worthiness, business volume and payment cycles.
• The new Customer Standard UI replaces the five functions that used to exist
in prior releases (Customers Standard, Customers Quick, Customers
Summary, 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 customer
form.
• No data is affected.
• Display of data has been enhanced to represent the TCA model.
37
Bill Presentment Architecture
Overview
Bill 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 Printing
o 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 Guide and
Oracle Receivables User Guide for more information.
38
Oracle Subledger Accounting
Oracle Subledger Accounting (SLA) provides a common accounting engine that replaces
the existing accounting processes in the subledger applications. The SLA upgrade
involves migrating existing accounting data between 11i and Release 12 to ensure a
continuous business operation.
NOTE: Please refer to the Oracle Subledger Accounting Implementation Guide for more
detailed information and definitions of the terminology used herein.
Oracle Subledger Accounting has changed accounting within Oracle applications:

• From accounting setups within each Oracle module to a unified accounting
definition in Subledger Accounting, with a common posting process to Oracle
General Ledger.
• From separate Global Accounting Engine functionality to a common standard for
all 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 standardized
accounting 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 Oracle
subledgers.
• If specific requirements are not met by startup accounting definitions, users
can copy and modify the seeded definitions and their assignments.
39
• In Release 12, each subledger application will maintain its existing accounting
rules; and Accounting Methods Builder (AMB), delivered within Subledger
Accounting, will work in conjunction with those rules. Implementation
teams 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 accounts
and 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 the
accounting 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. Deploying
companies 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 accounting
rules 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 that
appear 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 the
default 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 the
subledger transaction distribution.
• Account generator mechanisms that existed in 11i still exist and provide the
same functionality in R12.
40
Transaction Account Builder (TAB)
Overview
Transaction 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 default
accounts 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 Methods
Builder (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 the
combination 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 be
derived 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 create
accounting, 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, and
extraction.
41
• 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 to
websites or portals.
• With Release 12, we’ve 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 reports
to Oracle BI Publisher.
• Custom reports may need to be modified to extract data from SLA tables
rather than subledger distribution tables.
• Open Account Balance Listing Definitions: In R12, to run the Trial
Balance Report for a particular liability account, you must create the Open
Account 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 each
existing liability account per ledger.
See Oracle Subledger Accounting Implementation Guide for more detailed information.
42
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:
• from fixed rules to user configurable rules
• from single product setup to cross product setup
• from single organization setup to cross organization setup
• from multiple engines to single engine (see caveats in sections below)
• from multiple repositories to unique 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
Overview
The 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 configuration
owner 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 entity
only.
• External subscription model where the Configuration Owner may choose to
subscribe to the services of a Tax Service Provider for a given tax regime.
Process change
• Each entity within an organization can subscribe and use a single common
configuration source for all transactions. Alternatively, that entity can use the
common configuration source with overridden tax set up specifically required to
meet its own tax regulations;
43
• In Release 11i, the option to integrate with tax service providers was restricted to
Vertex and Taxware. In Release 12 that restriction no longer exists: you can
choose to integrate with your preferred tax partner. See considerations below.
See Oracle E-Business Tax Implementation Guide and Oracle E-Business Tax: Vertex
Q-Series and Taxware Sales/Use Tax System Implementation Guide
Configuration change
• If all entities in your enterprise are subject to the same tax regulations you can
setup tax only once, under the Global Configuration Owner, and have all your
entities subscribing that common tax setup;
• If any entity within your enterprise requires special tax handling that differs from
the common tax setup, you can either override the common tax setup that is
owned by the GCO or create and maintain specific tax setup for that entity that
becomes a Configuration Owner itself;
• You can optionally subscribe services of external providers to handle tax
configuration and tax calculation, using standard API’s.
Considerations
• Integration with external tax providers is currently available in the Order-To-Cash
business cycle only and restricted to Taxware and Vertex’s product versions that
were supported in Release 11i;
• Testing of standard API’s to integrate with external tax providers in the Order-To-
Cash and Procure-To-Pay business cycles is not completed at the date of writing
this document:
o Order-To-Cash testing underway, using Vertex O Series as a pilot;
o Procure-To-Pay testing not scheduled.
Tax Configuration Manager
Overview
The Tax Configuration Manager component is responsible for creating and maintaining
the structural foundation of Tax such as taxes, tax jurisdictions, fiscal classifications, tax
rates, tax rules.
In Release 12 there is an explicit association between tax setup and Legal Entities or
Operating Units. The enforcement of adequate tax rules across Legal Entities or
Operating Units within your company ensures that tax is correctly applied to all
transactions. This is particularly important when you operate in multiple countries with
disparate tax regulations, often times in a shared service model. Legal entities in each
country will be subject to local tax regulations which will impact the entire company.
Tax setup is uniformly created in a common User Interface for all Oracle products. Tax
regulations are defined only once and applied consistently across products.
44
Legal and business tax regulations are mapped to flexible tax rules and other components
of E-Business Tax. If your company expands business to new countries with different tax
requirements, you can easily scale the existing tax setup to meet those new requirements.
Tax configuration is central to the tax role. That premise has determined the creation of
tax configuration flows totally dedicated to the tax manager. There is a clear segregation
of User Interface flows for tax managers and for general business users.
Process Change
• There is a unique tax setup flow and common user interfaces across products. You
no longer need to enter tax setup in multiple product;
• Tax setup creation and maintenance is done in new User Interfaces. See Oracle E-
Business Tax Implementation Guide.
• You have multiple options for defining tax setup in Release 12:
o Migrate tax setup from Release 11i, and gradually adopt the E-Business
Tax setup and tax determination processes according to your needs. Once
you complete the transition to E-Business Tax processes, you can disable
the Release 11i migrated solution with no loss of service. See Oracle
Financials and Oracle Procurement Functional Upgrade Guide: Release
11i to Release 12.
o Manually enter your tax setup;
o Use the Tax Configuration Library with modifications: you can take
advantage of this predefined set of tax configuration data that may be used
as sample data to guide and expedite the E-Business Tax implementation
process. See Metalink note 463001.1;
o Integrate with tax content providers. See Configuration Options and
Provider Service Subscription above.
• Prior to Release 12, you could define Legal Entities in multiple, sometimes
ambiguous, ways. With the new Legal Entity model you now have to explicitly
define your legal entities as well as the association with the appropriate tax setup;
• Instead of creating tax setup in various products, like Oracle Payable or Oracle
Receivables, you create a single tax setup that is applied consistently across
products;
• Central setup and maintenance is now performed in new User Interfaces dedicated
to your tax personnel;
• The Tax Rules flow makes it easy for you to change existing tax rules and tax
rates and/or create new rules and rates, without modifying the product;
• You have the option to run taxes in Release 12 similarly to how you did it in
Release 11i and gradually migrate to the new E-Business Tax model, when you
have the time or the need to adopt the new capabilities of E-Business Tax.
Considerations
• Cannot update tax exclusiveness at invoice header or invoice line levels. See bug
6772098;
45
• There is no support for tax point date in E-Business Tax;
• Tax reporting configuration is associated with a Legal Entity and Tax Registration
Number. It is not integrated with the E-Business Tax internal subscription model;
• Tax reporting configuration not shareable across Legal Entities or Operating
Units;
Tax Determination Services
Overview
The Tax Determination Services component calculates transaction taxes based on
transaction details and tax setup information. This component carries the following
benefits:
• Automation of tax processing through a central tax engine. It improves the
operation efficiency of your company and reduces errors;
• The central tax engine uses a common set of tax rules applicable to all your
business entities. Ensures the accuracy of tax calculation for all tax regimes your
company is subject to;
• Covers standard Procure-To-Pay and Order-To-Cash transaction taxes, with the
exception of withholding taxes and those taxes handled by the Latin Tax Engine
solution.
Process Change
• Instead of disparate tax services provided by multiple products, the central tax
engine uniformly delivers automated tax services through a single application
interface to:
o Procure to Pay - Oracle Purchasing, Oracle Internet Procurement, Oracle
Consigned Inventory, Oracle Internet Expenses and Oracle Payables
o Order to Cash - Oracle Order Capture/iStore/Quoting, Oracle Order
Management, Oracle Trade Management, Oracle Services Contracts,
Oracle Project Accounting and Oracle Receivables
o Inter-company invoicing - Oracle Inter-company invoicing
o General Ledger - Oracle General Ledger
Each product only needs to pass the required information to E-Business Tax to get
the right tax determination and calculation.
• E-Business Tax replaces the following Release 11i tax solutions:
o Procure to Pay – Automatic Tax Calculation and Brazilian Payables and
Purchasing
o Order to Cash – Global Tax Engine
o General Ledger – General Ledger Automatic Tax Calculation
• Your users no longer have to enter the correct tax code at transaction entry point:
E-Business Tax determines the applicable tax or taxes for each transaction and
automatically calculates the tax amount(s). Only your authorized users can
override calculated tax amounts.
46
• There are distinct flows for tax setup and for operational activities such as
entering transactions;
• Tax determination and tax calculation are fully automated, based on tax setup
previously defined by the tax manager;
• Clerks whose main responsibility is to correctly enter transactions in the system
can rely on the product to get the correct taxes applied to transactions. They no
longer have to enter the relevant tax codes for each transaction because E-
Business Tax does that for them, reducing the risk of human errors.
Considerations
• Tax functionality not migrated to the E-Business Tax model, retained in Release
12: Payables withholding taxes, Payables Extended Withholdings (Latin
America), Latin Tax Engine (Receivables), Brazilian Withholding Tax Calendar,
Indian transaction taxes and EMEA VAT Reporting.
Tax Reporting
Overview
Tax Reporting and auditing rely on a single tax repository that stores both reference data
(taxes, tax jurisdictions, fiscal classifications, tax rates, tax rules, etc,) and transactional
data.
In addition to the single tax repository, tax reporting and auditing take advantage of the
XML Publisher reporting tool that facilitates output manipulation. It’s extremely easy to
customize existing templates or to create new ones using XML Publisher.
Prior to Release 12, tax reporting was a lot compromised by how you implemented your
legal entities. In Release 12 you can run all your tax reports by legal entity.
Tax reporting was largely enhanced with features initially requested by EMEA countries,
which can be used by countries in other regions with the same type of requirements.
Process Change
• Reference data and transactional data are now available from a central Tax
Repository. You no longer need to search for tax information in multiple
products;
• Enhanced tax reporting configuration with dedicated User Interfaces where you
define all reporting rules for your Reporting Entities;
• New reports delivered for Austria, Croatia and Israel;
• Business users can easily update templates delivered in the core product or create
new templates without changing code. The majority of tax reports are converted
to XML Publisher.
47
See Oracle E-Business Tax Reporting Guide and Oracle Financials for Europe
User Guide.
• Ability to run tax reports by Legal Entity and Tax Registration Number. In
Release 12 you can still run tax reports by Balancing Segment Value, however,
Oracle expects you to gradually move to tax reporting by legal entity and tax
registration number;
• Definition of reporting categories to report transactions by different business
angles: sales, purchases, goods, services, stocks, assets, domestic, import, export,
etc.;
• Tax reporting based on tax calendar that can different from the accounting
calendar;
• Reporting based on a user definable tax reporting date;
• Preliminary versions of tax reports to be run in order to support corrections and
reallocations prior to finalizing the reports (declarations) to tax authorities
• Final reporting
• Close tax periods after final reporting to prevent updating or reporting twice
transactions already finally reported;
Considerations
• Core tax reports run by Invoice Date only;
• Tax calendars, alternative tax dates, preliminary and final reporting, tax reporting
categories (or tax boxes) only used by EMEA VAT Reports;
• In order to meet reporting requirements, some of the EMEA countries have to
define multiple tax rate codes with the same tax rate;
• Multiple Reporting Currencies support not available in all tax reports;
• Tax Repository does not store General Ledger tax journals;
• A few tax reports were not converted to XML Publisher (still available in rdf).
Tax Simulator
Overview
Tax Simulator allows you to enter transactions, such as a Purchase or Sales Invoice, and
view the results of the corresponding tax calculation.
It allows you to verify if the tax configuration provides the expected results on your
entered transactions. It also gives you the capability to drill down to the rules that were
used in the simulation and to the rules that were not used. You can evaluate results,
update the rules if required, and re run the simulation with same set of transactions.
This is a valuable tool for tax managers who can use this interface to verify the tax
configuration and to simulate the effect of the introduction of a new rule or incremental
setup data, such as a new tax rate.
48
Process Change
• There is no predecessor for Tax Simulator before Release 12. The Tax Simulator
has dedicated User Interfaces where you can test all the tax setup before going
live.
• You can test tax setup in Purchase or Sales invoices using the new User Interfaces
of the Tax Simulator. See Oracle E-Business Tax User Guide.
Considerations
• Requires manual entry of transactions for simulation – no option for uploading;
• Simulation is restricted to the behavior of tax rules. It does not allow simulation
of tax amounts to be paid or collected.
See Oracle E-Business Tax Implementation Guide, Oracle E-Business Tax User Guide,
and Oracle E-Business Tax: Vertex Q-Series and Taxware Sales/Use Tax System
Implementation Guide for more detailed information.
49

R12 Upgrade Considerations by Product v6.0-1

Uploaded by

Document Information

Original Description:

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

R12 Upgrade Considerations by Product v6.0-1

Uploaded by

Copyright:

Available Formats

RELEASE 12

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

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

Oracle Financials Concepts Guide

Release 12 of Oracle Advanced Collections extends transactional and customer data in

Other new features in release 12 Oracle Advanced Collections include:

• New Implementation Checklist and Setup Screens

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

See Oracle Advanced Collections Implementation Guide and Oracle Advanced

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

The key components of the Advanced Global Intercompany System are:

Manual Intercompany Transactions

Release 12 highlights for Intercompany Invoicing:

Release 12 highlights for Intercompany Reconciliation;

• Subledger Accounting(SLA) Architecture and Inquiries

• Enhanced Mass Additions for Legacy Conversions:

• Automatic Preparation of Mass Additions

• Automatic Depreciation Rollback

• Flexible Reporting using XML Publisher

• Enhanced Functionality for Energy Industry

• Generic Subledger Accounting Architecture configuration has been discussed

In summary, the key setup steps are:

See Oracle Assets User Guide for more information.

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

The key new features in Release 12 are:

• Centralized Internal Bank Account Model

Centralized Internal Bank Account Model

Bank Account Transfers

See Oracle Cash Management User Guide for more information.

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

Release 12 highlights for Oracle General Ledger include;

Centralized Accounting Setup

Data Access Sets

Ledger / Ledger Sets Architecture

Ledger sets facilitate the following accounting operations across ledgers:

Replacement for Disabled Accounts

Supplier Representation in TCA

Payment Process Enhancements

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

• From proprietary Oracle reporting technology to standardized formatting using

The key components of Oracle Payments are:

The major features within funds disbursement are:

• Funds Disbursement Dashboard that enables payment administrators to

The major features within funds capture are:

• Funds Capture Dashboard provides payment administrators an overview of

Revenue Management Enhancements

GL Date Period Days in Daily Daily Fixed Variable

• Ability to create user defined Revenue Assignment Rules:

Line Level Cash Application

Customer Standard User Interface (UI) Redesign

Oracle Subledger Accounting has changed accounting within Oracle applications:

The key upgrade areas impacted by Oracle Subledger Accounting are: