Search Results gl_access_set_norm_assign_s

Overview

GL_ACCESS_DETAILS_PKG is an APPS-owned PL/SQL package body in Oracle E-Business Suite Release 12.1.1 and 12.2.2 that supports the maintenance of access set definitions within the General Ledger access control framework. Access sets determine which ledger and ledger set combinations a responsibility or user may access when performing GL functions, and the assignment of individual access details to a given access set is stored in the GL_ACCESS_SET_NORM_ASSIGN table. This package encapsulates the data-manipulation and validation logic used to create, lock, modify, and delete those access detail rows, providing a controlled programmatic interface over the underlying assignment table so that the Oracle GL forms and related components do not manipulate the table directly.

The package is classified as OTHER in the ETRM repository and is current with a VALID status in the APPS schema. It is referenced by one other database object, indicating that it functions as a lower-level utility consumed by a higher-level access set maintenance component rather than being an entry point itself.

Key Procedures and Functions

The package body exposes seven documented procedures and functions:

• GET_RECORD_ID — Retrieves the unique record identifier associated with an access detail row, typically used to obtain the primary key value needed for subsequent lock, update, or delete operations.
• IS_LEDGER_SET — Evaluates whether the access detail being processed refers to a ledger set rather than an individual ledger, allowing callers to branch logic based on the type of access target.
• INSERT_ROW — Inserts a new access detail assignment row into the normalized assignment table, establishing the link between an access set and the ledger or ledger set it grants access to.
• LOCK_ROW — Issues a locking read against an existing access detail row to serialize concurrent modification attempts and preserve data integrity during multi-step updates.
• DELETE_ROW — Removes an existing access detail assignment, revoking the associated access set privilege.
• CHECK_DUPLICATE — Determines whether an equivalent access detail assignment already exists, preventing duplicate entries for the same access set and ledger combination.
• VALIDATE_ACCESS_DETAIL — Performs the business-rule validation for an access detail row, confirming that the referenced ledger or ledger set is valid and that the assignment is permissible before it is persisted.

Tables Accessed

The package operates against the following tables, referenced through APPS synonyms:

• GL_ACCESS_SET_NORM_ASSIGN — The primary normalized assignment table holding access detail rows; read, inserted into, locked, and deleted by the package.
• GL_ACCESS_SET_NORM_ASSIGN_S — The sequence associated with the assignment table, used to generate unique record identifiers for newly inserted access detail rows. This object corresponds to the search term gl_access_set_norm_assign_s.
• GL_LEDGERS — Queried to validate that referenced ledgers exist and are valid for the access assignment, and to support ledger-versus-ledger-set determination.
• DUAL — Used for single-row evaluations, such as sequence retrieval and simple validation checks.

Additional dependencies include APP_EXCEPTION and APP_EXCEPTIONS for standardized error handling, FND_MESSAGE for message retrieval and display, and GL_FLEXFIELDS_PKG for key flexfield validation of ledger-related segments.

Usage Notes

GL_ACCESS_DETAILS_PKG is not intended for direct invocation by end users. It is typically called by the General Ledger access set maintenance forms and by higher-level access control packages when a user defines or edits the ledger and ledger set assignments that make up an access set. Its INSERT_ROW, LOCK_ROW, and DELETE_ROW procedures follow the standard Oracle Forms programmatic DML pattern, where the form transfers control to the package instead of issuing DML directly, and CHECK_DUPLICATE and VALIDATE_ACCESS_DETAIL enforce validation before commit. Custom code that manages access sets programmatically should call these routines in the same sequence used by the standard forms to preserve locking, duplicate-checking, and validation behavior. Because the package is not referenced by other database objects beyond its single consumer, it should be treated as an internal implementation artifact, and any customization should account for the possibility of changes across 12.1.1 and 12.2.2 maintenance levels.