Search Results user_message




Overview

OE_PC_CONSTRAINT_CNDS_V is an APPS-owned view in the Oracle E-Business Suite Order Management (ONT) module that exposes the condition rows belonging to processing constraints. Processing constraints are the configurable rules that govern which order and line attributes may be changed, and under what circumstances, once an order or return has been entered. Each constraint carries one or more conditions that determine when the constraint fires — for example, a specific order type, line type, or workflow activity — together with the validation entity, validation template, and record set against which the condition is evaluated.

The view denormalizes the raw condition table by joining it to its translation, entity, record set, and validation template sources, so that a condition is presented with human-readable display names rather than internal identifiers. This makes OE_PC_CONSTRAINT_CNDS_V particularly well suited to reporting on constraint configuration, validating a setup after a clone or migration, and as a data source for integration or diagnostic queries that must resolve a VALIDATION_ENTITY_ID to a meaningful label such as VALIDATION_ENTITY_DISPLAY_NAME. The view is classified as VALID, and it is a reporting projection only; it holds no storage of its own and inherits the DML characteristics of the base tables it joins.

Underlying Base Objects

In ETRM 12.2.2 the view is documented over five referenced base objects:

The joins are performed on CONDITION_ID, VALIDATION_ENTITY_ID, VALIDATION_TMPLT_ID, and RECORD_SET_ID. The translation join restricts to the session language via USERENV('LANG'), so the returned USER_MESSAGE is the message localized for the current user.

Key Columns

  • ROW_ID — the rowid of the underlying condition row, useful for direct retrieval or diagnostics.
  • CONDITION_ID / CONSTRAINT_ID — the condition primary key and the parent constraint to which it belongs.
  • GROUP_NUMBER — groups conditions that are evaluated together for a constraint.
  • VALIDATION_APPLICATION_ID, VALIDATION_ENTITY_ID, VALIDATION_ENTITY_DISPLAY_NAME — the entity (for example, an order header or line) against which the condition is validated, with its display label.
  • VALIDATION_TMPLT_ID, VALIDATION_TMPLT_DISPLAY_NAME — the validation template applied to the entity.
  • RECORD_SET_ID, RECORD_SET_DISPLAY_NAME — the record set that scopes the validation.
  • SCOPE_OP — the scope operator that combines conditions within a group.
  • USER_MESSAGE — the localized message shown when the constraint is violated.
  • START_DATE_ACTIVE / END_DATE_ACTIVE and ENABLED_FLAG — effective dating and enablement status.
  • SYSTEM_FLAG and MODIFIER_FLAG — identify seeded system constraints and whether the condition acts as a modifier.
  • ATTRIBUTE_CATEGORY through ATTRIBUTE15 — descriptive flexfield context and segment values associated with the condition.

Common Use Cases and Queries

Typical uses include auditing which conditions are attached to each constraint, verifying that localized user messages exist for a given language, and tracing why a particular field is protected on an order. The display-name columns remove the need to join to the entity, template, and record set views separately.

Listing active conditions for a constraint:

  • SELECT constraint_id, group_number, validation_entity_display_name, validation_tmplt_display_name, record_set_display_name, scope_op, enabled_flag FROM oe_pc_constraint_cnds_v WHERE constraint_id = :p_constraint_id AND enabled_flag = 'Y' ORDER BY group_number;

Searching by the display name a user searched for:

  • SELECT constraint_id, condition_id, validation_entity_display_name, user_message FROM oe_pc_constraint_cnds_v WHERE validation_entity_display_name = :p_entity_name ORDER BY constraint_id, group_number;

Reviewing message localization and effective dates:

  • SELECT c.constraint_id, c.user_message, c.start_date_active, c.end_date_active FROM oe_pc_constraint_cnds_v c WHERE c.end_date_active IS NULL OR c.end_date_active > SYSDATE;

Because the translation join is language-dependent, queries executed under different session languages may return different USER_MESSAGE values; all other columns remain consistent. These queries are read-only and should be executed with the APPS schema or an equivalent responsibility that has been granted access to the view.