Search Results gl_entity_budgets_pkg




Overview
Explore in AI Chat

Overview

APPS.GL_ENTITY_BUDGETS_PKG is a server-side PL/SQL package in the Oracle E-Business Suite General Ledger module. Its declared purpose, as stated in the package header, is "to contain validation and insertion routines for gl_entity_budgets." The package is therefore a low-level data maintenance utility for the GL_ENTITY_BUDGETS table, the intersection table that associates budget versions with the budget organizations (entities) that own them.

The package is defined with AUTHID CURRENT_USER, meaning that its SQL statements execute with the privileges of the invoking session rather than the package owner. In EBS this is the conventional declaration for packages that must respect the invoker's access to APPS synonyms and ledger security context. The package resides in the APPS schema and was originally created in October 1993 (D. J. Ogg), with the shipped version carrying a header revision of 120.3 dated 2005/05/05. The API classification recorded in ETRM is OTHER, indicating it is not one of the formally publicized Open Interfaces but an internal supporting package. It is referenced by two other packages, confirming its role as a shared utility rather than an entry point invoked directly by end users.

Key Procedures and Functions

ETRM documents two procedures in the package specification. No parameter lists are reproduced here; the descriptions reflect documented purpose only.

  • INSERT_BUDGET — Inserts records into GL_ENTITY_BUDGETS for a new budget. It takes a budget version identifier, a ledger identifier, and the standard audit columns (last updated by and last update login) as its arguments. It is the routine invoked when a budget version must be registered against the entity-budget cross-reference. The historical comment in the source documents a sample call of the form insert_budget(1000, 2, 0, 0), supplying a budget version ID, a ledger ID, and zeroed audit values.
  • INSERT_ENTITY — Inserts records into GL_ENTITY_BUDGETS for a new budget organization. It accepts a budget entity identifier, a ledger identifier, and the same audit columns. It is the counterpart routine used when a budget organization is created and must be linked into the entity-budget relationship for the applicable ledger.

Both procedures are procedural (void) rather than functions; neither returns a value, so callers determine success by exception handling. The two procedures share an identical argument signature shape, distinguished only by whether the primary key supplied is a budget version or a budget entity.

Tables Accessed

The package operates against four documented tables, reached through APPS synonyms:

  • GL_ENTITY_BUDGETS — the target table for both insertion routines; holds the association between budget entities and budget versions.
  • GL_BUDGET_VERSIONS — the source of budget version identity validated by INSERT_BUDGET.
  • GL_BUDGET_ENTITIES — the source of budget organization identity validated by INSERT_ENTITY.
  • GL_BUDGETS — the parent budget definition, used to confirm that the version and entity belong to a valid, defined budget.

The "validation and insertion" purpose stated in the header implies that each procedure reads the relevant parent tables to confirm existence and ledger consistency before writing the GL_ENTITY_BUDGETS row.

Usage Notes

Because the package is classified OTHER and is referenced by two other packages, it is normally called indirectly from higher-level GL budget and budget organization logic rather than from custom code. Typical invocation paths include the General Ledger budget entry and budget organization definition forms, and concurrent programs that create or copy budget versions and budget organizations, where the newly created identifier must be propagated into GL_ENTITY_BUDGETS.

Custom code should call these procedures only with valid, already-committed ledger, budget entity, and budget version identifiers, and should wrap calls in exception handlers since the procedures return no status. Supplying audit arguments of zero, as in the historical example, orphanes the row from proper audit tracking and should be avoided. As with all APPS-schema internals, the package signature is not a committed public interface and may change between releases; direct dependencies should be minimized and validated against the target release (12.1.1 or 12.2.2).