Search Results object_value_id

Overview

OKC_XPRT_RULE_OUTCOMES_ACT_V is a read-consistent reporting view owned by the APPS schema in Oracle E-Business Suite, delivered as part of the OKC – Contracts Core product family. Its purpose is to expose the set of active rule outcomes defined for the Oracle Contracts expert (XPRT) rules engine, consolidating records that govern how contract terms, clauses, and deviations are evaluated and applied during contract authoring and validation. Because the view is restricted to outcomes tied to rule headers whose status is ACTIVE, it presents the effective configuration currently driving contract behavior rather than the complete historical population of rule outcomes. In EBS 12.1.1 and 12.2.2, this view is commonly consumed by reporting layers, extensions, and integration interfaces that need to inspect the live rule outcome definitions without filtering the base tables themselves. The user-searched column MANDATORY_YN is exposed directly by this view and is a primary driver for consumers querying which outcomes are enforced versus optional.

Underlying Base Objects

The view is defined over three documented base objects, all referenced through APPS synonyms: OKC_XPRT_RULE_HDRS_ALL, OKC_XPRT_RULE_OUTCOMES, and OKC_XPRT_RULE_OUTCOMES_ACTIVE. Its view text is a UNION ALL of two SELECT statements. The first selects rule outcome rows from OKC_XPRT_RULE_OUTCOMES where the RULE_ID belongs to a rule header in OKC_XPRT_RULE_HDRS_ALL carrying STATUS_CODE = 'ACTIVE'. The second selects the same column list from OKC_XPRT_RULE_OUTCOMES_ACTIVE. The result is a combined result set in which active-outcome records from the standard table are merged with the rows held in the ACTIVE companion table. Both branches project an identical column list, so no column-level reconciliation is required by consumers. The dependency on OKC_XPRT_RULE_HDRS_ALL is solely through the correlated subquery on RULE_ID and STATUS_CODE; the outcome tables supply the substance of each row.

Key Columns

• RULE_OUTCOME_ID – Primary identifier for the rule outcome record.
• RULE_ID – Foreign key to the parent expert rule defined in OKC_XPRT_RULE_HDRS_ALL; the join predicate that scopes the view to active rules.
• OBJECT_TYPE – Classifies the object to which the outcome applies, enabling polymorphic rule targeting.
• OBJECT_VALUE_ID – Identifier of the specific object instance referenced by OBJECT_TYPE.
• OBJECT_VERSION_NUMBER – Optimistic locking / versioning column used by the XPRT framework to detect concurrent modifications.
• MANDATORY_YN – Flag indicating whether the rule outcome is mandatory. This is the column most frequently searched by implementers auditing which outcomes are enforced rather than advisory.
• MANDATORY_RWA – Companion attribute controlling mandatory behavior in the context of the rules workbench / rule authoring (RWA) semantics.
• CREATED_BY, CREATION_DATE, LAST_UPDATED_BY, LAST_UPDATE_DATE, LAST_UPDATE_LOGIN – Standard EBS WHO columns providing audit lineage for each outcome record.

Common Use Cases and Queries

Typical consumption includes auditing mandatory outcomes, validating rule configuration after a patch or migration, and feeding integration extracts that must reflect only active rules. A representative query retrieving all mandatory active outcomes is:

• SELECT rule_outcome_id, rule_id, object_type, object_value_id, mandatory_yn, mandatory_rwa FROM apps.okc_xprt_rule_outcomes_act_v WHERE mandatory_yn = 'Y';

To count outcomes per parent rule:

• SELECT rule_id, COUNT(*) FROM apps.okc_xprt_rule_outcomes_act_v GROUP BY rule_id ORDER BY 2 DESC;

To review recently modified configuration, filter on the audit columns:

• SELECT rule_outcome_id, rule_id, mandatory_yn, last_updated_by, last_update_date FROM apps.okc_xprt_rule_outcomes_act_v WHERE last_update_date > SYSDATE - 30;

Because the view performs no aggregation and applies only an active-status restriction, it is safe for direct querying and joins to OKC_XPRT_RULE_HDRS_ALL on RULE_ID. It should not be used as a DML target, and downstream logic must not assume uniqueness of RULE_OUTCOME_ID across the two UNION ALL branches without verification.