Search Results okc_k_vers_numbers_u1

Overview

The table OKC.OKC_K_VERS_NUMBERS is a core versioning object within the Oracle Contracts (OKC) module of Oracle E-Business Suite. It records the current version of a contract when that contract is treated as a document. A row is created when a contract is first created, at which point the major version is set to 0 and the minor version to 1. The versioning process increments the major version by one and resets the minor version to 0, while any change to any part of the contract — an insert, update, or delete — increments the minor version by 1. When the record is updated, the previous information is pushed to history, preserving a log of when the contract was updated and by whom, though the precise nature of the change is not captured in this row.

The object is owned by the OKC schema, holds FND Design Data under OKC.OKC_K_VERS_NUMBERS, and resides in the APPS_TS_TX_DATA tablespace with a PCT Free of 10. Its status is VALID. From a Data Vault modeling perspective, the heuristic classification is satellite-leaning, suggesting it functions as a descriptive, version-tracked child of a contract hub rather than a hub or link in its own right.

Key Information Stored

The table comprises ten documented columns. The single-column primary key is CHR_ID, which holds the ID of the contract whose version number is recorded. A unique index, OKC_K_VERS_NUMBERS_U1, exists on CHR_ID in the APPS_TS_TX_IDX tablespace, reinforcing its role as the business-key candidate and primary key.

• CHR_ID — Surrogate and primary key; the contract identifier that ties each version row to a contract header.
• MAJOR_VERSION — The major version of the contract for this history record; incremented by one during the versioning process.
• MINOR_VERSION — The minor version; set to 1 on creation, incremented on any contract change, and reset to 0 when the major version advances.
• OBJECT_VERSION_NUMBER — Sequential number set to 1 on insert and incremented on update; used by APIs to ensure the current record is passed during concurrency control.
• CREATED_BY, CREATION_DATE, LAST_UPDATED_BY, LAST_UPDATE_DATE, LAST_UPDATE_LOGIN — Standard Who columns capturing creation and last-update audit information.
• SECURITY_GROUP_ID — Used in hosted (multi-tenant) environments to isolate data by security group.

Common Use Cases and Queries

The most common use is determining the current version of a contract and auditing its version history. The following query retrieves the version state for a given contract:

• SELECT CHR_ID, MAJOR_VERSION, MINOR_VERSION, OBJECT_VERSION_NUMBER, LAST_UPDATED_BY, LAST_UPDATE_DATE FROM OKC.OKC_K_VERS_NUMBERS WHERE CHR_ID = :p_chr_id;
• Reporting the modification timeline: WHERE LAST_UPDATE_DATE BETWEEN :from_date AND :to_date, leveraging index OKC_K_VERS_NUMBERS_N1 on LAST_UPDATE_DATE.
• Detecting stale contracts by filtering rows whose MINOR_VERSION has advanced since a baseline.
• Enforcing API concurrency by comparing OBJECT_VERSION_NUMBER before committing updates.

Related Objects

The table participates in a small but essential set of relationships:

• OKC_OKC_K_HEADERS_B — Referenced through OKC_K_VERS_NUMBERS.CHR_ID, the parent contract header that anchors each version row.
• FND_SECURITY_GROUPS — Referenced through SECURITY_GROUP_ID, supporting hosted-environment data isolation.
• OKC_K_VERS_NUMBERS_U1 — The unique index on CHR_ID, enforcing one version row per contract.
• OKC_K_VERS_NUMBERS_N1 — The nonunique index on LAST_UPDATE_DATE, supporting audit and reporting queries.
• OKC Contracts APIs — The versioning process and DML contracts that insert, update, and push history rows rely on this table directly.