Results for “okl_prod_strm_types_v”

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

Overview

OKL_PROD_STRM_TYPES_V is an APPS-owned view within the Oracle E-Business Suite OKL (Leasing and Finance Management) product, delivered as part of the ETRM (Enterprise Transaction and Reporting Model) layer in release 12.1.1 and 12.2.2. Its documented purpose is to represent the association of stream types with products — the intersection entity that determines which pricing or accounting streams are valid for a given lease or finance product.

The view is a thin, pass-through wrapper defined exclusively over the OKL_PROD_STRM_TYPES synonym. No joins, filters, or expressions are applied; every column is a direct projection of the underlying base table attribute, with ROWID additionally exposed as ROW_ID. Because the view performs no transformation, it inherits the base table's referential integrity and validation state (VALID) and behaves identically to querying the synonym directly.

The relevance of this view to a search on "accrual_yn" is direct: ACCRUAL_YN is one of the columns exposed by the view. It indicates, at the stream-type-to-product association level, whether the associated stream type accrues for the product. This makes the view a convenient reference point for reporting on accrual behavior without needing to resolve the underlying table name or the product hierarchy.

Underlying Base Objects

The view is defined over a single documented base object:

• OKL_PROD_STRM_TYPES (SYNONYM) — the base table holding product-to-stream-type associations. The view selects all rows and all listed columns from this synonym with no WHERE clause, so row counts and cardinality match the base exactly.

Because only one base object is referenced, there is no join condition to consider and no risk of row amplification. Any change to the base table's data is immediately visible through the view. Conversely, the view is not updatable through its exposed columns in the general case; the presence of ROW_ID, OBJECT_VERSION_NUMBER, and WHO columns (CREATED_BY, CREATION_DATE, LAST_UPDATE_DATE, LAST_UPDATED_BY, LAST_UPDATE_LOGIN) is characteristic of an ETRM-style interface intended primarily for read-only reporting, not for DML.

Key Columns

• ROW_ID — the base table ROWID, uniquely identifying the association record; useful for de-duplication and direct-row correlation.
• ID — the primary key of the association record. Together with the columns below, it identifies a unique product/stream-type pairing.
• ACCRUAL_YN — flag indicating whether accrual applies to the stream type for the product. This is the column most relevant to accrual-related reporting.
• STY_ID — stream type identifier; foreign key to the stream type definition.
• PDT_ID — product identifier; foreign key to the product definition.
• FROM_DATE / TO_DATE — effective dating window for the association, supporting date-effective queries and historical reconstruction.
• OBJECT_VERSION_NUMBER — optimistic locking column used by the underlying application logic.
• CREATED_BY, CREATION_DATE, LAST_UPDATE_DATE, LAST_UPDATED_BY, LAST_UPDATE_LOGIN — standard WHO/audit columns for change tracking.

Common Use Cases and Queries

Because the view summarizes accrual behavior per product and stream type, it is commonly used to list which stream types accrue for a given product and to produce audit evidence of accrual configuration.

SELECT id, pdt_id, sty_id, accrual_yn, from_date, to_date
FROM   apps.okl_prod_strm_types_v
WHERE  accrual_yn = 'Y';

A second typical query restricts to currently effective associations and orders by product, supporting operational reconciliation:

SELECT pdt_id, sty_id, accrual_yn
FROM   apps.okl_prod_strm_types_v
WHERE  SYSDATE BETWEEN from_date AND NVL(to_date, SYSDATE + 1)
ORDER  BY pdt_id, sty_id;

To confirm whether any association exists for a specific stream type, a simple existence check on STY_ID is sufficient, since the view returns one row per association. As the view is a pure projection, all filters and joins — including lookups to product and stream-type reference tables — must be supplied by the query itself; none are embedded in the view.