Search Results okc_condition_lines_bh_pk

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:

• ID – Surrogate identifier for the condition line. Together with MAJOR_VERSION it forms the primary key OKC_CONDITION_LINES_BH_PK and the unique index OKC_CONDITION_LINES_BH_U1.
• MAJOR_VERSION – The version number of the condition line row; part of the composite primary and unique key.
• CNH_ID – Identifier of the parent condition header to which the line belongs.
• PDF_ID – Reference to the associated document/definition record.
• LEFT_COUNTER_ID / RIGHT_COUNTER_ID – Counterparties used on the left and right sides of a condition expression.
• LEFT_CTR_MASTER_ID / RIGHT_CTR_MASTER_ID – Master-level counterparty identifiers for the respective operands.
• DNZ_CHR_ID – Denormalized contract/characteristic identifier supporting efficient lookups.
• LOGICAL_OPERATOR – The logical connective (for example AND/OR) joining this line to adjacent lines.
• RELATIONAL_OPERATOR – The comparison operator applied within the line.
• LEFT_PARENTHESIS / RIGHT_PARENTHESIS – Grouping markers used to build parenthesized expressions.
• RIGHT_OPERAND and TOLERANCE – The value the left expression is compared against, and the permitted tolerance.
• SORTSEQ – Sequence controlling the evaluation order of lines.
• START_AT – The point at which the line takes effect in the condition.
• OBJECT_VERSION_NUMBER, CREATED_BY, CREATION_DATE, LAST_UPDATED_BY, LAST_UPDATE_DATE, LAST_UPDATE_LOGIN – Standard EBS concurrency and audit columns.
• ATTRIBUTE_CATEGORY and ATTRIBUTE1–15 – The DFF (descriptive flexfield) context and segments.
• SECURITY_GROUP_ID, APPLICATION_ID, SEEDED_FLAG – Multi-org security grouping, owning application, and seeded-data indicator.

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.