Search Results yield_type




Overview
Explore in AI Chat

Overview

OKL_CS_LEASE_RENEWALS_UV is a read-only database view owned by the APPS schema within the Oracle Lease and Finance Management (OKL) module of Oracle E-Business Suite. Its purpose is to present lease and finance transaction requests — specifically those associated with renewal and restructure activity — in a denormalized, user-friendly form suitable for reporting, inquiry screens, and integration. Rather than requiring join logic against lookup and user tables, the view surfaces already-resolved status and type descriptions alongside the raw request data.

The view is valid and exposed to external consumers such as Oracle Reports, OBIEE extracts, custom concurrent programs, and SOA or REST-based integrations. Because it abstracts the underlying transactional tables, it provides a stable, presentation-oriented interface for the renewal request lifecycle. It is relevant to both EBS 12.1.1 and 12.2.2, where the OKL data model remains consistent.

Underlying Base Objects

The view is defined over four documented base objects:

  • OKL_TRX_REQUESTS (SYNONYM) — the primary transactional source, aliased as TRQ. It holds the lease transaction request records, including amounts, terms, statuses, and types.
  • FND_LOOKUPS (VIEW) — joined twice, aliased as STAT and TYPE, to translate lookup codes into meaningful descriptions using lookup types OKL_REQUEST_STATUS and OKL_REQUEST_TYPE.
  • FND_USER (SYNONYM) — aliased as USR, joined on TRQ.LAST_UPDATED_BY = USR.USER_ID to resolve the requesting user's name.
  • FND_GLOBAL (PACKAGE) — referenced for session context such as responsibility and user, consistent with ETRM metadata.

The join to FND_LOOKUPS is an inner join constrained by lookup type, meaning any request with an unseeded status or type code would be excluded from the result set. The join to FND_USER is likewise inner, so unresolved user IDs are suppressed.

Key Columns

The view exposes 24 columns that map closely to the underlying request attributes:

Common Use Cases and Queries

A frequent scenario is identifying which user raised a renewal request, which is served directly by the REQUESTED_BY column. A typical query lists pending renewals with requester and status:

  • SELECT request_number, requested_by, request_status, request_type, rent, start_date FROM okl_cs_lease_renewals_uv WHERE requested_by = 'JSMITH';
  • SELECT request_status, COUNT(*) FROM okl_cs_lease_renewals_uv GROUP BY request_status;
  • SELECT request_number, rent, yield, term FROM okl_cs_lease_renewals_uv WHERE past_due_yn = 'Y' AND restructure_date IS NULL;

Because REQUESTED_BY derives from LAST_UPDATED_BY rather than a dedicated requester column, analysts should recognize that the value reflects the last user to modify the request, not necessarily the original originator. For original attribution, CREATED_BY or the base OKL_TRX_REQUESTS audit columns should be consulted.