Search Results okc_k_headers_all_bh_pk

Overview

OKC_K_HEADERS_ALL_BH is a Contracts Core (OKC) table in the Oracle E-Business Suite, residing in the OKC schema. Per the ETRM documentation, it is a mirror image of the base table OKC_K_HEADERS_ALL_B, and detailed column-level semantics are inherited from that base table. The "H" suffix indicates a history, or audit, companion table that captures the full lifecycle of contract header records retained in the base table. Its primary key is OKC_K_HEADERS_ALL_BH_PK, defined on the composite of ID and MAJOR_VERSION, which is the mechanism by which successive versions of the same contract header are distinguished.

The table is documented with 103 columns in the 12.2.2 physical schema. Relationships mined from its foreign keys indicate references to FND_SECURITY_GROUPS (via SECURITY_GROUP_ID), MTL_INV_PICKING_RULES (via INV_RULE_ID), and PN_PAYMENT_TERMS_ALL (via PAYMENT_TERM_ID). The heuristic Data Vault classification supplied is standalone, meaning the mined FK structure does not by itself indicate a hub, link, or satellite pattern; in modeling terms, this should be treated only as a suggestion, and the table is best understood as a versioned history satellite over the contract header business key rather than a true Data Vault hub.

Key Information Stored

The most significant columns for identifying and interpreting a history row are the following:

• ID — surrogate identifier of the contract header, shared with the base table and forming part of the primary key.
• MAJOR_VERSION — version number of the contract header record; together with ID it constitutes OKC_K_HEADERS_ALL_BH_PK and is the discriminator between historical snapshots of the same contract.
• CONTRACT_NUMBER and CONTRACT_NUMBER_MODIFIER — the user-visible contract identifier and its modifier; these form the leading columns of unique index OKC_K_HEADERS_ALL_BH_U1, making them the principal business-key candidates alongside MAJOR_VERSION.
• CHR_TYPE — the contract header type classification, distinguishing contract categories.
• STS_CODE and SCS_CODE — status and sub-status codes reflecting the contract's workflow state.
• BUY_OR_SELL and ISSUE_OR_RECEIVE — directional indicators for the contract.
• START_DATE and END_DATE — effective term dates for the contract header.
• DATE_SIGNED, DATE_APPROVED, DATE_TERMINATED, DATE_RENEWED — key lifecycle milestone dates.
• CURRENCY_CODE and ESTIMATED_AMOUNT — the contract currency and estimated monetary value.
• ORG_ID — the operating unit that owns the contract, the standard multi-org partitioning column.
• SECURITY_GROUP_ID — the security grouping referenced against FND_SECURITY_GROUPS.

A second unique index, OKC_K_HEADERS_ALL_BH_U2, is defined on (ID, MAJOR_VERSION), duplicating the primary key columns and reinforcing the versioned surrogate key. The remaining columns include audit columns (CREATED_BY, CREATION_DATE, LAST_UPDATED_BY, LAST_UPDATE_DATE, PROGRAM_ID, REQUEST_ID), the standard ATTRIBUTE1–15 flexfield columns, and attributes such as INV_RULE_ID, PAYMENT_TERM_ID, CUST_ACCT_ID, and BILL_TO_SITE_USE_ID.

Common Use Cases and Queries

Because this is the history counterpart of the contract header base table, its principal use cases are auditing, point-in-time reporting, and reconciliation of contract changes. A typical query reconstructs the version history of a single contract:

• Version history: SELECT ID, MAJOR_VERSION, CONTRACT_NUMBER, STS_CODE, START_DATE, END_DATE FROM OKC_K_HEADERS_ALL_BH WHERE ID = :p_id ORDER BY MAJOR_VERSION.
• Latest version lookup: filter on MAX(MAJOR_VERSION) per ID to obtain the most recent snapshot.
• Point-in-time extraction: constrain on LAST_UPDATE_DATE between two dates to identify headers changed within a period.
• Status movement analysis: group by STS_CODE and count DISTINCT CONTRACT_NUMBER to profile contracts by lifecycle state over time.
• Multi-org reporting: join on ORG_ID to report contract values by operating unit.

Because the mirror is populated by the base table's audit mechanism, queries should generally be read-only, and joins back to OKC_K_HEADERS_ALL_B on (ID, MAJOR_VERSION) support comparison of current versus historical state.

Related Objects

The following are the most significant related objects, using documented join columns:

• OKC_K_HEADERS_ALL_B — the base table this history mirrors; join on ID and MAJOR_VERSION.
• FND_SECURITY_GROUPS — referenced via SECURITY_GROUP_ID.
• MTL_INV_PICKING_RULES — referenced via INV_RULE_ID for inventory picking rule defaults.
• PN_PAYMENT_TERMS_ALL — referenced via PAYMENT_TERM_ID for payment terms.
• OKC_K_LINES_ALL_B — the contract lines base table, related to headers through the contract ID.
• OKC_K_PARTIES_ALL_B — contract party records linked to the header ID.
• OKC_K_HEADERS_ALL_TL — translated header attributes associated with the base header.

Any integration or reporting layer should treat OKC_K_HEADERS_ALL_BH as the authoritative record of historical contract header versions and should not attempt to modify it directly.