Oracle Cloud offers a broad portfolio of software as a service applications, platform as a service, and social capabilities, all on a subscription basis. Oracle Cloud delivers instant value and productivity for end users, administrators, and developers alike through functionally rich, integrated, secure, enterprise cloud services.
 Get a Free Magzine ...Profit:The Executive's Guide to Oracle Applications

Subscribe to the OracleAppsHub to receive notifications when there are new posts:

 get RSS feed
 Oracle Fusion Applications (OFA) is a portfolio of next generation suite of software applications from Oracle Corporation. It is distributed across various product families; including financial management, human capital management, customer relationship management, supply chain management, procurement, governance, and project portfolio management
 Get a Free Magzine ...Profit:The Executive's Guide to Oracle Applications

Organization Hierarchy model

Posted on July 7th, 2008 by Sanjit Anand ||Email This Post Email This Post

It was request from one of reader to provide some information for new organization Hierarchy model between two release of 11i and R12.Therefore invite you to run through the following diagram as below with some basics.

Read the rest of this entry »

Posted in Functional, Oracle Legal Entity Configurator | 1 Comment »

Release 12 : Legal Entity uptake

Posted on December 7th, 2007 by Sanjit Anand ||Email This Post Email This Post

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

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?

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

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.

Thanks to David, who pointed out last week regarding Bank Uptake in LE side in reference to my old post. Check his post for further information.

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.


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.


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.


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.

Suggested Reading

  1. Oracle Financials Concepts Guide,Release 12(Part No. B28873-01)
  2. David Haimes Blog : How do I define my Legal Entities?
  3. Release 12 Financial Applications RCD

Posted in Functional, Oracle Legal Entity Configurator, R12, Release12 | 16 Comments »