Search Results okc_k_headers_b




Overview
Explore in AI Chat

Overview

The OKC_K_HEADERS_B table is the core header-level entity within the Oracle E-Business Suite Contracts Core (OKC) module for both releases 12.1.1 and 12.2.2. It serves as the master record for a contract, storing its fundamental attributes and acting as the primary grouping mechanism for all associated contract lines, terms, and conditions. Every contract created in the system is anchored by a single row in this table. Its design facilitates complex contract relationships, such as renewals and amendments, through self-referential foreign keys, making it the central point of integration for numerous other entities within the Contracts and related application suites.

Key Information Stored

The table's structure is designed to manage contract identity, classification, status, and relationships. The primary identifier is the ID column (OKC_K_HEADERS_B_PK), a unique system-generated surrogate key used for internal joins. Business-level contract identification is managed through the composite unique key CHR_CHR2_UK on CONTRACT_NUMBER and CONTRACT_NUMBER_MODIFIER. Critical foreign key columns define a contract's state and relationships: STS_CODE links to OKC_STATUSES_B for lifecycle status (e.g., Entered, Signed, Active), SCS_CODE links to OKC_SUBCLASSES_B for contract type classification, and QCL_ID links to OKC_QA_CHECK_LISTS_B for quality assurance. The self-referential columns CHR_ID_AWARD, CHR_ID_RENEWED, CHR_ID_RENEWED_TO, and CHR_ID_RESPONSE are pivotal for tracking the lineage and relationships between contract versions, amendments, and renewals.

Common Use Cases and Queries

This table is central to contract reporting, data extraction, and integration workflows. Common operational and analytical queries include retrieving a contract's header information by its business number, listing all contracts of a specific subtype or status, and tracing the amendment history of a contract. For instance, to find the current active version of a renewed contract, one would join OKC_K_HEADERS_B to itself on the CHR_ID_RENEWED_TO relationship. A typical pattern for extracting key contract header data for reporting would involve joining to the status and subclass descriptive tables:

  • SELECT h.contract_number, h.contract_number_modifier, s.name status, sc.name subtype FROM okc_k_headers_b h, okc_statuses_b s, okc_subclasses_b sc WHERE h.sts_code = s.code AND h.scs_code = sc.code AND h.sts_code = 'ACTIVE';

Integration points, such as feeding contract data to Order Management (OKS) or Receivables (AR), also rely on queries against this table using the ID as the key reference.

Related Objects

As the principal contract table, OKC_K_HEADERS_B has extensive relationships. Its most direct children store contract details: OKC_K_LINES_B for lines, OKC_K_PARTY_ROLES_B for parties, OKC_K_ITEMS for items, and OKC_K_ACCESSES for security. It is also referenced by process and history tables like OKC_K_PROCESSES and OKC_PRICE_ADJUSTMENTS_H. Crucially, it integrates with other EBS modules, serving as a parent table for OKS_K_ORDER_DETAILS in Service Contracts, AHL_OSP_ORDERS_B in Complex Maintenance, and AR_RAMC_AUDIT_TRAIL in Receivables. The provided metadata confirms these dependencies, highlighting its role as a shared service entity across the application.