Search Results validation_pkg

Overview

OE_PC_CONDITIONS_V is a seeded APPS view in the Oracle E-Business Suite Order Management (ONT) module. It exposes the processing constraint conditions defined through the Oracle Order Management constraint and validation framework, sometimes referred to as the Process Constraints or order processing constraints infrastructure. The view consolidates condition records with their parent constraint definition, the validation template applied, the record set used for filtering, and the entity metadata needed to resolve the runtime validation package and procedure. In effect, it presents the full runtime context for a constraint condition in a single row, rather than requiring downstream code to join several configuration tables. This makes it suitable for diagnostics, extension development, and reporting on how order attributes are validated during order entry and order maintenance. The "V" suffix confirms it is a view rather than a base table, and the object is owned by APPS with a VALID status.

Underlying Base Objects

The view is defined over five synonym-referenced base objects in the ONT schema. OE_PC_CONDITIONS supplies the primary condition rows and the record identifiers, group number, system and modifier flags, and the DFF attribute columns. OE_PC_CONSTRAINTS supplies the owning constraint and its ENTITY_ID. OE_PC_VTMPLTS supplies the validation template short name, validation type, API package, and API procedure. OE_PC_RSETS supplies the record set short name used to build the dynamic validation package name. Two references to OE_AK_OBJECTS_EXT alias the entity registry: one as E for the constrained entity and one as VE for the validation entity, exposing the APPLICATION_ID and ENTITY_CODE for each. The view joins on CONSTRAINT_ID, ENTITY_ID, VALIDATION_ENTITY_ID, VALIDATION_TMPLT_ID, and RECORD_SET_ID. Because several condition sub-attributes (for example VALIDATION_ENTITY_ID and VALIDATION_TMPLT_ID) may be null, the effective join semantics depend on how each condition is configured in the framework.

Key Columns

• CONDITION_ID / CONSTRAINT_ID: Primary identifiers linking the condition to its parent constraint.
• APPLICATION_ID / ENTITY_ID / ENTITY_SHORT_NAME: The application and entity against which the constraint is registered (from OE_AK_OBJECTS_EXT alias E).
• VALIDATION_APPLICATION_ID: The application owning the validation entity, sourced from VE.APPLICATION_ID. This is the column users typically search for when tracing which application defines the validation logic. It is distinct from APPLICATION_ID, which belongs to the constrained entity.
• VALIDATION_ENTITY_ID / VALIDATION_ENTITY_SHORT_NAME: The entity used for validation, and its short code.
• VALIDATION_TMPLT_ID / VALIDATION_TMPLT_SHORT_NAME: The validation template and its short name.
• VALIDATION_PKG / VALIDATION_PROC: Derived columns resolved via DECODE on the template's VALIDATION_TYPE. When the type is 'API', the template's API_PKG and API_PROC are used; otherwise the package name is constructed from the entity IDs, record set short name, and template short name, and the procedure defaults to IS_VALID.
• RECORD_SET_ID / RECORD_SET_SHORT_NAME: The record set that scopes the validation.
• SCOPE_OP: The scope operator controlling how multiple conditions combine.
• SYSTEM_FLAG / MODIFIER_FLAG / ENABLED_FLAG: Seeded-versus-user flags, modifier status, and enablement.
• ATTRIBUTE_CATEGORY and ATTRIBUTE1–15: Descriptive flexfield context and segments.
• ROW_ID, audit columns (CREATION_DATE, CREATED_BY, LAST_UPDATE_DATE, LAST_UPDATED_BY, LAST_UPDATE_LOGIN): Standard WHO and row locator information.

Common Use Cases and Queries

Typical uses include identifying which validation package executes for a given order entity, auditing enabled constraints for an entity, and supporting extension development that must understand the seeded validation logic before adding custom constraints.

• Trace validation logic by application: SELECT condition_id, constraint_id, validation_application_id, validation_entity_short_name, validation_tmplt_short_name, validation_pkg, validation_proc FROM oe_pc_conditions_v WHERE validation_application_id = :app_id;
• List enabled conditions for an entity: SELECT condition_id, entity_short_name, system_flag, validation_tmplt_short_name FROM oe_pc_conditions_v WHERE entity_short_name = :entity AND enabled_flag = 'Y';
• Inspect resolved validation programs: SELECT condition_id, validation_pkg, validation_proc, record_set_short_name FROM oe_pc_conditions_v WHERE constraint_id = :constraint_id;

Because the view exposes base tables without filtering, queries should generally include CONSTRAINT_ID, ENTITY_ID, or VALIDATION_APPLICATION_ID predicates to keep result sets manageable in production environments.