Search Results okl_pool_assets_lov_uv




Overview
Explore in AI Chat

Overview

OKL_POOL_ASSETS_LOV_UV is a database view owned by the APPS schema in Oracle E-Business Suite, delivered as part of the OKL (Leasing and Finance Management) product family. The view is documented with VALID status and is described in the ETRM metadata as the "Securitization - Pool asset lists of values UI view." Its purpose is to supply the rows displayed by the pool assets list of values (LOV) used within securitization setup and processing screens, allowing users to select fixed assets that are eligible to be attached to a securitization pool.

Unlike a transactional table, this object is a read-only projection. It performs no data manipulation and holds no storage of its own; it derives its result set dynamically from leased contract lines linked to fixed assets. Because it is a single-purpose LOV view, it is generally queried by the EBS forms layer rather than being referenced directly by end users. In reporting or integration scenarios, however, the view can be used to identify the pool of assets that the application itself considers selectable for securitization purposes.

Underlying Base Objects

The view text joins six base objects, all exposed to APPS through synonyms in the documented ETRM 12.2.2 metadata: OKC_K_HEADERS_B, OKC_K_LINES_B, OKC_K_ITEMS, FA_ADDITIONS_B, FA_ADDITIONS_TL, and OKC_LINE_STYLES_B. These span two functional areas: the OKC/OKL contract schema, which stores the leasing contract header, line, item, and line-style information, and the FA fixed assets schema, which stores asset definitions and their translated descriptions.

The driving logic is that of contract structure. OKC_K_HEADERS_B supplies the contract header restricted to STS_CODE = 'BOOKED' and SCS_CODE = 'LEASE'. OKC_K_LINES_B provides the contract lines, which are joined to OKC_LINE_STYLES_B to retain only lines whose LTY_CODE = 'FIXED_ASSET'. OKC_K_ITEMS then links contract lines to the underlying asset through OBJECT1_ID1 (the asset ID as character), OBJECT1_ID2 = '#', and JTOT_OBJECT1_CODE = 'OKX_ASSET'. The resulting asset is resolved against FA_ADDITIONS_B for its identifier and number, and FA_ADDITIONS_TL supplies the language-specific description.

Key Columns

  • ASSET_ID — The unique identifier of the fixed asset in FA_ADDITIONS_B, sourced as FAAB.ASSET_ID. This is the value returned to the LOV for selection.
  • ASSET_NUMBER — The user-visible asset number from FA_ADDITIONS_B, typically the value shown in the LOV display field.
  • DESCRIPTION — The asset description from FA_ADDITIONS_TL, filtered by LANGUAGE = USERENV('LANG') so that the user sees the description in their current session language.

These three columns form the minimal LOV contract: an identifier, a display key, and a descriptive label. No additional context columns such as contract number or pool identifier are exposed, keeping the LOV focused on asset selection alone.

Common Use Cases and Queries

The primary use case is populating the asset LOV during securitization pool definition, where only leased fixed assets belonging to booked lease contracts are valid candidates. A typical verification query selecting from the view is:

  • SELECT asset_id, asset_number, description FROM okl_pool_assets_lov_uv WHERE asset_number LIKE :p_asset_num;
  • SELECT asset_id, asset_number, description FROM okl_pool_assets_lov_uv ORDER BY asset_number;

In reporting or reconciliation, the view can be joined back to pool or contract data to confirm which assets are currently eligible, or used to validate that a given asset appears in the securitization candidate set before pool assignment. Because the view enforces contract status and line-style restrictions internally, replicating its logic outside the view should be avoided; direct select statements against the view ensure consistent results with the application's own LOV behaviour.