Search Results request_status




Overview
Explore in AI Chat

Overview

The APPS.OKL_CS_REQUESTS_UV view is a reporting and integration object within the Oracle Leasing and Finance Management (OKL) module of Oracle E-Business Suite, available in releases 12.1.1 and 12.2.2. It presents a denormalized, user-friendly projection of transactional requests captured in the OKL transaction request table, enriching each row with the decoded meaning of its status and type codes. The view serves as the principal read-only interface through which concurrent programs, OAF pages, and custom reports retrieve request information without directly joining lookup tables.

Because it exposes a decoded REQUEST_STATUS column derived from the OKL_REQUEST_STATUS lookup type, the view is the natural starting point for any inquiry or report filtered on request_status. Rather than requiring the caller to resolve REQUEST_STATUS_CODE against FND_LOOKUPS, the view performs that resolution internally, ensuring consistent terminology and reducing the risk of incorrect joins in downstream SQL.

Underlying Base Objects

The view is defined over three documented base objects:

  • OKL_TRX_REQUESTS (SYNONYM) — the primary transactional source. Aliased as TRQ, it supplies the request number, request identifier, KHR identifiers, status and type codes, comments, and creation date.
  • FND_LOOKUPS (VIEW) — joined twice. The alias STAT resolves REQUEST_STATUS_CODE against lookup type OKL_REQUEST_STATUS, producing the REQUEST_STATUS column; the alias TYPE resolves REQUEST_TYPE_CODE against lookup type OKL_REQUEST_TYPE, producing the REQUEST_TYPE column.
  • FND_GLOBAL (PACKAGE) — referenced by the underlying request table or its dependent objects for session context such as user and responsibility identifiers.

The join predicates are inner joins on LOOKUP_CODE with the respective LOOKUP_TYPE filters, so only requests whose status and type codes have valid, active lookup definitions are returned. Requests carrying orphaned or disabled lookup codes will be suppressed from the result set — a behavior worth noting when reconciling view output against the base table.

Key Columns

  • REQUEST_NUMBER — the business-facing identifier of the request, suitable for display and search.
  • REQUEST_ID — the internal primary key (TRQ.ID) used for joins and drill-down navigation.
  • KHR_ID — the associated contract or KHR (contract header/line) identifier linking the request to its originating transaction context.
  • REQUEST_STATUS_CODE — the coded value stored in the base table; useful for exact-match predicates and indexing.
  • REQUEST_STATUS — the decoded meaning from OKL_REQUEST_STATUS, which is the column most commonly referenced in reporting and in searches for request_status.
  • REQUEST_TYPE_CODE / REQUEST_TYPE — the coded and decoded request classification from OKL_REQUEST_TYPE.
  • COMMENTS — free-text remarks captured with the request.
  • REQUEST_DATE — the creation timestamp of the request, derived from TRQ.CREATION_DATE.
  • PARENT_KHR_ID — the parent contract identifier, enabling hierarchical analysis of related requests.

Common Use Cases and Queries

Typical uses include open-request worklists, status distribution reporting, and integration extracts that feed external workflow or dashboard tools. Because the view already decodes status and type, most queries filter or group on the descriptive columns.

Retrieve all requests in a given status:

  • SELECT request_number, request_id, khr_id, request_status, request_date FROM apps.okl_cs_requests_uv WHERE request_status = 'Pending';

Count requests by status and type:

  • SELECT request_status, request_type, COUNT(*) FROM apps.okl_cs_requests_uv GROUP BY request_status, request_type;

Drill down on a specific contract:

  • SELECT request_number, request_status, comments FROM apps.okl_cs_requests_uv WHERE khr_id = :khr_id ORDER BY request_date DESC;

For exact-match predicates on coded values, filtering on REQUEST_STATUS_CODE is preferable for performance; filters on REQUEST_STATUS should be applied when business-friendly labels are required.