Results for “payment_frequency_code”

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

Overview

OKL_LEASE_RENEWALS_ALL_UV is a read-only database view owned by the APPS schema in Oracle E-Business Suite, defined within the OKL (Lease and Finance Management) product. It consolidates lease renewal request information across all operating units into a single, security-neutral result set, which distinguishes it from the operational and security-enabled views typically used by the forms-based renewal workflow. The "_ALL_UV" suffix reflects the EBS convention for a user-facing view spanning all operating units without an ORG_ID restriction clause in the view text.

The view is documented as VALID at both the 12.1.1 and 12.2.2 release levels of Oracle ETRM. Its principal role is reporting and integration: it denormalizes transactional renewal requests into a presentation-friendly shape by joining status and type codes to their user-facing lookup meanings, and by resolving the requesting user's login name. Downstream reporting tools, custom concurrent programs, and integration extracts can consume the view directly rather than reconstructing the join logic against the base transaction table.

Underlying Base Objects

According to the documented metadata, the view is constructed over the following objects:

• OKL_TRX_REQUESTS (SYNONYM) — the primary transactional source, referenced by the alias TRQ. This is the base table holding each lease renewal (restructure) request header.
• FND_LOOKUPS (VIEW) — referenced twice, aliased STAT and TYPE, to translate the request status code and request type code into descriptive meanings.
• FND_USER (SYNONYM) — aliased USR, joined on TRQ.LAST_UPDATED_BY = USR.USER_ID to derive the requesting user.
• FND_GLOBAL (PACKAGE) — listed among the referenced base objects; it supplies the session and application context (such as org and user context) used indirectly through the underlying base objects and lookups.

The joins are inner joins keyed on lookup type values OKL_REQUEST_STATUS and OKL_REQUEST_TYPE, meaning a renewal request surfaces only when both code values have a matching enabled lookup entry of the correct type.

Key Columns

The view exposes twenty-four columns. The most significant include:

• REQUEST_NUMBER / REQUEST_ID — the human-readable renewal request number and its internal primary key.
• OBJECT_VERSION_NUMBER — the optimistic locking version, useful for detecting concurrent changes in integration scenarios.
• KHR_ID / PARENT_KHR_ID — identifiers linking the request to the lease (KHR) contract being renewed and, where applicable, to a parent contract.
• REQUEST_STATUS_CODE / REQUEST_STATUS and REQUEST_TYPE_CODE / REQUEST_TYPE — the raw lookup codes paired with their translated meanings.
• REQUEST_DATE / REQUESTED_BY — derived from LAST_UPDATE_DATE and the FND_USER join, indicating who submitted the request and when.
• RENT, CURRENCY_CODE, YIELD, YIELD_TYPE, RESIDUAL — the commercial terms proposed in the renewal.
• START_DATE, END_DATE, TERM, RESTRUCTURE_DATE, PAYMENT_FREQUENCY_CODE — the proposed term structure of the renewed lease.
• PAST_DUE_YN, COMMENTS, CREATED_BY — exception indicator and descriptive attributes.

Common Use Cases and Queries

Typical uses include renewal pipeline reporting, aging of open renewal requests, and bulk extraction for downstream lease administration or BI repositories.

Renewal pipeline by status:

• SELECT REQUEST_NUMBER, REQUEST_STATUS, REQUEST_TYPE, REQUESTED_BY, START_DATE, END_DATE, RENT, CURRENCY_CODE FROM OKL_LEASE_RENEWALS_ALL_UV WHERE REQUEST_STATUS IN ('APPROVED','PENDING_APPROVAL') ORDER BY REQUEST_DATE DESC;

Renewals against a specific contract and past-due exceptions:

• SELECT REQUEST_NUMBER, KHR_ID, PARENT_KHR_ID, REQUEST_STATUS, RESTRUCTURE_DATE, PAST_DUE_YN FROM OKL_LEASE_RENEWALS_ALL_UV WHERE KHR_ID = :p_khr_id;
• SELECT REQUEST_NUMBER, REQUESTED_BY, REQUEST_DATE, REQUEST_STATUS FROM OKL_LEASE_RENEWALS_ALL_UV WHERE PAST_DUE_YN = 'Y';

Because the view contains no operating unit predicate, consumers requiring organizational segregation must apply their own security filtering, typically by joining to contract or org-striping tables rather than relying on the view itself.