Results for “strt_mo”

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

Overview

BEN_WTHN_YR_PERD is a table in the BEN (Advanced Benefits) schema of Oracle E-Business Suite, documented as VALID in both release 12.1.1 and 12.2.2. Its name abbreviates "Within Year Period," and it defines the intra-year time slices into which a benefits year period is divided. These subdivisions drive eligibility, enrollment window, and rate calculation logic throughout Oracle Advanced Benefits (OAB), where plan years are frequently segmented into shorter measurement intervals.

The table carries a heuristic Data Vault classification of satellite-leaning, mined from its foreign-key structure. Practically, this suggests BEN_WTHN_YR_PERD behaves as a descriptive child of BEN_YR_PERD: it holds the attributes of each within-year slice (start and end month, start and end day) while its parent identifies the owning year period. Modelers designing an analytics or warehouse layer for benefits data may therefore treat it as a satellite table attached to the BEN_YR_PERD hub.

Key Information Stored

The physical schema documents 45 columns. The most significant are:

• WTHN_YR_PERD_ID — the surrogate primary key, enforced by the unique index BEN_WTHN_YR_PERD_PK. This is the column users target when searching for "wthn_yr_perd_id" and serves as the join key to dependent tables.
• YR_PERD_ID — the foreign key to BEN_YR_PERD, identifying the parent year period that this within-year slice belongs to.
• BUSINESS_GROUP_ID — the operating business group (HR security organization) that owns the record.
• STRT_MO, END_MO — the starting and ending month boundaries of the slice.
• STRT_DAY, END_DAY — the starting and ending day-of-month boundaries, which together with the month columns define the exact date span.
• TM_UOM — the unit of measure applied to the time span.
• WYP_ATTRIBUTE_CATEGORY and WYP_ATTRIBUTE1 through WYP_ATTRIBUTE30 — the standard Oracle descriptive flexfield (DFF) columns, allowing customers to extend the table with site-specific attributes without structural change.
• LAST_UPDATE_DATE, LAST_UPDATED_BY, LAST_UPDATE_LOGIN, CREATION_DATE, CREATED_BY — the mandatory WHO audit columns recorded on every row.
• OBJECT_VERSION_NUMBER — the optimistic locking column used by the Oracle Applications framework to detect concurrent updates.

Of these, only WTHN_YR_PERD_ID is documented as a business-key candidate via a unique index; the remaining columns are descriptive or referential.

Common Use Cases and Queries

The primary practical use is resolving a within-year period identifier into its calendar boundaries, and vice versa, during enrollment or eligibility processing. A typical lookup resolves a slice to its parent year and span:

• SELECT w.wthn_yr_perd_id, w.yr_perd_id, w.strt_mo, w.strt_day, w.end_mo, w.end_day FROM ben_wthn_yr_perd w WHERE w.wthn_yr_perd_id = :p_id;
• SELECT p.yr_perd_id, p.name, w.wthn_yr_perd_id FROM ben_yr_perd p, ben_wthn_yr_perd w WHERE p.yr_perd_id = w.yr_perd_id AND p.business_group_id = :p_bg_id;

Reporting scenarios include listing all within-year slices for a plan year to validate enrollment window coverage, auditing gaps or overlaps between consecutive slices, and joining slice identifiers to enrollment period records for benefits activity analysis. Because the table is flexfield-enabled, queries may also filter or project WYP_ATTRIBUTE columns where a customer has configured them.

Related Objects

The FK metadata establishes the following principal relationships:

• BEN_YR_PERD — the parent year period table. BEN_WTHN_YR_PERD.YR_PERD_ID references BEN_YR_PERD, making this the mandatory parent join in nearly every query.
• BEN_ENRT_PERD — the enrollment period table, which references BEN_WTHN_YR_PERD through its WTHN_YR_PERD_ID column. This is the dominant downstream consumer, tying within-year slices to actual enrollment windows.

Additional dependencies follow indirectly through BEN_YR_PERD and BEN_ENRT_PERD, which participate in the broader OAB period model alongside plan, program, and eligibility objects. The table is maintained through the standard Advanced Benefits configuration and concurrent processing rather than through a dedicated public API, so integrations should read it directly or resolve periods through the supported benefits APIs that reference the same underlying identifiers.