Search Results fa_lookups_b_u1

Overview

FA.FA_LOOKUPS_B is the base (non-translated) lookup value table for the Oracle Assets (FA) module in Oracle E-Business Suite 12.1.1 and 12.2.2. It stores the seeded and user-defined code values that drive fixed asset processing — depreciation methods, asset categories, prorate conventions, transaction types for mass additions, and similar reference lists captured under the standard Oracle lookups framework. It belongs to the Fixed Assets schema but its design follows the common Oracle Applications lookup pattern, where a companion _TL table (here FA_LOOKUPS_TL) holds the translated, display-oriented meaning columns while _B holds the language-independent code and control attributes.

From a modeling perspective, the mined relationship metadata classifies this object as satellite-leaning. In Data Vault terms, it behaves as a satellite attached to the lookup-type hub (FA_LOOKUP_TYPES_B), with LOOKUP_TYPE and LOOKUP_CODE acting as the composite business key that links values to their type context. This is a heuristic classification and should be treated as a modeling suggestion rather than a physical constraint enforced by the database via an explicit hub table.

Key Information Stored

The table is composed of 27 documented columns. The most significant are:

• LOOKUP_TYPE and LOOKUP_CODE — the composite business key. Together they form the primary key FA_LOOKUPS_B_PK and are also the leading columns of the unique index FA_LOOKUPS_B_U1 (with ZD_EDITION_NAME appended in the 12.2.2 documented schema).
• ENABLED_FLAG — indicates whether the lookup value is active and selectable in application list-of-values.
• START_DATE_ACTIVE / END_DATE_ACTIVE — effective dating that governs when the value is valid for transactional use.
• ATTRIBUTE1 through ATTRIBUTE15 — 150-character descriptive flexfield segments carrying module-specific supplemental data.
• ATTRIBUTE_CATEGORY_CODE — selects the descriptive flexfield structure context for the attribute columns.
• CREATED_BY, CREATION_DATE, LAST_UPDATED_BY, LAST_UPDATE_DATE, LAST_UPDATE_LOGIN — the standard Who columns used for audit and concurrency tracking.
• ZD_EDITION_NAME — the editioning column present in the 12.2.2 documented schema, supporting the Online Patching (AD_ZD) editioning model for cross-edition read consistency.

A secondary nonunique index, FA_LOOKUPS_B_N1, exists on LOOKUP_CODE for reverse lookups. Both indexes reside in APPS_TS_SEED, consistent with the table's role as seeded setup data.

Common Use Cases and Queries

This table is queried primarily to resolve code values, to drive list-of-values, and to build validation and reporting joins. Typical patterns include:

• Enumerating active values for a given lookup type, typically joined with FA_LOOKUPS_TL to obtain display translations:

  SELECT b.LOOKUP_CODE, t.MEANING, b.ENABLED_FLAG
  FROM   FA.FA_LOOKUPS_B b, FA.FA_LOOKUPS_TL t
  WHERE  b.LOOKUP_TYPE = t.LOOKUP_TYPE
  AND    b.LOOKUP_CODE = t.LOOKUP_CODE
  AND    b.LOOKUP_TYPE = :p_type
  AND    b.ENABLED_FLAG = 'Y';

• Effective dating checks via START_DATE_ACTIVE and END_DATE_ACTIVE to validate that a lookup value was in force at a transaction date.
• Audit and setup reconciliation reports comparing seeded values against user-defined additions, filtered on the Who columns.
• Referential integrity checks against FA_LOOKUP_TYPES_B to detect orphaned values whose parent type has been disabled.

Related Objects

• FA.FA_LOOKUPS_TL — the translated table holding MEANING and DESCRIPTION, joined on LOOKUP_TYPE and LOOKUP_CODE.
• FA.FA_LOOKUP_TYPES_B — the parent type table; FA_LOOKUPS_B.LOOKUP_TYPE references it via the documented foreign key.
• FA.FA_LOOKUP_TYPES_TL — translated type names used for UI display alongside lookup values.
• FA.FA_ADDITIONS and FA.FA_MASS_ADDITIONS — asset transaction tables that reference lookup codes for transaction and source types.
• FA.FA_DEPRECIATION — references lookup codes for depreciation-related conventions.
• APPS.FA_LOOKUPS_B — the APPS-layer synonym through which application code and concurrent programs access the table.

Because translations and meaning text live in the _TL companion, any reporting query requiring human-readable values should join to FA_LOOKUPS_TL rather than reading the base table alone.