c


 

  

 !"#"
 



Sunday, 22 June 2008 14:27 Puneet Vishnoi
E-mail | Print | PDF
Please find first in the series of articles on R12 Subledger Accounting from Puneet Vishnoi.
Puneet is a freelance consultant in Europe. Prior to freelancing, he was one of the key developers in Oracle Corporation for Oracle
Projects Accounting and Oracle Grants Applications.
Puneet has designed numerous critical solutions in Oracle Applications R12 and 11i. He has vast experience in new R12 General
Ledger Architecture. Puneet Vishnoi also happens to be an excellent troubleshooter, resolving various business critical issues when he
was in Oracle Corporation.

This article is Part-1 of Subledger Accounting.

$%&
'
Oracle Sub Ledger accounting (SLA) is accounting hub in Oracle Application Release 12 (R12). It is used to derive all attributes required to account
a transaction in Oracle General Ledger. In R12, SLA is used to derive the very basic accounting attributes like entered amount, accounted amount,
Date, Currency code etc and the complex attributes like Ledger, Code Combination ID, Periods etc. After deriving these accounting attributes the
transactions are then interfaced to GL from SLA. Thus in R12 no sub ledgers (AP, PO, PA etc) interfaces the transactions directly to GL, but all the
transactions are interfaced to GL in following 2 steps:
1. Sub ledgers interface the data to SLA.
2. SLA derives the accounting information and interfaces the data to GL.

SLA gives the flexibility to manage the entire accounting rule at one place, which acts as a single source of truth for GL.

(
There is no separate responsibility to access SLA setup or the view the transactions generated by SLA. Rather we can access SLA setup and
review accounted transactions with extended menus attached to each sub ledger module.

Menu to access the SLA accounted transactions.

Menu to access the SLA Setup.
&
& )'
c



 
After validating / approving / costing the transaction in the respective module, the sub ledger calls SLA API to create a reference of the validated
transaction in SLA. This reference is known as EVENT. Events are created by calling the public API ³xla_events_pub_pkg.create_events´ provided
by SLA. It is up to the sub ledgers on how to call the API. For example Oracle Projects call this API from concurrent program ³PRC: Generate Cost
Accounting Events´ and Oracle Payables calls this API while user creates accounting for the Invoice.

While calling xla_events_pub_pkg.create_events, oracle passes a unique id and event class (Will discuss in next step). Unique ID can be an invoice
id or a po_distribution id or an expenditure_item_id etc. As soon as the sub ledger generates event in SLA, SLA returns unique event_id. This
event_id will then act as a reference to all the accounting entries generated by the SLA. Once event is successfully created in SLA, means that the
transaction is registered in SLA for accounting.

Taking the example of Oracle Projects in 11i where after costing the transaction user need to run the µPRC: Interface Cost to General Ledger¶
followed by µJournal Import¶ followed by µPRC: Tieback process¶. But in R12 user only need to run ³PRC: Generate Cost Accounting Events´ which
will register events in SLA and thereafter SLA will take care of accounting the transaction and interfacing it to GL. There is no tieback process in
R12, as there is one to one reference of event id between SLA and sub ledger tables.

&

&

*
!
 +  


+
+




 


'
In step 1 we discussed that while creating the event we also need to pass event class. This event class is used to distinguish between the types of
transaction passed for processing. To understand this better we will go thru the seeded oracle information.


(!

Responsibility: Projects, Vision Services (USA)

Menu: Setup > Subledger Accounting > Accounting Methods Builder > Events > Event Modal

This screen shows the hierarchical structure of different transactions that can be interfaced to SLA. Because the above screen shot is from Oracle
Projects responsibility thus it shows only the projects related transactions. In the entity screen we see only those transactions that can be interfaced to
the GL, that¶s why we do not see Invoice as one of the entity as Invoices are not directly interfaced to GL from PA but they are routed thru AR.

Identifiers are the unique ID that is passed to SLA from sub ledgers. Per the screenshot Oracle is passing expenditure_Item_id for entity
µEXPENDITURE¶. ³Identifier Column´ field under Identifier window tells what column in SLA table should store expenditure_item_id. The
identifier columns that can be used are SOURCE_ID_INT_1 to 4, SOURCE_ID_DATE_1 to 4, SOURCE_ID_CHAR_1 to 4 these values and
columns are present in table XLA_TRANSACTION_ENTITIES.

Event Class window displays the different kind of expenditure transactions that can be interfaced to GL. This level of hierarchy is known as Event
class, which is further classified into Event Types. In PA we have different event types like Labor Cost, Misc Cost, Usage Cost, Supplier Cost etc.
Further we could classify Supplier Cost as Expense Report and Invoices as Oracle Projects can interfaces only these 2 transactions from AP.

",




!
 -&

 
'
After registering the event in SLA, we can create accounting entries by running executable XDODTEXE. This executable is provided by SLA and is
used by all the sub ledgers with different concurrent program names. Around 160 concurrent programs are uses the same executable for example in
Projects it is used with name ³PRC: Create Accounting´. This executable does the following:
a. Gather information from base tables in sub ledgers.
b. Derive the accounting attributes based on the data fetched from sub ledgers.
c. Derive code combination id based on the business rules.
d. Create journal lines based on the seeded Journal definition.
e. Create lines in XLA_AE_HEADERS and XLA_AE_LINES.
Ê Ê
 

!
. !
/%


 
 
01"
 

Tuesday, 30 November 2010 00:00 Anil Passi
E-mail | Print | PDF
]





 







  






 



 

 





]

 




 










 






  




















 







!



"

#


 

















  







$



 


]








%   
%
 




$


 














] 


& 





 





  


]





%] 


&  %


%


%
 
 
  



] 

& 





 



%



%

"



]'&$]
 
 

()'
  


 

 




 




 

 
 
%

 
%


#



)

*

)

#


!

] 





" 



 




 












#





 
] 


 


 



+ 




 




 



,























 




 
  





 


,










# 















-












  


Ê Ê
 "2  
3


 
 
010 4   




Wednesday, 01 December 2010 07:24 Anil Passi
E-mail | Print | PDF
The Journal Line Definition "defines" how the entire journal is built. To create any journal, one of the key things is to get
the CCID or the code combination of segments. SLA needs to know where this CCID will be coming from. You also need to
know whether this CCID will be debit or this CCID will go into credit. Therefore you not just require the CCID, but you also
need to decide whether a specific CCID will be debited or credited. In SLA, the "Journal Line Type" will specify whether the
accounting entry is credit or debit. Also, you can then "attach something called an ADR to this Journal Line Type". The ADR
returns the final code combination. Therefore Journal Line type will leverage the JLT+ADR to know which CCID is crediting
and which CCID is debiting in the journal.
4or each and every application there is a combination of event class and event type. Depending upon the combination of event class and event
type the accounting gets triggered. The standard SLA out of the box from Oracle meets your requirement by 90%. 4or example you can fetch the
standard accounting from payables or receivables options. However where these standard seeded accounting do not suffice, you can go and
modify SLA to meet your business needs.

There is something called as Journal Entry Description. When a transaction is transferred as a journal, then every journal has credit/debit and
description. The journal has description at header and also at line level. The JED allows you to generate the description of the Journal at both
header and line level. 4or example you may want Customer Name or Customer Number in the journal description for a journal that is initiated
from Oracle Receivables module. Using JED in SLA you can build header or line level descriptions.

The image below describes the end result journal that is produced by SLA
In 
Journal Line Type, you can specify whether the entry is for credit or debit side. The Journal Line Type also provides options to do
accounting for Gain/Loss of 4oreign currency transactions. 4urther to that you can specify if SLA should merge the journal lines that have same
CCID.
Y
- We specify how the account combination must be generated. We tell the system how we want the CCID should be built and transferred to
the general ledger. You can either transfer the standard account as calculated within Subledger(AP or AR or PA etc) or the account generated
from Subledger can be modified or replaced via ADR configuration within SLA.
4urther to this, when defining ADR, you can specify the conditions under which a specific segment or CCID is returned. These conditions are like
I4 Conditions.

It is good to remember that the "Journal Line Definition=JED+JLT+ADR"

This is visible from the screenshot as shown below

You will notice that two "Journal Line Types" have been attached to this Journal Line Definition. The first journal line type assignment creates a
credit line in the journal and the second journal line type assignment creates a debit line in the journal.
„y now you would have understood the significance of Journal Line Definition. However you might be wondering how this Journal Line Definition
gets associated with a Subledger transaction. 4or example, how does Oracle E-„usiness Suite decide which specific Journal Line Definition should
be used when a specific event takes place against an invoice in Oracle Payables. In other words, how will SLA decide how the Journal will be
constructed when an invoice is validated within Payables. We will learn this via AAD in next part of the article using Application Accounting
Definitions.
Ê Ê
 0 3


 
 
01  0 



Thursday, 02 December 2010 00:00 Anil Passi
E-mail | Print | PDF
In the SLA Part 2 article you Entities, Event Class and Event Types. In the SLA Part 3 you learnt the high level basics of
Journal Line Definitions.
In this Part 4, you will see how the "Journal that gets constructed using Journal Line Definition" is associated with an
underlying transaction in the respective module.
As seen in the image above, the Application Accounting Definitions [AAD] is attached to one or more Journal Line definition [JLD].

Effectively it means that AAD = JLD for an Event Class+ Event Type combination = ADR+JED+JLT for an Event Class+ Event Type combination
As a thumb rule, you must remember that each Application Accounting Definition [AAD] belongs to a module. Therefore if you have one Ledger
implemented [ 11i Set Of „ooks] and two modules implemented like AP and AR, then you will have 2 AAD's defined, i.e. one for Payables and
another for Receivables.

In the above picture only one Event Class of Invoice is used in AAD. However in reality you will have more than one event classes like Invoices,
Payments etc associated with a AAD for Payables module.

Seeded Application Accounting Definitions are provided for each module out of the box by Oracle. However if the existing definitions do not
meet your business requirements, then you can copy the existing AAD's to a custom AAD, and then make alterations to the custom AAD, which
means creating custom JLT, custom JED and custom ADR as appropriate. It is important to remember that you must create a custom copy of an
existing SLA component before making modifications.

In the next article you will see Subledger Accounting Method.

Ê Ê
 

5

R






   

 
  R
Ê

As we have seen in the Part 4 of SLA, the Application Accounting definition is used to decide two things
a. When a specific event within Subledger example Payables or Receivables becomes eligible for Accounting
b. How the journal is constructed.

However, each Primary Ledger[ 11i equivalent of primary set of book] and also each secondary ledger should be able to
generate Journals as per their respective legislator requirements for all the modules implementedO This is where "Subledger
Accounting Method" [
Y] comes into the play. If you recollect from previous article, Application Accounting Definition is
connected to only one module like Payables or Receivables etc. However a Ledger[11i SO„ equivalent] needs accounting
entries to be processed across many modules. Hence SLAM provides an umbrella to join accounting entries from various
modules so that they can be channelled through to Oracle General Ledger. In other words a SLAM is a collection of
accounting definitions for various modules in Oracle Apps. A SLAM is then attached to the Ledger[11i equivalent of Set Of „ooks].

Therefore the flow of accounting entries appears as shown below

The flow represented in simple equation appears as below
Ledger Defined in GL-->SLAM-->AAD--> [Event Class and Event Type]-->Liability Lines-->[JED+JLT+ADR]
Ledger Defined in GL-->SLAM-->AAD--> [Event Class and Event Type]-->Expense Lines-->[JED+JLT+ADR]

In order to assign the SLAM to a ledger, go to the General Ledger Super User responsibility and click on menu as shown below.

Click on update against the ledger

Attach the SLAM to this ledger
You can also modify the SLA accounting options using the two screenshots as shown below
Ê Ê
 67!
 3 
Tuesday, 07 December 2010 00:00 Anil Passi
E-mail | Print | PDF
The overall flow of the SLA can therefore be depicted as shown in image below.
Overall, when you create new definitions in SLA, you can follow the bottom up model.

The parallel flow on top, as shown in image below is to ensure both a Credit and Debit line gets created for a Journal
Ê Ê
 1.
2  
3

R






   

  
 

 
Ê

In this article we will create a Journal Line Definition. You will basically apply the steps learnt thus far into practical
implementation.

However to create a Journal Line Definition, we need to create the following

1. Journal Entry Description !
 
 

  
2. Journal Line Type  
! 




3. Account Derivation Rules !

 
 

Therefore typically, two set of JED,JLT and ADR·s are required, with one set each for Credit line, and the other set for the
debit line.

In this article, we will create these three components.

Go to a subledger like Payables and within the SLA menu as shown below, you can open the Journal Enty Description screen. Click on New to
create a new JED.

Create a new Journal Entry Description named ANIL_JED. We will use this for generating the Journal Line Description for both the credit and the
debit lines.
The journal line description can be constructed by clicking on Details button. The description of the journal line can be a static text or dynamic
text based on database sources within SLA or the combination of the two.
Here we are using the Supplier Name to construct the journal line description.
In addition to the dynamic journal line text, SLA allows you to put conditions.
4or example
I4 CONDITION1=TRUE, then Journal Line Description should be abcd
ELSE I4 CONDITION2=TRUE, then Journal Line Description should be defg

Click on condition button to define the condition

After defining the Journal Entry description, now we can create Journal Line Type named ANIL_JLT_CREDIT for the credit line of the journal.
Specify the Transfer to GL in Summary or Detail mode. Also specify Merge, as explain in image below
Use the Payables setup option as source to build condition for JLT
In this example, we want to build a condition for ´Journal Line Typeµ eligibility depending upon whether in the Payables Options Screen has
Automatic Offset Method is set to None or „alancing or Account. In the above condition, we have placed an OR condition.
You can for example also build a condition based on Invoice Distribution type as shown below.
Next we need to define the Account Derivation Rule
Here we are creating an account derivation rule for the credit line.
An ADR can either return a full CCID or a specific segment. The values can be sourced either statically or from existing seeded dynamic sources
in SLA. These seeded sources are mapped to database tables.
We are stating that this specific ADR named ANIL_LIA„ILITY_ADR will return a constant value in company segment
In the above image you will see that the value for Company segment can be derived from the corresponding value set.

As below, it is also possible for the specific ADR to return a full segment combination. In fact you can specify conditions within an ADR. When
CONDITION1=TRUE then segment combonation a.b.c.d is returned or when CONDITION2=TRUE then d.e.f.g combination is returned for your
account.

4or the debit side, we are saying that the Account segment must always be 7450
The conditions can be defined. „ut conditions as evaluated as per the priority.
4inally we create a Journal Line Definition.
Here everything hangs together, JLTJLD,ADR=Journal Line Defnition

As shown below, we are saying that the CCID for the Credit Line of the journal will be calculated from ANIL_LIA„ILITY_ADR
And the CCID for the debit line will be calculated by the CCID value in Invoice Distribution line, with the specific segment from Account segment
being replaced as per ANIL_EXPENSE_ADR.
4or example, if the CCID in AP_INVOICE_DISTRI„UTION equates A.„.C.D.E.4 then your journal line debit entry will be A.„.7450.D.E.4

Ê Ê
R






   

 
   

 

  
Ê

  .
 3
3
Thursday, 09 December 2010 00:00 Anil Passi
E-mail | Print | PDF

In the previous part of this SLA article, you have learnt creation of the Journal Line Definition. Now it is time to create AAD,
which is "Application Accounting Definition".

The purpose of AAD in SLA is to dictate which "Journal Line Definition" must be used when a specific event takes place
against a specific type of transaction in a specific module like Payables or Receivables. If you recollect, the "Journal Line
Definition" definition creates a Credit Line and the Debit Line of a Journal.

Oracle ships out of the box an AAD for every simply module/application that uses SLA.
Hence for each application like AP,AR,PA,PO etc there will exist an existing AAD in the Subledger Modules. However, for this
example we will create a new AAD for Payables.

In the previous article you created a Journal Line Definition that is responsible for constructing a Journal. However, in AAD screen you will
specify when the Journal Line Definition will be used. In this case, as per the image below, we are stating that journal line definition ANIL_JLD
should be used for creating journal whenever any event occurs against an Invoice in Payables.
You can also click on "Header Assignment" button in AAD to attached "Journal Entry Description" [JED] which dictates how the Journal Header
description will be constructed. If you recollect, in Journal Entry Description, we concatenate static text and dynamic content from SLA
Sources[mapped to D„ columns or pl/sql functions] so as to construct a description for Journal Line or Journal header.
In this article we have seen that AAD is created for each module. However, in any implementation there is a need to perform accounting for all
the modules. "APPS24USION UK" might be running Payables and Receivables and also Project Accounting. Hence we need to create a SLAM-
Subledger Accounting Method.

Using AAD we specify the Journal creation rules per module. In SLAM we specify how the Journals must be built for the entire organization
"APPS24USION UK" across Payables and Receivables and Project Accounting. The company "APPS24USION UK" will have a legal entity in UK, and
hence the SLAM will be attached to the UK Legal Entity.
Ê Ê
R






   

 
  R
Ê

 8.



5

Friday, 10 December 2010 00:00 Anil Passi
E-mail | Print | PDF

In previous article we have seen that in SLA, the "Application Accounting Definition" is created for each module in E„usiness
Suite. However, in any implementation there is a need to perform accounting across various different modules. 4or example,
a company named "APPS24USION UK" might be running Payables and Receivables and also Project Accounting. Hence we need
to create a SLAM [Subledger Accounting Method] that will take care of generating the Accounting journal lines for each of the
module. Hence a SLAM is nothing but a grouping of all the AAD's possibly for a given chart of account.

Using AAD we specify the Journal creation rules per module. In SLAM we specify the applications/modules for which the
Journals must be built for the entire organization such as "APPS24USION UK" across Payables and Receivables and Project
Accounting. The decision of whether the journal must be created is delegated to the AAD. As for how the journal is
constructed and how the accounts are derived is delegated to the Journal Line Definition.

The company such as "APPS24USION UK" will have a legal entity in UK, and hence the SLAM will be attached to the UK Legal Entity.

In the image below we are creating a SLAM named ANIL_SLAM, and attaching the AAD named ANIL_PAYA„LES. This is a simplistic example,
because in reality you will have the AAD's of other applications like Receivables , Project Accounting, 4ixed Assets etc attached to the SLAM as
well.
In the above image, click on Accounting Setups, and here you can attach the SLAM to a Ledger. To remind you, in R12, the Ledger is equivalent
of set of books in 11i.
Ê Ê
R






   

  


 Ê

  #/

 .
Monday, 13 December 2010 00:00 Anil Passi
E-mail | Print | PDF

In the SLA articles Part 1 to Part 6, we understood the basic concepts of Subledger Accounting.
In the SLA articles Part 7 to Part 9, we configured SLA for Payables as an example.

In this article, we will test the configuration to see the results of the configuration performed in Part 7 to Part 9 of the SLA
articles. We will also explain the results of the test.

Our SLA setup was done for Payables, hence we will create an Invoice in Payables and check the accounting entries to
reconcile those against our SLA setup.

If you recollect, we created an AAD named ANIL_PAY„LES which is attached to Oracle Payables module. This AAD will invoke JLD named
ANIL_JLD to build the journal lines when an event takes place against the Payables invoice.

In the image below we are creating an Invoice from Payables responsibility and ensuring its invoice line distribution account is 01-110-6100-0000-
000.
Next we click on Actions button and validate the invoice and create accounting entries.
Now check the accounting generated by clicking on menu title Reports||View Accounting as shown in the image below.
You will notice that the Debit entry of 1000 is charged to 01-110-7450-0000-000 instead of being charged to 01-110-6100-0000-000 in the Invoice
Distribution Line of Payables. Please note that the third segments value of 6100 from Invoice Distribution has been replaced by 7450 from ADR
named ANIL_EXPENSE_ADR as shown below.

The complete logic is described after this image.

Now, let us revisit how the credit line in the journal has been built. Typically Code Combination for the credit/liability accounting entry of the
invoice line is picked from Payables Options setup of the operating unit. However in this case, in SLA we have hard coded the credit account to
be 01.000.2220.0000.000. This was done by defining ANIL_LIA„ILIY_ADR as shown below. In this case the ADR returns the complete CCID because
the Output Type radio button is set to 4lexfield.
Hence, the SLA has generated the same Credit entry CCID for the invoice, as shown in image below
Needless to say that the ANIL_LIA„ILITY_ADR was attached to the Journal Line Type=ANIL_JLT_CREDIT.
Ê Ê
R






   

 
  
 

 Ê

  
.9



Friday, 17 December 2010 07:17 Anil Passi
E-mail | Print | PDF

We have thus far seen the basic fundamentals and a simplistic scenario of Subledger Accounting. In the example that we saw,
we created components required for the SLA configuration from ground zero. That is also known as the bottom up approach,
where you build the lower level components and then move up the chain to attach your SLA configuration to your Ledger[11i
SetOf„ook equivalent in R12].
However you never ever use that approach in real life for modules such as Oracle Payables, Oracle Receivables, Oracle Cash
Management, Oracle 4ixed Assets or Oracle Project Accounting etc. The reason is that, SLA comes pre-configured for all the
widely used modules in the E„usiness Suite. All the commonly used rules are already seeded into the SLA config by Oracle,
hence all you need to do is to customize those components.

„
     
  

Y   
  

      

   I can customize the account generator in Procurement and 4ixed Assets. Do I really ever need to customize ´Subledger Accountingµ
in such cases?
Y   The pre-configured SLA by Oracle will use the accounts generated in respective modules as the source. ' 

 
 

 
   
 

 
  
 Effectively "garbage in garbage out", or you can say "quality
of the account that goes into SLA, and the same quality accounts are then sent to General Ledger". The message from seeded SLA in most cases
is ´What you feed to SLA will also be fed into the Oracle General Ledgerµ. Therefore if you have already customized the account generation
workflow in the respective module then you do not require customization in SLA. In fact, the customizations on the seeded SLA configurations
must be kept to bare minimum. Although SLA provides you with ability to override accounting definition, however the main reason for creation
of SLA was to implement multiple shadow accountings against ledgers.

   If all the respective modules can generate accounting properly then why is SLA really needed?
Y    Well, the main reason behind creation of SLA itself was to create shadow journals for secondary ledger. Please see the Part 1 in this
series of articles.

Now let us take the example for customization of an existing SLA definition pre-seeded by Oracle in R12. In this example, a SLAM named
STANDARD_ACCRUAL is attached to the Ledger [Set Of „ook equivalent of 11i ]. As you will notice from the image below, many modules such as
Leasing, Loans, Cash Management, Payables etc are attached to this SLAM. However we are interested in modifying just the Payables piece of
this SLAM. Create a copy of this SLAM as shown in the image below. We will create a SLAM named ANIL_SLAM__STANDARD_ACCRUAL which
happens to be the exact copy of SLAM named STANDARD_ACCRUAL.
Now create new entry for Payables within the copied SLAM, i.e. new SLAM will

be " ANIL_SLAM__STANDARD_ACCRUAL"

Now you have created a new SLAM. In this SLAM, end date the AAD assignment of Payables and add a new entry for Payables. Note that we still
have AAD named "Accrual „asis" attached. However after we copy the "Accrual „asis" into a custom AAD, we will then return to this screen in
order to replace "Accrual „asis" by custom AAD. Click on "Application Accounting Definition" button.
Now, click on copy, and this time we will copy the AAD definition named ´Accrual „asisµ to create a new AAD named ANIL_STD_PAYA„LES_STD.
The new AAD will be called ANIL_STD_PAYA„LES_STD as shown below. Click on button labelled Done to complete the Copy operation for the
AAD.
Now this new AAD has been created. „efore we customize this AAD, we need to ensure that this AAD has been attached to the custom SLAM that
we created in Step 1 of this article.

Now, back to the SLAM screen, for the custom SLAM, for Payables AAD assignment record, we attach the custom AAD to Payables. Please note
that the Payables entry that is attached to custom AAD named ´Accrual „asisµ has now been end dated, as shown in image below.
Now go back to AAD, by clicking on Application Accounting Definition button as per the image above.

4ollow the instructions as per images below

Now copy the Journal Line Definition itself.
The image below shows how the custom/copied journal line definition will be modified. Our idea here is to attach a custom ADR for the
generation of an account.
The name of the copied JLD will appear as below.
Attach the custom ADR as shown below
And now attach your custom Journal Line Definition to the custom AAD.
This completes the cycle for customization of the pre-seeded SLA configuration.
Ê

Ê Ê
Ê