Search Results delete_batch

Overview

The APPS.GL_IMPORT_REFERENCES_PKG package body is a maintenance utility within the Oracle General Ledger module of Oracle E-Business Suite (validated against 12.1.1 and 12.2.2). Its business function is to preserve referential integrity between the journal entry tables and the GL_IMPORT_REFERENCES table, which stores the cross-reference between imported subledger transactions and the journal lines they generated in General Ledger. When journal batches, headers, or lines are deleted from the GL_JE_* tables, any surviving import reference rows would become orphaned, potentially breaking drill-down from General Ledger back to the originating subledger transaction. This package provides the cleanup logic that removes those stale import reference records. The header comment ($Header: gliimrfb.pls 120.2 2005/05/05 ...) indicates the object dates from the 11i era and remained stable through the 12.x releases, and ETRM classifies it as an "OTHER" API rather than a public, externally supported interface.

Key Procedures and Functions

Four procedures are documented, all of which perform deletions from GL_IMPORT_REFERENCES:

• DELETE_LINE — Removes the import reference row corresponding to a single journal line. It is invoked when an individual line is deleted from JE_LINES, scoped by journal header identifier and line number.
• DELETE_LINES — Removes all import reference rows belonging to a journal header, used when the entire set of lines for a header is deleted.
• DELETE_HEADER — Removes all import reference rows for a journal header when that header is deleted from GL_JE_HEADERS.
• DELETE_BATCH — The procedure targeted by the user's search. It removes all import reference rows associated with every journal header in a deleted batch. Rather than filtering directly on a batch column, it deletes rows whose JE_HEADER_ID appears in a subquery against GL_JE_HEADERS for the supplied batch identifier, thereby covering all headers that belonged to the batch in a single statement. This is the broadest of the four cleanup operations.

Each procedure declares a NO_DATA_FOUND exception handler that simply returns null. Because DELETE statements do not raise NO_DATA_FOUND when zero rows match, the handler is effectively inert; the procedures treat a no-match deletion as a benign no-op.

Tables Accessed

• GL_IMPORT_REFERENCES — The sole write target. All four procedures issue DELETE statements against this table, filtered by JE_HEADER_ID and optionally JE_LINE_NUM.
• GL_JE_HEADERS — Read only, and only within DELETE_BATCH. The subquery resolves the set of header identifiers belonging to the batch being purged, allowing the delete to cascade from batch to header to import reference without the caller having to enumerate headers.

Both objects are accessed through APPS synonyms, consistent with the package's ownership by the APPS schema.

Usage Notes

The package is a supporting dependency rather than an entry point. ETRM records that it is referenced by two other packages, which is consistent with its role as a called helper from the journal deletion or purge logic in General Ledger. Typical invocation paths include the Journal Entry form and related batch deletion or purge concurrent programs, where the calling code first removes rows from the journal tables and then calls the appropriate DELETE_* procedure to synchronize GL_IMPORT_REFERENCES. Custom code that deletes journal batches or headers directly should call DELETE_BATCH, DELETE_HEADER, or DELETE_LINE as appropriate to avoid orphaned import references. Because all procedures are transactional and uncommitted, the caller controls the commit boundary, and the deletions participate in the same transaction as the journal deletion they accompany.