Search Results insert_budget_transfer_row

Overview

APPS.GL_BC_PACKETS_PKG is a server-side PL/SQL package in the Oracle E-Business Suite General Ledger module that supports the Budgetary Control (funds check and funds reservation) process. Its documented purpose is to contain validation and insertion routines for the GL_BC_PACKETS table. When a journal batch is submitted for funds checking or funds reservation, the application must assemble the journal lines into a discrete "packet" that can be passed to the budgetary control engine and the results recorded. GL_BC_PACKETS_PKG encapsulates the identifier generation, packet assembly, existence checking, ledger resolution, and packet lifecycle management (copy and delete) logic required to perform that work consistently. The package has been present since the earliest releases of the product (header revision 120.6, dated 2005/07/29) and remains classified under Oracle's ETRM registry as an OTHER API, meaning it is an internal support package rather than a formally published public API. All objects are owned by the APPS schema and are normally invoked from within the EBS application runtime rather than by external callers.

Key Procedures and Functions

The ETRM 12.2.2 metadata documents eleven procedures and functions. GET_UNIQUE_ID returns a unique packet identifier used to key newly created packets. INSERT_JE_PACKET selects data from the journal line tables and inserts a complete packet into GL_BC_PACKETS, accepting a batch identifier, ledger identifier, a mode code distinguishing Reserve Funds from Check Funds, the user identifier, and session and serial identifiers, and returning the ID of the newly inserted packet. EXISTS_PACKET tests whether rows exist in GL_BC_PACKETS for a given packet ID and returns a Boolean. GET_LEDGER_ID resolves the ledger associated with the rows of a given packet.

A related group of routines manages budget transfer rows: INSERT_BUDGET_TRANSFER_ROW, UPDATE_BUDGET_TRANSFER_ROW, LOCK_BUDGET_TRANSFER_ROW, and DELETE_BUDGET_TRANSFER_ROW. These provide the insert, update, concurrency-locking, and removal operations for budget transfer records within the budgetary control packet structure. LOCK_BUDGET_TRANSFER_ROW is notable because it enforces serialization so that concurrent sessions do not modify the same transfer row simultaneously.

The procedure most relevant to the search term delete_packet is DELETE_PACKET, which removes a packet and its associated rows from the budgetary control packet tables, typically after the funds check or reservation has completed or when a batch is abandoned. COPY_PACKET duplicates an existing packet, and VIEW_BC_RESULTS_SETUP supports presentation of budgetary control results. Because external signatures are not reproduced in the metadata, callers should reference the package specification in the database rather than assume parameter lists.

Tables Accessed

The package references the following tables through APPS synonyms. GL_BC_PACKETS and GL_BC_PACKETS_S hold the packet header and its related packet data, and are the primary targets of insertion, copying, and deletion. GL_JE_BATCHES, GL_JE_HEADERS, and GL_JE_LINES are the journal sources from which packet contents are selected during INSERT_JE_PACKET. GL_PERIOD_STATUSES is consulted to determine the open or closed status of the accounting period associated with the journals being processed. PSA_BC_REPORT_EVENTS_GT and PSA_BC_XML_REPORT_S are used in support of budgetary control reporting and XML report output. DUAL is used for single-row computations and sequence-style value retrieval, notably in GET_UNIQUE_ID.

Usage Notes

GL_BC_PACKETS_PKG is invoked indirectly by the General Ledger budgetary control flow whenever journals are funds checked or reserved, including from the Journal Entry form and from concurrent programs that submit batches for budgetary control. The package is referenced by one other package in the ETRM registry, indicating that it is itself a supporting component of a higher-level budgetary control routine rather than an entry point. Custom code should treat DELETE_PACKET and the other routines as internal APIs: because the package is classified OTHER and its specification is subject to change between 12.1.1 and 12.2.2, direct invocation should be limited to scenarios where the standard budgetary control programs cannot be used, and the package specification should be reviewed in the target instance before any dependency is established.