Search Results jl_zz_gl_axi_tmp




Overview

JL_ZZ_GL_AXI_TMP is a temporary staging table owned by the JL schema, the database account that supports the Latin America Localizations product family in Oracle E-Business Suite (EBS) 12.1.1 and 12.2.2. The table exists to hold intermediate, run-scoped data produced and consumed by the Inflation Adjustment Report, a statutory reporting process used in Latin American countries to restate accounting balances for inflation and to compute the resulting adjustment amounts. Because the object is documented as a temporary table rather than a permanent transactional entity, the rows it stores are transient by design: they are populated during a report or adjustment run, used for the calculation and presentation of results, and purged or overwritten on subsequent runs.

From a modeling perspective, the metadata classifies this object heuristically as standalone under Data Vault conventions. Standing alone, with no documented foreign-key parents or children, it is best understood not as a hub, link, or satellite in the strict Data Vault sense, but as a transient working set. Were it modeled formally, the natural business key (run, period, and account combination) is already captured by the unique index documented below, which would serve as the candidate hub key; the balance and amount columns would function as satellite attributes tied to that key.

Key Information Stored

The table is documented with nine columns. Its surrogate identity and business-key candidates are defined as follows:

  • Primary Key — JL_ZZ_GL_AXI_TMP_PK: a composite key on PERIOD_FROM, CODE_COMBINATION_ID, and AXI_RUN_ID. The unique index JL_ZZ_GL_AXI_TMP_U1 covers the same three columns, confirming that this combination is the business-key candidate for the working set.
  • AXI_RUN_ID: identifies the specific inflation adjustment run; scoping every row to a run keeps concurrent or historical executions isolated.
  • PERIOD_FROM / PERIOD_TO: the accounting period range over which the balance is accumulated and adjusted.
  • CODE_COMBINATION_ID: the accounting flexfield combination (account) whose balances are being restated.
  • GROUP_ID: a grouping or batch identifier used to organize rows within the run.
  • YTD_BALANCE / PTD_BALANCE: the year-to-date and period-to-date balances for the account and period range.
  • ADJUSTMENT_AMOUNT: the computed inflation adjustment applied to the balance.
  • FV_FLAG: a flag indicating a status or validation condition relevant to the row's processing (for example, whether the figure has been finalized or verified).

Common Use Cases and Queries

Typical usage centers on reporting and diagnostics for a single adjustment run. To inspect the staged balances for a given run:

  • SELECT code_combination_id, period_from, period_to, ytd_balance, ptd_balance, adjustment_amount FROM jl_zz_gl_axi_tmp WHERE axi_run_id = :run_id;
  • SELECT SUM(adjustment_amount) FROM jl_zz_gl_axi_tmp WHERE axi_run_id = :run_id GROUP BY code_combination_id;
  • SELECT * FROM jl_zz_gl_axi_tmp WHERE fv_flag = 'Y' AND axi_run_id = :run_id;

These patterns support reconciliation of inflation-adjusted balances to the General Ledger, verification of run completeness by run id and group id, and troubleshooting of rows flagged by FV_FLAG.

Related Objects

Because the mined relationship data identifies this object as standalone, no foreign keys are documented. Related objects are therefore operational rather than referential, and joins are made on the documented key columns:

  • GL_CODE_COMBINATIONS — joined on CODE_COMBINATION_ID to resolve account descriptions.
  • GL_PERIODS / GL_LEDGERS — joined on the PERIOD_FROM and PERIOD_TO ranges for calendar context.
  • The Inflation Adjustment Report program and its concurrent process — the producer and primary consumer of rows keyed by AXI_RUN_ID.
  • GL_BALANCES — the conventional source of YTD and PTD figures compared against the staged values.

Administrators should confirm that run-scoped rows are purged between executions, since the temporary nature of the table assumes no permanent retention.