Search Results oki_cov_prd_lines




Overview
Explore in AI Chat

Overview

OKI_COV_PRD_LINES is a Contracts Intelligence table in Oracle E-Business Suite that stores information about covered product lines within Contracts for Service. It belongs to the OKI product/module, which Oracle classifies as Contracts Intelligence (Obsolete). In the documented ETRM 12.1.1 physical schema, the table is owned by OKI and contains 91 columns. The metadata explicitly notes that this table is not implemented in this database — meaning references to it describe a legacy or dormant structure, and the object may not exist as a populated, supported artifact in a working 12.1.1 or 12.2.2 instance.

Functionally, a covered product line represents a serviceable item under a service contract: the product being covered, the associated contract line, pricing, quantities, installation and order details, and the sites and contacts related to billing, shipping, and installation. It therefore bridges contract header/line information with installed base and covered-product data.

The ETRM relationship data classifies this object as a standalone table via a heuristic Data Vault analysis of its foreign key structure; no parent-child FK links were mined. This should be read as a modeling suggestion only: in a Data Vault design, the table would not naturally resolve into a hub or link with confidence, and could be treated as an isolated satellite-like structure keyed on its own surrogate identifier. The documented primary key is OKI_COV_PRD_LINES_PK on CLE_ID, and a unique index OKI_COV_PRD_LINES_U1 also exists on CLE_ID.

Key Information Stored

The surrogate primary key is CLE_ID, which uniquely identifies each covered product line record. The unique index OKI_COV_PRD_LINES_U1 duplicates this on CLE_ID, indicating the table has a single-column business-key candidate rather than a composite natural key. The most significant columns include:

Common Use Cases and Queries

Because the table is documented as not implemented, its primary relevance is historical migration analysis, data-model archaeology, or reporting in legacy Contracts for Service environments. Typical query patterns would join covered product lines back to their contract header using CHR_ID or COMPLETE_CONTRACT_NUMBER, and resolve parent-child relationships through PARENT_CLE_ID:

  • Contract coverage listing — select CLE_ID, COMPLETE_CONTRACT_NUMBER, LINE_NUMBER, SERVICE_ITEM, COV_PROD_QUANTITY, UNIT_PRICE, CURRENCY_CODE filtered by START_DATE/END_DATE to list active covered products per contract.
  • Renewal exposure — filter on IS_EXP_NOT_RENEWED_YN = 'Y' and END_DATE to identify expiring coverage that will not renew.
  • Self-join for line hierarchy — join a.CLE_ID = b.PARENT_CLE_ID to reconstruct parent/child product line structures.
  • Pricing reconciliation — compare UNIT_PRICE against PRICE_NEGOTIATED, SOB_PRICE_UNIT, and BASE_PRICE_UNIT across currencies.
  • Installed base reporting — aggregate by INVENTORY_ORGANIZATION_ID, COV_PROD_INSTALL_SITE_ID, or SYSTEM_NAME to report serviced assets.

A representative pattern: SELECT CLE_ID, COMPLETE_CONTRACT_NUMBER, SERVICE_ITEM, COV_PROD_QUANTITY FROM OKI_COV_PRD_LINES WHERE END_DATE >= SYSDATE AND NVL(IS_EXP_NOT_RENEWED_YN,'N') = 'N';

Related Objects

The mined relationship data classifies OKI_COV_PRD_LINES as standalone, with no formal foreign keys documented. Logical associations inferred from column contents include the following significant objects:

  • Contract headers via CHR_ID / COMPLETE_CONTRACT_NUMBER (OKI contract header table).
  • Contract lines via LINE_NUMBER and PARENT_CLE_ID self-reference.
  • Covered product / customer item tables via COVERED_PRODUCT_ID and CUSTOMER_PRODUCT_ITEM_ID.
  • Order management tables via COV_PROD_ORDER_NUMBER, COV_PROD_ORDER_LINE_ID.
  • Site and party tables (bill-to, ship-to, install) via the COV_PROD_*_SITE_ID columns.
  • Inventory organization via INVENTORY_ORGANIZATION_ID.
  • Product agreement via PRODUCT_AGREEMENT_ID.

Because OKI is obsolete and the object is not implemented, new development should not depend on this table; integration or reporting requirements should target currently supported Service Contracts and installed base tables instead.