Search Results okc_k_vers_numbers




Overview
Explore in AI Chat

Overview

OKC_K_VERS_NUMBERS is a Contracts Core (OKC) base table in Oracle E-Business Suite 12.1.1 and 12.2.2 that records the current document version of a contract. Where OKC_K_HEADERS_B stores the contract header itself, OKC_K_VERS_NUMBERS acts as the version registry, assigning a major and minor version number to each contract so that the application can identify the latest approved or authored rendition of the contract document. The table is owned by the OKC schema and is documented as VALID in ETRM. In Data Vault terms, the heuristic mining of the foreign key structure classifies this object as satellite-leaning: it is best modeled as a satellite attached to the OKC_K_HEADERS_B hub, carrying descriptive version attributes keyed by the contract header identifier rather than introducing new business entities of its own.

Key Information Stored

The physical schema documents ten columns. The surrogate primary key is enforced by OKC_K_VERS_NUMBERS_PK on CHR_ID, and a second unique index, OKC_K_VERS_NUMBERS_U1, also covers CHR_ID, making that column the effective business-key candidate and the join path back to the contract header.

  • CHR_ID — Contract header identifier; primary key column and the foreign key to OKC_K_HEADERS_B. One row in this table corresponds to one contract header.
  • MAJOR_VERSION — The major version counter for the contract document, incremented on substantive revisions.
  • MINOR_VERSION — The minor version counter, used for incremental or subordinate revisions within a major version.
  • OBJECT_VERSION_NUMBER — Optimistic locking column maintained by the framework to detect concurrent updates.
  • CREATED_BY, CREATION_DATE, LAST_UPDATED_BY, LAST_UPDATE_DATE — Standard WHO audit columns recording who created and last changed the version record, and when.
  • LAST_UPDATE_LOGIN — The login of the user session that performed the most recent update.
  • SECURITY_GROUP_ID — Multi-tenant and access-control discriminator, with a foreign key to FND_SECURITY_GROUPS.

Common Use Cases and Queries

The primary reporting scenario is determining which version of a contract is current and how many revisions a contract has undergone. A typical query joins the version table to the header base table:

SELECT h.contract_number, h.contract_type,
       v.major_version, v.minor_version,
       v.last_updated_by, v.last_update_date
  FROM okc_k_headers_b h,
       okc_k_vers_numbers v
 WHERE h.id = v.chr_id
   AND h.contract_number = :contract_number;

Contract administrators use the same pattern to audit revision history across a contract portfolio, for example grouping by CONTRACT_TYPE to compare average major version counts. Integrations and interfaces frequently read MAJOR_VERSION and MINOR_VERSION to stamp version information onto outbound documents or print layouts, ensuring the printed contract matches the stored rendition. Because OBJECT_VERSION_NUMBER is maintained by the framework, custom code that updates these rows must preserve it to avoid optimistic-lock conflicts. Reporting on SECURITY_GROUP_ID supports multi-org or secured-access filtering when version data is exposed to restricted responsibilities.

Related Objects

The following dependencies are documented in the ETRM relationship metadata and schema:

  • OKC_K_HEADERS_B — Parent contract header table; joined on OKC_K_VERS_NUMBERS.CHR_ID = OKC_K_HEADERS_B.ID (documented FK).
  • FND_SECURITY_GROUPS — Referenced through SECURITY_GROUP_ID for access-control grouping.
  • OKC_K_VERS_NUMBERS_PK / OKC_K_VERS_NUMBERS_U1 — The primary key and unique index that enforce one version record per contract header.
  • OKC_K_HEADERS_TL — Language-dependent header translations, commonly combined with OKC_K_HEADERS_B and this table in contract listing reports.
  • OKC_K_LINES_B and OKC_K_ITEMS — Contract lines and items that logically attach to the header identified by CHR_ID, frequently queried alongside version data.

Applications should treat OKC_K_VERS_NUMBERS as a satellite of the contract header: it holds no independent business identity beyond CHR_ID and derives its lifecycle entirely from the parent contract record.