Search Results pa_perf_rules_n1

Overview

PA.PA_PERF_RULES is a transactional configuration table in the Oracle E-Business Suite Projects (PA) schema that stores the master definitions of performance rules used by the Performance Management and key performance area (KPA) framework. Each row defines a single reusable rule that evaluates measures such as cost, revenue, or schedule variance against thresholds and produces a score. The table is the authoritative catalogue from which performance objects, thresholds, and transactions draw their scoring logic, making it a foundational reference for project performance reporting and analytics.

From a dimensional modeling perspective, the mined dependency structure classifies PA_PERF_RULES as hub-leaning: it carries a stable surrogate identity (RULE_ID) that is referenced by multiple downstream fact-style tables, while its descriptive attributes (name, description, measure format, scoring method) behave like an attached satellite. This classification is offered as a heuristic suggestion rather than a documented EBS property, but it aligns well with the table's role as a durable business key registry surrounded by transaction-like dependents.

Key Information Stored

The physical schema in ETRM 12.2.2 documents nineteen columns. The most significant are:

• RULE_ID — NUMBER(15) surrogate primary key, enforced by unique index PA_PERF_RULES_U1. Every downstream KPA summary, threshold, and transaction row joins back through this column.
• RULE_NAME and RULE_TYPE — the composite business key, enforced by unique index PA_PERF_RULES_U2 (RULE_NAME, RULE_TYPE). This is the user-facing identifier that guarantees a rule name is unique within its type.
• RULE_DESCRIPTION — VARCHAR2(240) free-text explanation presented to end users.
• KPA_CODE — VARCHAR2(30) linking the rule to its key performance area.
• MEASURE_ID and MEASURE_FORMAT — identify the measure being evaluated and how it is rendered.
• SCORE_METHOD — VARCHAR2(30) with valid values MIN, MAX, and SUM, controlling how individual scores aggregate.
• CURRENCY_TYPE, PERIOD_TYPE (valid GL or PA), and PRECISION — govern currency handling, calendar basis, and numeric rounding.
• START_DATE_ACTIVE and END_DATE_ACTIVE — date-range enablement, allowing rules to be time-bounded.
• RECORD_VERSION_NUMBER — NUMBER(15) used for record locking in self-service applications.
• CREATION_DATE, CREATED_BY, LAST_UPDATE_DATE, LAST_UPDATED_BY, LAST_UPDATE_LOGIN — the standard WHO audit columns required for every EBS transactional table.

The unique index PA_PERF_RULES_N1 on RULE_TYPE supports queries that filter by rule category.

Common Use Cases and Queries

The primary use case is retrieving active rule definitions for a given KPA or rule type to drive performance dashboards. A typical query selects currently enabled rules:

• Reporting: SELECT RULE_ID, RULE_NAME, RULE_TYPE, KPA_CODE, SCORE_METHOD FROM PA.PA_PERF_RULES WHERE TRUNC(SYSDATE) BETWEEN START_DATE_ACTIVE AND NVL(END_DATE_ACTIVE, TRUNC(SYSDATE));
• Reconciliation of KPA results back to the owning rule by joining PA_PERF_KPA_SUMMARY_DET on RULE_ID.
• Configuration auditing: identify rules with overlapping name/type combinations or missing measure assignments before enabling them in self-service.
• Threshold analysis: join PA_PERF_THRESHOLDS on THRES_OBJ_ID to review the threshold bands attached to each rule.

Because the rule name/type pair is unique, integration loads should match on RULE_NAME and RULE_TYPE first, then resolve RULE_ID for dependent inserts.

Related Objects

Several documented foreign keys reference this table, and these are the most important dependents to consider:

• PA_PERF_KPA_SUMMARY_DET — references RULE_ID; holds summarized KPA scores per rule.
• PA_PERF_OBJECT_RULES — references RULE_ID; associates performance objects with the applicable rules.
• PA_PERF_THRESHOLDS — references THRES_OBJ_ID back to the rule; defines the threshold values applied during scoring.
• PA_PERF_TRANSACTIONS — references RULE_ID; stores the detailed performance transactions generated when rules execute.

Together these dependents form the operational perimeter of PA_PERF_RULES and must be considered in any purge, migration, or data-fix activity, since they inherit the rule's lifecycle and locking semantics.