Results for “okl_vp_change_requests”

AI-generated from documented ETRM metadata — verify critical details on the linked pages.

Overview

OKL_VP_CHANGE_REQUESTS is a transactional table within the OKL (Lease and Finance Management) schema of Oracle E-Business Suite, documented as VALID in both 12.1.1 and 12.2.2. Its stated purpose is to store change requests raised against Vendor Agreements, forming the workflow and audit backbone through which modifications to a lease or financing contract — such as term, rate, party, or clause adjustments — are proposed, tracked, approved, and ultimately applied. The table sits at the center of the vendor agreement amendment lifecycle, allowing multiple change requests to accumulate against a single contract record without directly mutating the underlying agreement until approvals are complete.

From a dimensional or Data Vault modeling perspective, the ETRM metadata classifies this object as hub-leaning (heuristic, mined from FK structure). This suggests that OKL_VP_CHANGE_REQUESTS can be treated as a candidate hub of change-request business keys, with dependent status, date, and audit attributes potentially separable into satellites. This classification is a modeling suggestion, not an enforced construct.

Key Information Stored

The table contains 37 documented columns. The most operationally significant are:

• ID — surrogate primary key, enforced by OKL_VP_CHANGE_REQUESTS_PK and also the sole column of the unique index OKL_VP_CHANGE_REQUESTS_U1, making it both the physical and business-key candidate.
• CHANGE_REQUEST_NUMBER — user-facing identifier used in forms and reports.
• CHR_ID — the header reference (OKL_K_HEADERS.CRS_ID points into this table, so CHR_ID is the header-side linkage).
• CHANGE_TYPE_CODE — enumerates the nature of the amendment.
• STATUS_CODE — drives the approval workflow state.
• REQUEST_DATE, EFFECTIVE_DATE, APPROVED_DATE, REJECTED_DATE, INEFFECTIVE_DATE, APPLIED_DATE — the full lifecycle date timeline.
• REQUEST_ID, PROGRAM_APPLICATION_ID, PROGRAM_ID, PROGRAM_UPDATE_DATE — concurrent-program and request attribution.
• OBJECT_VERSION_NUMBER — optimistic locking for concurrent updates.
• CREATED_BY, CREATION_DATE, LAST_UPDATED_BY, LAST_UPDATE_DATE, LAST_UPDATE_LOGIN — standard WHO audit columns.
• ATTRIBUTE_CATEGORY through ATTRIBUTE15 — the flexible DFF descriptive segment.

Common Use Cases and Queries

Typical scenarios include amendment pipelines, approval backlog reporting, and audit reconstruction. Sample patterns:

• List open change requests for a contract:

  SELECT CHANGE_REQUEST_NUMBER, CHANGE_TYPE_CODE, STATUS_CODE, REQUEST_DATE
  FROM   OKL_VP_CHANGE_REQUESTS
  WHERE  STATUS_CODE = 'PENDING';

• Lifecycle timing measurement between REQUEST_DATE and APPROVED_DATE for cycle-time KPIs.
• Joining to OKL_K_HEADERS to attribute each request to its owning agreement.
• Extracting DFF attributes (ATTRIBUTE1–15) for reconciliation with custom reporting.

Related Objects

• OKL_K_HEADERS — the primary dependent table; OKL_K_HEADERS.CRS_ID references OKL_VP_CHANGE_REQUESTS, linking each header to the change request that governs it.
• OKL_VP_CHANGE_REQUEST_* derived tables — associated detail rows capturing line-level amendments.
• OKL_VP_* vendor agreement tables — the agreement master records amended by these requests.
• OKL_K_* contract tables — downstream contracts generated from approved changes.
• WF / AME workflow objects — approval routing for STATUS_CODE transitions.

Because the documented FK surface is narrow (only OKL_K_HEADERS), most relationships are functional rather than enforced, so joins should be validated against the OKL application schema in the target release.