Search Results oke_chg_requests




Overview
Explore in AI Chat

Overview

The OKE_CHG_REQUESTS table is a core data object within the Oracle E-Business Suite (EBS) Project Contracts module (OKE). It serves as the central repository for storing all metadata and header-level information pertaining to contract change requests. In the lifecycle of a project contract, modifications to terms, deliverables, pricing, or scope are formally managed through a structured change control process. This table is the primary transactional table for that process, tracking each change request from initiation through approval and implementation. Its existence is critical for maintaining audit trails, supporting approval workflows, and ensuring that all contractual modifications are systematically recorded and linked to their originating contract.

Key Information Stored

The table's structure is designed to uniquely identify and describe each change request and its relationship to the core contract. The primary identifier is the CHG_REQUEST_ID, a system-generated unique key. Each change request is intrinsically linked to a specific project contract via the K_HEADER_ID foreign key, which references the OKE_K_HEADERS table. A human-readable sequence for the request is stored in CHG_REQUEST_NUM. The current state of the request's workflow (e.g., Draft, Submitted, Approved, Rejected) is held in CHG_STATUS_CODE, which references the OKE_CHG_STATUSES_B lookup table. To maintain a history of actions, the table points to the most recent log entry via LAST_CHG_LOG_ID, which links to the OKE_CHG_LOGS table. While the provided metadata focuses on key identifiers and foreign keys, typical implementations would also include columns for creation date, last update date, requestor, description, reason code, and effective dates.

Common Use Cases and Queries

This table is central to reporting and operational queries within Project Contracts. Common use cases include generating change request status reports, analyzing change frequency and types for specific contracts or projects, and auditing the change history. A fundamental query retrieves all change requests for a given contract, often joining to related tables for more context.

  • Basic Status Report: SELECT cr.chg_request_num, cr.chg_status_code, cr.creation_date FROM oke_chg_requests cr WHERE cr.k_header_id = :p_contract_id ORDER BY cr.creation_date DESC;
  • Open Change Requests: Identifying pending requests is crucial for project management: SELECT kh.contract_number, cr.chg_request_num FROM oke_chg_requests cr JOIN oke_k_headers kh ON cr.k_header_id = kh.k_header_id WHERE cr.chg_status_code NOT IN ('APPROVED', 'REJECTED', 'CANCELLED');
  • Integration with Billing: Since billing events can be tied to change requests, queries often join OKE_CHG_REQUESTS with OKE_K_BILLING_EVENTS to correlate revenue recognition with specific contractual changes.

Related Objects

The OKE_CHG_REQUESTS table has extensive relationships, acting as a hub for the change management process. The documented foreign key relationships are:

  • Parent/Reference Tables: OKE_K_HEADERS (via K_HEADER_ID), OKE_CHG_STATUSES_B (via CHG_STATUS_CODE), and OKE_CHG_LOGS (via LAST_CHG_LOG_ID).
  • Child/Dependent Tables: The table is referenced as a parent by several key transactional and history tables:

These relationships illustrate that a single change request record can spawn multiple approval steps, log entries, associated billing events, communications, and version histories, forming a complete audit trail.