Results for “condition_expr_code”

AI-generated from documented ETRM metadata — verify critical details on the linked pages.

Overview

OKC_XPRT_RULE_HDRS_ALL is a Contracts Core (OKC) table that stores the header-level definition of rules used by Oracle EBS Contracts expert (XPRT) processing. It holds rule header information for rules tied to specific contract templates as well as rules assigned globally across all templates within an operating unit. Each row represents one rule, identified by the surrogate primary key RULE_ID via the constraint OKC_XPRT_RULE_HDRS_ALL_PK.

Functionally, this table acts as the master registry for the expert rule engine: it defines a rule through its intent, type, conditions, and status, and then feeds downstream rule components such as conditions, outcomes, and template associations. It is heavily used during contract authoring and template application, where the system evaluates rules to drive clause selection, deviation handling, and terms behavior.

Under the heuristic Data Vault classification supplied in the metadata, this object is treated as a standalone structure. In modeling terms, this suggests it functions most naturally as a hub-like reference entity for rule identity, with downstream child tables (conditions, outcomes, template rules) acting as links or satellites that surround it. The classification is a modeling suggestion rather than a physical design statement.

Key Information Stored

The table exposes 22 columns. The most significant are summarized below.

• RULE_ID — The surrogate primary key (OKC_XPRT_RULE_HDRS_ALL_PK) uniquely identifying each rule header.
• ORG_ID — The operating unit that owns the rule; foreign key to HR_ALL_ORGANIZATION_UNITS.ORG_ID.
• RULE_NAME — The business name of the rule. Combined with ORG_ID, it forms the second unique business-key candidate (OKC_XPRT_RULE_HDRS_ALL_U2).
• RULE_DESCRIPTION — Free-text description of the rule's purpose.
• INTENT — The rule's intent or purpose category, guiding how it is applied during contract processing.
• RULE_TYPE — Classifies the rule (for example, template-specific versus broad behavior).
• STATUS_CODE — Lifecycle state of the rule (e.g., active/published versus draft).
• ORG_WIDE_FLAG — Indicates whether the rule applies to all templates in the operating unit rather than a single template.
• PUBLISHED_FLAG — Signals whether the rule has been released for use.
• LINE_LEVEL_FLAG — Indicates whether the rule operates at the contract line level.
• CONDITION_EXPR_CODE — Reference to the condition expression driving rule evaluation.
• ACTIVATION_DATE — The date the rule becomes effective.
• OBJECT_VERSION_NUMBER — Optimistic locking column supporting concurrent updates through the OAF/BC4J framework.
• CREATED_BY, CREATION_DATE, LAST_UPDATED_BY, LAST_UPDATE_DATE — Standard EBS audit columns.
• REQUEST_ID, PROGRAM_ID, PROGRAM_APPLICATION_ID, PROGRAM_UPDATE_DATE, LAST_UPDATE_LOGIN — Concurrent program and session context columns identifying the process that created or last modified the row.

The two documented unique indexes — U1 on RULE_ID and U2 on (ORG_ID, RULE_NAME) — distinguish the surrogate key from the natural business key.

Common Use Cases and Queries

Typical usage centers on reporting and troubleshooting the expert rule engine. A frequent pattern is listing all active rules for an operating unit:

• SELECT rule_id, rule_name, rule_type, status_code FROM okc_xprt_rule_hdrs_all WHERE org_id = :p_org_id AND status_code = 'ACTIVE';
• Joining to OKC_XPRT_TEMPLATE_RULES to enumerate rules attached to a given contract template.
• Joining to OKC_XPRT_RULE_CONDITIONS and OKC_XPRT_RULE_OUTCOMES to reconstruct full rule logic for audit or debugging.
• Identifying organizational-wide rules using ORG_WIDE_FLAG = 'Y'.
• Detecting duplicate or conflicting rule names by grouping on (ORG_ID, RULE_NAME).

Because the table is keyed by RULE_ID, most joins flow outward to the child rule component tables. Reports commonly filter by ORG_ID, STATUS_CODE, and PUBLISHED_FLAG to scope results to a specific operating unit and release state.

Related Objects

The documented foreign keys establish the following key relationships:

• HR_ALL_ORGANIZATION_UNITS — Joined via OKC_XPRT_RULE_HDRS_ALL.ORG_ID to resolve the owning operating unit.
• OKC_TERMS_DEVIATIONS_T — Referenced via RULE_ID; associates rules with terms deviations.
• OKC_XPRT_RULE_CONDITIONS — Referenced via RULE_ID; holds the condition components of each rule.
• OKC_XPRT_RULE_OUTCOMES — Referenced via RULE_ID; holds the outcome components that fire when conditions are met.
• OKC_XPRT_TEMPLATE_RULES — Referenced via RULE_ID; links rules to specific contract templates.

Together these child tables form the complete expert rule engine model, with OKC_XPRT_RULE_HDRS_ALL serving as the central header entity that conditions, outcomes, deviations, and template associations all reference through RULE_ID.