Search Results pji_mt_measures_vl




Overview
Explore in AI Chat

Overview

PJI_MT_MEASURES_VL is a seeded, read-only view owned by the APPS schema in Oracle E-Business Suite, delivered as part of the PJI (Project Intelligence) product family. As its name implies, the _VL suffix denotes a "view with language" — a translated view that joins a base ("_B") table with its translation ("_TL") table and filters the translation rows by the session's language. In this case, the view materializes the definition of the measures used for reporting within Oracle Projects.

Project Intelligence relies on "measures" as the logical metrics exposed to analytical reporting and dashboards. Each measure carries a code, a measure set, an execution type, and a PL/SQL API reference that governs how the measure's data is computed or retrieved. Because measure names and descriptions must be presented in the user's preferred language, the base definition table is paired with a translation table; the view resolves the appropriate translation at query time. This makes PJI_MT_MEASURES_VL the practical access path for any code or report that needs to display measure metadata in a human-readable, localized form.

Underlying Base Objects

The documented view text is defined over two synonyms in the APPS schema:

  • PJI_MT_MEASURES_B — the base (language-independent) table holding structural measure attributes such as the measure identifier, set code, measure code, execution type, and the PL/SQL API reference.
  • PJI_MT_MEASURES_TL — the translation table holding the language-specific NAME and DESCRIPTION for each measure, keyed by MEASURE_ID and LANGUAGE.

The join is a straightforward equijoin on MEASURE_ID, with the translation side restricted by LANGUAGE = USERENV('LANG'). This ensures that only the row matching the current runtime language of the user's session is returned, effectively producing one row per measure. The view text also selects B.ROWID as ROW_ID, a convention frequently used by Oracle Forms-based maintenance screens to identify the underlying base row for update processing.

Key Columns

The view exposes thirteen columns drawn from the two base objects:

  • ROW_ID — the base table ROWID, used programmatically to reference the source record.
  • MEASURE_ID — the primary identifier for the measure; the join key linking base and translation records.
  • MEASURE_SET_CODE — identifies the measure set or grouping to which the measure belongs.
  • MEASURE_CODE — the internal, language-independent code for the measure.
  • XTD_TYPE — the execution/extension type describing how the measure is evaluated.
  • PL_SQL_API — the PL/SQL API invoked to compute or retrieve the measure's values.
  • CREATION_DATE, LAST_UPDATE_DATE, LAST_UPDATED_BY, CREATED_BY, LAST_UPDATE_LOGIN — standard WHO audit columns inherited from the base table.
  • NAME — the translated, user-facing name of the measure (from PJI_MT_MEASURES_TL).
  • DESCRIPTION — the translated descriptive text for the measure (from PJI_MT_MEASURES_TL).

Common Use Cases and Queries

Typical consumers of this view include Project Intelligence reporting components, measure maintenance forms, and custom extracts that must present measure metadata in the user's language. A common pattern is to retrieve all measures for a given set for display or validation:

SELECT measure_id,
       measure_set_code,
       measure_code,
       name,
       description,
       xtd_type,
       pl_sql_api
FROM   apps.pji_mt_measures_vl
WHERE  measure_set_code = :p_measure_set
ORDER  BY name;

Because the view already filters on the session language, callers need not supply a language predicate. When resolving a measure by its internal code — for example, when translating an analytical column header — a lookup on MEASURE_CODE is sufficient:

SELECT name, description
FROM   apps.pji_mt_measures_vl
WHERE  measure_code = :p_measure_code;

Developers building custom dashboards or extending Project Intelligence often query this view to enumerate available measures and their associated PL_SQL_API references, enabling dynamic invocation of the correct computation logic. Standard EBS security applies: the view is queried under the APPS schema, and callers should respect the product's access and MOAC conventions where applicable.