Search Results oke_chg_requests_u1

Overview

OKE.OKE_CHG_REQUESTS is the header-level transaction table for change requests within the Oracle E-Business Suite Contracts (OKE) module. A change request captures a formal proposal to alter one or more attributes of an existing project contract document — price, quantity, scope, terms, or deliverables — submitted either by the customer or by the contractor, on a unilateral or bilateral basis. Each row represents one change request tied to a specific contract document through K_HEADER_ID, and the table is the primary source of truth for change request status, type, reason, and negotiation lifecycle within Contract Management.

Functionally the table acts as the driver of contract versioning. The metadata states that a new contract version is produced when a change request transitions from a status of type Approved to one of type In Progress, and again from In Progress to Completed. Status codes can be associated with workflow processes that are launched on status updates, so OKE_CHG_REQUESTS is also an integration point with Oracle Workflow. The table resides in the APPS_TS_TX_DATA tablespace and carries 39 documented columns in the 12.2.2 schema, consistent with its 12.1.1 heritage.

Under a heuristic Data Vault classification derived from the foreign-key topology, this table is best modeled as a hub: it holds the durable business key of the change request and the unique identifier that links to surrounding satellites and links.

Key Information Stored

The documented schema distinguishes surrogate identity, business keys, and descriptive attributes:

• CHG_REQUEST_ID — surrogate primary key (OKE_CHG_REQUESTS_PK), sourced from the sequence behind OKE_CHG_REQUESTS_S. Enforced by unique index OKE_CHG_REQUESTS_U1, which is the index the user searched for.
• CHG_REQUEST_NUM and K_HEADER_ID — the composite business key enforced by unique index OKE_CHG_REQUESTS_U2. CHG_REQUEST_NUM is the user-visible change request number (VARCHAR2(30)); K_HEADER_ID identifies the parent contract document.
• CHG_TYPE_CODE, CHG_STATUS_CODE, CHG_REASON_CODE — classification and lifecycle codes; each is indexed by a non-unique index (N2, N3, N4) and CHG_STATUS_CODE resolves against OKE_CHG_STATUSES_B.
• IMPACT_FUNDING_FLAG and EFFECTIVE_DATE — flag whether the change affects funding and the date the change takes effect.
• REQUESTED_BY_PERSON_ID, REQUESTED_DATE, RECEIVE_DATE, APPROVE_DATE, IMPLEMENT_DATE — the negotiation timeline from request through approval to implementation.
• PREV_VERSION and NEW_VERSION — the contract versions before and after the change, underpinning version history.
• DESCRIPTION and CHG_TEXT — free-text summary and detail of the requested change.
• LAST_CHG_LOG_ID — pointer to the most recent entry in OKE_CHG_LOGS.
• Standard Who columns (CREATION_DATE, CREATED_BY, LAST_UPDATE_DATE, LAST_UPDATED_BY, LAST_UPDATE_LOGIN) and the ATTRIBUTE_CATEGORY plus ATTRIBUTE1–ATTRIBUTE15 DFF columns complete the row.

Common Use Cases and Queries

Typical reporting covers open change requests per contract, cycle-time analysis from REQUESTED_DATE to APPROVE_DATE, and change volume by reason code. A frequently used pattern joins the header to its contract and status:

• Open change requests: SELECT c.chg_request_num, c.chg_status_code, c.requested_date FROM oke.oke_chg_requests c WHERE c.chg_status_code = :status AND c.k_header_id = :contract_id;
• Approval turnaround: aggregate (c.approve_date - c.requested_date) grouped by CHG_REASON_CODE or CHG_TYPE_CODE.
• Version audit: select CHG_REQUEST_NUM, PREV_VERSION, NEW_VERSION, IMPLEMENT_DATE ordered by K_HEADER_ID to reproduce the contract versioning trail.
• Funding impact review: filter IMPACT_FUNDING_FLAG = 'Y' to isolate changes that alter contract funding.

Because CHG_STATUS_CODE drives workflow and version creation, integration queries should read the status from this table rather than inferring it from OKE_CHG_LOGS.

Related Objects

The documented foreign-key relationships define the immediate neighborhood of the table:

• OKE.OKE_K_HEADERS — parent contract document, joined on K_HEADER_ID.
• OKE.OKE_CHG_STATUSES_B — status lookup, joined on CHG_STATUS_CODE.
• OKE.OKE_CHG_LOGS — change log entries; referenced via LAST_CHG_LOG_ID and referencing this table back through CHG_REQUEST_ID.
• OKE.OKE_APPROVAL_HISTORY — approval records linked by CHG_REQUEST_ID.
• OKE.OKE_K_BILLING_EVENTS — billing events linked through BILL_CHG_REQ_ID.
• OKE.OKE_K_COMMUNICATIONS — communications linked by CHG_REQUEST_ID.
• OKE.OKE_K_RELATED_ENTITIES — related entity associations on CHG_REQUEST_ID.
• OKE.OKE_K_VERS_NUMBERS_H — contract version numbers referencing CHG_REQUEST_ID.

All joins should use the surrogate CHG_REQUEST_ID where possible, reserving the composite CHG_REQUEST_NUM/K_HEADER_ID key for user-facing lookups.