Results for “default_record”

AI-generated from documented ETRM metadata — verify critical details on the linked pages.

Overview

The JAI_RGM_LOOKUPS table is a reference data object owned by the JA schema (Asia/Pacific Localizations) within Oracle E-Business Suite 12.1.1 and 12.2.2. Its documented purpose is to store lookup values for regime, meaning it functions as the configuration substrate for the Regime Management functionality that supports country-specific statutory reporting, tax regimes, and regulatory compliance requirements across the Asia/Pacific region. The object is a standard transactional schema table with status VALID in the ETRM 12.2.2 physical model and contains 14 documented columns.

From a heuristic Data Vault modeling perspective, the object's FK structure classifies it as standalone, meaning it holds no dependent foreign key relationships to other business entities within the mined relationship graph. Rather than serving as a hub, link, or satellite, it behaves as an independent reference/lookup table whose business key is derived from the combination of LOOKUP_ID and ZD_EDITION_NAME. This standalone classification should be treated as a modeling suggestion rather than a functional constraint — the regime lookups are consumed contextually by localization processes rather than through declared referential integrity.

Key Information Stored

JAI_RGM_LOOKUPS captures the attribute-level configuration for each regime recognized by the Asia/Pacific Localizations. The most significant columns are:

• LOOKUP_ID — surrogate primary key of the table, uniquely identified by the JAI_RGM_LOOKUPS_PK constraint.
• REGIME_CODE — the identifier of the regime to which a lookup value belongs; the principal partitioning attribute.
• ATTRIBUTE_TYPE_CODE — categorizes the kind of lookup attribute (for example, regimes, thresholds, or document types).
• ATTRIBUTE_CODE — the specific coded attribute within the attribute type.
• ATTRIBUTE_VALUE — the coded value returned to consuming logic.
• DISPLAY_VALUE — the user-facing label presented in forms and reports.
• DEFAULT_RECORD — a flag indicating whether the row is the default selection for its attribute type.
• ZD_EDITION_NAME — the editioning column used by EBS online patching in Release 12.2; together with LOOKUP_ID it forms the unique business-key candidate JAI_RGM_LOOKUPS_PK.
• OBJECT_VERSION_NUMBER — the optimistic locking column used by the EBS framework.
• CREATED_BY, CREATION_DATE, LAST_UPDATED_BY, LAST_UPDATE_DATE, LAST_UPDATE_LOGIN — the standard WHO audit columns that record the identity and timestamp of the creating and last-updating users.

The distinction between the surrogate key (LOOKUP_ID) and the unique business-key candidate (LOOKUP_ID, ZD_EDITION_NAME) is important for integration and data-migration work: external systems should resolve lookups by REGIME_CODE plus ATTRIBUTE_TYPE_CODE and ATTRIBUTE_CODE, not by the surrogate identifier.

Common Use Cases and Queries

The table is consulted whenever localization logic must resolve a regime-specific value — for example, mapping a legal reporting entity to its applicable regime code during statutory report generation, or providing defaults for statutory document attributes.

A typical reporting query retrieves all active lookups for a given regime:

• SELECT ATTRIBUTE_TYPE_CODE, ATTRIBUTE_CODE, ATTRIBUTE_VALUE, DISPLAY_VALUE FROM JA.JAI_RGM_LOOKUPS WHERE REGIME_CODE = :p_regime AND DEFAULT_RECORD = 'Y' ORDER BY ATTRIBUTE_TYPE_CODE, ATTRIBUTE_CODE;

Integration and validation scenarios may use an equality check against the concat of type and code to resolve a display label, while upgrade or patch analysis queries compare ZD_EDITION_NAME across editions to identify rows added or superseded during an online patching cycle in 12.2. Data-migration audits frequently join to the WHO audit columns to trace when a lookup configuration was last changed by an administrator.

Related Objects

Because the ETRM metadata classifies JAI_RGM_LOOKUPS as standalone, no declared foreign keys link it to parent or child tables. Nonetheless, in practice the object is consumed by the Asia/Pacific Localization executables, concurrent programs, and report definitions that populate and read regime information. Its configuration values are typically referenced by application code rather than database-level constraints, so dependency analysis should focus on the localization programs and any customer-defined views that select from JA.JAI_RGM_LOOKUPS filtered by REGIME_CODE, ATTRIBUTE_TYPE_CODE, and ATTRIBUTE_CODE. Direct DML against the table should be avoided; regime lookup maintenance is expected to be performed through the supported Asia/Pacific Localizations setup windows, which honour the OBJECT_VERSION_NUMBER locking column and the editioning column during patching operations.