Professional Documents
Culture Documents
Murthy Mamidanna
ERP Architect
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.
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.
See Pic1 below for the limitation enforced by the traditional AutoAccounting Rules in Project Accounting.
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
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.
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.
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.
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.
2.
3.
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.
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.
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.
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.
Page 12