Results for “okc_sections_bh”

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

Overview

OKC_SECTIONS_BH is an Oracle E-Business Suite table owned by the OKC schema (Contracts Core). It serves as the history (audit) table that mirrors its base table, OKC_SECTIONS_B, capturing successive versions of contract section records. In EBS 12.1.1 and 12.2.2, the "_BH" suffix designates a date-tracked history table that preserves the full lifecycle of a row, so any change made to the corresponding base record generates a new historical version keyed by a major version number rather than overwriting the prior state.

The table is classified heuristically as standalone within a Data Vault model. This classification is offered as a modeling suggestion only; the table's structure suggests it behaves as a satellite-like history store rather than a hub or link, since it holds descriptive attributes and versioning information around the contract section entity rather than the pure business keys that would define a hub.

Key Information Stored

The primary key, enforced by OKC_SECTIONS_BH_PK, is composed of ID and MAJOR_VERSION. ID identifies the underlying contract section, and MAJOR_VERSION distinguishes each historical instance of that section. A unique index, OKC_SECTIONS_BH_U1, also covers (ID, MAJOR_VERSION), reinforcing the natural business-key candidate for the version record.

Among the 46 documented columns, the most significant include:

• ID and MAJOR_VERSION — surrogate/version key pair defining each historical row.
• SCN_ID and SCN_CODE — reference to the parent contract section and its short code.
• LABEL and HEADING — the displayable title and heading of the section.
• DESCRIPTION and AMENDMENT_DESCRIPTION — narrative text describing the section and any amendment.
• SECTION_SEQUENCE — ordering of the section within the contract.
• DOCUMENT_TYPE and DOCUMENT_ID — the owning contract document.
• AMENDMENT_OPERATION_CODE and SUMMARY_AMEND_OPERATION_CODE — codes indicating the operation performed during an amendment.
• LAST_AMENDED_BY and LAST_AMENDMENT_DATE — who amended the section and when.
• OBJECT_VERSION_NUMBER — optimistic locking control value.
• AUDIT columns — CREATED_BY, CREATION_DATE, LAST_UPDATED_BY, LAST_UPDATE_DATE, and LAST_UPDATE_LOGIN.
• SECURITY_GROUP_ID — access control reference.

Common Use Cases and Queries

This table supports auditing and point-in-time reconstruction of contract sections. Typical reporting includes comparing a section's current state against prior versions, tracing the sequence of amendments, and identifying who changed a section and when.

• Retrieve the full version history of a section:
  SELECT id, major_version, label, heading, amendment_operation_code, last_amended_by, last_amendment_date FROM okc.okc_sections_bh WHERE id = :section_id ORDER BY major_version;
• Find the most recent version:
  SELECT * FROM okc.okc_sections_bh WHERE id = :section_id AND major_version = (SELECT MAX(major_version) FROM okc.okc_sections_bh WHERE id = :section_id);
• Audit report of amendments by date range:
  SELECT id, scn_id, amendment_operation_code, last_amended_by, last_amendment_date FROM okc.okc_sections_bh WHERE last_amendment_date BETWEEN :from_date AND :to_date;

Because rows are versioned, joins back to the current contract document should use SCN_ID or DOCUMENT_ID rather than assuming a single row per section.

Related Objects

The table's documented foreign key points to FND_SECURITY_GROUPS via SECURITY_GROUP_ID, tying section history to security group definitions. Functionally, its closest relationship is to its base table, OKC_SECTIONS_B, from which every historical row originates. Related objects include:

• OKC_SECTIONS_B — the current/base section table mirrored by this history table.
• FND_SECURITY_GROUPS — joined on SECURITY_GROUP_ID.
• OKC_CONTRACTS / contract document objects — referenced through DOCUMENT_ID and DOCUMENT_TYPE.
• OKC section amendment APIs — the contracts amendment logic that writes these history records.

Querying by ID and MAJOR_VERSION provides the most reliable access path given the documented primary and unique indexes.