Results for “ben_popl_actn_typ_f”

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

Overview

BEN_POPL_ACTN_TYP_F is a table in the BEN (Advanced Benefits) schema of Oracle E-Business Suite, holding configuration for the time allowed to respond to a given action type. In Oracle Advanced Benefits, an "action type" defines a category of participant activity — such as electing a plan, waiving coverage, or completing an enrollment step — and this table stores the rules that govern how long a participant has to respond before the action becomes due, mandatory, or is enforced as a once-only event.

The table is an effective-dated (date-tracked) object. It is implemented as a _F (date-tracked) table, meaning each logical record is preserved across multiple effective date ranges using EFFECTIVE_START_DATE and EFFECTIVE_END_DATE rather than being overwritten. The primary key BEN_POPL_ACTN_TYP_F_PK is composed of POPL_ACTN_TYP_ID, EFFECTIVE_START_DATE, and EFFECTIVE_END_DATE.

Heuristic Data Vault classification suggests this object is satellite-leaning. The identifier POPL_ACTN_TYP_ID functions as a hub-like surrogate key, while the effective-dated descriptive and rule attributes behave as satellite payload attached to that key. The single documented foreign key to BEN_ACTN_TYP.ACTN_TYP_ID reinforces this role: the table extends the base action type with population- or plan-specific timing rules.

Key Information Stored

Of the 48 documented columns, the most operationally significant are:

• POPL_ACTN_TYP_ID — the surrogate primary key identifying each action-type timing record; this is the value users reference when searching for "popl_actn_typ_id".
• EFFECTIVE_START_DATE / EFFECTIVE_END_DATE — the effective-dating pair that, together with POPL_ACTN_TYP_ID, forms the composite primary key.
• ACTN_TYP_ID — foreign key to BEN_ACTN_TYP, linking the timing rule to its underlying action type.
• BUSINESS_GROUP_ID — the operating unit / business group scoping the configuration.
• PGM_ID / PL_ID — the program and plan context to which the rule applies.
• ACTN_TYP_DUE_DT_CD — code controlling how the due date is calculated for the action type.
• ACTN_TYP_DUE_DT_RL — the rule or offset value applied to that due-date calculation.
• MANDATORY — flag indicating whether the action must be completed.
• ONCE_OR_ALWAYS — flag determining whether the action may be performed only once or repeatedly.
• PAT_ATTRIBUTE_CATEGORY and PAT_ATTRIBUTE1–PAT_ATTRIBUTE30 — a flexible descriptive flexfield block enabling client-specific extensibility.
• LAST_UPDATE_DATE, LAST_UPDATED_BY, CREATED_BY, CREATION_DATE, OBJECT_VERSION_NUMBER — standard Oracle who-columns and the optimistic-locking version number.

The business-key candidate is the same composite unique index as the primary key (POPL_ACTN_TYP_ID, EFFECTIVE_START_DATE, EFFECTIVE_END_DATE), distinguishing it from the surrogate identifier alone.

Common Use Cases and Queries

Typical reporting retrieves the currently effective timing rule for a given action type. A common pattern joins to the parent action type and filters by the system date:

• Resolving the surrogate to a business meaning: SELECT * FROM ben.ben_popl_actn_typ_f WHERE popl_actn_typ_id = :id;
• Fetching the active rule as of today: WHERE TRUNC(SYSDATE) BETWEEN effective_start_date AND effective_end_date;
• Joining to the parent: SELECT a.actn_typ_id, f.actn_typ_due_dt_cd, f.actn_typ_due_dt_rl FROM ben.ben_popl_actn_typ_f f JOIN ben.ben_actn_typ a ON f.actn_typ_id = a.actn_typ_id;
• Auditing history: querying all date-tracked rows for one POPL_ACTN_TYP_ID to trace configuration changes over time.

Related Objects

• BEN_ACTN_TYP — parent object joined via BEN_POPL_ACTN_TYP_F.ACTN_TYP_ID = BEN_ACTN_TYP.ACTN_TYP_ID.
• BEN_POPL_ACTN_TYP_F_PK — the composite primary-key index.
• Benefit program (PGM_ID) and plan (PL_ID) definition objects, which scope the timing rule.
• Advanced Benefits concurrent processes and the enrollment/action-type determination logic that consume MANDATORY, ONCE_OR_ALWAYS, and the due-date columns.

Because the configuration is date-tracked, downstream reporting and processing logic must always constrain on effective dates to avoid selecting superseded rules.