Search Results pa_verification_rules_pk




Overview

PA_VERIFICATION_RULES is a reference and setup table within the Oracle Projects (PA) schema of Oracle E-Business Suite. It stores the definitions of verification rules that control how project-related transactions are validated, and associates each rule with the calling process that invokes it. The ETRM metadata documents the object as "10SC Only," indicating that its functional relevance is historically tied to a specific localization or regional implementation scope rather than to a broad global feature set. In practice the table functions as a configuration-driven lookup: each row defines a rule, a human-readable meaning and description, a flag indicating whether the rule is predefined by Oracle, the calling process that triggers the rule, and the name of the PL/SQL procedure that implements the check.

The heuristic Data Vault classification supplied in the metadata is standalone, meaning the entity participates in no documented foreign-key relationships to other tables and is modelled most naturally as an independent reference set. Where an integration or warehouse modelling effort requires it, this suggests treating PA_VERIFICATION_RULES as a small reference table (effectively a hub of rule identifiers) rather than as a dependent satellite attached to a parent transaction entity.

Key Information Stored

The table contains eleven documented columns. The composite primary key, enforced through PA_VERIFICATION_RULES_PK, consists of VERIFICATION_RULE and CALLING_PROCESS. A second unique index, PA_VERIFICATION_RULES_U1, covers the same two columns, confirming them as the business-key candidates that uniquely identify a rule within a given calling context. Because the key is composite and meaningful rather than surrogate, callers must supply both values to resolve a single rule.

  • VERIFICATION_RULE — the identifier or code of the rule itself; part of the composite primary key.
  • CALLING_PROCESS — the process that invokes the rule; the second half of the composite primary key and the discriminator that allows the same rule concept to behave differently across entry points.
  • MEANING — the user-facing label for the rule, typically the value displayed in lookups and setup forms.
  • DESCRIPTION — the extended explanation of what the rule enforces.
  • PREDEFINED_FLAG — indicates whether the row is seeded by Oracle (predefined) or defined by the implementing organization; seeded rows generally should not be modified or deleted.
  • PROCEDURE_NAME — the name of the stored procedure that executes the verification logic, linking the configuration row to its implementation.
  • LAST_UPDATE_DATE, LAST_UPDATED_BY, CREATION_DATE, CREATED_BY, LAST_UPDATE_LOGIN — the standard EBS WHO columns providing audit and concurrency tracking for each row.

Common Use Cases and Queries

The principal use case is diagnostic: determining which rule fires for a given calling process and which procedure implements it. A typical query lists all rules associated with a calling process:

  • SELECT verification_rule, meaning, procedure_name, predefined_flag FROM pa.pa_verification_rules WHERE calling_process = :calling_process;
  • Resolving a single rule: SELECT * FROM pa.pa_verification_rules WHERE verification_rule = :rule AND calling_process = :process;
  • Separating seeded from custom configuration: SELECT verification_rule, calling_process, meaning FROM pa.pa_verification_rules WHERE predefined_flag = 'N';
  • Audit reporting on configuration changes, using LAST_UPDATE_DATE and LAST_UPDATED_BY to trace modifications since a given date.

Reporting scenarios include documenting the available verification rule set for an implementation, supporting upgrade impact analysis by identifying customer-defined rows, and troubleshooting validation failures by mapping an error back to its PROCEDURE_NAME.

Related Objects

The metadata records no foreign-key relationships for this table, and its heuristic classification is standalone, so no join columns to parent or child tables are documented. Dependencies are therefore logical rather than declarative: the PROCEDURE_NAME column points into the PA schema's PL/SQL package and procedure layer that executes each rule, and the CALLING_PROCESS values correspond to the Oracle Projects transaction and validation entry points that invoke those procedures. Related objects of interest include the PA schema packages implementing the verification procedures referenced by PROCEDURE_NAME, the Oracle Projects setup and lookup views that expose verification rules for maintenance, and the standard EBS lookup and concurrent program definitions that enumerate the calling processes. Because no FK constraints are documented, join keys must be inferred from the PROCEDURE_NAME and CALLING_PROCESS values rather than from a declared relationship.