Results for “per_cobra_coverage_benefits_v”

AI-generated from documented ETRM metadata — verify critical details on the linked pages.

Overview

The PER_COBRA_COVERAGE_BENEFITS_V view is a Human Resources (PER) product database object owned by the APPS schema and defined as VALID on Oracle E-Business Suite releases 12.1.1 and 12.2.2. Its stated purpose within the ETRM repository is to support the user interface of the COBRA coverage benefits functionality. COBRA coverage in Oracle Advanced Benefits allows an administrator to record and maintain the benefit coverages that a former employee or dependent elects to continue after a qualifying event, including the elements that represent those coverages and the elections associated with them.

Because the view joins the transactional COBRA coverage table to benefit classification and element type definitions, it exposes a denormalized, presentation-ready result set. A user searching for benefit_classification_name is typically seeking the human-readable classification label associated with a COBRA coverage record rather than the internal identifier. This view supplies that name directly, removing the need to join BEN_BENEFIT_CLASSIFICATIONS separately in reporting queries. Its role is therefore both UI support and a convenient reporting and integration surface for COBRA coverage data.

Underlying Base Objects

The documented base objects underlying the view are BEN_BENEFIT_CLASSIFICATIONS (synonym), FND_SESSIONS (synonym), HR_API (package), HR_CHKFMT (package), HR_LOOKUPS (view), PAY_ELEMENT_TYPES_F (synonym), PAY_ELEMENT_TYPES_F_TL (synonym), and PER_COBRA_COVERAGE_BENEFITS_F (synonym). The primary transactional source is PER_COBRA_COVERAGE_BENEFITS_F, aliased CCB, which stores the COBRA coverage benefit rows. It is joined to PAY_ELEMENT_TYPES_F and its translation table PAY_ELEMENT_TYPES_F_TL on ELEMENT_TYPE_ID, yielding ELEMENT_NAME. The element type is further linked to BEN_BENEFIT_CLASSIFICATIONS on BENEFIT_CLASSIFICATION_ID, producing BENEFIT_CLASSIFICATION_NAME.

Coverage type codes are resolved against HR_LOOKUPS using lookup type US_BENEFIT_COVERAGE, returning the meaning text. FND_SESSIONS is included to constrain the effective date range of the element type against the current session date. The packages HR_API and HR_CHKFMT are referenced by the view definition to support formatting and date-handling logic.

Key Columns

• COBRA_COVERAGE_BENEFIT_ID — primary identifier of the COBRA coverage benefit row.
• BENEFIT_CLASSIFICATION_NAME — descriptive classification of the associated benefit.
• ELEMENT_NAME — the payroll element name representing the coverage.
• COVERAGE_TYPE and COVERAGE_TYPE_MEANING — the lookup code and its translated meaning.
• COVERAGE_AMOUNT — the monetary or unit amount of the coverage.
• EFFECTIVE_START_DATE / EFFECTIVE_END_DATE — date-effective range of the record.
• COBRA_COVERAGE_ENROLLMENT_ID — link back to the enrollment.
• ACCEPT_REJECT_FLAG — whether the coverage was accepted or declined.
• BUSINESS_GROUP_ID and the ATTRIBUTE1–ATTRIBUTE20 descriptive flexfield columns.
• Audit columns: CREATED_BY, CREATION_DATE, LAST_UPDATED_BY, LAST_UPDATE_DATE, LAST_UPDATE_LOGIN.

Common Use Cases and Queries

Typical uses include listing all COBRA coverage benefits for a business group, reporting by classification, and extracting data for interfaces. The following query returns coverage details filtered by classification name.

SELECT benefit_classification_name,
       element_name,
       coverage_type_meaning,
       coverage_amount,
       effective_start_date,
       effective_end_date
  FROM apps.per_cobra_coverage_benefits_v
 WHERE business_group_id = :p_business_group_id
   AND benefit_classification_name = :p_classification_name
 ORDER BY element_name;

Administrators reviewing accept/reject decisions can filter on the flag, while effective-dated analysis uses the start and end date columns. Because the view is a UI-support object, Oracle does not guarantee its column list across patches; consumers should therefore restrict themselves to documented columns and avoid DML against the view, using the underlying _F tables for any maintenance.