Search Results okl_indices_v




Overview
Explore in AI Chat

Overview

The OKL_INDICES_V view is a reporting and integration layer object within the Oracle E-Business Suite (EBS) Leasing and Finance Management module (OKL). It resides in the APPS schema and is documented as an interest rate header view. Its principal role is to expose index definitions — the underlying reference rates used to price and periodically re-price lease and finance contracts — in a stable, query-friendly form. Because it is a view rather than a base table, it allows reporting tools, concurrent programs, and external integrations to consume index header data without directly touching the transactional table. This separation promotes consistency of access and gives Oracle a controlled interface through which the shape of index data may be presented. In ETRM 12.1.1 and 12.2.2 the object is delivered with a VALID status, indicating that it is a supported, compiled component of the shipped application. Its presence allows developers to build custom queries, Oracle Reports, BI Publisher data templates, and interface extracts against a documented object name rather than an internal table.

Underlying Base Objects

The documented base object referenced by the view is the OKL_INDICES table, accessed through a synonym. The view text performs a straightforward projection from that table, aliased as IDXB, selecting a defined set of columns and their attributes. The view does not appear to perform joins or aggregations; it is a direct, one-to-one projection of the underlying header rows. Consequently, filters, ordering, and any business logic applied to the data must be supplied by the consuming query. Practically, this means the view returns the same number of rows as the base table and each view row corresponds to exactly one index header record. The synonym reference ensures that the view can be resolved correctly within the APPS schema regardless of the invoking session's default schema.

Key Columns

The view exposes a broad set of columns. The most significant are described below.

  • ID — the unique identifier of the index header record; the primary key for joining to related index detail or rate tables.
  • NAME — the user-defined or seeded name of the interest rate index, such as a specific benchmark rate.
  • DESCRIPTION — descriptive text clarifying the purpose or source of the index.
  • IDX_FREQUENCY — the frequency at which the index is published or reset, which drives re-pricing cycles.
  • IDX_TYPE — the classification of the index, distinguishing the category of reference rate.
  • OBJECT_VERSION_NUMBER — the optimistic locking version used by the application when manipulating the record.
  • ATTRIBUTE_CATEGORY and ATTRIBUTE1 through ATTRIBUTE15 — the standard Oracle EBS flexible attribute columns, available for customer-specific extensions.
  • ROW_ID — the underlying row identifier from the base table, useful for direct row addressing.
  • Audit columns — CREATED_BY, CREATION_DATE, LAST_UPDATED_BY, LAST_UPDATE_DATE, and LAST_UPDATE_LOGIN capture the standard who-did-what audit trail.
  • Concurrent program context — PROGRAM_ID, REQUEST_ID, PROGRAM_APPLICATION_ID, and PROGRAM_UPDATE_DATE record the request that last modified the row.

Common Use Cases and Queries

Typical usage centers on listing available indices, joining index headers to subordinate rate or contract data, and auditing configuration changes. A basic inventory query returns the principal business columns:

  • SELECT id, name, description, idx_type, idx_frequency FROM okl_indices_v ORDER BY name;
  • Locate a specific index by name: SELECT id, name FROM okl_indices_v WHERE name = :index_name;
  • Review recently modified definitions using audit columns: SELECT id, name, last_updated_by, last_update_date FROM okl_indices_v WHERE last_update_date >= :from_date ORDER BY last_update_date DESC;
  • Query flexfield values: SELECT id, name, attribute1, attribute2 FROM okl_indices_v WHERE attribute_category = :category;

Because the view is a plain projection, developers should apply the same security and performance considerations they would for the base table, including appropriate predicates and indexes on join keys such as ID.