Results for “task_owner_id”

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

Overview

OKC_CONDITION_HEADERS_B is the core definition table for contract conditions within the Oracle Contracts Core (OKC) module of Oracle E-Business Suite 12.1.1 and 12.2.2. A condition, in the Contracts terms model, represents a reusable business rule that governs when and how certain outcomes, deliverables, or obligations are triggered during the contract lifecycle. This table stores the header-level definition of each condition — its name, type, timing behavior, validity dates, and template status — while the granular detail of a condition is held in associated line, occurrence, outcome, and time-value tables that all reference this header through the CNH_ID column. Because conditions are a fundamental building block of Contract Terms and Conditions (T&C) authoring, OKC_CONDITION_HEADERS_B sits near the center of the OKC data model and is referenced heavily by both configuration and transactional processes.

From a Data Vault modeling perspective, the metadata's heuristic classification of this object is hub-leaning. This suggests it functions primarily as a business-entity hub that anchors a stable business key (the condition identifier) around which satellites of descriptive and temporal attributes, as well as links to related condition components, could be modeled. Analysts designing a downstream warehouse should treat the primary key and the unique business key as the hub identity and isolate the numerous descriptive and audit columns into one or more satellite structures.

Key Information Stored

The table contains 44 documented columns. The most significant for functional and reporting purposes include the following:

• ID — The surrogate primary key (OKC_CONDITION_HEADERS_B_PK). It uniquely identifies each condition header record and is the column referenced as CNH_ID throughout the OKC child tables.
• ZD_EDITION_NAME — Together with ID, this forms the unique index OKC_CONDITION_HEADERS_B_U1, which is the documented business-key candidate and reflects the edition-based redefinition support in 12.2.2.
• NAME — The user-facing name of the condition definition.
• CNH_TYPE — The condition type, distinguishing categories of condition behavior.
• BEFORE_AFTER — Indicates whether the condition is evaluated before or after a referenced event or action.
• ONE_TIME_YN, TRACKED_YN, CONDITION_VALID_YN, TEMPLATE_YN — Flags controlling one-time applicability, tracking behavior, validity, and whether the record serves as a reusable template.
• ACN_ID — Foreign key to OKC_ACTIONS_B, linking the condition to the action that drives it.
• OBJECT_ID, JTOT_OBJECT_CODE — Identify the owning business object and its JTOT (Janus Totals / object type) code for polymorphic association.
• DATE_ACTIVE, DATE_INACTIVE — Effective dating for the condition definition.
• DNZ_CHR_ID — Associates the condition header with a contract document.
• SECURITY_GROUP_ID, APPLICATION_ID, SEEDED_FLAG — Security, multi-org (application), and Oracle-seeded data indicators.
• ATTRIBUTE_CATEGORY and ATTRIBUTE1–ATTRIBUTE15, CREATED_BY, CREATION_DATE, LAST_UPDATED_BY, LAST_UPDATE_DATE, LAST_UPDATE_LOGIN, OBJECT_VERSION_NUMBER — Standard EBS descriptive flexfield, audit, and optimistic-locking columns.

Common Use Cases and Queries

Typical usage centers on retrieving condition definitions for contract authoring, auditing which conditions are active, and reporting on template versus instance conditions. A common pattern joins the header to its lines and outcomes:

• Locate a condition by name: SELECT ID, NAME, CNH_TYPE FROM OKC_CONDITION_HEADERS_B WHERE NAME = :name;
• List active, non-template conditions for a contract: SELECT ID, NAME FROM OKC_CONDITION_HEADERS_B WHERE CONDITION_VALID_YN = 'Y' AND TEMPLATE_YN = 'N' AND DNZ_CHR_ID = :chr_id;
• Expand a condition fully: join OKC_CONDITION_LINES_B, OKC_OUTCOMES_B, OKC_CONDITION_OCCURS, and OKC_TIMEVALUES_B on CNH_ID = ID.
• Audit recently changed definitions using LAST_UPDATE_DATE and LAST_UPDATED_BY.
• Cross-reference subject matter experts via TASK_OWNER_ID and LAST_RUNDATE for scheduling or run-history reporting.

Always filter on ZD_EDITION_NAME where editioning is in use, and honor SECURITY_GROUP_ID for data security.

Related Objects

The following objects most significantly reference or are referenced by OKC_CONDITION_HEADERS_B:

• OKC_ACTIONS_B — referenced via OKC_CONDITION_HEADERS_B.ACN_ID.
• CS_COUNTER_GROUPS — referenced via COUNTER_GROUP_ID.
• FND_SECURITY_GROUPS — referenced via SECURITY_GROUP_ID.
• OKC_CONDITION_LINES_B — child lines joined on CNH_ID = ID.
• OKC_OUTCOMES_B — condition outcomes joined on CNH_ID = ID.
• OKC_CONDITION_OCCURS — occurrence/trigger definitions joined on CNH_ID = ID.
• OKC_TIMEVALUES_B and OKC_TIMEVALUES — time-based values joined on CNH_ID = ID.
• CSC_PLAN_LINES — references the header through CONDITION_ID.

These relationships confirm the header's role as the anchor entity for the complete condition construct across OKC and the adjacent CSC planning schema.