Results for “ben_elig_dsbld_prte_d”

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

Overview

The view BEN_ELIG_DSBLD_PRTE_D is owned by the APPS schema and belongs to the BEN (Advanced Benefits) product module within Oracle E-Business Suite. It exposes disability participation eligibility criteria configured through the Advanced Benefits eligibility profile framework. In the Oracle EBS 12.1.1 and 12.2.2 data models, eligibility profiles are composed of one or more eligibility criteria records, each stored in a dedicated criteria table. This view surfaces the disability-related criterion, presenting rows that define whether a person marked with a specific disability code (DSBLD_CD) is included in or excluded from a given eligibility profile.

The "D" suffix in the view name follows the Oracle EBS convention for a database view that is derived from an underlying "_F" table. The view is used primarily for reporting, concurrent program processing, and integration extracts that need to evaluate benefit eligibility profiles without navigating the full entity relationship. Because it is designated as the supplied detail view for the disability criterion, inquiry screens and self-service flows within Oracle Advanced Benefits reference it to render and validate disability rules.

Underlying Base Objects

The documented view text joins two source objects:

• BEN_ELIG_DSBLD_PRTE_F — the base table that physically stores disability participation criteria records. It is referenced through a SYNONYM in the APPS schema and supplies all columns except the joined user information.
• FND_USER_VIEW — the Applications Foundation user directory view, joined with an outer join (FUSER.USER_ID(+) = EDB.LAST_UPDATED_BY) so that the last-updating user is resolved to a directory identity without filtering out rows whose updater is not present in the user directory.

The join is an outer join in standard Oracle syntax, meaning every row from the disability criteria table is retained even when no matching FND_USER_VIEW record exists. The view does not perform any aggregation, date filtering, or business logic transformation; it is a straight projection with a descriptive user join.

Key Columns

• ELIG_DSBLD_PRTE_ID — Primary identifier of the disability criterion record. Used as the foreign key reference throughout the eligibility profile framework.
• DSBLD_CD — The disability code being evaluated; the central search column for this view.
• ELIGY_PRFL_ID — The eligibility profile to which this criterion belongs, linking the rule to its parent profile.
• EXCLD_FLAG — Indicates whether the criterion excludes (Y) or includes (N) persons matching the disability code.
• EFFECTIVE_START_DATE / EFFECTIVE_END_DATE — Effective-dating range governing when the criterion is active.
• BUSINESS_GROUP_ID — The business group (HR organization) that owns the record, providing multi-tenant partitioning.
• ORDR_NUM — Sequencing value that determines evaluation order among criteria within a profile.
• OBJECT_VERSION_NUMBER — Optimistic locking token maintained by the framework.
• Standard audit columns: LAST_UPDATE_DATE, LAST_UPDATED_BY, LAST_UPDATE_LOGIN, CREATED_BY, CREATION_DATE.

Common Use Cases and Queries

Typical scenarios include auditing disability rules attached to eligibility profiles, troubleshooting eligibility determination results, and extracting benefit configuration for downstream systems. A direct search on the reported column would resemble:

SELECT edp.ELIG_DSBLD_PRTE_ID,
       edp.ELIGY_PRFL_ID,
       edp.DSBLD_CD,
       edp.EXCLD_FLAG,
       edp.EFFECTIVE_START_DATE,
       edp.EFFECTIVE_END_DATE
FROM   APPS.BEN_ELIG_DSBLD_PRTE_D edp
WHERE  edp.DSBLD_CD = :dsbld_cd
AND    TRUNC(SYSDATE) BETWEEN edp.EFFECTIVE_START_DATE
                          AND NVL(edp.EFFECTIVE_END_DATE, TRUNC(SYSDATE));

To join criteria back to their parent profile, query against BEN_ELIGY_PRFL using ELIGY_PRFL_ID. Because the view is a simple, non-aggregated projection over BEN_ELIG_DSBLD_PRTE_F, it is fully indexable through the base table and is safe for large-volume extracts. In 12.2.2 the structure is unchanged from 12.1.1; only the underlying synonym resolution and FND_USER_VIEW definition differ per release, so reports should always reference the APPS-synonymed view rather than the base table directly.