Search Results inflation_adjustment

Overview

The APPS.JL_ZZ_GL_INFL_ADJ_PKG package is a Latin America localization component for Oracle General Ledger, providing the core engine that performs inflation adjustment for Argentina. It calculates and posts the monetary correction entries required to restate historical balances into constant currency using a government-published price index. This functionality is essential in economies experiencing high inflation, where statutory reporting must reflect the loss of purchasing power on non-monetary assets, liabilities, and equity.

The package is classified as OTHER in the ETRM metadata, meaning it is an internal implementation package rather than a public or published API. It is not referenced by any other packages, and its principal entry point was designed to be called interactively from the Inflation Adjustment Report rather than submitted independently as a concurrent request, as reflected in the documented history note dated 20/08/97. The source header indicates the shipped version is 115.2, dated 21/11/2002, and the package is declared with AUTHID CURRENT_USER.

Key Procedures and Functions

The package exposes a single documented callable, INFLATION_ADJUSTMENT, defined as a function that returns a numeric status value.

• INFLATION_ADJUSTMENT — Performs the inflation adjustment for Argentina. Its documented parameters are the Inflation Run Id (the execution identifier for the adjustment run), the From Period and To Period (the first and last accounting periods to be adjusted), the Set of Books Id (the ledger being adjusted), the Index Id (the price index used to restate account balances), and a working Group Id. The function returns diagnostic output through three IN OUT parameters: an error message, an error message number, and an error message code, which are surfaced back to the calling report. The function's return value conveys the overall success or failure of the run.

No other procedures or functions are documented in the package specification; all processing described above is contained within the single inflation adjustment routine and its internal, private logic.

Tables Accessed

The package reads and writes a broad set of General Ledger and Fixed Assets tables through APPS synonyms. Documented references include:

• FA_PRICE_INDEX_VALUES — provides the index values used to compute the adjustment factors.
• GL_PERIODS and GL_PERIOD_STATUSES — define the adjustment period range and confirm period status prior to processing.
• GL_BALANCES — the primary source of balances being restated.
• GL_JE_HEADERS, GL_JE_LINES, GL_JE_CATEGORIES, and GL_JE_SOURCES — support creation of the inflation adjustment journal entries and their associated source and category definitions.
• GL_INTERFACE and GL_INTERFACE_CONTROL_S — used to stage and control the import of generated adjustment lines into the GL interface.
• FND_ID_FLEX_SEGMENTS — supplies the accounting flexfield segment structure needed to build valid account combinations.
• JL_ZZ_GL_AXI and JL_ZZ_GL_AXI_TMP — the Argentine localization tables that store inflation adjustment index definitions and temporary working data.
• DBMS_SQL — a dynamic SQL utility used internally, not a base table.

Usage Notes

Inflation adjustment is initiated through the Latin America General Ledger Inflation Adjustment Report (or equivalent concurrent program), which collects the run parameters and invokes INFLATION_ADJUSTMENT. Because the procedure was explicitly redesigned to be called from that report rather than submitted directly, administrators should invoke it through the standard report and not through a standalone concurrent request definition. The package is not published as a supported public API, and no other Oracle EBS packages reference it, so custom development that calls INFLATION_ADJUSTMENT directly must treat it as an unsupported internal interface and validate behavior against the target release (11.0 origin; shipped through 12.1.1 and 12.2.2). Error handling relies on the returned message, number, and code parameters, which must be checked by the caller after each execution. Typical prerequisites include an open, defined adjustment period range, a valid set of books, and a populated price index for the periods being processed.