Search Results g_calling_module

Overview

GMF_ALLOC_PROC is the core allocation engine within the Oracle E-Business Suite Process Manufacturing (OPM) financials family. Its principal responsibility is to allocate expenses and costs across accounting entities according to user-defined allocation codes, bases, and methodologies. The package body is the executable implementation of the GMF_ALLOC_PROC specification, and it is classified by ETRM as an "OTHER" API, indicating it is not a published open interface but an internal procedural component invoked by OPM applications and concurrent processes.

The central entry point, COST_ALLOC_PROC, accepts a from-allocation code, a to-allocation code, and a refresh-interface flag, and returns exception information through the standard errbuf output parameter. The refresh flag controls whether the GL allocation interface table is rebuilt prior to processing (1) or left untouched (0), allowing callers to avoid redundant interface refreshes across repeated runs.

The package has evolved considerably since its early releases. The header comment block records changes spanning 1999 through 2008, including migration from FND_FLEX_VALUE to FND_FLEX_VALUES_VL, the removal of DBMS_OUTPUT calls, conversion to SUBSTRB/INSTRB for AOL standards, UTF-related fixes, and a significant performance redesign of the balance-retrieval logic that populates a temporary working table of code combinations rather than repeatedly querying the GL balances directly. The g_calling_module global variable, of interest to the searching user, is a package-level variable used to identify the invoking context so that behavior and trace output can be conditioned on the caller.

Key Procedures and Functions

• COST_ALLOC_PROC — The main driver procedure; orchestrates the entire allocation cycle and is the documented main call.
• DELETE_ALLOCATIONS — Removes existing allocation records for the allocation codes being reprocessed, preventing duplication.
• GET_LEGAL_ENTITY_DETAILS — Retrieves legal entity attributes required for determining the correct accounting context of an allocation.
• COST_ALLOCATE — Performs the core calculation that distributes cost amounts from the source allocation to the target allocation.
• GET_EXPENSES — Gathers the expense lines eligible for allocation.
• INSERT_ALLOC_INP — Writes allocation input rows into the interface/detail tables for subsequent processing.
• PUT_ALLOC_EXPENSES — Persists allocated expense results; noted historically for a change to the X_amount variable datatype.
• GET_ALLOC_BASIS — Resolves the allocation basis (the driver percentage or quantity) used to apportion costs.
• REFRESH_FIXED — Refreshes fixed or seeded allocation components.
• PROCESS_ALLOC_DTL — Processes individual allocation detail records, applying each detail rule.

Tables Accessed

The package reads and writes setup, interface, and result tables through APPS synonyms. Setup and master data include GL_ALOC_MST (allocation master definitions), GL_ALOC_BAS (allocation bases), CM_MTHD_MST (calculation methods), GMF_FISCAL_POLICIES and the CM_CLDR_HDR/CM_CLDR_DTL calendar tables for period determination, and FND_ID_FLEX_STRUCTURES for key flexfield structure metadata. Interface and working tables include GL_ALOC_INP, GL_ALOC_DTL, GL_ALOC_EXP, and the sequences GEM5_GL_ALOC_INP_ID_S and GEM5_ALLOCDTL_ID_S used for surrogate key generation. Concurrent program context is derived from FND_CONCURRENT_PROGRAMS, FND_CONCURRENT_REQUESTS, and FND_APPLICATION.

Usage Notes

GMF_ALLOC_PROC is typically invoked from OPM cost allocation concurrent programs and from application forms rather than from external custom code. ETRM records zero referring packages, confirming it functions as a terminal internal component. Developers embedding the package in custom logic should supply the three input parameters, observe the refresh-interface flag carefully to avoid unnecessary rebuilds, and rely on the g_calling_module global to trace which caller triggered a given run. Job control in 12.1.1 and 12.2.2 differs slightly, but the procedural interface remains stable.