Search Results ben_ler_rltd_per_cs_ler_f




Overview

BEN_LER_RLTD_PER_CS_LER_F is a table in the BEN (Advanced Benefits) schema of Oracle E-Business Suite, present in both 12.1.1 and 12.2.2. The table stores the configuration metadata that governs the detection of Life Events based on changes to related persons. More precisely, it defines the data changes on a related person that must occur in order to trigger life event detection within the benefits processing engine.

In the context of Oracle Advanced Benefits, a life event (for example, a marriage, birth, or change in dependent status) triggers an eligibility re-evaluation and potentially an enrollment opportunity for an employee. The BEN_LER_RLTD_PER_CS_LER_F table holds the rules that link a Life Event Reason (LER) to related-person change criteria, so the system knows which related-person data modifications constitute a detectable life event.

Based on heuristic Data Vault classification mined from the foreign-key structure, the table appears to be a standalone object. Practically, it functions as a configuration/definition table (logically a reference/setup table) that supplies the rules driving life event detection, rather than a transactional fact table. The classification is offered as a modeling suggestion only; the physical schema shows no documented foreign keys.

Key Information Stored

The table is keyed by a surrogate primary key, BEN_LER_RLTD_PER_CS_LER_F_PK, composed of LER_RLTD_PER_CS_LER_ID, EFFECTIVE_START_DATE, and EFFECTIVE_END_DATE. A second documented unique index, BEN_LER_RTLD_PER_CS_LER_F_PK (noting the transposed spelling "RTLD" in the documented name), carries the same three columns and is the business-key candidate and date-effective control.

The 45 documented columns include the following most important ones:

Common Use Cases and Queries

Administrators and implementers query this table to audit which related-person changes are configured to trigger specific life events, and to validate that configuration across business groups. Typical scenarios include troubleshooting why a life event was not detected, verifying that the mandatory-change flag is set correctly, and extracting a configuration listing for documentation or migration.

A sample query to list the rules for a given life event reason:

  • SELECT lrc.ler_rltd_per_cs_ler_id, lrc.ler_id, lrc.rltd_per_chg_cs_ler_id, lrc.chg_mandatory_cd, lrc.effective_start_date, lrc.effective_end_date FROM ben.ben_ler_rltd_per_cs_ler_f lrc WHERE lrc.ler_id = :p_ler_id AND TRUNC(SYSDATE) BETWEEN lrc.effective_start_date AND lrc.effective_end_date;

Reporting use cases include generating a cross-reference of life event reasons against related-person change causes, and auditing DFF attributes (LRC_ATTRIBUTE1–30) for customer-specific configuration. Because the table is date-effective, most queries should filter by effective dates to return only the current active row.

Related Objects

The documented metadata identifies no explicit foreign keys; the table is standalone in the FK sense. The most significant related objects, referenced through the configuration identifiers, are:

  • BEN_LER_RLTD_PER_CS_LER_F itself — its primary key BEN_LER_RLTD_PER_CS_LER_F_PK (LER_RLTD_PER_CS_LER_ID, EFFECTIVE_START_DATE, EFFECTIVE_END_DATE) defines uniqueness.
  • Life Event Reason configuration objects in the BEN schema, joined on LER_ID.
  • Related-person change-cause setup objects, joined on RLTD_PER_CHG_CS_LER_ID.
  • Business group / HR organization setup, joined on BUSINESS_GROUP_ID.
  • Advanced Benefits life event detection APIs and concurrent processes that consume these rules to trigger eligibility re-evaluation.