Search Results insert_elim_history

Overview

The APPS.GL_ELIM_GEN_PKG package body supports the elimination generation process within Oracle General Ledger. Eliminations are the accounting entries that remove intercompany and intracompany balances so that consolidated financial statements do not double-count transactions between affiliated entities. This package provides the low-level primitives that the elimination engine relies upon: it caches the accounting period boundaries for the current elimination run, records the creation of an elimination run in the elimination history table, and persists the final state of that run after processing completes.

The package follows a session-state pattern. The SET_DATA procedure writes the period start and end dates into package-level variables, and the corresponding GET_PERIOD_START_DATE and GET_PERIOD_END_DATE functions expose those values to any other unit executing within the same database session. This avoids repeatedly querying period definitions while an elimination set is being processed. The remaining procedures handle the database-facing work of logging and finalizing elimination runs.

The header comment ($Header: glelgenb.pls 120.4 2005/05/05 ... kvora ship $) indicates the package body was last revised in the 11i/12.0 era and has carried forward essentially unchanged into 12.1.1 and 12.2.2. It is a stable, mature component of the General Ledger elimination toolset.

Key Procedures and Functions

• SET_DATA — Accepts a period start date and a period end date and stores them in package global variables (period_start_date and period_end_date). It performs no validation; it is a pure setter that establishes the working date range for the session.
• GET_PERIOD_START_DATE — Returns the cached period start date previously set by SET_DATA. Implemented as a function returning DATE.
• GET_PERIOD_END_DATE — Returns the cached period end date previously set by SET_DATA. Implemented as a function returning DATE.
• INSERT_ELIM_HISTORY — Creates a new row in GL_ELIMINATION_HISTORY for an elimination run. It locks the history table in share update mode, draws a new run identifier from the GL_ELIM_HISTORY_S sequence, and inserts the run with a status code of 'GS' (run started), along with the request ID, elimination set ID, ledger ID, period name, and the standard WHO audit columns populated from FND_PROFILE values. Errors are trapped: a predefined APP_EXCEPTIONS.APPLICATION_EXCEPTION is re-raised unchanged, while any other error raises the standard GL_UNHANDLED_EXCEPTION message with the procedure name as a token before propagating.
• SAVE_TO_ELIM_HIST — Documented as the fifth packaged unit; it commits the results of the elimination run back to the elimination history, marking the run as complete. (Only its signature presence is documented; behavior described at a high level.)

Tables Accessed

• GL_ELIMINATION_HISTORY — The primary audit table. INSERT_ELIM_HISTORY writes the initial run record here, and SAVE_TO_ELIM_HIST updates it upon completion.
• GL_ELIM_HISTORY_S — The sequence supplying elimination_run_id values via NEXTVAL, ensuring each elimination run receives a unique identifier.
• DUAL — Used as the source for selecting the next sequence value.

Usage Notes

This package is not intended for direct ad hoc invocation. It is driven by the General Ledger elimination concurrent program (typically the "Generate Eliminations" or consolidation elimination request) and by related PL/SQL units that pass the accounting period dates and request context into the session. The typical sequence is: call SET_DATA once per run to establish the period range, call INSERT_ELIM_HISTORY to log the start of the run with status 'GS', then—after the elimination journals are generated—call SAVE_TO_ELIM_HIST to finalize the history record.

Because the period dates are held in package globals, the state is scoped to the database session; concurrent runs must each execute in their own session, which the concurrent manager guarantees. The package is not referenced by any other documented package, so its contract is effectively private to the elimination generation flow within Oracle General Ledger. Custom code should not call SET_DATA or the insert/commit routines against a production ledger without first understanding the downstream consolidation dependencies, as the elimination history table feeds subsequent reporting and revaluation of intercompany balances.