Search Results gl_access_set_ledgers_v




Overview

The GL_ACCESS_SET_LEDGERS_V view in the APPS schema is a General Ledger (GL) reporting and integration object that exposes the relationship between access sets and the ledgers they authorize. An access set is a General Ledger security mechanism that groups one or more ledgers and assigns an access privilege to that group; the privilege determines what a user assigned to the access set may do with the ledger (for example, read-only versus read-and-write). This view joins the underlying access-set-to-ledger assignment table to the ledger definition table and projects both the assignment attributes and descriptive ledger attributes into a single queryable structure.

The view is documented as VALID in ETRM 12.2.2 and is present in 12.1.1 environments as well. Because access set and ledger assignments drive row-level security across the GL application, the view is frequently used by DBAs and developers to audit which ledgers a given access set contains, which privilege is granted, and how long the assignment is effective. It is a read-oriented object; the base assignment table should be maintained through the standard access set maintenance forms rather than direct DML.

Underlying Base Objects

The view is defined over two referenced base objects:

  • GL_ACCESS_SET_LEDGERS (TABLE) — the transactional source of access set to ledger assignments. It supplies the access set identifier, ledger identifier, the access privilege code, and the standard WHO columns along with the assignment effective dates.
  • GL_LEDGERS (SYNONYM) — the ledger definition source. It supplies the ledger name, currency code, and object type code, and is joined to the assignment table on LEDGER_ID.

The join is an equality join on GL_ASL.LEDGER_ID = LDG.LEDGER_ID. The view also exposes GL_ASL.ROWID aliased as ROW_ID, giving a stable pseudocolumn identifier for the underlying assignment row. Because GL_LEDGERS is referenced as a synonym, the view resolves through the APPS synonym layer to the underlying ledger table at runtime.

Key Columns

  • ROW_ID — the ROWID of the underlying GL_ACCESS_SET_LEDGERS row.
  • ACCESS_SET_ID — identifier of the access set; joins to the access set definition header.
  • LEDGER_ID — identifier of the ledger assigned to the access set.
  • LEDGER_NAME — the ledger name from GL_LEDGERS.
  • CURRENCY_CODE — the ledger's functional currency.
  • OBJECT_TYPE_CODE — the object type of the ledger.
  • ACCESS_PRIVILEGE_CODE — the privilege granted for this access set and ledger combination. This is the column most frequently queried by users searching on "access_privilege_code"; it indicates the level of access (for example, read versus write) the access set confers on the ledger.
  • START_DATE / END_DATE — the effective date range of the assignment, enabling time-bounded access auditing.
  • LAST_UPDATE_DATE, LAST_UPDATED_BY, CREATION_DATE, CREATED_BY, LAST_UPDATE_LOGIN — standard WHO audit columns.

Common Use Cases and Queries

Typical uses include auditing access set membership for a ledger, verifying the privilege granted by each access set, and identifying assignments that have expired or not yet started.

List all ledgers and privileges for a specific access set:

SELECT access_set_id, ledger_id, ledger_name,
       access_privilege_code, start_date, end_date
FROM   apps.gl_access_set_ledgers_v
WHERE  access_set_id = :p_access_set_id
ORDER  BY ledger_name;

Find every access set granting access to a particular ledger:

SELECT access_set_id, ledger_name, access_privilege_code
FROM   apps.gl_access_set_ledgers_v
WHERE  ledger_id = :p_ledger_id;

Identify currently effective assignments by privilege code:

SELECT access_set_id, ledger_id, ledger_name, access_privilege_code
FROM   apps.gl_access_set_ledgers_v
WHERE  access_privilege_code = :p_privilege
AND    TRUNC(SYSDATE) BETWEEN start_date AND NVL(end_date, SYSDATE);

Because the view performs a simple two-table join without aggregation, it can be used directly in reports, concurrent programs, and integration extracts that need to reconcile access set security with the ledger hierarchy.