from http://apps2fusion.com/at/58-pv/303-r12-sla-subledger-accounting
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.
Why SLA and what does it do?
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.
Note: 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.
How does SLA works?
1. Register sub ledger transactions in SLA.
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.
2. How does SLA understand whether unique id is invoice id or a po_distribution id or an expenditure_item_id as SLA uses same table to store all the identifier?
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.
Navigation:
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.
3. Based on the identifiers and event class, how SLA creates accounting lines?
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.
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.
Why SLA and what does it do?
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.
Note: 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.
How does SLA works?
1. Register sub ledger transactions in SLA.
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.
2. How does SLA understand whether unique id is invoice id or a po_distribution id or an expenditure_item_id as SLA uses same table to store all the identifier?
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.
Navigation:
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.
3. Based on the identifiers and event class, how SLA creates accounting lines?
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.
No comments:
Post a Comment