Search Results okl_cov_prod_lines_v




Overview
Explore in AI Chat

Overview

The OKL_COV_PROD_LINES_V view is a reporting and integration object owned by the APPS schema within the Oracle E-Business Suite Leasing and Finance Management module (OKL). Its purpose is to expose covered product lines that originate in Oracle Service Contracts. In leasing and finance business flows, a "covered product" describes an asset or item that is placed under a service contract, and this view provides a consolidated, read-only representation of those lines so that other ETRM components, reports, and interfaces can consume them without navigating the underlying Service Contracts schema directly.

The view isolates records based on two defining conditions: the line style must be COVER_PROD, and the parent contract header must carry a service contract type (SCS_CODE = 'SERVICE'). This filters the result set to genuine covered-product lines belonging to service contracts and excludes unrelated contract line records. The view is documented as VALID and is available in both 12.1.1 and 12.2.2 environments.

Underlying Base Objects

The view is defined over the core Oracle Service Contracts (OKC) tables, referenced through APPS synonyms. The documented base objects are:

  • OKC_K_LINES_B — the base (non-translated) contract lines table, aliased CLE, supplying line identifiers, start and end dates, status code, and the contract header reference (DNZ_CHR_ID).
  • OKC_K_LINES_TL — the translation table, aliased TL, supplying the language-dependent NAME and ITEM_DESCRIPTION columns, joined on ID and restricted to the session language via USERENV('LANG').
  • OKC_LINE_STYLES_B — the line styles table, aliased LSE, joined on LSE_ID to enforce the COVER_PROD line style filter.
  • OKC_K_HEADERS_B — the contract headers table, aliased CHR, joined on DNZ_CHR_ID and filtered by SCS_CODE to restrict results to service contracts. It also supplies AUTHORING_ORG_ID.

The joins follow the contract line to its style, its owning header, and its translated text, producing one row per covered product line per language.

Key Columns

  • NAME — the translated name of the covered product line from OKC_K_LINES_TL.
  • DESCRIPTION — the translated item description of the line.
  • START_DATE_ACTIVE — the line start date (CLE.START_DATE), indicating when the coverage becomes effective.
  • END_DATE_ACTIVE — the line end date (CLE.END_DATE), indicating when coverage expires.
  • STATUS — a derived availability indicator. A value of 'I' (inactive) is returned when the current date precedes the start date or exceeds the end date; otherwise 'A' (active). This is computed with nested DECODE and SIGN logic against SYSDATE.
  • STS_CODE — the underlying line status code from the base line record.
  • ORG_ID — the authoring organization identifier sourced from the contract header, enabling multi-org reporting.

Two internal identifier columns (ID1 from CLE.ID and a literal '#' ID2) also appear in the view definition but are not part of the documented public column list.

Common Use Cases and Queries

This view is typically used to report active covered products, support lease-to-service reconciliation, and feed downstream interfaces requiring only currently effective coverage. A representative query listing active covered products for the current organization follows:

SELECT name, description, start_date_active, end_date_active, sts_code, org_id
FROM apps.okl_cov_prod_lines_v
WHERE status = 'A'
ORDER BY name;

To review coverage that has expired or is not yet effective:

SELECT name, start_date_active, end_date_active, org_id
FROM apps.okl_cov_prod_lines_v
WHERE status = 'I';

For multi-organization environments, results can be scoped with a predicate on ORG_ID to isolate a specific operating unit. Because STATUS is computed dynamically at query time against SYSDATE, reports always reflect the current effective state of each covered product line without requiring date arithmetic on the caller's side. All queries should be issued as the APPS schema user or a responsibility with equivalent access to the OKL reporting objects.