Search Results version_contract

Overview

OKC_CHANGE_REQUESTS_B is the core Contracts Core (OKC) table that stores a request to make one or more changes to a contract. Each row represents a single change request raised against a contract header, capturing the requester, the type of change, approval and application timestamps, and the versioning information needed to track how a contract evolves over its lifecycle. It is the parent object for the individual change lines and downstream process, party-role, and access records that implement the requested modifications.

The table resides in the OKC schema with 39 documented columns and is validated in both 12.1.1 and 12.2.2. Its architecture treats a change request as a header-level transaction that is approved, rejected, made effective, or applied against a specific contract version. The heuristic Data Vault classification mined from the foreign key structure is hub-leaning; this should be read as a modeling suggestion rather than a physical design statement. In that reading, OKC_CHANGE_REQUESTS_B behaves as a business hub keyed by the change request identity, while associated detail (change lines, party roles, process steps) hangs off it as satellites or links.

Key Information Stored

The surrogate primary key is ID, enforced by OKC_CHANGE_REQUESTS_B_PK and also exposed as the unique index OKC_CHANGE_REQUESTS_B_U1. This is the technical key rather than a business key, which is important when correlating records across integrations.

• ID — surrogate primary key for the change request; referenced as CRT_ID by child tables.
• CHR_ID — foreign key to OKC_K_HEADERS_B, identifying the contract header being changed.
• CRS_CODE — status or type code describing the stage of the change request.
• CRT_TYPE — the category or type of change request raised.
• USER_ID — the user who submitted or owns the request.
• DATETIME_REQUEST — when the change request was created.
• DATETIME_EFFECTIVE — when the requested change becomes effective.
• DATETIME_APPROVED / DATETIME_REJECTED — approval and rejection timestamps that drive workflow outcome.
• DATETIME_INEFFECTIVE — when the change request ceases to be effective.
• DATETIME_APPLIED — when the change was actually applied to the contract.
• VERSION_CONTRACT and APPLIED_CONTRACT_VERSION — the contract version requested versus the version on which it was applied.
• SIGNATURE_REQUIRED_YN, AUTHORITY, EXTENDED_YN — control flags governing approval and signature requirements.
• OBJECT_VERSION_NUMBER — optimistic locking column used by the OAF/BC4J layer.
• SECURITY_GROUP_ID — foreign key to FND_SECURITY_GROUPS supporting multi-org data security.
• CREATED_BY, CREATION_DATE, LAST_UPDATED_BY, LAST_UPDATE_DATE, LAST_UPDATE_LOGIN — standard WHO audit columns.
• The fifteen ATTRIBUTE columns plus ATTRIBUTE_CATEGORY provide the standard DFF extensibility block.

Common Use Cases and Queries

The table is central to change-request reporting: tracking outstanding approvals, measuring cycle time from request to application, and auditing the contract version trail. A typical query lists pending change requests against a contract header:

• Join OKC_CHANGE_REQUESTS_B to OKC_K_HEADERS_B on CHR_ID to display contract number alongside each request.
• Filter on CRS_CODE or DATETIME_APPROVED IS NULL to isolate in-flight approvals.
• Compute lead time as DATETIME_APPLIED minus DATETIME_REQUEST for SLA reporting.
• Compare VERSION_CONTRACT to APPLIED_CONTRACT_VERSION to find requests applied against an earlier revision.
• Restrict results by SECURITY_GROUP_ID when reporting across operating units.

Typical SQL: SELECT c.ID, h.CONTRACT_NUMBER, c.CRS_CODE, c.DATETIME_REQUEST, c.DATETIME_APPLIED FROM OKC_CHANGE_REQUESTS_B c, OKC_K_HEADERS_B h WHERE c.CHR_ID = h.ID.

Related Objects

• OKC_K_HEADERS_B — parent contract header; joined via OKC_CHANGE_REQUESTS_B.CHR_ID = OKC_K_HEADERS_B.ID.
• OKC_CHANGES_B — individual change lines; joined via OKC_CHANGES_B.CRT_ID = OKC_CHANGE_REQUESTS_B.ID.
• OKC_CR_K_ACCESSES — access control records for the request; joined via OKC_CR_K_ACCESSES.CRT_ID = OKC_CHANGE_REQUESTS_B.ID.
• OKC_CHANGE_PARTY_ROLE — party roles affected by the request; joined via OKC_CHANGE_PARTY_ROLE.CRT_ID = OKC_CHANGE_REQUESTS_B.ID.
• OKC_K_PROCESSES — process/workflow steps for the request; joined via OKC_K_PROCESSES.CRT_ID = OKC_CHANGE_REQUESTS_B.ID.
• FND_SECURITY_GROUPS — data-security grouping referenced by SECURITY_GROUP_ID.

The OKC Contracts Core APIs and the change-request UI layers operate on this table as the header entity, inserting the request record first and then attaching child change, access, and process rows.