Search Results create_implicit_access_set




Overview
Explore in AI Chat

Overview

APPS.GL_ACCESS_SETS_PKG is a server-side PL/SQL package within the Oracle E-Business Suite General Ledger module. Its stated purpose, per the embedded header comment, is to provide "server routines related to table gl_access_sets." The package encapsulates the business logic that governs the creation, maintenance, and retrieval of data access set definitions, which are the central mechanism by which General Ledger enforces segment value security and controls which ledgers, balancing segment values, and management segment values a given responsibility or user may access. The package is declared AUTHID CURRENT_USER, meaning its SQL statements execute under the privileges of the invoking schema rather than the package owner, a standard convention for APPS-owned shared packages. The header indicates an original creation date of 19-Feb-2001 by T. Cheng, with the shipped version carrying a revision string of 120.7 dated 05-May-2005, confirming the package has been stable across the 11i through 12.x release line, including 12.1.1 and 12.2.2.

Key Procedures and Functions

  • GET_UNIQUE_ID — Retrieves the next unique access set identifier from the sequence GL_ACCESS_SETS_S.
  • HAS_DETAILS_IN_DB — Determines whether any access detail rows already exist in the database for a given access set.
  • MAINTAIN_DEF_LEDGER_ASSIGN — Checks whether a default ledger detail assignment exists for the data access set; inserts the assignment when absent and returns a boolean status.
  • GET_VALUE_SET_ID — Returns the value set identifier associated with a given chart of accounts and segment qualifier, supporting validation of segment values used within access set definitions.
  • SELECT_COLUMNS — Populates the access set attributes for a supplied access set identifier, serving as the primary retrieval routine for the form layer.
  • CREATE_IMPLICIT_ACCESS_SET — Creates an implicit access set, typically generated as a byproduct of defining a ledger or ledger set rather than entered manually by the user.
  • UPDATE_IMPLICIT_ACCESS_SET — Modifies an existing implicit access set, keeping the generated definition synchronized with changes to the underlying ledger or ledger set configuration. This is the routine that corresponds to the user's search term, update_implicit_access_set.
  • INSERT_ROW — Inserts a new row into the GL_ACCESS_SETS table.
  • UPDATE_ROW — Updates an existing GL_ACCESS_SETS row.
  • LOCK_ROW — Acquires a row-level lock on an access set record to serialize concurrent modification.

Tables Accessed

The package works primarily against GL_ACCESS_SETS and its sequence GL_ACCESS_SETS_S, which hold the access set header definitions and supply primary keys respectively. GL_ACCESS_SET_NORM_ASSIGN stores the normalized assignment rows that map ledgers, balancing segments, and management segments to each access set, and is manipulated by the insert, update, and default-assignment routines. Validation logic reads FND_ID_FLEX_SEGMENTS and FND_SEGMENT_ATTRIBUTE_VALUES to resolve segment qualifiers and value set identifiers, while DUAL supports trivial single-row lookups. All references are made through APPS synonyms, and the package is itself referenced by two other packages, indicating it is a shared utility rather than a standalone entry point.

Usage Notes

GL_ACCESS_SETS_PKG is invoked indirectly during General Ledger setup rather than called directly by end users. The Oracle Forms-based Data Access Sets definition form calls the select, insert, update, and lock routines to maintain access set records, while the ledger and ledger set definition flows invoke the implicit access set routines to generate and refresh implicit definitions automatically. Because it is an internal, undocumented API, custom code should avoid calling it directly; instead, integrators should use the supported Data Access Set open interfaces and concurrent programs. Where direct invocation is unavoidable, callers must preserve the locking discipline established by LOCK_ROW and account for the AUTHID CURRENT_USER semantics when executing from a custom schema.