Search Results gl_set_of_bks_id

Overview

BIS_SETS_OF_BOOKS_V is an Oracle Applications (APPS) view, owned by the APPS schema and classified under the BIS – Applications BIS product family. It exposes the relationship between Oracle General Ledger sets of books (ledgers), the GL_SET_OF_BKS_ID profile option, and the responsibilities to which those profile values are assigned. In Oracle EBS 12.1.1 and 12.2.2, this view is a lightweight resolution layer: given a responsibility context, it returns the set of books identifier and name that would be resolved for GL_SET_OF_BKS_ID at that responsibility level.

Its primary role is to support reporting and integration logic that must determine which accounting set of books applies to a user's responsibility without re-implementing the profile option resolution rules directly. The view encapsulates the interaction between FND_PROFILE_OPTIONS, FND_PROFILE_OPTION_VALUES, FND_RESPONSIBILITY, and GL_SETS_OF_BOOKS, so consuming code can join through a single object. This makes it valuable in BIS-style reporting and any custom inquiry that needs responsibility-to-ledger mapping.

Underlying Base Objects

The documented view text is defined over four base objects: FND_PROFILE_OPTIONS (aliased P), FND_PROFILE_OPTION_VALUES (aliased V1, with a correlated sub-query over V2), FND_RESPONSIBILITY (aliased R2), and GL_SETS_OF_BOOKS (aliased O). No base objects are separately documented in the ETRM metadata, so the view text is the authoritative definition.

The view is a UNION of two branches. In the first branch, profile option values stored at LEVEL_ID = 10001 (the responsibility level) are resolved for the GL_SET_OF_BKS_ID profile option, then joined to FND_RESPONSIBILITY by RESPONSIBILITY_ID. A NOT EXISTS clause suppresses responsibilities for which a site-level value (LEVEL_ID = 10003) also exists, preserving the standard profile option precedence where a lower-level value overrides. In the second branch, site-level values (LEVEL_ID = 10003) are selected directly and joined to GL_SETS_OF_BOOKS. Both branches convert the profile option value to a number and match it against GL_SETS_OF_BOOKS.SET_OF_BOOKS_ID.

Key Columns

• ID — The set of books identifier, derived as TO_CHAR(O.SET_OF_BOOKS_ID). In 12.2.2 this corresponds to the ledger identifier exposed through the GL_SETS_OF_BOOKS compatibility view.
• VALUE — The name of the set of books (O.NAME), providing a human-readable label for the resolved ledger.
• RESPONSIBILITY_ID — The responsibility identifier associated with the profile value. In the responsibility-level branch this comes from FND_RESPONSIBILITY; in the site-level branch it is the LEVEL_VALUE, which carries the responsibility context for the site default.

Because the columns are named ID, VALUE, and RESPONSIBILITY_ID rather than SET_OF_BOOKS_ID, consumers must reference them explicitly, commonly by joining ID back to GL_SETS_OF_BOOKS.SET_OF_BOOKS_ID on a TO_NUMBER conversion.

Common Use Cases and Queries

A frequent scenario is resolving the ledger for a given responsibility, particularly in custom reports that must display accounting context. For example, joining to FND_RESPONSIBILITY provides responsibility names alongside the resolved set of books.

• Determine ledger name for a responsibility: SELECT b.ID, b.VALUE FROM BIS_SETS_OF_BOOKS_V b WHERE b.RESPONSIBILITY_ID = :resp_id;
• List all responsibility-to-ledger mappings: SELECT b.RESPONSIBILITY_ID, b.ID, b.VALUE FROM BIS_SETS_OF_BOOKS_V b;
• Join to GL_SETS_OF_BOOKS for additional attributes: SELECT b.VALUE, g.CURRENCY_CODE FROM BIS_SETS_OF_BOOKS_V b, GL_SETS_OF_BOOKS g WHERE TO_NUMBER(b.ID) = g.SET_OF_BOOKS_ID;

Because the view is read-only and defined with profile option logic, it should be treated as an inquiry object. In 12.2.2, where multiple ledgers may be assigned to a responsibility, the view still reflects the profile option resolution rather than the full ledger assignment model, so it is best used for profile-derived context rather than exhaustive ledger access. Performance is generally acceptable for single-responsibility lookups, but full-table queries benefit from joining on indexed profile and responsibility columns.