Search Results styb_purpose_meaning

Overview

OKL_STRM_TYPE_V is a read-only database view owned by the APPS schema in Oracle E-Business Suite Release 12.1.1 and 12.2.2. It belongs to the OKL product family, Oracle Lease and Finance Management (also referred to as Oracle Fusion Lease and Finance Management in later documentation). The view holds the definition of payment types, which in the OKL data model are known as stream types. A stream type classifies each cash flow or billing stream generated by a lease or loan contract, for example rent, tax, insurance, late charges, or residual value streams. The view consolidates the language-independent attributes stored on the base table with the translated descriptive attributes stored on the translation table, producing a single reporting-friendly row per stream type per session language.

Because the view joins the base and translation tables at query time, it automatically returns descriptions in the language of the current session as determined by USERENV('LANG'). This makes it the preferred source for reports, concurrent programs, and integrations that need user-facing payment type descriptions rather than internal codes.

Underlying Base Objects

The view is defined over the following documented objects:

• OKL_STRM_TYPE_B — the base table holding code, control flags, scope, class, and audit columns for each stream type. Referenced by synonym in the view text.
• OKL_STRM_TYPE_TL — the translation table holding NAME, SHORT_DESCRIPTION, DESCRIPTION, and SFWT_FLAG per language. The view restricts this table to STYT.LANGUAGE = USERENV('LANG').
• OKL_ACCOUNTING_UTIL — a PL/SQL package used in the view text. The function GET_LOOKUP_MEANING('OKL_STREAM_TYPE_PURPOSE', STYB.STREAM_TYPE_PURPOSE) is called to translate the stream type purpose code into its lookup meaning, exposed as the column STYB_PURPOSE_MEANING.

The join condition is STYB.ID = STYT.ID, so the primary identifier of the payment type is the ID column, with the base table supplying operational attributes and the translation table supplying descriptive text.

Key Columns

• ROW_ID / ID — ROW_ID is the ROWID of the base table row; ID is the primary key of the stream type.
• CODE — the internal code identifying the payment type.
• NAME, SHORT_DESCRIPTION, DESCRIPTION — translated values from OKL_STRM_TYPE_TL.
• SFWT_FLAG — translated flag, sourced from the translation table.
• STREAM_TYPE_SCOPE, STREAM_TYPE_SUBCLASS, STREAM_TYPE_CLASS — control attributes that determine how the stream is classified and processed.
• STREAM_TYPE_PURPOSE and STYB_PURPOSE_MEANING — the purpose code and its decoded lookup meaning via OKL_ACCOUNTING_UTIL.
• BILLABLE_YN, TAXABLE_DEFAULT_YN, FUNDABLE_YN, PERIODIC_YN, CAPITALIZE_YN, ACCRUAL_YN, CONTINGENCY — behavioral flags governing billing, taxation, funding, capitalization, accrual, and contingency treatment.
• ALLOCATION_FACTOR — the factor used when allocating amounts across streams.
• START_DATE, END_DATE — effective dating of the payment type definition.
• VERSION, OBJECT_VERSION_NUMBER, CUSTOMIZATION_LEVEL — versioning and extensibility metadata.
• ATTRIBUTE_CATEGORY and ATTRIBUTE1 through ATTRIBUTE15 — the DFF (descriptive flexfield) columns.
• CREATED_BY, CREATION_DATE, LAST_UPDATED_BY, LAST_UPDATE_DATE, LAST_UPDATE_LOGIN — standard audit columns.

Common Use Cases and Queries

Typical uses include lease payment type setup verification, billing stream reporting, and integrations that populate or validate stream type data. A simple lookup query to list billable payment types with their translated names:

SELECT id, code, name, stream_type_purpose, billable_yn
FROM   apps.okl_strm_type_v
WHERE  billable_yn = 'Y'
ORDER  BY name;

To report by purpose, the convenience column exposes the decoded lookup value:

SELECT id, name, stream_type_purpose, styb_purpose_meaning
FROM   apps.okl_strm_type_v
WHERE  start_date <= TRUNC(SYSDATE)
AND   (end_date IS NULL OR end_date > TRUNC(SYSDATE));

Most transactions reference stream types by ID; the view is therefore joined to contract tables or used in LOV queries. Note that the language restriction and the lookup function call are evaluated at query time, so behavior depends on the session language, and direct updates through the view are not supported.