Contact Us

  • Register

Oracle Gold Partners, training schedule is listed here designed by Five Star Rated Oracle Press Authors & Oracle ACE's.

webinar new

Search Our Trainings

User Rating: 5 / 5

Star ActiveStar ActiveStar ActiveStar ActiveStar Active

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.

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

Join our FAH Group on Linkedin


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. For 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 JLT 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 Foreign currency transactions. Further to that you can specify if SLA should merge the journal lines that have same CCID.

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

Further to this, when defining ADR, you can specify the conditions under which a specific segment or CCID is returned. These conditions are like IF 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.

By 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. For example, how does Oracle E-Business 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.


Anil Passi


+1 #1 Joy 2010-12-02 08:50
Hi Anil,

Thanks for your posts on SLA. The concepts are explained in very simple terms and can be grasped very easily. I believe in many R12 implementations we are not fully leveraging SLA functionality because of lack of clarity on this area. I am sure we can do away with lot of customizations on accounting generators if we can leverage SLA. Please confirm on this point. Waiting for your newer posts on this subject. Keep up the good work.

J oy
+1 #2 Prasad CP 2010-12-02 12:06
Thanks Anil , you have put the concepts very lucidly . Those who like it diagramitically this is how it all fits

\ | /
\ | /
\ | /
\ | /
\ | /
\ | /
\ | /

ADR = Account Derivation Rules
JED = Journal Entry Description
JLT = Journal Line Type
JLD = Journal Line Definition
AAD = Application Accounting Definition
SLAM = Subledger Accounting Method
0 #3 Anil Passi 2010-12-03 05:33
That is right Joy, you no longer need to customize Account Generator Workflow, as you can control account build from SLA centrally. Also this gives business users visibility into the config of SLA.

A nil Passi
0 #4 SwatiT 2011-06-28 05:53
Hi Puneet,

Very nice way of writing.

Could you please tell me if FAH has its own reporting?

0 #5 Sagar Gaikwad 2011-10-12 03:30
Currently when a PO item is received in Oracle the system generates an automatic accrual into the GRNI accounts 223000/224000.
Is it possible for the system to recognize the supplier and to continue using the GRNI accounts but to add an intercompany segment where applicable?
0 #6 Shoban 2012-05-22 15:11
Hello Anil,

I have scenario here, Wanted to understand if this is achievable scenario. If yes, can you please guide me on this please.

Curren tly, IPV and EPV are being coded to 12345 accounts in the case of inventory items, and to the 56789 clearing account in the case of ABC service fee invoices.

Belo w i have shown as to how IPV and EPV should be coded to the relevant 13*20 account depending on whether it relates to;

1. Raw Materials, WIP (BLKT) or Finished Goods (BSTK or FG), or in the case of
2. ABC Service fees, where the relevant 13*20 account is determined by whether the fee is for WIP (BLKT) or FG (BSTK of FG).

In Oracle PV’s should be booked to the Balance Sheet – COMPANY.000.13* 20.00000.Produc t Code.000.

In the manufacturing entities, price variances on the purchase of raw materials and on ABC fees charged should be coded to the relevant PV accounts on the balance sheet [13120, 13220, 13320]

IPV and EPV should be coded to the relevant 13*20 account depending on whether it relates to raw materials, WIP (BLKT) or FG (BSTK or FG).

IPV and EPV on ABC fee invoices should be coded to the relevant 13*20 account driven by whether the fee is for WIP (BLKT) or FG (BSTK or FG).

The coding should be based on the inventory category code set attached to each item number, which contains Manufacturing Stage, Material Type, Product and Alliance. The material type and the product categories should be able to determine the US GAAP account and product code combinations.


· The Material type in the category code set drives the natural account in the GL

· The Product in the category code set drives the Product segment in the GL

This table outlines the logic upon which each attribute in the Account Segment String is determined.

BS = from purchasing LE
CC = Always 0000 on balance sheet
NATURAL ACCOUNT = Derived from the MATERIAL TYPE on the Inventory Category Code Set
Location = Always 00000
PRODUCT = Derived from PRODUCT SEGMENT on the Inventory Category Code Set
INTERCOMPAN Y = Always 000
FUTURE 1 = Always 000000
FUTURE 2 = Always 000000
0 #7 Gunjan Bansal 2012-06-14 02:03
Hi Anil,

Very nice Article .. Simple language and easy to understand..

C ould you please tell me the difference between SLA and FAH..

Add comment

Security code

About Apps2Fusion

Apps2Fusion are passionate about training. Training is our core business and we have been doing this for many many years. We thrive to meet expectations of our trainees and we are Oracle Gold Partners. We work hard to advise trainees with right career paths. We have published various five star rated Oracle Press Books each was best sellers in its category. We have helped many and could help you as well.