Achieving Complex Accounting Requirements Using Sub Ledger Accounting A Real Life Case Study

Murthy Mamidanna
ERP Architect

CARTUS (www.cartus.com) INTRODUCTION

Sub ledger Accounting, a.k.a SLA, introduced in Release 12 of Oracle Applications opens tremendous opportunities to create accounting in sub ledgers. Prior to Release 12, accounting in sub ledgers was driven by different types of setups, such as setup options and autoaccounting. In addition to standardizing the accounting rule setups across sub ledger modules of Oracle, SLA provides flexibility that hitherto did not exist. SLA, generates accounting entries in addition to the entries generated by the traditional setups. The accounting entries generated by traditional setups and rules are called default accounting. By default, SLA uses the same account generated by default accounting. However, when the default rule in SLA is changed the accounting entry created by SLA prevails over the accounting entry created by default accounting. One of the most often requested accounting requirements during Oracle ERP implementation is ability to default an Asset account (for example Receivable account or Unbilled Receivable Account) based on different parameters that are specific to the implementation. As an example Prior to R12 a Receivable account can only be defaulted from Salesreps, Customer Site or Transaction Type setup, whereas there may be a requirement to drive generation of receivable account a different parameter. This paper covers two real life implementation scenarios of SLA which go on to demonstrate the flexibility offered by SLA in creating accounting entries.

BUILDING BLOCKS OF SLA

Setting up of SLA is achieved by defining various building blocks. While this paper does not elaborate on details of how SLA is setup, a brief description below on each of the building block creates an understanding of how SLA works.

The first setup of SLA is to create a mapping set and determine the use of an input source for that mapping set. A mapping set feeds into the setup of Account Derivation Rule and an Account Derivation Rule is attached to a Journal Line Type and so on. A mapping set contains mapping between an input source and a target account.

COLLABORATE 12OAUG Forum

Copyright 2012 by Murthy Mamidanna

Page 1

 An input source can be a standard source in Oracle that is available for use from the transaction in question. For example, Transaction Flexfield Attribute1. Or it can be a custom source that uses a PL/SQL Function to derive the source by using one or more standard source parameters. An Account Derivation Rule defines mapping between a Mapping Set and an Input Source. The input source could be a standard source or a custom source. For an accounting event class, for example Invoices, there can be multiple Journal Line Types, as in Invoice Receivable or Invoice Revenue. Journal line types specify if the journal line is to be a debit, credit, or gain/loss line. A Journal Line definition is a collection of Account Derivation rule, Journal Line Type description definition and Supporting references assignments. A Journal Line Definition is then attached to an Event Class. An Event Class is associated with an Accounting Event, such as Invoice, Receipt, Adjustment. As application accounting definition is defined for a certain Sub ledger application such as Receivables, and is a collection of all Accounting Events in that application. All the application accounting definitions are then collectively defined under a Sub ledger Accounting Method or SLAM, which is attached to a Ledger.

THE MULTIPLE UBR EXAMPLE

One of the often heard accounting requirements is the ability to drive asset account in the Sub ledger using a transaction level parameter. A typical sub ledger journal entry is characterized by one asset account on one side and multiple expense/income accounts on the other side. This real life example from Project Accounting (PA) module demonstrates derivation of Unbilled Receivables Account using task number on a Project. Traditional AutoAccounting rules in PA, do not allow us to use Task Number as a parameter source to derive Unbilled Receivables account. This is because, there can be only one Unbilled Receivables account in one journal entry whereas there may be more than one Revenue journal line, each Revenue line pertaining to different task number. While this is a valid rule, certain implementations may not allow for different task numbers on different revenue lines of a journal entry. Consequently, there can be a need to use the task number, which is same on all revenue journal lines, to derive the unbilled receivable account. When revenue is generated prior to generating Invoice the journal entry is, Unbilled Receivables Revenue Dr 99999 Cr 99999

See Pic1 below for the limitation enforced by the traditional AutoAccounting Rules in Project Accounting.

COLLABORATE 12OAUG Forum

Copyright 2012 by Murthy Mamidanna

Page 2

PIC1. The scenario for this example is, for a project there are multiple tasks. Funding (a concept in PA) is done at task level. Certain individual tasks are funded by separate task specific agreements and rest of tasks are funding by a different agreement. So, for example a project called Project A, let us say we have a total of 5 tasks. The tasks are identified by their numbers and are numbered as T-412, T-413, T-586, T-302 and T-99. While tasks T-412,T-413,T586 are funded by Agreement#1, task T-302 is funded by Agreement#2 and task T-99 is funded by Agreement#3. When tasks are funded by different agreements, the revenue gets generated on the project separately for each of the agreements and consequently they generate separate journal entries. In this example, assuming there are billable transactions on all the five tasks, when revenue is generated the journal entries would look like as follows, Revenue JE from Agreement#1: Unbilled Receivables Dr XXXXX Cr Cr Cr XXX XXX XXX

Revenue for T-412 Revenue for T-413 Revenue for T-586 Revenue JE from Agreement#2: Unbilled Receivables Dr XXX

Revenue for T-302 Revenue JE from Agreement#3: Unbilled Receivables Revenue for T-99 Dr XXX

Cr

XXX

Cr

XXX

COLLABORATE 12OAUG Forum

Copyright 2012 by Murthy Mamidanna

Page 3

Our goal is to have different UBR account for the 3 above journal entries pertaining to the same Project A. Although there can be more than one Revenue line for each of the above journal entries, we know that since Agreement#2 only funds T-302 and Agreement#3 only funds T-99, all the revenue lines for these agreements will pertain to only T-302 and T-99 respectively. The JE generated for rest of the tasks on the project could have revenue lines for the rest of the 3 tasks. To achieve this we have to access the revenue line pertaining to the UBR entry and obtain the task number pertaining to the revenue line. We do this by creating a Custom Source and a mapping set that maps the input to output account. Pic2 shows the mapping set defined for this.

PIC2. We need to create a custom source that uses a PL/SQL function to create the input string required for this mapping set to derive the output account. During the create accounting process SLA creates internal identifier known as accounting event id for each journal entry. For the PL/SQL function that is used in the custom source, we will provide event id as input. Using the event id from the UBR line we will locate the revenue line and get the task number associated for the revenue line. The setup for custom source is shown in PIC3 below.

COLLABORATE 12OAUG Forum

Copyright 2012 by Murthy Mamidanna

Page 4

PIC3. It is important to note that the parameter source that can be used for a custom source is dependent on the sub ledger application (in this example it is Projects), the accounting event class and the journal line type. In this example the accounting event class is Revenue and the journal line type to which we are going to assign account derivation rule is Unbilled Receivables. Although the list of values for Parameters Name field displays all the available parameters for all applications, accounting event classes and journal line types, if we choose a parameter that is not relevant for the particular application/accounting event/journal line type combination then the PL/SQL function will not get a value. Section Important Oracle Validations: at the end of this example talks about more validations application performs on SLA rules. A way to identify which parameters would be available for a particular event class is to examine the view assigned to the event class in the accounting event class options (Navigation is SetupSubledger AccountingAccounting Methods BuilderEventsAccounting Event Class Options) window (see PIC4).

PIC4. If we like to use a header level parameter we will examine the header view. If we want to use a line level parameter, as in this example, we have to look at the line view. Note that we can only potentially look at those objects from the Accounting Event Class Options window that have Always Populated checked. If it is un -checked then that view may only get executed conditionally. PIC5 below shows the columns available in the view we are interested in , PA_XLA_REVENUE_LINES_V.

COLLABORATE 12OAUG Forum

Copyright 2012 by Murthy Mamidanna

Page 5

PIC5. Note the column event_id. This is accounting event_id that SLA generates for each accounting journal entry. PIC6 below shows the event_id being selected for the UBR (Debit) side of the journal entry. Notice that this select does not have task_id value selected. We want to drive the generation of UBR account using task_id. So, we will use the event_id and access the Revenue (Credit) side of the entry to get the task_id.

PIC6. PIC7 below shows information from the view for the Revenue (Credit) side of the entry. In this side we see the line level details along with the event_id.

COLLABORATE 12OAUG Forum

Copyright 2012 by Murthy Mamidanna

Page 6

PIC7. Note the columns event_id, task_id and the line type (Revenue Event Revenue). Here, we are only examining a section of this view to illustrate the idea of deriving UBR account. So, there may be other sections of the view that represent different line types, for example Revenue for Expenditures. While devising a complete solution, you will need to examine all the sections and understand how the data can be used in your specific implementation scenario. Using event_id as input, we can write code (See PIC8 below) to derive an input value to be used to derive the account. Note that, the Account derivation rule derives an account using the mapping set and a source, in this example a custom source (See PIC3).

PIC8.
COLLABORATE 12OAUG Forum Copyright 2012 by Murthy Mamidanna Page 7

This custom PL/SQL function which is used in setting up the custom source (PIC3) returns the string of balancing segment-a derived value from task number.

Important Considerations:
1.

2. 3.

One of the important assumptions in this example is that the multiple journal lines on the credit side have consistent values, i.e., return a single value, so that the custom source can return a single valid row for every situation. This is implementation specific. Many implementations have parameters at line level that have implementation specific same value for all the lines for a certain type of transaction. A PL/SQL function used in the custom source definition should return a single value and only a single value for every type of parameter. When using custom sources and writing custom code, one should be cognizant of performance and impacts to the code due to upgrades and patches.

Important Oracle Validations:

1. When defining a custom source, Oracle does not validate the PL/SQL function specified at the time of saving the custom source. The validity of the PL/SQL Function, i.e., if it is a function and that its state is valid is checked when the Application Accounting Definition is validated. Also, Oracle does not validate the parameters specified for the custom source while saving the custom source. Whether the parameters are valid to the context i.e, to the accounting event class to which this custom source will eventually be assigned, is checked while assigning the account derivation rule to the journal line type. If the custom source used in the account derivation rule is using a parameter that is not relevant to the particular journal line type then the account derivation rule will not appear in the list of values. If the PL/SQL function used in the custom source definition does not return a value then create accounting program will complete warning and will show exceptions in the Accounting report. To identify the values that are assigned to the parameters for a particular run of create accounting, one can set the profile option SLA: Enable Diagnostics to Yes and submit the concurrent program Transaction Object Diagnostics for the specific request id of Accounting program. The transaction object diagnostics generates a report that shows the values that are assigned to the parameters/sources used in the custom sources and account derivation rules.

2.

3.

RECEIVABLE ACCOUNT DERIVATION EXAMPLE

In this second example, we will examine how to use additional parameters on a transaction to derive accounting using SLA. We use receivable account in Accounts Receivable (AR) module for this example. AR module use Autoaccounting rules to derive default accounting for the receivable account. Receivable account can only be derived using Salesreps or Customer site or Transaction Type when using the traditional autoaccounting rules (See Pic9 below).

COLLABORATE 12OAUG Forum

Copyright 2012 by Murthy Mamidanna

Page 8

Pic9. However, using SLA we can access more parameters that are at the transaction (invoice) level to derive the receivable account. As in this example, we can use a transaction flexfield value to derive the account. If the mapping between a value on the transaction and the account to be used is one-to-one without an additional logic, then we do not need to write any PL/SQL or use a custom source. Pic10 and Pic11 below show the transaction flexfield value and mapping set definition that defines the receivable account mapping.

Pic10.

COLLABORATE 12OAUG Forum

Copyright 2012 by Murthy Mamidanna

Page 9

Pic11. Note that the autoaccounting setup uses Transaction Type to derive the default receivable account (See Pic9). And note the GL account string (See Pic12 below) that is setup against the transaction type used in this example transaction (See Pic10) invoice# 100276650. Default accounting uses transaction type and generates the receivable account as shown in Pic13 below.

Pic12.

COLLABORATE 12OAUG Forum

Copyright 2012 by Murthy Mamidanna

Page 10

Pic13. Whereas SLA uses the mapping set and the source of Transaction flexfield Attribute4 column to derive the receivable account. Pic14 below shows the account derivation rule. Note that, if there are only certain types of invoices that we have need to use transaction flexfield to derive the account then, we can define a condition on the account derivation rule. For this example, we have setup the account derivation rule to use Transaction flexfield Attribute4 as a source to derive receivable account only if the transaction source is PROJECTS INVOICES. For all other sources we use the default receivable account that is derived by the traditional autoaccounting rules.

COLLABORATE 12OAUG Forum

Copyright 2012 by Murthy Mamidanna

Page 11

Pic14. Pic15 below shows the accounting derived for the same transaction (invoice# 100276650) by the SLA create accounting process. Note the account that it derived using the mapping set (Pic11) we defined.

Pic15.

CONCLUSION:
Subledger Accounting provides a lot of flexibility in deriving accounting in subledgers. With some PL/SQL coding we can achieve complex accounting that was hitherto not possible. Refer to oracle note ids 790945.1, 797115.1 for some useful information about SLA. Also, the ability to run create accounting program i n draft mode gives us very good way of defining and fine tuning SLA setups.

COLLABORATE 12OAUG Forum

Copyright 2012 by Murthy Mamidanna

Page 12