Blog

Introduction to Subledger Accounting

Summary

In R11 and earlier releases, the sub ledgers are the source of reference for the account coding of Project transactions via Distributions. With the introduction of Subledger Accounting (SLA) in R12, this is no longer the case. Subledger Accounting is a rule-based accounting engine that defines how journal entries are generated for subledger transactions in Oracle E-Business Suite. All subledger accounting is managed by SLA, i.e. journals are not posted directly to the GL from a subledger but are now “processed” by and through SLA. SLA does not exist as a separate discreet module. It is an underlying engine that provides a set of functions, supported by a new schema and underlying tables, that will allow configuration and maintenance of accounting rules. These are accessible within the subledgers as additional menu functions.

For Projects, the Subledger Accounting inquiries appear under the new heading Accounting Inquiries and include:

• Accounting Events
• Journal Entries
• Journal Entry Lines

The Setup menu options for SLA have also been added to the Setup Navigation branch of the menu.

The SLA Accounting Process

As the subledgers record new transaction entries and adjustments, and validate them, they become eligible for accounting by SLA. Eligible transactions are processed by the running of SLA-specific concurrent requests. These requests will vary from subledger to subledger but ultimately, SLA accounting is completed by performing two steps.

The first step is for SLA to determine what subledger transactions are eligible for processing and to create entries in the SLA tables to represent them. No accounting is created. In Projects, valid  transactions will include those that have been processed via cost “Distribution” and revenue  “Generation” concurrent requests and would be eligible for the PRC: Interface to GL processes of earlier releases. One SLA “Event” entry will be created for each transaction.

In Oracle Projects, examples of these SLA concurrent processes include:

• PRC: Generate Cost Accounting Events
• PRC: Generate Cross Charge Accounting Events
• PRC: Generate Revenue Accounting Events

There is a one-to-one relationship between a subledger transaction and an Event entry. For example, each miscellaneous transaction line in Expenditure Inquiry will have a corresponding Event in SLA, though there may ultimately be several journal lines produced as a result of that single event. Note that after running one of these first requests, there are no accounting entries for the new Events in SLA.

The second stage will generate accounting entries based on the rules defined in SLA for the entries or “Events” now held in SLA. Note that although Projects distribution and draft revenue generation processes will have generated elements of the accounting entries, these are not necessarily used by SLA, unless the SLA rules indicate they should be. SLA rules could be defined that ignore the results produced by AutoAccounting and instead proceed to generate journal entries based on entirely different criteria.

The generation of accounting entries is done by running a second concurrent request. For Projects, this is PRC: Create Accounting. This request actually calls an executable that is shared across the subledgers, i.e. each subledger will have it’s own concurrent program to call, but they will all call the same executable. This second request will do the following:

1. Collect relevant data on transactions from the core subledger tables
2. Determine  accounting attributes based on the collected data
3. Determine  Code Combination IDs (CCID) based on the rules defined within SLA
4. Create journal lines based on the Journal Definition (part of the SLA rules)
5. Create lines in SLA’s Accounting Entry Header and Lines tables (XLA_AE_HEADERS and XLA_AE_LINES).

When this second request is submitted, the user will specify the mode it should be run in. In “Draft” mode, the accounting is generated for user review but is not eligible for transfer to the GL. This allows users to review all the accounting without fear of the results being posted to the GL. The request must be submitted in “Final” mode for posting to the GL to be possible.

Below is an illustration highlighting the concurrent requests and components created for each:

Advantages of SLA

• Prior to SLA, the method of generating accounting for a transaction varied greatly from subledger to subledger. SLA allows a common set of rules to be defined that can be used across the subledgers. All transactions that result in accounting in the GL will be represented in SLA before accounting rules are applied. It should be noted that the seeded SLA rules will expect to find account code distributions in the same locations as they would have been prior to the introduction of SLA and will fail without this. For example, in Projects, AutoAccounting rules will still need to be configured and the values generated by the execution of these rules, will be used by SLA. In effect, the out-of-the-box rules of SLA expect the account codes to have been captured/generated by the subledgers.
• As a centralised repository of subledger transactions for accounting, SLA maintains full relationships between GL postings and the subledger sources. This also supports the creation of different accounting entries in different reporting ledgers from a single transaction, e.g. to accommodate statutory and regulatory requirements.
• SLA allows users to define entirely new sets of accounting rules or “Accounting Methods”. Seeded rules that come pre-installed cannot be updated and are assigned the owner “Oracle”. However, copies can be made and these are “User” owned. This has been done in order to allow users to create their own logic while protecting the integrity of seeded configuration for upgrades, i.e. an upgrade process will not fail because expected seeded entries are missing/have been modified.
• SLA provides users with the ability to immediately create, view, transfer and post accounting in GL when transactions are entered into subledgers such as AP rather than wait for the transactions to be processed in the next scheduled concurrent request. Online and offline accounting share accounting rules and validations. There is no logical difference. Draft mode is available to “online” accounting and may be used to review the accounting. This allows users to initiate the generation of accounting lines in SLA directly from within the subledger, rather than needing to run a concurrent request. When run in “draft” mode, the generated accounting journals will not be eligible for posting to the GL but will allow the user to view what the journal entries will be based on the current set of SLA rules. When processed in “Final” mode, journals will be eligible for posting to the GL from SLA. This is similar to running the distribution processes from the transaction forms rather than navigating to the concurrent requests form.  This would allow the user to view the SLA-based accounting results without navigating away from the transaction screens.
• Subledger Accounting provides users with the option to create accounting entries in “draft” as well as “Final” mode. When in “draft”mode, the accounting entries will be generated but will not be eligible for interfacing to the GL.  This allows users to review the accounting without fear of errors being posted to the GL. As rules in SLA change to meet changing business requirements, this mode will allow users to test and confirm the accounting results before “final” mode is used. Draft mode is a review mode. Final mode will generate accounting entries that are eligible for transfer to the GL. Users are not required to generate in draft mode and can create accounting in Final mode directly. Modes and override options can be set during the configuration of Subledger Options.
• SLA can store substituted disabled accounts on SLA journal lines for audit and reconciliation purposes. When an account is disabled, users can continue to create accounting for transactions that include the disabled account without generating an error based on the substitution. This could allow for date-dependent values to be used and prepared in advance of coding changes, and can ensure that the valid codes are used.
• SLA allows users to customise their view of the accounting by using the attributes of the journal entry. Users may also define and save searches. Embedded flows support two-way drilling between journal entry headers, journal lines, T-Accounts and Transaction data. Note that the distribution line entries of the transaction in the original ledger are notupdated by SLA. These entries are considered to be “default” and SLA may use or ignore them, according to the rules defined in the accounting engine. For example cost distribution lines for expenditure items in Oracle Projects will account using rules in Auto Accounting, but SLA may create different accounting for these. Therefore the accounting on these cost distribution lines is not necessarily what ends up in the GL. One scenario where this may be useful is where expenditure items are transferred from one project to another. If the original transaction was accounted in for example 2010 and the transfer took place in 2012 then the accounting produced in Oracle Projects by standard AutoAccounting is as follows:
  • Reversal expenditure item – debit and credit are copied from the original line
  • New expenditure item – debit and credit are derived from AA rules as defined and assigned at the point the transfer is process
• When these reversal and new transactions go through SLA both lines will be accounted in SLA and the reversal line will not necessarily have the same accounting as the original line that it is reversing. A classic scenario is where AA references a lookup set where the mapping has been changed since the original transactions was accounted.
• Using the Diagnostics framework, Subledger Accounting will allow users to view the transaction information used to create sub-ledger journal entries. Diagnostic information is also shown as an HTML Report.
• SLA rules can be date-dependent, i.e. dates can be specified to define the period during which the rule should be used. This will allow planned changes to be prepared in advance of the date in which they go into effect.

Disadvantages of SLA

• Now there are an additional set of database tables for SLA, the potential issues in reconciling GL to the subledgers increase, i.e. you now have to:
  • Reconcile GL to SLA, which should be straight forward, but still has to be done
  • Reconcile SLA to the subledgers – the existing problems between for instance AP / GL / Projects may still exist, and therefore reconciliation is still important

25 Nov, 2010 by Steve Harfield

E-Business Suite