Search Results approved_date

Overview

OKL_VP_CHANGE_REQUESTS_V is an entity view owned by the APPS schema in Oracle E-Business Suite Release 12.1.1 and 12.2.2. It belongs to the OKL product family, Oracle Lease and Finance Management. The view is documented as the entity view for the base table OKL_VP_CHANGE_REQUESTS, meaning it serves as a controlled read interface over the change request data stored in that table. The prefix VP indicates that the underlying table is maintained by the Leasing and Finance Management application's versioning and pricing infrastructure, where change requests capture modifications to contracts or related financial constructs that require tracking through a lifecycle of request, approval, effectivity, and application.

The view exposes one row per change request record and preserves the ROWID of the underlying row through the aliased column ROW_ID. This makes it usable not only for reporting but also for direct row identification in integration code. The view exists in the standard EBS APPS schema, so it is accessible to any responsibility or concurrent program whose database user has been granted privileges on the APPS synonym. Its principal consumers are custom reports, conversion and interface programs, and extensions that must inspect or react to change request state without querying the base table directly.

Underlying Base Objects

The view text is a straightforward single-table projection over OKL_VP_CHANGE_REQUESTS, aliased VCR in the defining query. No joins, unions, or aggregations are present. The documented base object in the 12.2.2 metadata is OKL_VP_CHANGE_REQUESTS, exposed to the APPS schema through a synonym. Consequently, the view inherits the table's column set without transformation, and there is no filtering or derived logic that would exclude rows. All standard EBS audit columns present on the base table are carried through unchanged.

Key Columns

• ID — Primary identifier of the change request record.
• OBJECT_VERSION_NUMBER — Optimistic locking column used to detect concurrent updates.
• CHANGE_REQUEST_NUMBER — User-facing document number for the change request.
• CHR_ID — Foreign key reference to the contract or change header context to which the request applies.
• CHANGE_TYPE_CODE — Code classifying the nature of the change request. This is the column most frequently referenced when filtering or grouping change requests by category, and it is typically validated against an OKL lookup.
• STATUS_CODE — Current lifecycle state of the request, such as requested, approved, rejected, applied, or ineffective.
• REQUEST_DATE, EFFECTIVE_DATE, APPROVED_DATE, REJECTED_DATE, INEFFECTIVE_DATE, APPLIED_DATE — Date stamps for each stage of the request lifecycle, allowing cycle-time and aging analysis.
• ATTRIBUTE_CATEGORY and ATTRIBUTE1 through ATTRIBUTE15 — Descriptive flexfield columns inherited from the base table. Note that the view definition maps ATTRIBUTE6 to the underlying ATTRIBUTE5 column, a defect that should be accounted for when reading or writing flexible attribute data through this view.
• REQUEST_ID, PROGRAM_APPLICATION_ID, PROGRAM_ID, PROGRAM_UPDATE_DATE — Concurrent request tracking columns identifying the program that last touched the record.
• CREATED_BY, CREATION_DATE, LAST_UPDATED_BY, LAST_UPDATE_DATE, LAST_UPDATE_LOGIN — Standard EBS audit columns.

Common Use Cases and Queries

Typical usage includes monitoring change requests awaiting approval, reporting applied changes by type, and feeding downstream interfaces. A representative query filtering on the change type is:

SELECT change_request_number, change_type_code, status_code, request_date, approved_date, applied_date FROM apps.okl_vp_change_requests_v WHERE change_type_code = :p_change_type AND status_code = 'APPLIED' ORDER BY applied_date DESC;

Because the view is a pass-through projection, it can also be used to resolve the base row ID for updates performed through the entity: SELECT row_id, id FROM apps.okl_vp_change_requests_v WHERE change_request_number = :p_number. Cycle-time reporting compares request_date to approved_date or applied_date, while audit queries reconcile created_by and last_updated_by against the concurrent request columns. Developers should treat the view as read-oriented and direct DML to the base table through supported APIs.