Search Results gl_je_headers_pkg




Overview

APPS.GL_JE_HEADERS_PKG is a server-side PL/SQL package that encapsulates the core data-management logic for journal entry headers in the Oracle E-Business Suite General Ledger. The header record is the master row of every journal entry, holding the batch reference, ledger, period, category, currency, conversion attributes, and control totals that ultimately drive posting and reporting. This package provides the programmatic layer through which journal headers are validated, inserted, locked, updated, deleted, and recalculated, shielding callers from the physical schema. It is classified as a package of type OTHER rather than a published public API, indicating it is intended primarily for internal use by the General Ledger journal-entry subcomponents.

The package sits at the center of a tightly coupled set of journal objects. The dependency documentation records that GL_JE_BATCHES_PKG, GL_JE_LINES_PKG, and GL_JE_HEADERS_PKG itself reference it, and the package in turn references two other packages. In ETRM 12.2.2 it is documented with sixteen procedures and functions, making it the principal handler for header-level integrity within the journal entry stack.

Key Procedures and Functions

  • CHECK_UNIQUE — Verifies that a header being created or modified does not violate the uniqueness rules governing journal headers within their batch and ledger context.
  • GET_UNIQUE_ID — Obtains the next unique identifier used to key a header record.
  • INSERT_ROW — Performs the physical insert of a new GL_JE_HEADERS row after validation and defaulting have been completed.
  • UPDATE_ROW — Applies changes to an existing header record.
  • DELETE_ROW — Removes a single header row.
  • DELETE_HEADERS — Deletes headers in bulk, typically as part of cleaning up an entire batch or set of entries.
  • LOCK_ROW — Acquires a row-level lock on the header, serializing concurrent modifications.
  • POPULATE_FIELDS — Derives and defaults the many header attributes that are not directly supplied by the caller.
  • CALCULATE_TOTALS — Sums the associated journal lines to refresh the entered, accounted, and foreign-currency control totals held on the header.
  • CHANGE_EFFECTIVE_DATE — Adjusts the effective date of the header, propagating the date used for accounting and period derivation.
  • MAX_EFFECTIVE_DATE — Returns the maximum effective date permissible for the header, used as a validation ceiling.
  • CHANGE_PERIOD — Reassigns the header to a different accounting period.
  • NEEDS_TAX — Determines whether the journal entry requires tax handling based on its attributes.
  • HAS_SEQNUM — Indicates whether a sequence number has been assigned to the header.

Tables Accessed

  • GL_JE_HEADERS / GL_JE_HEADERS_S — The base table and its shadow table, which hold the header rows and their audit/DTL information.
  • GL_JE_BATCHES — The parent batch, read for batching context and control total validation.
  • GL_JE_LINES — Sourced by CALCULATE_TOTALS to derive header amounts.
  • GL_JE_LINES_RECON — Reconciliation data supporting line-level checks.
  • GL_LEDGERS — Provides ledger attributes such as currency and chart of accounts.
  • GL_PERIOD_STATUSES — Supplies period open/closed status used during period changes and validation.
  • FUN_SEQ_VERSIONS — Sequence versioning used when generating unique identifiers.
  • DUAL — Used for scalar evaluations and sequence retrieval.

Usage Notes

The package is invoked principally by the General Ledger journal entry forms and by the sibling packages GL_JE_BATCHES_PKG and GL_JE_LINES_PKG, which together implement the write path for journal entries. Because it is not a published API, custom code should not call it directly where a supported interface exists. Its header routines are typically reached indirectly through the Journal Import concurrent program or through the journal entry form when a user saves, changes a period, or alters an effective date. Custom extensions that must manipulate headers should do so cautiously, honoring the locking, uniqueness, and total-recalculation behavior enforced here so that downstream posting and reconciliation remain consistent.