R12 FINANCIAL NEW

FEATURES OVERVIEW

Agenda
Why R12 Created
R12 architecture
New R12 Features
MOAC
Sub ledger Accounting and Ledger Sets
Legal Enhancement
eBtax
Global Intercompany system
Centralized banking
Reporting including XML Publisher

Q&A

Multi Org Access Control

Multi-Org architecture was first introduced in Oracle Applications
Release 10.6.
Its primary objective was to secure data from unauthorized access
by individual in different Operating Unit in enterprise.
Although security by Operating Units has been widely used as a
reliable method to protect from unauthorized access to information,
many customers have requested to increase flexibility to enable
user to access one or more Operating Units per user responsibility.
Multi-Org Access Control feature allows reduction in operating
costs, but more importantly, it lays a more flexible software
foundation to allow Oracle Applications to support complex
business model such as Shared Services without compromising
data security.

Access Control
The Multi-Org Access Control feature, also known as
"Security by Operating Unit", will enable users to access
to secured data in one or more Operating Units within one
responsibility.
The feature uses Security Profile concept introduced in
Release 11i Oracle Human Resources Management
System, which allows system administrator to predefine
the scope of access privilege as a profile option.
A security profile may be defined in hierarchical or listing
mode, which may consist one or more Operating Units.
A profile option, "MO: Security Profile", is used to associate
predefined security profile to a user responsibility.

In 11i the sub ledger accounting method (cash/accrual) was

used to be defined at the sub ledger setup (AP/AR).
However in R12 things have changed. You define the sub
ledger accounting method at the ledger level.
All sub ledgers tied to that ledger will use that particular
accounting convention.
So there is a difference in 11i and R12. The accounting
"Convention" is now married to the ledger and hence the term
4Cs.
If you are not planning to use sub ledgers then you do not
have to choose a value in the accounting method field. You can
leave it blank.
Your GL functionality will remain unaffected. However you will
have to specify an accounting method at the ledger setup,
before you could use a sub ledger.

Advanced Global Intercompany System

Advanced Global Intercompany System (AGIS) enables you to create, settle
and reconcile intercompany transactions.
Intercompany transactions are transactions that occur between two related
legal entities in an enterprise or between groups in the same legal entity.
Transactions that occur between two legal entities are called intercompany
transactions and transactions that occur between two groups within one
legal entity are called intercompany transactions.
The balances of the intercompany transactions must be eliminated or
adjusted when preparing the consolidated financial statement, or it might
result in overstated financial results, which in turn might lead to legal
repercussions against the enterprise.
Intercompany transactions can be identified and eliminated by the use of
specific accounts to book these transactions. Defining these accounts
allows you to book transactions that are identified as intercompany
transactions in the specific accounts.
These accounts must be defined as a part of the General Ledger setup
process.

R12 TCA-Trading Community

Architecture
In Oracle R12, Suppliers are now part of TCA(Trading
Community Architecture), where suppliers are defined as
parties and supplier sites as party sites.
Each supplier, supplier sites and contact details can be
defined globally in TCA level.
It means, any changes to supplier/supplier sites/address
reflects across Operating Units with out really updating
every OU and all the supplier information can be leveraged
by multiple Operating Units.
Supplier bank information can also be handled at TCA
level.

Invoice Entry & Cancellation

In Oracle R12, there is an additional level of detail called Invoice lines
between Invoice Header and invoice distribution to capture the data
related to Items, freight, miscellaneous, Tax, Prepayment or withholding
tax. An invoice line can have one or more invoice distributions.
With the introduction of invoice lines, there is lot of significant
improvement in the data flow to other modules which are integrated with
Payables.
For example:
1. Fixed Assets use the data stored in the Invoice lines fields such as
Manufacturer, Model, Serial Number, Warranty Number, Asset Book and
Asset Category to track the assets.
2. E-Business tax takes information from the AP invoice lines and
creates summary and detail tax lines in E-Business tax repository.
3. Sub ledger Accounting require the invoice distributions should be
stored at the maximum level of detail. With additional level in the invoice
hierarchy, data flow will be improved to the Sub ledger accounting.

Cancellation of Invoices
An invoice line may be discarded on
its own or as a part of invoice
cancellation.
A discarded invoice line will have an
amount as 0, marked as discarded
and creates a negative respective
transaction in the distributions.
If a line is discarded as a part of
invoice cancellation it will be marked
as cancelled.

Payment Process
In R12, Oracle Payments is a new module
introduced to centralize the payment
process into one payment engine, so that
multiple applications can leverage the
same functionality.
In R12 Payables, user can find Payments
manager under payment entry, which will
re-direct the page to a OAF page. So unlike
in 11i, user need to use Payables Payments
dashboard to begin the payment process.

Banks
Bank accounts are moved into TCA
architecture which needs to be
defined in R12
> Cash Management now owns
Banks Set up Definition.
> All the internal bank accounts of
11.5.10, will be migrated into
Centralized Bank model
automatically during the upgrade.

Transfer journal entries to General Ledger

Users can transfer journal entries to General Ledger in two ways.

1. RunCreate Accounting Programwith Transfer to GL option as Yes.

2. RunTransfer Journal Entries to GLafter running Create Accounting Program with

Transfer to GL parameter set to NO or after create accounting online in Final mode.
Create Accounting Program:
Payables Accounting Process is obsolete in R12 and is replaced with Create
Accounting program. The create accounting program creates sub ledger journal
entries by processing eligible accounting events. The Create Accounting program
uses application accounting definitions, which are created in Accounting Method
Builder(AMB) to create sub ledger journal entries.
The Create Accounting program
1. Creates and validates sub ledger journal entries.
2. Transfers the final journal entries in the current batch run to General Ledger and
starts General Ledger Posting Process.
3. Generates Sub ledger Accounting Program Report.
The create Accounting program creates journal entries in three modes.

Draft: Users can create the journal entries in SLA in draft mode
and can review and make changes again.
Final: With this option users can create journal entries in SLA which
can not be modified again. Here users need to run Transfer Journal
Entries to GL to post the sub ledger journal entries to GL.
Final Post: With this options users can create the journal entries
and post to GL with out using Transfer Journal Entries to GL
program.

Invoice Approval Workflow

Invoice work flow has been enhanced to include line level
invoice approval. Based on rules setup for Payables
Invoice Approval Transaction Type in AME, the work flow
determines if the invoice Header (invoice document)
needs approval or invoice lines needs approval or both.
If both invoice lines and document need approval, all the
lines of the invoice requiring approval must be approved
before the invoice document can be
approved.

The approval status both at header level as well as line

level shows whether the invoice document or invoice
lines need approval or not.

AP AR Netting
The Payables and Receivables Netting feature
enables the automatic netting of Payable and
Receivable transactions within a business enterprise.
You can predefine a netting agreement that
incorporates the netting business rules and
transaction criteria needed to run your tailored
netting process.
The netting process automatically creates the
Payables payments and Receivables receipts
required to clear a selected number of Payables and
Receivables transactions.