Search Results okc_rep_contract_vers_pk

Overview

OKC_REP_CONTRACT_VERS is a Contracts Core (OKC) repository table within Oracle E-Business Suite that stores all previous versions of a contract. Each time a contract is amended, renewed, or otherwise revised in Oracle Contracts, the prior state of the contract header is preserved as a row in this table, keyed by contract identifier and version number. In EBS 12.1.1 and 12.2.2 the table resides in the OKC schema and is documented as VALID with 70 columns in the ETRM 12.2.2 physical schema.

The heuristic Data Vault classification mined from the foreign key structure is link. This suggests the table is best modeled as a relationship-bearing construct that connects a contract entity to its versioned attributes, rather than as a pure hub of business keys or a satellite of descriptive attributes. Practically, it functions as a version history store: the current contract header lives in OKC_REP_CONTRACTS_ALL (or its repository equivalent), while prior versions are archived here.

Key Information Stored

The primary key is OKC_REP_CONTRACT_VERS_PK, defined on (CONTRACT_ID, CONTRACT_VERSION_NUM). A unique index, OKC_REP_CONTRACT_VERS_U1, covers the same column pair and represents the business-key candidate for the versioned contract identity. The most significant columns include:

• CONTRACT_ID, CONTRACT_VERSION_NUM — surrogate/composite key identifying the contract and its specific historical version.
• CONTRACT_NUMBER, CONTRACT_NAME, CONTRACT_DESC — business identifiers and descriptive text for the version.
• CONTRACT_TYPE — foreign key to OKC_BUS_DOC_TYPES_B, classifying the contract (e.g., sales, purchase, service).
• CONTRACT_STATUS_CODE — lifecycle status (active, cancelled, terminated) at the time the version was captured.
• LATEST_SIGNED_VER_NUMBER — tracks the most recently executed signature version.
• CONTRACT_EFFECTIVE_DATE, CONTRACT_EXPIRATION_DATE — validity window of the version.
• CURRENCY_CODE, AMOUNT — financial value of the contract at that version.
• ORG_ID — multi-org operating unit context.
• AUTHORING_PARTY_CODE, OWNER_ID — the party that authored the contract and the internal owner.
• NOTIFY_CONTACT_ROLE_ID — foreign key to OKC_REP_CONTACT_ROLES_B for expiration notification routing.
• VERSION_COMMENTS — reason or notes recorded when the version was superseded.
• Standard audit columns (CREATED_BY, CREATION_DATE, LAST_UPDATED_BY, LAST_UPDATE_DATE, OBJECT_VERSION_NUMBER) and the ATTRIBUTE1–15 DFF columns for extensibility.

Common Use Cases and Queries

Typical reporting scenarios include contract version history for audit, comparison of terms across amendments, and reconstruction of the contract state as of a given date. A representative query retrieves all versions for a contract:

• SELECT contract_number, contract_version_num, contract_status_code, contract_effective_date, contract_expiration_date, amount FROM okc_rep_contract_vers WHERE contract_id = :p_contract_id ORDER BY contract_version_num;
• Join to OKC_BUS_DOC_TYPES_B on contract_type = bus_doc_type_code to label contract types in version reports.
• Join to OKC_REP_CONTACT_ROLES_B on notify_contact_role_id to identify notification recipients per version.

Because ORG_ID is present, queries should generally be filtered by operating unit in multi-org environments to avoid cross-org leakage in reports.

Related Objects

• OKC_REP_CONTRACTS_ALL — current contract header; supplies CONTRACT_ID for version joins.
• OKC_BUS_DOC_TYPES_B — referenced via CONTRACT_TYPE for document type classification.
• OKC_REP_CONTACT_ROLES_B — referenced via NOTIFY_CONTACT_ROLE_ID for notification roles.
• OKC_REP_CONTRACT_VERS child attribute tables (e.g., contract lines, parties) keyed by CONTRACT_ID and CONTRACT_VERSION_NUM.
• OKC_CONTRACT_PUB and related Contracts Core PL/SQL APIs that write version records during amendment processing.