Search Results item_generated_name




Overview

FF_FDI_USAGES_X is a date-effective (XF) view owned by the APPS schema in Oracle E-Business Suite, belonging to the FastFormula (FF) product family. It presents the currently active rows of the FastFormula flexfield item usage definition, exposing only those records whose effective date range encloses the current system date. The view is defined with a WHERE clause of TRUNC(SYSDATE) BETWEEN EFFECTIVE_START_DATE AND EFFECTIVE_END_DATE, so it behaves as a "today" snapshot rather than a full historical record.

Its role in EBS reporting and integration is to give applications, concurrent programs, and custom reports a convenient read path to the valid FastFormula usage metadata without requiring the caller to filter on effective dates. This is particularly important for the FastFormula engine itself, which must resolve formula items, data types, and context bindings at runtime according to the date on which processing occurs.

Underlying Base Objects

The view is defined over a single documented base object, FF_FDI_USAGES_F, referenced through a synonym. The "_F" suffix denotes the base (non-translated, non-date-effective-filtered) table that stores all effective-dated rows, including past, present, and future versions. FF_FDI_USAGES_X is the conventional date-effective view layered on top of it.

Because the view is a filtered projection rather than a join, its column list mirrors the base table exactly. It introduces no derived columns, aggregations, or outer joins; the only transformation is the TRUNC(SYSDATE) predicate applied to the effective date pair. This keeps the view inexpensive and suitable for use as an inline filter in larger formula-resolution queries.

Key Columns

  • FORMULA_ID — Surrogate identifier linking the usage row to its parent FastFormula definition in the FF_FORMULAS tables.
  • ITEM_NAME — Name of the formula item (variable or parameter) whose usage is being described.
  • EFFECTIVE_START_DATE / EFFECTIVE_END_DATE — The date-effectiveness bounds. The view exposes only rows where the current date falls between these values.
  • DATA_TYPE — Datatype of the item as understood by the FastFormula parser (for example, numeric, character, or date).
  • ITEM_GENERATED_NAME — Internally generated identifier for the item, used when the compiler must disambiguate names.
  • LOAD_WHEN_RUNNING — Flag indicating whether the item must be loaded/initialized at formula execution time.
  • USAGE — Classifies how the item is used within the formula (input, output, local, and similar categories).
  • CONTEXT_LEVEL_SUM — Numeric summary of context levels associated with the item, used in context-sensitive formula evaluation.
  • INDICATOR_VAR_NAME — Name of the indicator variable bound to the item where applicable.
  • GLOBAL_ID — The global identifier for the usage record; frequently the column of interest when tracing a formula item across environments or integration payloads, since the user search term "global_id" maps directly to this column.
  • CONTEXT_ID — Foreign reference to the context definition that governs the item's availability.

Common Use Cases and Queries

The most frequent scenario is resolving the set of items a formula currently expects, or tracing a specific global identifier back to its formula and usage metadata. A representative query follows.

SELECT formula_id,
       item_name,
       data_type,
       usage,
       global_id,
       context_id
FROM   apps.ff_fdi_usages_x
WHERE  formula_id = :p_formula_id
ORDER  BY item_name;

To locate a usage row by its global identifier — the case implied by the search term — the query narrows on GLOBAL_ID directly:

SELECT formula_id, item_name, data_type, usage
FROM   apps.ff_fdi_usages_x
WHERE  global_id = :p_global_id;

Integration and migration routines compare the currently effective usage definitions across instances by selecting GLOBAL_ID, ITEM_NAME, and USAGE, then reconciling differences. Because the view returns only the active version, historical comparisons against FF_FDI_USAGES_F must be performed on the base table instead. Reports that must respect a business date other than the system date should also query the "_F" table and supply an explicit effective-date predicate.