1.Ledgers and Ledger Sets:
The ledger is a new fundamental concept in Release 12. The ledger replaces the 11i concept of a set of books. It represents an accounting representation for one or more legal entities or for a business need such as consolidation or management reporting.
11i & Prior = Sets of Books (3 C’s)
Chart of Accounts
Accounting Calendar
Currency
R12 = Ledgers (4 C’s)
Chart of accounts
Ledger currency
Accounting calendar
Accounting method – new 4th
4th C in R12:
In 11i the subledger accounting method (cash/accrual) was used to be defined at the subledger setup (AP/AR). However in R12 things have changed. You define the subledger accounting method at the ledger level. All subledgers tied to that ledger will use that particular accounting convention. So there is a difference in 11i and R12. The accounting "Convention" is now married to the ledger and hence the term 4Cs.
If you are not planning to use subledgers then you do not have to choose a value in the accounting method field. You can leave it blank. Your GL functionality will remain unaffected. However you will have to specify an accounting method at the ledger setup, before you could use a subledger.
Primary Ledger:
The main “Activity” Ledger
Usually in the local currency
For Operational reporting
Secondary Ledger:
Differs from Primary Ledger by Chart of Account, Calendar, and/or Accounting Method
For Statutory, Tax or Consolidated reporting
Reporting Currency Ledger:
Differs from Primary Ledger by Currency ONLY
Just a translation of the Primary Ledger – no rules required
For Consolidated reporting
LEDGER SETS:
Grouping of ledgers with the same chart of accounts and calendar/period type combination. Essentially treats multiple ledgers as one
2.Multi-Org Access Control(MOAC):
'Multi-Org Access Control' popularly known as 'MOAC' in short form is a enhanced feature in Release 12. MOAC will enable users to access secured data in one or more Operating Units from a single responsibility.
End-Users can access/transact data within several operating units based on Security Profile attached to a responsibility. i.e. End-Users can access/transact data on multiple Operating units by accessing one operating unit at a time without changing a responsibility. This Provides flexibility for end-users to work conveniently with multiple Operating Units in shared service Environments with single responsibility.
Profile Options which take major Role in MOAC
MO: Security Profile
MO: Default Operating Unit(Optional)
MO: Operating Unit(Mandatory for only Single Org or if MO: Security Profile is not defined)
Technically:
In 11i, data was restricted to a single operating unit using views which partition the base table data based on the OU setting controlled by Profile Options.
1.Based out of base tables (generally named with '_ALL') contained data for all operating units.
2.Each such table contained a column named ORG_ID to indicate what operating unit a particular row belonged to.
3.Data was then restricted by using restricted views (without _ALL table) which would only return rows which corresponded to the current operating unit's organization ID.
4.The current OU was stored in the first 10 characters of the database Application Context variable CLIENT_INFO.
5.When logging into the applications, the CLIENT_INFO value was set to the appropriate operating unit organization ID for the session based on the profile option setting for 'MO: Operating Unit'.
6.In SQL*Plus, CLIENT_INFO could be set to point to a particular operating unit using
execute dbms_application_info.set_client_info('');
Ex: ap_invoices_all- is base table with org_id column
ap_invoices - is a view on base table where org_id = SUBSTRB (USERENV ('CLIENT_INFO'), 1, 10)
In release 12 a more flexible architecture allows users to define security profiles so that users may access data for more than one operating unit within a single responsibility.
1. Oracle Multi-org views have been removed, and replaced with synonyms. Thats means in R12 table with out _ALL is no longer be a view defined on base table as Oracle have used the convention earlier, but provided a synonym which points to _ALL table.
2.The data is restriction by assigning a virtual private database (VPD) policy to the synonym. This policy allows the system to dynamically generate restricting conditions when queries are run against the synonym.
3.Data relating to defined VPD policies is viewable in the data dictionary view DBA_POLICIES.
Ex: ap_invoices_all- is base table with org_id column
ap_invoices - is a APPS synonym of base table where org_id = sys_context('multi_org2',current_org_id)
3.Subledger Accounting(SLA):
You can consider SLA as a bridge or an Intermediate platform that talks to Subledger products (these are other applications or modules) and the General ledger. All Accounting entries for your modules (like AP, AR, Projects, Inventory, etc) are treated as Sub-Ledgers and they first sent to the SLA engine. The SLA applies its rules (some or these rules are pre-configured and also you can configure as many rules as you want) and then sends the necessary journal entries to the General ledger.
In a nutshell, the following services are provided by Oracle SLA
Rule based Generation and storing of accounting entries
Storing subledger balances
Subledger or SLA accounting entries
Subledger reporting (some examples could be Open Account Balances Listing and Subledger Journal Reports, etc )
4.Tax Engine
It Centrally manage tax transactions across entire E-Business Suite.
5.Actual Shipment Date for Pick Release:
Now in R12 onward Oracle has introduced feature to allow user enter Actual Shipment Date.
This feature was very well required as in many industries they do the actual Shipping in Date D1 and then process the Shipping data in Oracle system on date D2. In Oracle System it always take the system data as the shipping date, thus result in discrepancies, Also many a time organization uses 3rd party system for Pick Pack and ship and then bring back the data into Oracle Shipping for Invoicing and other calculation , but again Oracle by default put the System data as shipping date and it create problems in managing the shipment activities and revenue recognition.
With this enhancement, Oracle allow user to enter the “Actual Departure Date” in
The ledger is a new fundamental concept in Release 12. The ledger replaces the 11i concept of a set of books. It represents an accounting representation for one or more legal entities or for a business need such as consolidation or management reporting.
11i & Prior = Sets of Books (3 C’s)
Chart of Accounts
Accounting Calendar
Currency
R12 = Ledgers (4 C’s)
Chart of accounts
Ledger currency
Accounting calendar
Accounting method – new 4th
4th C in R12:
In 11i the subledger accounting method (cash/accrual) was used to be defined at the subledger setup (AP/AR). However in R12 things have changed. You define the subledger accounting method at the ledger level. All subledgers tied to that ledger will use that particular accounting convention. So there is a difference in 11i and R12. The accounting "Convention" is now married to the ledger and hence the term 4Cs.
If you are not planning to use subledgers then you do not have to choose a value in the accounting method field. You can leave it blank. Your GL functionality will remain unaffected. However you will have to specify an accounting method at the ledger setup, before you could use a subledger.
Primary Ledger:
The main “Activity” Ledger
Usually in the local currency
For Operational reporting
Secondary Ledger:
Differs from Primary Ledger by Chart of Account, Calendar, and/or Accounting Method
For Statutory, Tax or Consolidated reporting
Reporting Currency Ledger:
Differs from Primary Ledger by Currency ONLY
Just a translation of the Primary Ledger – no rules required
For Consolidated reporting
LEDGER SETS:
Grouping of ledgers with the same chart of accounts and calendar/period type combination. Essentially treats multiple ledgers as one
2.Multi-Org Access Control(MOAC):
'Multi-Org Access Control' popularly known as 'MOAC' in short form is a enhanced feature in Release 12. MOAC will enable users to access secured data in one or more Operating Units from a single responsibility.
End-Users can access/transact data within several operating units based on Security Profile attached to a responsibility. i.e. End-Users can access/transact data on multiple Operating units by accessing one operating unit at a time without changing a responsibility. This Provides flexibility for end-users to work conveniently with multiple Operating Units in shared service Environments with single responsibility.
Profile Options which take major Role in MOAC
MO: Security Profile
MO: Default Operating Unit(Optional)
MO: Operating Unit(Mandatory for only Single Org or if MO: Security Profile is not defined)
Technically:
In 11i, data was restricted to a single operating unit using views which partition the base table data based on the OU setting controlled by Profile Options.
1.Based out of base tables (generally named with '_ALL') contained data for all operating units.
2.Each such table contained a column named ORG_ID to indicate what operating unit a particular row belonged to.
3.Data was then restricted by using restricted views (without _ALL table) which would only return rows which corresponded to the current operating unit's organization ID.
4.The current OU was stored in the first 10 characters of the database Application Context variable CLIENT_INFO.
5.When logging into the applications, the CLIENT_INFO value was set to the appropriate operating unit organization ID for the session based on the profile option setting for 'MO: Operating Unit'.
6.In SQL*Plus, CLIENT_INFO could be set to point to a particular operating unit using
execute dbms_application_info.set_client_info('
Ex: ap_invoices_all- is base table with org_id column
ap_invoices - is a view on base table where org_id = SUBSTRB (USERENV ('CLIENT_INFO'), 1, 10)
In release 12 a more flexible architecture allows users to define security profiles so that users may access data for more than one operating unit within a single responsibility.
1. Oracle Multi-org views have been removed, and replaced with synonyms. Thats means in R12 table with out _ALL is no longer be a view defined on base table as Oracle have used the convention earlier, but provided a synonym which points to _ALL table.
2.The data is restriction by assigning a virtual private database (VPD) policy to the synonym. This policy allows the system to dynamically generate restricting conditions when queries are run against the synonym.
3.Data relating to defined VPD policies is viewable in the data dictionary view DBA_POLICIES.
Ex: ap_invoices_all- is base table with org_id column
ap_invoices - is a APPS synonym of base table where org_id = sys_context('multi_org2',current_org_id)
You can consider SLA as a bridge or an Intermediate platform that talks to Subledger products (these are other applications or modules) and the General ledger. All Accounting entries for your modules (like AP, AR, Projects, Inventory, etc) are treated as Sub-Ledgers and they first sent to the SLA engine. The SLA applies its rules (some or these rules are pre-configured and also you can configure as many rules as you want) and then sends the necessary journal entries to the General ledger.
In a nutshell, the following services are provided by Oracle SLA
Rule based Generation and storing of accounting entries
Storing subledger balances
Subledger or SLA accounting entries
Subledger reporting (some examples could be Open Account Balances Listing and Subledger Journal Reports, etc )
4.Tax Engine
It Centrally manage tax transactions across entire E-Business Suite.
- Single Repository of transactions for global business insight
- Centralized rules applied to transactions to manage globally and reduce risk
- Automation of tax processes on transactions to improve operational efficiency
- Improved Reporting
- Effective Date Setup
- Extensible architecture that supports additions, e.g. Self-assessed Use Tax
5.Actual Shipment Date for Pick Release:
Now in R12 onward Oracle has introduced feature to allow user enter Actual Shipment Date.
This feature was very well required as in many industries they do the actual Shipping in Date D1 and then process the Shipping data in Oracle system on date D2. In Oracle System it always take the system data as the shipping date, thus result in discrepancies, Also many a time organization uses 3rd party system for Pick Pack and ship and then bring back the data into Oracle Shipping for Invoicing and other calculation , but again Oracle by default put the System data as shipping date and it create problems in managing the shipment activities and revenue recognition.
With this enhancement, Oracle allow user to enter the “Actual Departure Date” in
- Sales Order Picking
- Ship confirm SRS Parameter Window
- Pick release SRS Parameter Window
