Search Results update_elig_cvrd_dpnt




Overview

APPS.BEN_ELIG_CVRD_DPNT_API is a PL/SQL package body within the Oracle E-Business Suite Advanced Benefits (BEN) module. It provides the programmatic interface for creating, maintaining, and deleting records that represent an eligible covered dependent within a participant's enrollment result. In benefits processing, a covered dependent record links a dependent person to a participant enrollment result and carries the dependent's coverage start and end dates, a coverage pending indicator, and a set of descriptive (PDP) attribute columns used to store flexfield-style supplementary data.

The package is classified as an API in the ETRM metadata, meaning it is intended to be the supported entry point for external callers rather than a private implementation unit. Its procedures enforce business rules, write to the underlying BEN base tables, and manage the action and result records that the benefits engine relies upon. The header comment (bepdpapi.pkb) and the 2008 build date confirm the package is a long-standing component of the benefits architecture and remains shipped in both 12.1.1 and 12.2.2.

Key Procedures and Functions

  • CREATE_ELIG_CVRD_DPNT — Inserts a new eligible covered dependent record, accepting the enrollment result, dependent person, coverage dates, coverage pending flag, and up to twenty-one attribute columns. It returns the generated primary key and the effective dating boundaries, and supports a validation-only mode.
  • UPDATE_ELIG_CVRD_DPNT — Modifies an existing covered dependent record. This is the procedure most frequently targeted by the search term "update_elig_cvrd_dpnt" and is the standard mechanism for adjusting coverage dates, pending status, or attribute values.
  • DELETE_ELIG_CVRD_DPNT — Removes an eligible covered dependent record in accordance with the effective-dating and referential rules of the benefits tables.
  • LCK — Row locking utility used to serialize concurrent modification of a covered dependent record prior to update or delete operations.
  • DPNT_ACTN_ITEMS — Processes the action items that must accompany dependent-related changes so that the benefits action and result tables remain consistent.
  • DPNT_ACTN_ITEMS_W — A wrapper variant of the action item processing logic.
  • ADD_USAGE — Registers a usage (reference) of the covered dependent record, supporting dependency tracking.
  • REMOVE_USAGE — Releases a previously registered usage.
  • CHK_MAX_NUM_DPNT_FOR_PEN — Validates that the number of covered dependents does not exceed the maximum permitted for the plan or plan option.

Tables Accessed

The package reads and writes BEN_ELIG_CVRD_DPNT_F, the base table holding covered dependent rows, and interacts with BEN_PRTT_ENRT_RSLT_F and BEN_PRTT_ENRT_ACTN_F to keep enrollment results and actions synchronized. Plan and option context is drawn from BEN_PL_F, BEN_OPT_F, and BEN_OIPL_F. Design requirements and their relationships are validated against BEN_DSGN_RQMT_F, BEN_DSGN_RQMT_RLSHP_TYP, and BEN_PER_IN_LER. Dependent identity and coverage evidence come from PER_ALL_PEOPLE_F, PER_CONTACT_RELATIONSHIPS, PER_PERSON_TYPES, and PER_PERSON_TYPE_USAGES_F. Additional benefit tables consulted include BEN_CVRD_DPNT_CTFN_PRVDD_F and BEN_PRMRY_CARE_PRVDR_F, which hold dependent certification and primary care provider data.

Usage Notes

BEN_ELIG_CVRD_DPNT_API is normally invoked indirectly by the Oracle Benefits forms and by benefits concurrent processes rather than being called directly from end-user interfaces. The ETRM metadata records that the package is referenced by fifteen other packages, indicating it functions as a shared service across enrollment, life event, and dependent certification processing. When developing custom code, developers should call this API instead of writing directly to BEN_ELIG_CVRD_DPNT_F so that effective dating, action item generation, usage tracking, and maximum dependent validation are applied consistently. Because UPDATE_ELIG_CVRD_DPNT operates on effective-dated rows and relies on the LCK procedure, callers should supply accurate primary keys and anticipate validation errors returned when dependent limits or design requirements are violated.