Search Results okc_condition_lines_bh




Overview
Explore in AI Chat

Overview

OKC_CONDITION_LINES_BH is the history (audit) table for OKC_CONDITION_LINES_B within the OKC – Contracts Core product of Oracle E-Business Suite. It resides in the OKC schema and is classified as VALID in both Oracle EBS 12.1.1 and 12.2.2. The table preserves previous versions of condition line records whenever a condition line is modified, enabling point-in-time reconstruction of contract rule structures, version comparison, and audit reporting.

OKC_CONDITION_LINES_B stores the base ("_B") definitional rows for condition lines — the individual logical operands, operators, parentheses, and relational constructs that make up a condition (for example, the condition rows that drive contract terms eligibility, pricing qualification, or clause selection). Each time a row in OKC_CONDITION_LINES_B is updated or superseded, the prior state is written to OKC_CONDITION_LINES_BH. Versioning is expressed through the MAJOR_VERSION column, which is part of the primary key.

The ETRM metadata classifies this object heuristically as standalone in a Data Vault sense. In practice, a history table of this kind behaves more like a satellite than a hub or link: its grain is the versioned attribute set of a parent business entity, and it carries the descriptive and relationship fields (operators, operands, tolerances, sequencing) rather than introducing new business entities. This is a modeling suggestion, not a documented Data Vault designation.

Key Information Stored

The table contains 44 documented columns. The most significant are:

Note that CNL_TYPE identifies the condition line type, and AAE_ID links to the associated rule/attribute record.

Common Use Cases and Queries

Typical uses include: audit reconciliation between current and historical condition structures; generating version-to-version change reports for contract rules; reconstructing the condition logic in effect at a given date; and troubleshooting why a contract qualified (or failed to qualify) under a specific rule version. A baseline query pattern is:

  • SELECT ID, MAJOR_VERSION, CNH_ID, LOGICAL_OPERATOR, RELATIONAL_OPERATOR, RIGHT_OPERAND, TOLERANCE, SORTSEQ, LAST_UPDATE_DATE FROM OKC_CONDITION_LINES_BH WHERE ID = :p_id ORDER BY MAJOR_VERSION DESC;
  • Join to OKC_CONDITION_LINES_B on (ID, MAJOR_VERSION) to diff current versus prior versions, filtering on OBJECT_VERSION_NUMBER or LAST_UPDATE_DATE to isolate recent changes.
  • Filter by DNZ_CHR_ID or CNH_ID to report all historical condition lines for a given contract or condition header.
  • Restrict by SECURITY_GROUP_ID for multi-org-aware reporting.

Related Objects

The most significant related objects, based on the documented key and foreign-key structure, are:

  • OKC_CONDITION_LINES_B – The current (non-history) base table; joined on ID and MAJOR_VERSION for version comparison.
  • OKC_CONDITION_LINES_BH_PK / OKC_CONDITION_LINES_BH_U1 – Primary key constraint and unique index on (ID, MAJOR_VERSION), defining row uniqueness.
  • FND_SECURITY_GROUPS – Referenced via SECURITY_GROUP_ID; join column SECURITY_GROUP_ID = FND_SECURITY_GROUPS.SECURITY_GROUP_ID.
  • OKC_CONDITION_HEADERS_B / condition header tables – Parent headers referenced through CNH_ID.
  • OKC_CONDITION_LINES_TL – Translated line attributes, where applicable, joined via ID.
  • OKC_RULES / OKC_RULE_* rule objects – Consume condition lines to evaluate contract eligibility and qualification.
  • OKC_DOCUMENTS / contract document tables – Related through the condition-to-document association (PDF_ID).
  • FND_APPLICATION – Referenced by APPLICATION_ID to identify the owning application.

Because the ETRM metadata classifies the object as standalone, no additional outgoing foreign keys beyond SECURITY_GROUP_ID are documented; relationships to header, rule, and document tables are established through denormalized identifier columns rather than enforced constraints.