Search Results clean_up_explicit_sets




Overview
Explore in AI Chat

Overview

The APPS.GL_FLATTEN_LEDGER_SETS package is a General Ledger utility program in Oracle E-Business Suite (documented for 12.1.1 and 12.2.2) that maintains the flattened and normalized representations of ledger sets whenever the underlying ledger hierarchy changes. Ledger sets group multiple ledgers so that journals, reporting, and period-status operations can be processed across all members simultaneously. Because a ledger set may be defined either explicitly (specific ledgers added by the user) or implicitly (derived from a ledger or ledger-set hierarchy), the assignments that resolve a set into its component ledgers must be recalculated and stored in flattened form for efficient retrieval.

This package encapsulates that maintenance logic. Rather than resolving hierarchies at query time, Oracle General Ledger pre-computes the expanded membership of each ledger set into the assignment tables, and GL_FLATTEN_LEDGER_SETS is the routine responsible for keeping those pre-computed rows synchronized with changes made through the Ledger Set definition form. It is classified as an OTHER API — an internal, non-public interface rather than a supported open API — and is referenced by one other package within the application.

Key Procedures and Functions

Two procedures/functions are documented in the ETRM metadata:

  • FIX_EXPLICIT_SETS — Processes all changes to explicit ledger sets made through the Ledger Set form. When a user adds or removes ledgers from an explicitly defined ledger set, this routine reconciles the stored assignments so that the flattened membership reflects the user's edits.
  • CLEAN_UP_EXPLICIT_SETS — Performs the corresponding cleanup of explicit ledger set data, removing or correcting stale assignment rows so that obsolete membership records do not persist after ledger sets are modified or deleted.

The package header comments also describe a broader internal family of routines — Fix_Implicit_Sets, Fix_Norm_Table, and Fix_Flattened_Table — which process changes arising from the ledger hierarchy and populate the normalized and flattened assignment tables. These are documented in the source comments but are not enumerated in the ETRM procedure list. No parameter lists are published; the documented interface exposes no arguments.

Tables Accessed

The package reads and writes the following tables (referenced through APPS synonyms):

  • GL_LEDGERS — The ledger definition table, read to resolve ledger identity and hierarchy relationships.
  • GL_LEDGER_SET_ASSIGNMENTS — The primary flattened assignment table, populated so each ledger set reports its fully expanded set of member ledgers.
  • GL_LEDGER_SET_NORM_ASSIGN — The normalized assignment table, holding the direct (non-flattened) set-to-ledger relationships.
  • GL_ACCESS_SET_NORM_ASSIGN and GL_ACCESS_SET_NORM_ASSIGN_S — Access-set normalization tables used to align ledger-set membership with access-set security assignments.
  • DUAL — Used for singleton SELECTs (for example, existence checks and return-value evaluation).

Together these tables provide the storage layer that allows ledger-set queries to avoid recursive hierarchy traversal at runtime.

Usage Notes

In normal operation this package is invoked indirectly. The Ledger Set definition form calls it when a user saves changes to an explicit or implicit ledger set, triggering the flattening and normalization routines. It may also be executed by internal ledger-hierarchy maintenance logic and by concurrent or background processing that validates and repairs ledger-set assignments after structural changes.

Because it is classified as an OTHER API, it is not part of Oracle's supported public API surface, and custom code should not call it directly unless the behavior has been validated for the specific release. Developers performing data fixes or diagnostics on ledger-set membership may reference it to understand why assignment rows in GL_LEDGER_SET_ASSIGNMENTS and GL_LEDGER_SET_NORM_ASSIGN differ from the displayed hierarchy. Any direct invocation should be followed by verification of the flattened tables and, where appropriate, a resubmission through the standard form or a concurrent rebuild process.