Search Results oks_cov_types_b_pk

Overview

OKS_COV_TYPES_B is a Service Contracts (OKS) module reference table that stores the defined coverage type codes for an Oracle E-Business Suite deployment, together with the importance ranking assigned to each. Coverage types drive how contract coverage is classified and prioritized on service contract lines, entitlement checks, and service request coverage validation. The table operates as a setup/seed data object rather than a transactional one: rows are maintained during implementation and are normally static thereafter. The _B suffix follows the standard Oracle EBS convention indicating the base table whose translated attributes would be held in a companion _TL table, though the documented physical schema for this object carries no translated columns.

The mined Data Vault classification is standalone, meaning the object is modeled as neither a hub, link, nor satellite under that heuristic. In practice, if a Data Vault representation were desired, CODE would serve as the natural business key of a hub, with the descriptive and audit columns forming a satellite; the absence of mined foreign key relationships is consistent with a self-contained lookup rather than a transactional entity.

Key Information Stored

The primary key of the table is OKS_COV_TYPES_B_PK, defined on the CODE column. This is significant: the primary key is the business key itself, not a generated surrogate, so CODE is both the unique identifier and the value that other objects reference. Important columns include:

• CODE — the coverage type code; primary key and business-key candidate.
• IMPORTANCE_LEVEL — the ranking or priority weight assigned to the coverage type, used for ordering and precedence in coverage evaluation.
• ENABLED_FLAG — controls whether the coverage type is available for selection.
• START_DATE_ACTIVE and END_DATE_ACTIVE — the effective dating window for the type.
• CREATED_BY, CREATION_DATE, LAST_UPDATED_BY, LAST_UPDATE_LOGIN, LAST_UPDATE_DATE — the standard Oracle EBS Who Columns audit set.
• ATTRIBUTE_CATEGORY and ATTRIBUTE1 through ATTRIBUTE15 — the standard DFF/extension columns reserved for customer-specific descriptive flexfield segments.

The documented schema exposes 26 columns; the remainder above are the descriptor flexfield placeholders that carry no seeded meaning until configured.

Common Use Cases and Queries

Typical usage is lookup and validation rather than transaction processing. A validation query used by interfaces and reports:

• SELECT code, importance_level FROM oks_cov_types_b WHERE enabled_flag = 'Y' AND TRUNC(SYSDATE) BETWEEN NVL(start_date_active, SYSDATE) AND NVL(end_date_active, SYSDATE) ORDER BY importance_level;
• Listing all active coverage types for a setup migration or configuration comparison between environments.
• Feeding LOV queries in concurrent program parameters and Service Contracts forms.
• Basis for coverage-type distribution reports showing which coverage types are actually referenced across contract lines.

Because the table is low-volume and effectively static, queries are simple lookups without heavy join cost. When combining with transactional coverage data, joins are made on the code column rather than on a numeric ID.

Related Objects

No foreign key relationships were mined for this object, reflecting its role as a standalone lookup. Related objects are therefore identified by shared usage of the CODE value as a foreign key in dependent tables, along with the standard Service Contracts coverage entities:

• Coverage definition and coverage-line tables in the OKS schema that carry a coverage type code referencing OKS_COV_TYPES_B.CODE.
• Service contract header and line objects that select a coverage type during contract authoring.
• Entitlement and service request coverage validation logic within the Service Contracts and Depot Repair flows.
• Setup/configuration extract programs and concurrent programs that list coverage types.
• The translated counterpart table, if present, joined on CODE for language-specific descriptions.

Any query that needs the coverage type descriptor should join on CODE and restrict to enabled rows within the active date window to avoid returning retired coverage types.