A Real Life Case Study_SLA

7/29/2019 A Real Life Case Study_SLA

1/12

COLLABORATE 12OAUG Forum Copyright 2012 by Murthy Mamidanna Page 1

Achieving Complex Accounting Requirements Using Sub Ledger Accounting -

A Real Life Case Study

Murthy MamidannaERP 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 SLASetting 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 understandingof 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.
http://www.cartus.com/http://www.cartus.com/http://www.cartus.com/http://www.cartus.com/


2/12


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 EXAMPLEOne 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 Dr 99999

Revenue Cr 99999

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


3/12


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,T-

586 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

Revenue for T-412 Cr XXX




Unbilled Receivables Dr XXX



Unbilled Receivables Dr XXX



4/12


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 numberpertaining 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 PIC3below.


5/12


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


6/12


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.

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


7/12


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.


8/12


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

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

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

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

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

RECEIVABLE ACCOUNT DERIVATION EXAMPLEIn 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

Pic9below).


9/12


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 Pic11below show the transaction flexfield value

and mapping set definition that defines the receivable account mapping.

Pic10.


10/12


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

Pic12.


11/12


12/12


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.

Documents

A Real Life Case Study_SLA