Search Results display_in_lease_center

Overview

OKL_SEC_INVESTOR_DTLS_UV is a reporting view owned by the APPS schema in Oracle E-Business Suite, delivered as part of the OKL – Lease and Finance Management (also referred to as Oracle Lease Management / ETRM) product family. Its documented description is "Investor Agreement Investor Details View." The view consolidates investor agreement header information with the pooling and stream-type attributes that govern how lease contracts are grouped and presented within the Lease Center.

The name of the view and the presence of the DISPLAY_IN_LEASE_CENTER column indicate that it was purpose-built to support the investor-side display of lease and finance information, particularly where securitization, syndication, or investor agreements are involved. The view exposes both contract-level identity and lookup-driven descriptive values, making it suitable for reporting, integration extracts, and UI data sources that need to resolve investor agreements and their associated pools without embedding the join logic in each consumer. Because it is a view rather than a table, it presents a read-only, always-current projection of the underlying transactional data.

Underlying Base Objects

The view text draws on a defined set of base objects. The documented referencing metadata lists the following: FND_GLOBAL (package), FND_LOOKUPS (view), and the synonyms OKC_K_HEADERS_ALL_B, OKC_STATUSES_TL, OKL_K_HEADERS, OKL_POOLS, OKL_POOL_CONTENTS, and OKL_STRM_TYPE_B.

• OKC_K_HEADERS_ALL_B supplies the core contract header rows. It is referenced twice in the UNION — once as the investor agreement (filtered on SCS_CODE = 'INVESTOR') and once as the related pool host contract.
• OKL_K_HEADERS provides the OKL-specific contract extension, including SECURITIZATION_TYPE, which is decoded into the investor agreement type meaning.
• OKL_POOLS and OKL_POOL_CONTENTS provide pool identity and the association between pools and contracts, including POOL_NUMBER and DISPLAY_IN_LEASE_CENTER.
• OKL_STRM_TYPE_B supplies stream type definitions, filtered to subclasses RENT and RESIDUAL, with subclass and purpose meanings resolved through FND_LOOKUPS.
• OKC_STATUSES_TL resolves the contract status code into a language-specific meaning via USERENV('LANG').
• FND_LOOKUPS resolves three distinct lookup types: OKL_STREAM_TYPE_SUBCLASS, OKL_STREAM_TYPE_PURPOSE, and OKL_SECURITIZATION_TYPE.

The view is defined as a UNION ALL of two branches. The first returns fully resolved investor agreement details, while the second returns pool and stream information only, with the agreement columns cast to NULL. This structure ensures pool contents without a matching investor agreement are still surfaced.

Key Columns

• KHR_ID — Contract header identifier; the primary join key to the OKL contract header.
• INVESTOR_AGRMNT_NUMBER — Contract number of the investor agreement (NULL in the second UNION branch).
• INVESTOR_AGRMNT_STATUS — Language-resolved status meaning from OKC_STATUSES_TL.
• INVESTOR_AGRMNT_TYPE — Decoded securitization type; values map SALE and LOAN to SECURITIZATION, while SYNDICATION remains SYNDICATION.
• STRM_TYPE_SUBCLASS — Stream type subclass meaning, restricted to RENT or RESIDUAL.
• STRM_TYPE_PURPOSE — Stream type purpose meaning from FND_LOOKUPS.
• POOL_NUMBER — Identifier of the pool containing the contract.
• DISPLAY_IN_LEASE_CENTER — Flag from OKL_POOLS controlling whether the pool is presented in the Lease Center UI.

Common Use Cases and Queries

Typical consumers include investor reporting extracts, securitization reconciliation, and Lease Center pool filtering. A query to retrieve all investor agreements displayed in the Lease Center might read:

SELECT khr_id, investor_agrmnt_number, investor_agrmnt_status, investor_agrmnt_type, pool_number FROM okl_sec_investor_dtls_uv WHERE display_in_lease_center = 'Y';

To isolate residual streams by pool:

SELECT pool_number, strm_type_subclass, strm_type_purpose FROM okl_sec_investor_dtls_uv WHERE strm_type_subclass = 'RESIDUAL';

Because the view relies on USERENV('LANG') and FND_LOOKUPS, queries executed in different sessions may return translated meanings, so reports should not hard-code expected meaning strings. Joins or DISTINCT logic already applied in the view make it safe to use directly as a reporting source without additional deduplication in most cases.