Search Results flex_field_name




Overview

APPS.BIS_FLEX_FIELDS_V is a reporting view in the Oracle E-Business Suite (EBS) 12.1.1 and 12.2.2 releases that consolidates the master list of key and descriptive flexfields defined across the EBS application schema. The view is owned by the APPS schema and is defined as a UNION of two source queries, returning a unified catalogue of flexfield definitions keyed by application. Each row represents a single flexfield — either a Key Flexfield or a Descriptive Flexfield — and carries identifying attributes together with standard EBS audit columns.

The view is used by Oracle Business Intelligence (BIS) and related reporting components, and by custom reporting and integration logic that needs to enumerate or look up flexfields by name or code. Because the object name exposes the flex_field_name attribute, it is frequently queried by administrators and developers searching for the descriptive or key flexfield that sits behind a documented or configured field. It provides a single point of reference rather than requiring callers to query FND_ID_FLEXS and FND_DESCRIPTIVE_FLEXS_VL separately.

Underlying Base Objects

The view text is composed of two SELECT statements joined by UNION, both of which join to FND_APPLICATION_VL to resolve the application name and application_id.

  • FND_ID_FLEXS (referenced via synonym) — the definition table for Key Flexfields. Rows from this table supply the 'K' indicator in the flexfield type discriminator column. The columns ID_FLEX_CODE and ID_FLEX_NAME map to flex_field_code and flex_field_name respectively.
  • FND_DESCRIPTIVE_FLEXS_VL (view) — the descriptive flexfield definition view. Rows from this source supply the 'D' indicator. DESCRIPTIVE_FLEXFIELD_NAME maps to flex_field_code and TITLE maps to flex_field_name. Records whose DESCRIPTIVE_FLEXFIELD_NAME matches the pattern '$SRS$%' are explicitly excluded.
  • FND_APPLICATION_VL (view) — supplies APPLICATION_ID and APPLICATION_NAME, joined in both branches on the application_id foreign key.

Because the view is defined as a UNION rather than a UNION ALL, duplicate rows returned by the two branches would be collapsed; in practice the discriminating literal ('K','D') keeps key and descriptive rows distinct.

Key Columns

  • APPLICATION_ID — the numeric identifier of the owning application, joining to FND_APPLICATION_VL and, indirectly, FND_APPLICATIONS.
  • APPLICATION_NAME — the translated (VL) name of the owning application, resolved from FND_APPLICATION_VL.
  • FLEX_FIELD_CODE — the internal flexfield code: ID_FLEX_CODE for key flexfields, or DESCRIPTIVE_FLEXFIELD_NAME for descriptive flexfields.
  • FLEX_FIELD_NAME — the user-facing name: ID_FLEX_NAME for key flexfields, or TITLE for descriptive flexfields.
  • LAST_UPDATE_DATE, LAST_UPDATED_BY, LAST_UPDATE_LOGIN — standard EBS audit columns recording the most recent modification.
  • CREATED_BY, CREATION_DATE — standard EBS audit columns recording row creation.
  • Flexfield type literal ('K' or 'D') — an unnamed discriminator column (the trailing literal in each branch) indicating whether the row originates from a Key ('K') or Descriptive ('D') flexfield.

Common Use Cases and Queries

Typical usage involves enumerating all flexfields for an application, identifying the flexfield behind a given name, or feeding reporting metadata pipelines.

To list all flexfields for a specific application:

SELECT application_name, flex_field_code, flex_field_name
FROM   apps.bis_flex_fields_v
WHERE  application_id = :app_id
ORDER  BY flex_field_name;

To search for a flexfield by name:

SELECT application_name, flex_field_code, flex_field_name
FROM   apps.bis_flex_fields_v
WHERE  UPPER(flex_field_name) LIKE '%' || UPPER(:flex_field_name) || '%';

The view is also commonly joined to other flexfield metadata (such as FND_FLEX_VALUES or FND_SEGMENT_ATTRIBUTES) when building dynamic flexfield-driven reports. Because it depends on VL (translated) views for application and descriptive flexfield names, results reflect the session language; callers requiring base-language values should reference the underlying tables instead.