Search Results recursive_yn

Overview

OKC_LINE_STYLES_V is a view owned by the APPS schema in Oracle E-Business Suite, belonging to the OKC (Contracts Core) product family. As documented in the ETRM metadata for releases 12.1.1 and 12.2.2, this view is defined over the OKC_LINE_STYLE_B base table, exposing line style definition data used throughout Oracle Contracts and its integration points with Order Management, Advanced Pricing, and Service Contracts.

The view serves as the primary read interface for line style configurations, which govern how contract lines behave during pricing, recursion, and item processing. Line styles are reusable templates that determine whether a line is priced, whether pricing recurs, whether service items are permitted, and the hierarchical parent-child relationships between styles. Because the underlying _B table stores language-independent columns and the _TL table stores translated name and description values, this view joins both to expose a single denormalized row per line style in the session's current language.

The view is marked VALID and is typically referenced by Oracle Forms, OAF pages, and concurrent programs rather than by end users directly. Developers and integrators query it to build validation lists, lookup-driven LOVs, and custom reports.

Underlying Base Objects

Per the documented view text, OKC_LINE_STYLES_V is defined as a join between two synonyms: OKC_LINE_STYLES_B and OKC_LINE_STYLES_TL. The join condition is LSEB.ID = LSET.ID AND LSET.LANGUAGE = USERENV('LANG'). The _B table supplies all functional attributes (pricing flags, hierarchy IDs, descriptive flexfield columns, audit columns), while the _TL table contributes the translatable NAME and DESCRIPTION and the SFWT_FLAG used for translation workflow.

OKC_LINE_STYLE_B is the base table named in the ETRM description, and OKC_LINE_STYLES_TL is the translation table. The USERENV('LANG') predicate ensures that only the row matching the caller's language environment is returned, preventing duplicate results when multiple translations exist. Because the view is defined on synonyms rather than fully qualified names, it remains portable across APPS installations and honors whatever synonyms are configured in the environment.

Key Columns

• ROW_ID — The ROWID of the base _B row, useful for direct row addressing.
• ID — Primary key of the line style; the join key between _B and _TL.
• LTY_CODE — Line type code associated with the style.
• LSE_PARENT_ID — Self-referencing parent style identifier, enabling hierarchical style definitions.
• OBJECT_VERSION_NUMBER — Optimistic locking column used by the framework.
• NAME / DESCRIPTION — User-facing, translatable labels from _TL.
• SFWT_FLAG — Translation workflow flag sourced from the _TL table.
• PRICED_YN, RECURSIVE_YN, ITEM_TO_PRICE_YN, PRICE_BASIS_YN, SERVICE_ITEM_YN, PROTECTED_YN — Behavioral flags controlling pricing, recursion, item pricing eligibility, and protection from deletion.
• LSE_TYPE — Classifies the style by usage type.
• ACCESS_LEVEL — Visibility/security level for the style.
• ATTRIBUTE_CATEGORY and ATTRIBUTE1–ATTRIBUTE15 — Descriptive flexfield (DFF) columns.
• APPLICATION_ID, CREATED_BY, CREATION_DATE, LAST_UPDATED_BY, LAST_UPDATE_DATE, LAST_UPDATE_LOGIN — Standard WHO audit columns.

Common Use Cases and Queries

Typical scenarios include validating a line style during contract authoring, populating an LOV for style selection, and auditing pricing behavior across existing styles. A basic lookup query:

SELECT id, name, lty_code, priced_yn, recursive_yn
FROM   apps.okc_line_styles_v
WHERE  protected_yn = 'N'
ORDER  BY name;

To inspect the style hierarchy:

SELECT child.name, parent.name AS parent_name, child.lse_type
FROM   apps.okc_line_styles_v child,
       apps.okc_line_styles_v parent
WHERE  child.lse_parent_id = parent.id(+);

To find styles permitting service items:

SELECT id, name, service_item_yn, price_basis_yn
FROM   apps.okc_line_styles_v
WHERE  service_item_yn = 'Y';

Because the view enforces USERENV('LANG'), reports automatically return names in the runtime language. Integrators should nonetheless always reference the view from the APPS schema or a synonym to avoid translation duplication and to honor the documented join semantics.