Search Results okc_k_headers_all_bh_u1

Overview

OKC.OKC_K_HEADERS_ALL_BH is an Oracle E-Business Suite table in the Contracts (OKC) schema, the module underlying the Contracts Core functionality used by Oracle Purchasing, Order Management, Service Contracts, and Project Contracts. The _BH suffix designates the table as a mirror or image copy of the base table OKC_K_HEADERS_ALL_B; per the documented metadata, the column-level definitions of OKC_K_HEADERS_ALL_BH mirror those of the base table, and the base table is the authoritative source for detailed column semantics. In the standard EBS design pattern, such archive tables store historical or pre-upgrade snapshots of contract header rows, preserving a point-in-time record of contract terms independently of the transactional base table.

The table is classified heuristically as a standalone Data Vault object: the FK-mining exercise did not surface parent-child structure strong enough to model a hub or link, suggesting the table is best treated as a self-contained snapshot rather than as a conformed integration point in a Data Vault build. This classification is a modeling suggestion, not a documented characteristic; in practice it reflects the fact that the _BH table copies rows from OKC_K_HEADERS_ALL_B rather than participating in the transactional referential web.

Key Information Stored

The table carries 103 documented columns. The surrogate primary key is OKC_K_HEADERS_ALL_BH_PK over the composite of ID and MAJOR_VERSION. Two unique indexes serve as business-key candidates:

• OKC_K_HEADERS_ALL_BH_U1 — uniqueness over CONTRACT_NUMBER, CONTRACT_NUMBER_MODIFIER, MAJOR_VERSION. This is the natural human-facing identifier of a contract version.
• OKC_K_HEADERS_ALL_BH_U2 — uniqueness over ID, MAJOR_VERSION, matching the physical primary key. This is the index named in the user search term.

The most consequential columns are: ID (surrogate contract identifier, shared across versions); CONTRACT_NUMBER and CONTRACT_NUMBER_MODIFIER (the user-visible number and its modifier); MAJOR_VERSION (version discriminator that makes the composite keys meaningful); CHR_TYPE (contract header type, distinguishing agreements from other document classes); STS_CODE (status code — draft, active, terminated, cancelled); SCS_CODE (signature/confirmation status); BUY_OR_SELL and ISSUE_OR_RECEIVE (directionality of the contract); START_DATE, END_DATE, DATE_SIGNED, DATE_TERMINATED (lifecycle dates); CURRENCY_CODE and ESTIMATED_AMOUNT (value and currency); ORG_ID and AUTHORING_ORG_ID (multi-org and authoring context); and the ATTRIBUTE_CATEGORY/ATTRIBUTE1..15 DFF block used for extensibility. Audit columns CREATED_BY, CREATION_DATE, LAST_UPDATED_BY, LAST_UPDATE_DATE, LAST_UPDATE_LOGIN, and OBJECT_VERSION_NUMBER support concurrency and lineage. The ORIG_SYSTEM_* and UPG_ORIG_SYSTEM_REF* columns record the foreign source during migration or upgrade.

Common Use Cases and Queries

Typical uses are (a) point-in-time reporting on contracts as they stood at an archive point, (b) reconciliation of version history against OKC_K_HEADERS_ALL_B, and (c) audit queries that confirm the migrated value of a contract after an upgrade or relocation.

• Retrieve the latest archived version of every contract: SELECT * FROM okc_k_headers_all_bh h WHERE h.major_version = (SELECT MAX(b.major_version) FROM okc_k_headers_all_bh b WHERE b.id = h.id);
• Locate a specific contract version via the natural business key: SELECT * FROM okc_k_headers_all_bh WHERE contract_number = :num AND contract_number_modifier = :mod AND major_version = :ver;
• Compare archived to base rows to detect drift introduced by upgrades or data fixes: SELECT NVL(a.sts_code,'-') base_sts, NVL(b.sts_code,'-') bh_sts FROM okc_k_headers_all_b a, okc_k_headers_all_bh b WHERE a.id=b.id(+) AND a.major_version=b.major_version(+) AND ...
• All-version history for one contract: SELECT major_version, sts_code, start_date, end_date FROM okc_k_headers_all_bh WHERE id = :contract_id ORDER BY major_version;
• Status and amount reporting across the archive snapshot: aggregate by CHR_TYPE, BUY_OR_SELL, and STS_CODE for trend analysis of contract values.

Related Objects

The table participates in a limited set of foreign-key relationships plus logical ties to the base and companion contract tables:

• OKC.OKC_K_HEADERS_ALL_BH.SECURITY_GROUP_ID → FND_SECURITY_GROUPS — applies row-level security context.
• OKC.OKC_K_HEADERS_ALL_BH.INV_RULE_ID → MTL_INV_PICKING_RULES — inventory picking rule applied to the contract.
• OKC.OKC_K_HEADERS_ALL_BH.PAYMENT_TERM_ID → PN_PAYMENT_TERMS_ALL — payment terms for the contract.
• OKC.OKC_K_HEADERS_ALL_B — base table; OKC_K_HEADERS_ALL_BH is its mirror image and should be joined on ID and MAJOR_VERSION.
• OKC.OKC_K_LINES_B and OKC.OKC_K_LINES_BH — contract lines keyed by CHR_ID/ID; the line-level counterpart of the header mirror.
• OKC.OKC_K_HEADERS_TL and OKC.OKC_K_HDR_PARTIES — translated header text and header-party association, joined on ID (and MAJOR_VERSION where applicable).
• The OKC Contracts Core PL/SQL API OKC_CONTRACT_HEADERS_PUB and related concurrent programs, which normally operate on the base table and cause the archive rows to be produced.