The intent of this document is provide the reader with a fundamental understanding of Oracle Ledger Sets and Data Access Sets, enriched with lessons learned from actual implementations. Matt Makowsky is an Oracle Financial Applications Consultant with 17 years experience and a Senior Solutions Architect with Perficient.
In Oracle EBS Release 12, two new concepts were introduced called “Ledger Sets” and “Data Access Sets”. They are similar concepts, however they can intersect in their usage of each other, or they can remain completely mutually exclusive of each other.
For starters, I’ll define each in layman’s terms:
A “Ledger Set” is a grouping of ledgers that share the same chart of accounts and calendar. The purpose of a ledger is to provide access to multiple ledgers at one time from a GL responsibility PLUS provide the ability to run other concurrent programs and reports across an entire ledger set. For example, you can run revaluation across an entire ledger set and have individual journals produced within each ledger within the ledger set. You can open all the periods for every ledger in the ledger set. You can run a trial balance across all the ledgers in a ledger set. When you create a ledger set, Oracle AUTOMATICALLY creates a “Data Access Set”.
The “Data Access Set”, provides the access to a ledger to view and/or to create journals within a ledger. It does not provide any of the functionality of a ledger set. If you create a data access set manually (without first creating a ledger set), you will have access to those ledgers, but cannot run the above mentioned processes across them as you could if you have a ledger set. It is the data access set that is assigned to a responsibility. If the data access set ties to a ledger set, then the user would have all of the additional functionality provided by the ledger set.
The Data Access Set and Ledger Set may “intersect”, if for example, you wish to have a ledger set that provides open/close functionality across 6 ledgers, but allows data entry ONLY in a 7th ledger, then you would create a ledger set with the 6 ledgers. Then, create a data access set, listing the ledger set and the additional 7th ledger. Use that data access set to assign to the GL responsibility. In this case, when the user attempts to open all the periods for the ledgers, it will only open up 6 of the ledgers. The 7th ledger would not be included.
The Data Access Set also allows for a more granular restriction on the Balancing Segment Value (BSV). With that restriction, you can limit the ledger access down to one single BSV for data entry. A US-based user might require access to a ledger in the UK, however only a US-owned entity within the UK. In this case, you would create a data access set with the UK Ledger, and restrict it to a single BSV for the US-owned entity. This is similar to the implementation of a value set security rule, however the combination of ledger sets and a restrictive access set would eliminate the need for a value set security rule, which is simply one less item to maintain in the system. By using the data access set, the user would not be able to open and close periods within the UK ledger, because their access is limited to one BSV. The value set security rule will not prevent that function, and you would need to pay further attention to “menu function” security to make sure that the user does not have access to open and close periods in a ledger that is not their own.
To summarize:
Ledger Sets provide ability to run processes and reports across multiple ledgers.
Access Sets can limit access within a ledger
A Ledger Set can be assigned to a Data Access Set with additional ledgers and restrictions may be placed on the BSVs within those ledgers.
The Data Access Set may act as a better alternative to Value Set Security Rules
Very Nice in-depth article!!