Oracle Applications: Oracle R12 Financials

R12, Financial track is one of BEST release ever. We have already seen some great functionality like:

A single responsibility to access and transact on multiple organizations
A single ledger to manage multiple currencies
Ledger sets to manage accounting processes across ledgers
Centralized rules engines for tax, accounting and inter company
A separate and simple payment creation and delivery solution
Centralized trading partners (suppliers, banks, first party legal entities)
Simplified reporting via XML Publisher and DBI
Netting across trading partners
Here are some of features:

Oracle Payable:

Few Features like invoice Lines, Line level approvals, Matching to a PO shipment or receipt, Suppliers in TCA makes a complete new look. Read in details:

Read for more details

Welcome to R12 Account Payable:

As we learnt during Release 12, the E-Business Suite has couple of new products like Subledger Accounting, E-Business Tax thus significant changes have been observed in Account Payable data module as some of functionality is shared by some other products. Thus it is important to understand what is new. I would like to briefly outline the details of some of new changes and underlying impact on the objects. More details can be found in R12 release documents published by Oracle a month ago.

Let’s have a dissection view of R12 payable, with some of its core objects

Suppliers:

We have seen in 11i

Suppliers defined in AP.
Supplier contacts replicated for each supplier site.

Where as in R12

A single change to an address can be seen instantly by all OUs
No longer need to manually ‘push’ updates across OUs.This can be best understood by the figure below.
Supplier becomes as TCA Party.
Suppliers Sites as TCA Party Site for each distinct address.
Contacts for each supplier/address , it means Single supplier address and contact can be leveraged by multiple sites, for each OU

Then the question is what will happen if any one can come from existing financial products. The Impact from upgrade can summarize as:

1. When we upgrade supplier tables replaced with backward compatible views.

2. One party site for each distinct supplier site address

Country and address line1 are required, this is because creation of suppliers in Party in TCA data model would requires Country and address information, but it also understood if there is no country or address line 1 specified for a supplier site in cases when upgrades takes place, Payables derives the country based on the most frequently used operating unit of the Supplier’s historical transactions.

3. Employee as suppliers: address NOT migrated to party site in TCA remains in Oracle HR for data security reasons.

As we know in 11i employees are part of internal supplier’s record in order for Oracle Payables to create payments for their expense reports. Employees defined in Oracle Human Resources and associated with an Oracle Payables supplier record have existing party information. During the upgrade, Oracle Payables updates the existing party information to have a party usage of supplier but it does not migrate the employee address to the party site in TCA, they remain in Oracle Human Resources for data security reasons.

Utilize TCA Party relationships for franchise or subsidiary and its parent company.

Invoice:

Till 11i version, we have seen invoices:

Had only distributions line.
Allocation of freight and special charges are captured at the distribution level only
Tax and payment and Project accounting Payment was captured through global Descriptive Flexfields.

But in R12,

1. Invoice Lines as a new additional line accommodated in Invoice data model.

Because of introduction of invoice line there is significant improvement of data flow with n other oracle modules like

Fixed Asset - Asset Tracking
Business Tax - Tax line
Payment - Payment
SubLedger Accounting - Accounting

Allocate freight and special charges are captured to the lines on the invoice

3. Invoice distributions created at the maximum level of detail similar to 11i.

Core functionality

The impact with Upgrade can be summarized as:

One invoice line for every distribution in 11i

2. Sub Ledger Accounting requires that Payables transform the invoice distributions to be stored at the maximum level of detail

3. Global Descriptive Flexfields migrated to named columns.

That’s means functional testing is more required while upgrade takes place.

Banks and Bank Details

Now a days corporate treasury role has been greatly enhanced thus picking up a global bank as partner

for all banking need is demand of time in global working model. The recent couple of years have seen drastic increase in acquisition and merger of company thus global working as well as global instance get popularity in ERP arena, and this is one of reason of the reason bank data model has been significant changes from 11 to 11i and 11i to R12.

Internal Bank Accounts

In 11i you might have observed, internal Banks defined in AP and that is shared by AP/AR/CE, Payroll and Treasury and they are bank accounts often replicated in multiple OUs

Where as in R12,

Bank and Branch become part of TCA Parties.
Internal Bank Account in Cash Management which is owned by a Legal Entity. Here the Operating units have granted usage rights.

Suppliers Bank Accounts

In 11i

Banks/Branches defined in AP
Bank accounts often replicated in multiple OUs Before

R12

Suppliers, Banks and Branches are defined as Parties in TCA
Supplier (party’s) payment information and all payment instruments (Bank Accounts, Credit Cards) moved into Oracle Payments.

The typical data model for bank can be summarized as:

Impact of Upgrade

1. With Upgrade banks and branches migrated to TCA parties

2. Banks merged if the following attributes are all the same:

a. Bank Number

b. Institution type

c. Country

d. Bank admin email

e. Bank name alt

f. Tax payer ID

g. Tax reference number

h. Description, Effective dates

Bank accounts, bank account uses are migrated into cash management.

Transactions are stamped with the bank account uses identifiers as part of the upgrade

Integration with Oracle E-Business Tax

In 11i

Oracle standard functionality was based out of User which determines tax by assigning Tax Codes at line level of invoice and Tax rules was controlled at underline code.
There was global descriptive flex fields were captured for country-specific tax attributes.
More important at most of the setup performed at OU level.

In R12

A new module eBusinessTax determines tax based on facts about each transaction, this is reason why Oracle has introduced additional line information at invoice level.
The module “ebusiness Tax” set and configure Tax rules which can be viewed
Tax attributes collected in fields on key entities
Configure tax rules once per regime and share with your legal entities

Impact of Upgrade

1. Payables Tax setup, Tax Code defaulting rules defined per OU are migrated to eBusiness Tax.

2. OUs migrated to tax content owner in R12

3. Tax information in tax codes are transformed to Regime-Rate flow.

E-Business Tax takes information from the AP invoice lines and creates summary and detail tax lines in the E-Business Tax repository.

Multi Org Access Control

MOAC is new enhancement to the Multiple Organizations feature of Oracle Applications.

This feature enables user to access data from one or many Operating Units while within a set given responsibility. Due to this change, all processing and some Reporting in Oracle Payables is available across Operating Units from a single Applications responsibility. Hence you can isolate your transaction data by Operating unit for security and local level compliance while still enabling shared Service centre processing. Data security is maintained using the Multiple Organizations Security Profile, defined in Oracle HRMS, which specifies a list of operating units and determines the data access privileges for a user.

Impact of Upgrade

R12 Upgrade does not automatically create security profiles, thus is important if any one want to use Multiple Organizations Access Control, the first things is to define security profiles, then link them to respective responsibilities or users.

Reference: Details can be found more on R12 RCD documents, from Oracle site.

R12 : Suppliers & Trading Community Architecture:

In earlier post, we have seen supplier has been moved into TCA model. Comparing to 11i version, three new AP tables containing supplier unique data been introduced. They have the links to TCA tables:

AP_SUPPLIERS
AP_SUPPLIER_SITES_ALL
AP_SUPPLIER_CONTACTS

And more important we understood three old PO Vendors tables obsolete, by Views provided for backward compatibility

Here is data model .This will really helps you to understand while designing integration with EBS R12.

Legal Entity & Legal Entity Architecture

Release 12: Legal Entity uptake

We are well aware of some of Oracle E-Business Suite R12 Architectural changes in the Financials section like:

Legal Entity
Ledger Sets
Accounting Engine (SLA)
Transaction Based Taxes(E-Tax)
Inter-company Accounting (AGIS)
Multi-Organization Access Control (MOAC)

Let’s uptake to Legal Entity:

Financial books defined as “A Legal Entity is an entity identified through the registration with the legal authority.”

That’s means,In this compliance world and in Oracle system it corresponds closely and defined as the system “Legal Entity” corresponds with an independently identifiable “legal person” a public company, a private business or limited partnership, a trust, a not-for-profit, a government or a non-government organization (NGO) - that can operate as if it were a real person in conducting business transactions.

What is meant for with LE?

Own property weather its is assets or inventory or receivable
Trade (borrow, sell, buy, incur expenses, employ)
Repay debt (liabilities, equity)
Pay Taxes
Account for themselves (legal reports, audits)
Can get the right to:
And the responsibility to:

Note for R11i with respect to R12

Release 11i GRE/LEs will be upgraded as Release 12 Legal Entities.
Release 11i Operating Units and Inventory orgs will be upgraded as Establishments.

One Legal Entity can have several establishments.

In Release 12 there is no specific link between Operating Units and Legal Entities where as in R11 it was.
The Legal Entity is linked to a Ledger and the Operating unit is also linked to a Ledger.
Every Release 12 transaction must be associated with both an Operating Unit and a Legal Entity.
The Legal Entity is also required for e-Business Tax to establish which taxes will be applicable to the transaction.

The New Model called” LEA (Legal Entity Architecture)”

Legal Entity architecture, which is new in this release, provides users with the ability to model an enterprise’s legal organizational structure and define rules and attributes specific to legal entities.

Bank Account whether its is remittance bank or internal bank is now owned by the Legal Entity instead of Operating Unit, and can be used by any of the Operating Units sharing the same Ledger as that Legal Entity.

As marked (dotted red line) in above figure the relationship between legal Entity and Operating Unit is no more active. This concept allows Operating Units to be governed by more than one jurisdiction, but the accounting is still performed in a single ledger.

Multiple Legal Entities can be associated with a single Ledger, allowing the LEs to share the same ledger and chart of accounts, calendar and currency. Each LE points to one Ledger.

Multiple Operating Units can also be associated with a single Ledger. Each OU points to only on Ledger.

Take a note; in R12 EBS multiple legal entities can be associated with a single Ledger, allowing the LEs to share the same ledger and chart of accounts, calendar and currency. Each LE points to one Ledger. Multiple Operating Units can also be associated with a single Ledger. Each OU points to only on Ledger.

Where it affects:

“Most of the Financial Application Products”

Cash Management (Bank)

As discussed in earlier, in Release 12 Bank Accounts are owned by Legal Entities and can be accessed by multiple Operating Units.

As we know in 11i the Bank Accounts were Operating Unit Specific.

For all Internal Banks should be assigned to a Legal Entity.

Receivables:

Now all REC activity must have a legal owner, so Legal Entity is stamped on every transaction. Receivables activity such as transaction whether credit memo or debit memo or invoice must have stamps on it and receipt header with the Legal Entity information.

Because there can be multiple legal entities using the same ledger, it may be necessary for the user to assign the LE. Each transaction can only belong to one Legal Entity, so when multiple legal entities exist, either the system or the user will assign the LE.

Transaction

The defaulting hierarchy for a transaction comes from the setup of the Transaction Type and Transaction Batch Source. Receivables will look first to the Transaction type. If a LE has not been assigned, then Receivables will look to the Batch Source. The assignment of the LE to the Transaction Type and Transaction Batch Source is option, so if Receivables cannot find a default LE, then it is up to the user to provide the LE value.

Receipts

The LE defaulting for receipts works differently than transactions.

Let’s look at how defaulting occurs for the Receipt Header.

As we know , internal Bank Accounts is not owned by legal entities instead of operating units, so LE defaults from internal (remittance) bank account.

The Receipt Method in Receivables has the bank account assignment, which determines what bank account gets assigned to the receipt.

Take a note in version 11 the receipt Method was called the Payment Method. Now in Release 12 this featured with same name “Payment Method” now used by new application called Oracle Payments. Therefore in AR, you will now see a Receipt Method, which is part of receipt setup; and Payment Method, which is part of Payments setup. Once the bank account is assigned to a receipt header, this information can be used to find the appropriate LE. Because the LE comes from only one source, the bank account, there is no special setup to be performed in Receivables. Defaulting of the single LE always occurs, so the user does not need to assign or update LE on receipts.

How LE affects receipts and there applications and refunds

We seen the receipts inherit the LE from the bank account weather its is manual, Automatic, Lockbox and Post Quick Cash Programs. There is no way that user can change the value.

Receipt application across Legal Entities is allowed if the receipt and transactions are in same OU and Sub Ledgers Accounting will performed by inter-company accounting for cross-LE receipt applications or cross-LE receipt clearing.

SLA will create inter-company accounting as long as LE is setup as one of the CCID (Account Code Combination) segment derivation sources in SLA.

Payable

Invoices and Payments indicate the operating unit and the legal entity owner of the transaction. The legal entity can be used as selection criteria when preparing pay runs.

Projects

As we know in 11i in EBS maintains the default legal context on the Operating Unit. There is not much impact in Projects model. Earlier in 11i we used to consider the Legal Entity of the Operating Unit as the Legal Entity of the Projects Transactions. Now the Legal Entity attached at the Default Legal Context of the Operating Unit is the Legal Entity of the Projects Transactions.

So the Legal Entity of the Projects expenditure transactions will be the Legal Entity attached at the Default Legal Context of the Expenditure Operating Unit and the Legal Entity of the Project will be the Legal Entity attached at the Default Legal Context of the Project owning operating unit.

LE and TCA

Legal Entity is still dependent on TCA. A party (supplier, customer, bank, student etc) is an entity that can enter into business relationships. As we know the Oracle TCA’s model supports four types of parties: organization, person, group, and party relationship. Under the TCA model, Parties (including Legal Entities) exist just once in our E-business Suite system for single maintenance and consistency. Legal Entities will be stored in TCA as Parties of party type ‘ORGANIZATION’. A Legal Profile, containing specific Legal Entity attributes, will be associated to the TCA Party. In addition, other TCA components will be used for Addresses, Contacts, Party Information, etc.

Where to do the setup

There should be no confusion.

May be , some may think if this is just extension of GRE/LE from old version , then Why this required to do set up from both ASM and HR in R12?

In R12 ,it is separate the legal entity from the GRE which is a HR organization. We did not link the 2 entities together as they serve 2 different purposes altogether.

The HR model does not look at the new Legal Entity model. It continues to use the GRE/LE as a legal entity. So the HR requirement can be achieved using the HR organization of type GRE/LE.

Therefore, Legal Entities do have to be set up in both ASM and HR in R12.

Hope this sound interesting for new change in Financial Architecture.

More details about LE:

How do I define my Legal Entities?

In the real world a Legal Entity (LE) can enter into contracts, own cash (bank accounts), employ people, pay taxes, be sued and similar. In Oracle Financials Release 12, a whole new product; Legal Entity Configurator, was created to manage them. We allow you to define your real world Legal Entities and then map them to the E-Business Suite objects and structures. Transactions are stamped with an owning (first party) Legal Entity and that will be used to drive tax, accounting, intercompany and Legal Reporting.

So let’s look at the relationships LE have to other E-Business suite objects.

1- Accounting Structures

In the General Ledger Set Up a Legal Entity can be mapped to

A Single Ledger
One or more Balancing Segment Values (aka Company Code) within a ledger.

2 - Operating Unit

There is no explicit mapping of Legal Entity to an OU, the relationship is derived from the ledger assigned to the OU and the Legal Entity mappings to ledgers as detailed above.

So how might you set up your LE in relation to your other set up in financials? There are two implementation models

1: Many

LE are mapped to the Balancing Segment Value (BSV, aka Company code) within a Ledger, so multiple LE are accounted for in a ledger.
An OU will have one Ledger assigned so transactions for many LE are processed and accounted in a single OU

1:1:1

A single LE is mapped to a Ledger
An OU will have one Ledger assigned
Therefore an OU only has one LE (that means it is easy to derive the LE given the OU)

So what model should you use?

That depends where the LE are registered.

The 1: M model is recommended and preferred in the US, the 1:1:1 model is recommended for most non US regions

Multi-Org Access Controls

Multi-Org Access Control feature allows you to enter process data and generate reports from a single responsibility.

For More details:

MOAC : From Multi-Org….To Multi-Access

This new Feature in R12, enables companies that have implemented or implementing shared services operating model to efficiently process business transactions by allowing them to access, process and report on data for an unlimited number of operating units within a single applications responsibility. Users are no longer required to switch applications responsibilities when processing transactions for multiple operating units.

Data security is maintained using security profiles that determine the data access privileges associated to responsibilities granted to a user.

Because of this you can perform multiple tasks across operating units without changing responsibilities, the simple case can be best described as diagram in the left, where 3 user from three difference OU’s required three separate responsibility to perform the task.

MOAC Benefits..

Multi-Org Access Control feature allows you to enter, process data and generate reports from a single responsibility
This is achieved by providing the Operating Unit field on the forms/pages and while running the concurrent processes
To Set this feature you need to define the security profile containing operating units and set it at MO: Security Profile
You can default the Operating Unit on forms/pages by setting the MO: Default Operating Unit profile

What are the new changes from Multi Organization (Multi Org) to Multiple Organization Access Control (MOAC).

MO: Security Profile
List of operating units for a responsibility
all transactions
setup data specific to OU, like transaction type
For example: submit the Payables Open Interface Import w/OU param null to import all records across all OUs
As discussed above, security Profiles for data security
OU field on UI
Enhanced Multi-Org Reporting and Processing
Ledger/Ledger Set parameter on accounting reports and processes
OU parameter on other standard reports and processes

Where and how to define a security profile?

Using Oracle HRMS, you can define your security profile using two forms:

The Security Profile form
The Global Security Profile form that is shown here.

The Security Profile Form allows you to select operating units from only one Business Group. The Global Security profile Form allows you to select operating units from multiple Business Groups.

The decision on which form to use is really up to you and depends on your HR implementation and how you want to partition data. All you need to do is enter a name, and select the Security Type called “Secure organizations by organization hierarchy and/or organization list”. This allows you to assign multiple OUs. When assigning operating units, first select classification Operating Unit, and then select the organization or Operating Unit name. You can assign as many operating units as you want.

AP-AR netting

This is used to offset Payable & Receivables and other functionality like trading Partner Approval.

Read for More:

R12 : Setting up for AP/AR Netting:

Oracle Purchasing

You enter purchasing documents by operating unit. These include standard and blanket agreement purchase orders, requisitions, RFQ’s and quotes. You assign a PO shipment to an inventory organization, any inventory organization in the same set of books as the PO’s operating unit.
You enter receipts by inventory organization.

Account Payable

You setup one default liability account by operating unit.
You enter invoices in one operating unit at a time.
You run payment runs in one operating unit at a time.
You can consolidate supplier invoices on one payment only within an operating unit.
You setup bank accounts and associated cash accounts within an operating unit.
You select invoices for payment on one payment run for one bank account based on pay group, priority, amount, currency, or payment method (i.e. check, electronic) within an operating unit.

PO/AP:

You setup suppliers for the entire database instance but addresses for each operating unit.
You merge suppliers and addresses within an operating unit.
You report supplier/customer netting within an operating unit.

In Finance, transaction management processing is one of labor intensive task in ERP, as it requires extensive data entry , chance are very very high for duplication/re-entry. As we know Procure to Pay life cycle start itself from contract management till making payment.

As we know the efficient Procure to pay process have these sub processes;