Search Results gl_je_batches_pkg




Overview
Explore in AI Chat

Overview

The APPS.GL_JE_BATCHES_PKG package body encapsulates the core server-side logic that Oracle General Ledger uses to create, validate, maintain, and delete journal entry batches. In the Oracle EBS 12.1.1 and 12.2.2 data model, a journal batch is the topmost grouping in the journal hierarchy: a batch contains one or more journal headers, each header contains journal lines, and all lines must belong to a single ledger. This package supplies the reusable processing routines that the Journal Entry form, the Journal Import concurrent program, and various approval and tax validation workflows rely upon to enforce batch-level integrity.

Because a batch is the unit that is ultimately posted to the General Ledger, the package is central to maintaining the consistency of the journal posting flow. It abstracts the low-level insert, update, and locking operations against the batch tables so that callers do not need to embed that logic in every form or concurrent program.

Key Procedures and Functions

  • INSERT_ROW — Creates a new journal batch record, deriving the batch identifier and populating mandatory batch attributes.
  • UPDATE_ROW — Applies changes to an existing batch record, typically when the user saves a modified batch in the Journal Entry form.
  • DELETE_ROW — Removes a batch when it is purged or the user deletes an unposted batch.
  • LOCK_ROW — Obtains a concurrency lock on the batch so that simultaneous edits cannot corrupt the same record.
  • CHECK_UNIQUE — Validates that the batch name and related key values are unique within the appropriate context, preventing duplicate batches.
  • GET_UNIQUE_ID — Returns a new unique identifier for a batch being created.
  • POPULATE_FIELDS — Fills in derived or defaulted batch attributes before an insert or update so that all required columns are supplied consistently.
  • NEEDS_APPROVAL — Determines whether the batch requires journal approval before posting, based on the applicable approval rules.
  • NEEDS_TAX — Determines whether tax validation is required for the batch.
  • HAS_LINES — Tests whether the batch contains any journal lines, which governs whether certain maintenance or deletion operations are permitted.
  • ALL_STAT_HEADERS — Examines all headers belonging to the batch to confirm that their statuses are consistent, supporting batch-level status determination.
  • BC_LEDGER — Resolves the ledger associated with the batch, used extensively for validation and security checks.

Tables Accessed

The package operates directly on the GL journal schema, referencing the following objects through APPS synonyms:

  • GL_JE_BATCHES / GL_JE_BATCHES_S — the primary batch tables; the _S table stores translated descriptive columns such as batch name and description.
  • GL_JE_HEADERS — queried to evaluate header statuses and existence of headers within the batch.
  • GL_JE_LINES — queried by HAS_LINES to determine whether journal lines exist.
  • GL_JE_SOURCES — supplies the journal source (e.g., Manual, Payables) that drives validation and processing rules.
  • GL_LEDGERS — identifies the ledger to which the batch belongs and supports ledger-based validation.
  • DUAL — used for single-row calculations, such as generating unique identifiers.

The package also depends on GL_JE_HEADERS_PKG for header-level processing and on utilities such as FND_MESSAGE, FND_CONCURRENT, and APP_EXCEPTION/APP_EXCEPTIONS for messaging and error handling.

Usage Notes

Typical invocation occurs from the Journal Entry form and its underlying blocks, where INSERT_ROW, UPDATE_ROW, DELETE_ROW, and LOCK_ROW are called during the normal save-and-lock cycle. The Journal Import program and its post-import routines call the validation helpers (CHECK_UNIQUE, NEEDS_APPROVAL, NEEDS_TAX, and ALL_STAT_HEADERS) to determine whether an imported batch is ready for approval or posting. Custom code should invoke these public routines rather than executing DML against GL_JE_BATCHES directly, since the package enforces naming uniqueness, ledger association, and status consistency rules that are critical to downstream posting. Per the ETRM metadata, this package body is validated in 12.2.2, is classified as OTHER, and is not referenced by any other database object, making it a top-level API entry point for batch maintenance.