Search Results fnd_id_flex_structures_v




Overview
Explore in AI Chat

Overview

FND_ID_FLEX_STRUCTURES_V is an Oracle E-Business Suite view owned by the APPS schema within the FND — Application Object Library product. It presents a list of existing key flexfield structures, exposing the identifying attributes that define each structure registered against an application and a key flexfield code. In Oracle EBS 12.1.1 and 12.2.2, key flexfield structures form the backbone of several core features — the Accounting Flexfield (GL), the Key Flexfields used by Oracle Assets, Oracle Inventory item categories, and others — and this view provides a stable, read-only reporting surface over that metadata.

Because the view is a thin projection over the structure definition table set, it is safe and inexpensive to query from reports, discovery scripts, and integration extracts that need to enumerate structures without touching the wider, more complex flexfield definition model. It is especially useful when an integration must determine which structures are enabled before mapping segments or building cross-references.

Underlying Base Objects

The documented view text is:

Accordingly, the sole documented referenced base object is FND_ID_FLEX_STRUCTURES_VL, which is itself a view. The _VL suffix denotes a "view with language," indicating that underlying translations are resolved and that the descriptive name column returned is presented in the session's current language. The FND_ID_FLEX_STRUCTURES_V view therefore does not perform joins of its own; its behavior and any enabled/translated filtering are inherited from the VL view and, ultimately, from the base FND_ID_FLEX_STRUCTURES table. This layering is characteristic of FND metadata objects, where base tables, translated (_TL) tables, VL views, and consumer-facing views are stacked to isolate callers from translation logic.

Key Columns

  • APPLICATION_ID — The application owning the key flexfield definition. Joins to FND_APPLICATION for the application short name and description.
  • ID_FLEX_CODE — The key flexfield code identifying the flexfield itself (for example, GL# for the Accounting Flexfield, or the applicable code for other key flexfields).
  • ID_FLEX_NUM — The structure number, which uniquely identifies a structure within a given application and flexfield code. This is the value referenced by segments, combinations, and structure-specific setups.
  • ID_FLEX_STRUCTURE_NAME — The descriptive, user-visible structure name, generally resolved in the language of the querying session through the underlying VL view.
  • ENABLED_FLAG — Indicates whether the structure is currently active (typically Y for enabled, N for disabled). Structures that are disabled are generally excluded from transactional use and should be filtered out of most point-in-time reporting.

The composite key of APPLICATION_ID, ID_FLEX_CODE, and ID_FLEX_NUM is the practical identifying tuple for a structure.

Common Use Cases and Queries

The view is commonly used to enumerate available key flexfield structures during implementation validation, to resolve structure numbers to descriptive names in extracts, and to confirm that a referenced structure is enabled before downstream processing. A basic listing of enabled structures:

SELECT application_id, id_flex_code, id_flex_num,
       id_flex_structure_name, enabled_flag
  FROM fnd_id_flex_structures_v
 WHERE enabled_flag = 'Y'
 ORDER BY application_id, id_flex_code, id_flex_num;

To isolate the Accounting Flexfield structures, filter on the flexfield code:

SELECT id_flex_num, id_flex_structure_name, enabled_flag
  FROM fnd_id_flex_structures_v
 WHERE id_flex_code = 'GL#'
   AND enabled_flag = 'Y';

To obtain the owning application name alongside each structure, join to the application table:

SELECT fifs.id_flex_code, fifs.id_flex_num,
       fifs.id_flex_structure_name, fa.application_short_name
  FROM fnd_id_flex_structures_v fifs,
       fnd_application fa
 WHERE fifs.application_id = fa.application_id;

As the view exposes only metadata, it carries no transactional volume; queries remain lightweight and are appropriate for inclusion in concurrent reports, reconciliation scripts, and integration lookups across both 12.1.1 and 12.2.2.