Search Results kpa_name




Overview
Explore in AI Chat

Overview

APPS.PA_PERF_OBJECT_RULES_V is a non-supported, internal Oracle E-Business Suite view owned by the APPS schema. It exposes configuration data for performance rules that have been associated with specific project objects, such as projects, tasks, or resources, within the Oracle Projects performance reporting framework. The view joins the object-to-rule association table with the performance rule definition view to present a denormalized, human-readable record of each rule assignment, including the rule name, description, rule type, the Key Performance Area (KPA) to which the rule belongs, and the associated measure definition. Because of its denormalized structure, the view is convenient for reporting and diagnostic queries that would otherwise require multiple joins across the underlying base objects. Oracle Corporation explicitly marks this object as Internal Use Only and does not support direct data access except through standard Oracle Applications programs; any custom query or integration should therefore be treated as diagnostic or read-only and validated for forward compatibility.

Underlying Base Objects

Per the documented ETRM metadata for 12.2.2, the view is defined over two referenced objects: the synonym PA_PERF_OBJECT_RULES and the view PA_PERF_RULES_V. PA_PERF_OBJECT_RULES supplies the object-rule association rows, contributed through columns such as OBJECT_RULE_ID, OBJECT_TYPE, OBJECT_ID, and RULE_ID, which together establish the linkage between a performance rule and a specific project object instance. PA_PERF_RULES_V supplies the rule-level descriptive and structural attributes, including RULE_NAME, RULE_DESCRIPTION, RULE_TYPE, RULE_TYPE_NAME, KPA_CODE, KPA_NAME, MEASURE_ID, MEASURE_NAME, MEASURE_FORMAT, CURRENCY_TYPE, PERIOD_TYPE, PRECISION, and SCORE_METHOD. The view therefore functions as a consolidation layer that merges association metadata with rule definition metadata, allowing a single SELECT to resolve both the identity of the assigned rule and the full descriptive context of that rule, including its KPA and measure. Standard Who columns (CREATION_DATE, CREATED_BY, LAST_UPDATE_LOGIN, LAST_UPDATED_BY) are also exposed, and RECORD_VERSION_NUMBER supports optimistic record locking in self-service applications.

Key Columns

  • OBJECT_RULE_ID — Unique identifier of the rule-to-object association.
  • OBJECT_TYPE / OBJECT_ID — The type and unique identifier of the project object to which the rule is attached.
  • RULE_ID / RULE_NAME / RULE_DESCRIPTION — Identity and descriptive text of the assigned performance rule.
  • RULE_TYPE / RULE_TYPE_NAME — Internal code and display name for the rule classification.
  • KPA_CODE / KPA_NAME — The Key Performance Area code and its descriptive name; the column most commonly searched, since kpa_name is the business-facing label for the KPA.
  • MEASURE_ID / MEASURE_NAME / MEASURE_FORMAT — The measure referenced by the rule, its name, and its formatting characteristics.
  • CURRENCY_TYPE / PERIOD_TYPE / PRECISION — Currency handling, calendar source (GL or PA), and numeric precision for the measure.
  • START_DATE_ACTIVE / END_DATE_ACTIVE — Effective dating that determines when the rule association is active.
  • SCORE_METHOD — Method used to compute the rule score.

Common Use Cases and Queries

Typical diagnostic scenarios include identifying which rules are assigned to a given KPA, auditing rule-to-object associations for a project, and resolving a measure back to its owning rule and KPA. A representative query filtering on the KPA name is:

SELECT object_rule_id, object_type, object_id, rule_id, rule_name, kpa_code, kpa_name, measure_name, start_date_active, end_date_active
FROM apps.pa_perf_object_rules_v
WHERE kpa_name = :p_kpa_name
ORDER BY rule_name;

To inspect associations for a specific project object:

SELECT object_rule_id, rule_name, rule_type_name, kpa_name, measure_name
FROM apps.pa_perf_object_rules_v
WHERE object_type = :p_object_type
AND object_id = :p_object_id;

Because the object is internal and unsupported, these queries should be used only for troubleshooting or controlled reporting, and joins to supported APIs or extracts are preferable for production integrations.