Search Results bis_functional_areas_vl




Overview
Explore in AI Chat

Overview

BIS_FUNCTIONAL_AREAS_VL is an Oracle E-Business Suite view owned by the APPS schema and classified under the BIS (Applications BIS) product family. It is documented in ETRM for both 12.1.1 and 12.2.2 as a VALID database object of type VIEW. Its name follows the standard "_VL" (View with Language) convention used throughout the EBS data model, indicating that it exposes both the language-independent attributes of an entity and the language-dependent (translatable) attributes resolved through a Translation (_TL) table.

Functionally, the view presents the set of "functional areas" — the business groupings used by Oracle Business Intelligence and related EBS components (for example, in performance management, benchmarking, and Business Intelligence System administration) to categorize metrics, key performance indicators, and analytical content. Rather than storing descriptive text in a single base table, EBS separates the short code from the translatable name and description, and this view joins them on demand. As a result, the view is the natural reporting and integration source for any query that requires a functional area identifier together with its human-readable label in the session language.

Underlying Base Objects

Although the ETRM metadata entry lists no referenced base objects, the documented view text defines the view explicitly over two tables:

  • BIS_FUNCTIONAL_AREAS (aliased FA) — the language-independent base table, supplying the primary key and operational attributes.
  • BIS_FUNCTIONAL_AREAS_TL (aliased FA_TL) — the translation table, supplying the language-dependent NAME and DESCRIPTION columns for each row and each installed language.

The two tables are joined on FUNCTIONAL_AREA_ID, the entity's primary key, and the translation side is filtered by FA_TL.LANGUAGE = USERENV('LANG'). This means the view automatically projects the translation row matching the language of the current database session, defaulting to the runtime language established by the EBS session. Because the join is an equi-join with no outer join operator, only functional areas that possess a translation row for the session language are returned; functional areas missing a matching translation entry are suppressed from the result set.

The view therefore behaves as a localized, read-only presentation layer over the pair of tables, insulating report writers and integration components from the need to write the language-resolution join themselves.

Key Columns

The view text defines the following projected columns, all inherited from the two base tables:

  • FUNCTIONAL_AREA_ID — the surrogate primary key that uniquely identifies each functional area. Used as the join key to related BIS tables.
  • SHORT_NAME — a language-independent short identifier or code for the functional area, suitable for programmatic lookups and stable references.
  • NAME — the translated, display-ready name of the functional area in the session language, sourced from BIS_FUNCTIONAL_AREAS_TL.
  • DESCRIPTION — the translated long description of the functional area, also from the translation table.
  • CREATED_BY, CREATION_DATE — standard audit columns recording the creating user and creation timestamp of the base row.
  • LAST_UPDATED_BY, LAST_UPDATE_DATE, LAST_UPDATE_LOGIN — standard audit columns recording the most recent modification details, used for change tracking and audit reporting.

Caution should be exercised when consuming NAME and DESCRIPTION in integrations: these are language-sensitive values and may differ between sessions depending on USERENV('LANG'). Where a language-neutral key is required, SHORT_NAME or FUNCTIONAL_AREA_ID should be used instead.

Common Use Cases and Queries

The primary use case is presenting functional area metadata to end users and downstream systems in their own language. Typical scenarios include BI dashboards that display functional area labels, validation lists (LOVs) for filtering analytical content, and integration extracts that must carry descriptive text alongside identifiers.

A straightforward listing of functional areas in the session language:

  • SELECT functional_area_id, short_name, name, description FROM apps.bis_functional_areas_vl ORDER BY name;

Resolving a single functional area for a known key or code:

  • SELECT functional_area_id, name FROM apps.bis_functional_areas_vl WHERE short_name = :short_name;
  • SELECT name, description FROM apps.bis_functional_areas_vl WHERE functional_area_id = :id;

Joining the view to tables that reference FUNCTIONAL_AREA_ID, for example to enrich a metric or KPI report with a translated functional area label:

  • SELECT m.metric_name, fa.name AS functional_area FROM apps.bis_metrics m, apps.bis_functional_areas_vl fa WHERE m.functional_area_id = fa.functional_area_id;

Because the view is defined entirely with base-table columns and no aggregation, it is generally updatable through the translation table and is safe for use in read-only reporting. For multi-language extracts, querying BIS_FUNCTIONAL_AREAS_TL directly — with an explicit LANGUAGE predicate — is preferable to relying on the session language resolved by USERENV('LANG').