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

R12 SLA vis-à-vis AX of 11i

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

Read this:

We have already seen oracle new Oracle Sub ledger Accounting replaces the Global Accounting Engine, which normally used for European & Regional Localizations need in earlier versions. SLA itself extends the AX engine functionality by providing customizable accounting rules via a flexible

Is SLA a clone of AX?
Yes, almost the functionality was derived from there itself, lets see vis-à-vis to uptake some of the functionality in these two products.


Not only functionality, some of the reports replaces the corresponding reports of the Global Accounting Engine.


The good is that both the Global Accounting Engine(AX) and Oracle Subledger Accounting(SLA) generate accounting from a compiled definition of accounting rules defined by users. Oracle Subledger Accounting further maintains version control on the rules enabling users to modify the rules while maintaining auditability.

What you say..sounds good :)

Posted in EBS Suite, Functional, R12, Release12, Subledger Accounting | 2 Comments »

Release 12 : Legal Entity uptake

Posted on December 7th, 2007 by Sanjit Anand |Print This Post Print This Post |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 »

Release 12 : What’s New in Oracle Receivables

Posted on December 3rd, 2007 by Sanjit Anand |Print This Post Print This Post |Email This Post Email This Post


Oracle’s Release 12 of the E-Business Suite is also called the “ Global Business Release ”, as it has numerous enhancements designed to make it easier to do business on a global basis. A more flexible, centralized global accounting structure has been introduced which makes it easier to operate between and across operating units and legal entities. Overall, R12 contains 18 new modules and 2443 enhancements to existing functionality.

Oracle's Release 12 (R12) of their E-Business Suite continues to extend the functionality of the Receivables arena , in addition to incorporated new financial architecture and new products , Oracle Receivables is now very natured product.As part of this post, we will look at Oracle's newest/enhanced offerings in Oracle Receivables.


Revenue Recognition

In R12 revenue recognition is based on Rules and Events, and they are:

  • Time-Based Revenue Recognition
    • Ratably Over Time
    • Upon Expiration of Contingencies
  • Event-Based Revenue Recognition
    • Payment
    • Customer Acceptance
  • Rule-Based Revenue Recognition
    • Payment Term Thresholds
    • Refund Policy Thresholds
    • Customer Credit worthiness

Lets take a quick look on some of the new changes:

  • Daily Revenue Recognition
    • Revenue distribution over full as well as partial accounting periods.
    • Fulfills stringent accounting standards
    • Accuracy to the number of days in the accounting period.
  • Enhanced Revenue Contingencies :
    • Fully Supports US GAAP and IAS
    • User definable contingencies
    • User definable defaulting rules for contingencies assignment
    • Supports parent-child (e.g. Product and Service) relationship
    • Integration with Order Management and Service Contracts
    • User Interface as well as Programming Interface (API) support
    • Access control through seeded Revenue Managers Responsibility
  • Deferred Revenue Management

Event-Based Revenue Management in Oracle Receivables allows users to define revenue deferral reasons or contingencies and corresponding revenue recognition events. In Release 12, revenue contingencies for customer acceptance that are applied to goods sold in Order Management are now applied to services sold to cover those goods. Revenue is deferred for service ordered in both Order Management and Service Contracts. Acceptance contingencies associated with an item instance are automatically applied to service revenue associated with the item instance when it is covered in a Service Contract as a Covered Product. Revenue for services on other covered levels, subscriptions and usage is not impacted by contingencies applied to goods associated with those services.

2Global Architecturenewfeature

As we know, with in global architecture , these new things has been introduced.

  • Sub ledger Accounting - Journal Creation takes place prior to GL.
  • Bank Model - This unified model enables to park customer Bank as well as Internal bank information into there new model, so that working capital cash flow should be enhanced.
  • EBusiness Tax - Oracle E-Business Tax is a new product that uniformly delivers tax services to all Oracle EBusiness Suite business flows. In Release 12, Receivables is enhanced to support
    integration with the E-Business Tax product.
  • Intercompany - This is enhanced by automatic balancing,

3MOAC Control

moacThis enhance you by enabling and performing tasks across operating Units (OUs), where you have access to without changing responsibilities.As we know , MOAC enables companies that have implemented a 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.

In nutshell, once MOAC is enabled, then you can:

  • Perform Setups for any OU
  • Enter invoices across OUs
  • Receive Cash for any OU
  • Manage Customer Credit across all OU
  • Run reports across OUs

Because of this greatly enhanced Role based security options, the ability to access multiple operating units with a single responsibility can simplify SOX compliance monitoring from finance controller side.

4Line Level Cash Applications

The Line Level Cash Applications solution allows the application of receipts to linesspecific transaction items such as individual lines, groups of lines, or tax or freight buckets. From the receipt workbench,you are able choose whether to allocate cash to the entire transaction or to apply amounts against specific items according to the customer remittance.

  • Apply to specific lines or groups of lines
  • Indicate when tax, freight or finance charges only are paid
  • Make changes as needed
  • Easily view activity against receipts
  • Know what historical activity affects your receipt
  • See what prior activity affects a new application

5Enhanced Customer Screen

We have seen 11i Customer standard forms makes easier by simple navigation. This times there is clearer separation of the party and account layers, which makes a consist ant look and feel.More over full backward compatibility with 11i UI Bill Presentment Architecture has been provided.

The AR Create Customer page in R12 has eliminated the navigation to separate windows. Now, users can specify the following on a single page:

  • Customer Information
  • Account Details
  • Address
  • Account Site Details
  • Business Purpose



Oracle Receivables is fully integrated with Oracle Payables to deliver a seamless, automated process to generate check and bank account transfer refunds for eligible receipts and credit memos.

7Late Charges

As we know oracle receivables delivers enhanced Late Charges functionality enabling the creation of standard late charge policies that can be assigned to customer accounts or account sites.Flexible policy configurations include multiple interest calculation formulas, transaction and account balance thresholds, and currency-level rate setups. With new changes these are the enhanced functionality:

  • Expanded assessment and calculation capabilities
  • Tiered charge schedules
  • Penalty charge calculation
  • Integration with Balance Forward Billing
  • Centralized setup and maintenance of late charge policies
  • Calculation performed independent of Dunning and Statement processing



8 AR-AP Netting

The matching of open receivables and open payables is automated.

9Balance Forward Billing

This makes easy transaction processing.

Balance Forward Billing is an enhanced version of the existing consolidated billing functionality for industries where customers are billed for all their account activity on a regular, cyclical basis.

Balance Forward Billing provides the ability to setup cycle-based billing at the account or account site levels, enable event based billing, and leverage user configurable billing formats provided by Oracle Bill Presentment Architecture.

A typical case can be best understood as

  • Payment Term defaults
  • from Site profile if Bill Level = Site
  • from Account profile if Bill Level = Account
  • Billing Date derived from transaction date and billing cycle
  • Due Date derived from billing date and payment term
  • Optionally select non-Balance Forward term if Override Terms = Yes


Posted in EBS Suite, Functional, Oracle Receivable, R12, Release12 | 12 Comments »

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

Posted on December 2nd, 2007 by Sanjit Anand |Print This Post Print This Post |Email This Post Email This Post


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.

blu 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

redWhat are the new changes from Multi Organization(Multi Org) to Multiple Organization Access Control.moac

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

purpWhere 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.

moac navi
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.

Posted in EBS Suite, Functional, R12, Release12 | 11 Comments »

R12 : Suppliers & Trading Community Architecture

Posted on November 26th, 2007 by Sanjit Anand |Print This Post Print This Post |Email This Post Email This Post

Read this :

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:


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 to understand while designing integration with EBS R12.


Posted in EBS Suite, Oracle Payable, R12, Release12 | 9 Comments »

R12 : Bank & Trading Community Architecture(TCA)

Posted on November 26th, 2007 by Sanjit Anand |Print This Post Print This Post |Email This Post Email This Post

Read this:


dgreybarrow-2Three key CE tables now as:

  • CE_BANK_ACCOUNTS for bank accounts
  • CE_BANK_ACCT_USES_ALL for account uses by Operating Units & Legal Entities
  • CE_GL_ACCOUNTS_CCID for bank account use accounting data

dgreybarrow-2TCA and Bank

The TCA party model is being used to model banks and bank branches as parties with the associated attributes of Relationships, Address, Contact and Locations. The TCA tables used by Cash Management for modeling Banks and Bank Branches are listed below:


The HZ_ORGANIZATION_PROFILES table stores additional attributes of banks and bank branches along with the history of changes made to Banks and Bank Branches. The contact person at the bank, bank branch and bank account is defined as a party in HZ_PARTIES, while the contact details will be stored in HZ_CONTACT_POINTS (stores contact methods), HZ_ORG_CONTACTS (stores the contact’s title) and HZ_ORG_CONTACT_ROLES (stores the contact’s purpose or role). The address details of Banks and Bank Branches will be in HZ_LOCATIONS (stores addresses) and HZ_PARTY_SITES (stores party sites).

The new table CE_BANK_ACCOUNT stores bank account attributes while the CE_BANK_ACCT_USES_ALL table stores the bank account use attributes specific to Operating Unit (AR, AP) and Legal Entity (Treasury).

The accounting data pertaining to the bank account use will be stored in the CE_GL_ACCOUNTS_CCID table.

All of the bank, branch and bank account related attributes in AP_BANK_BRANCHES and AP_BANK_ACCOUNTS_ALL tables will be upgraded to HZ_PARTIES and the new tables in Cash Management.

Within TCA model, here is various attributes how they fits inside the model.



Posted in EBS Suite, Oracle Payable, R12, Release12 | 2 Comments »

R12 SLA: Analyzing Subledger Accounting

Posted on November 25th, 2007 by Sanjit Anand |Print This Post Print This Post |Email This Post Email This Post

As in last post about subledger accounting we understood with this new feature:

  • All accounting performed before transfer to the GL.
  • and this is achieved by user setup who can do by definable accounting rules.

At the data level, it’s a big change for all the subledgers, though there is a first generation changes we have noticed sometime when 11i Payables where concept of “Accounting Events ” introduced first time and accounting performed at subledger level first before moving into GL.

The same idea has been incorporated in new sub ledger accounting model , indeed a was a real need because of some uneven functionality likes:

  • Inconsistencies in Accounting Generation like Summary vs. Detail
  • Direct to General Ledger vs. Open Interface
  • Inconsistent Drilldown from General Ledger
  • Also it has been seen inconsistent Mechanisms for controlling Accounting as certain options has been used in existing version:
    • flex builder
    • Account Generator
    • Automatic Offsets

What is sub ledger mean for a non finance person?

  • A new transactional application that generates accounting impact
  • Used to store detailed information not needed for a general ledger
  • Sub ledgers post summarized activity to a general ledger periodically to maintain centralized account balances for the company

With these accounting at this level the respective sub ledgers & General Ledger is tied out, as below.


bluHow Receivables Accounting happen in 11i

As we know the final accounting data not generated prior to transfer to GL as only distribution level information is passed to GL.

In 11i , we know three distinct distributions tables for invoices / Credit Memos / Debit Memos have to capture accounting class & amounts information but not debits & credits.

    • Receipts & Adjustments
      • Unapplied, applied
      • Both debits & credits
    • Misc. Cash Receipts
      • Both debits & credits
  • As we know "View Accounting” is a report against distributions to see the accounting information.


purpHow Payables Accounting happen in 11i

We know accounting data generated and stored in “Accounting Events” tables prior to transfer to GL in Payable. Once Transaction get completed it was need to run the “Create Accounting” process which basically populate data into accounting events tables.Then the actual line information move takes place from accounting events table to General Ledger Tables.The existing 11i accounting Process is can be best understood by figure below.


red1Subledger to Ledger Reporting in 11i

It means complete, final accounting only available in the GL

  • All debits and credits
  • All journal entries
  • All balances

The only issues in pre R12 versions was to link summarized accounting data with source details.

greHow it is resolved in Release 12 Subledger Accounting

All sub ledger accounting data generated and stored in shared SLA tables prior to transfer to GL , and this is achieved by running “Create Accounting” to populate SLA tables(Very very similar to Payable events). Once this can be done , user can “View Accounting” only after “Create Accounting” is run and completed successfully.

Transferring Accounting information from AP/AR to GL in R12

The Create Accounting process has similar options, you can create accounting in Final or Draft mode and if Final mode is selected, the Transfer to GL parameter can be used to automatically transfer the accounting created by the corresponding run. When the Create Accounting process transfers the journal entries to GL it only transfers the accounting created by the process that calls it. If there is accounting created by the online option = Final or a previous Create Accounting program that was not transferred, that accounting will not be transferred. The Transfer Journal Entries to GL program needs to be ran separately to transfer any accounting created online or created by a previous Create Accounting process that did not transfer the entries.

redIs/was link an issue in 11i?

Yes, From Distributions to SLA

  • Create Accounting process
  • Applies accounting rules
  • Loads SLA tables, GL tables
    Creates detailed data per accounting rules,stores in SLA “distribution links” table


SLA Distribution Links Table

  • Must join through to get true Distribution ==> SLA journals matches
  • Holds finest granularity of accounting data
  • Multiple distributions may be aggregated into a few SLA journal lines


and Final picture looks like:


purpSLA Key attribute :Something called Event Model ? What is all about?

Event Model are basically definition of the sub ledger transaction types and there life cycle.

It has three levels

  • Event Entity: Highest level, often 1 per sub ledger application
  • Event Class: classifies transaction types for accounting rule purposes
  • Event Type: for each transaction type, defines possible actions with accounting significance.

It is very important that applications must tell SLA when an event has occurred.When a user runs the SLA Create Accounting program, it processes all events with the appropriate status

we have notice some of event classes in Payable and Receivable.

  • Payables
    • Invoice
    • Debit Memo
    • Prepayment
    • Payments
    • Refunds
  • Receivables
    • Invoice
    • Deposit
    • Receipt
    • Bill Receivable

and typical event Types are like

  • AP Invoice Events
    • Validated
    • Adjusted
    • Cancelled
  • AR Receipt Events
    • Created
    • Applied
    • Unapplied
    • Updated
    • Reversed

Posted in EBS Suite, R12, Release12 | 16 Comments »

R12 SLA: From Product Accounting to Subledger Accounting

Posted on November 16th, 2007 by Sanjit Anand |Print This Post Print This Post |Email This Post Email This Post

Most of us are well aware that in Release 12 of Oracle Applications, Subledger Accounting (SLA) has been introduced, which is a Rule-based accounting engine, toolset & repository which is supporting most of Oracle business Suite modules. As we know driver for introduction this is to have an option of allowing multiple accounting representations for a single business event, resolving conflicts between corporate and local fiscal accounting requirements. The Functionality is somehow very similar to Global accounting engine, which oracle does offer for European reporting Need.

purp So What is Subledger Accounting?

• SLA is an intermediate step between subledger products and the Oracle General Ledger
• Journal entries are created in Subledger Accounting and then transferred to Oracle General Ledger
• Each subledger transaction that requires accounting is represented by a complete and balanced subledger journal entry stored in a common data model


Is this Module or what?

It is good to know ,sub ledger Accounting is a Service, not an Application .

The high points of SLA would be:

  • There are no SLA responsibilities
  • Users do not login to SLA
  • SLA is a service provided to Oracle Applications
  • SLA forms and programs are embedded within standard Oracle Application responsibilities
  • SLA provides the following services to Oracle Applications
  • Generation and storage of detailed accounting entries
  • Storage of subledger balances (e.g. third party control account balances)
  • Subledger accounting entries
  • Subledger reporting (e.g. Subledger journal reports, open account balances listing)

bluWhat oracle application Module taking services for SLA?
Most of modules which need accounting entry with finance uses service of SLA Modules.

greThis new Product has these many new functionality such as:

  • Journal Entry Setup and sequencing
  • Date Effective Application accounting Definitions
  • Multiple Accounting Representation
  • Multi-period Accounting
  • Summarization Options
  • Draft and online accounting
  • Replacement for disabled accounts
  • Process category Accounting
  • Transaction account Builder
  • Accrual Reversal Accounting
  • Accounted and Gain/Loss Amount calculations
  • Application Accounting Definition Loader
  • Enhanced Reporting Currency Functionality

redThe overall advantage of SLA can be summarized by oracle as below:



bluGL Flow with Subledger-Level Secondary Ledger

Lets take a case , with a scenario with basic Finance module, you can find how tightly accounting model is separated with transaction model in release 12.


This is the typical flow within one product with SLA can be best described as:


Posted in EBS Suite, R12, Release12 | 17 Comments »

Welcome to R12 Account Payable

Posted on February 22nd, 2007 by anand |Print This Post Print This Post |Email This Post Email This Post

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


We have seen in 11i

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

Where as in R12

  • 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
    • 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.


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.

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


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


2. 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.
4. Core functionality

The impact with Upgrade can be summarized as:

1. 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 areana, 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 we have seen 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


  • 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

3. Bank accounts, bank account uses are migrated into cash management.
4. 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 importanta 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.
4. 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.

Posted in Oracle Payable, R12 | 28 Comments »

Page 4 of 41234

Next Entries »