Results for “actn_typ”
4 results
AI-generated from documented ETRM metadata — verify critical details on the linked pages.
Overview
APPS.BEN_POPL_ACTN_TYP_D is a denormalized reporting view in the Oracle E-Business Suite Advanced Benefits (BEN) module. It exposes configuration data for population action types — the rules that determine which life events or action items apply to a given benefits population, and when those actions are due. In the underlying data model, this configuration is held in the effective-dated table BEN_POPL_ACTN_TYP_F, keyed by POPL_ACTN_TYP_ID. The view decorates those surrogate identifiers with human-readable descriptions: the action type name, the program and plan names it is associated with, the meaning of the due-date rule, and the name of the Fast Formula that calculates the due date. It also resolves the LAST_UPDATED_BY user id to an FND_USER name.
The view supports the "actn_typ" search pattern frequently used by implementers and support analysts who need to trace why a particular action type is appearing (or failing to appear) for a population. It is read-only and intended for inquiry, reporting, and diagnostic purposes rather than transactional processing.
Underlying Base Objects
The view is defined over the following documented base objects, all referenced through APPS synonyms:
- BEN_POPL_ACTN_TYP_F — the primary effective-dated entity table supplying POPL_ACTN_TYP_ID, EFFECTIVE_START_DATE, EFFECTIVE_END_DATE, ACTN_TYP_ID, PGM_ID, PL_ID, ACTN_TYP_DUE_DT_CD, and ACTN_TYP_DUE_DT_RL.
- BEN_ACTN_TYP — provides the action type NAME via ACTN_TYP_ID.
- BEN_PGM_F — provides the program NAME via PGM_ID.
- BEN_PL_F — provides the plan NAME via PL_ID.
- HR_LOOKUPS — supplies the MEANING for the lookup code held in ACTN_TYP_DUE_DT_CD, restricted to LOOKUP_TYPE = 'BEN_ACTN_TYP_DUE_DT'.
- FF_FORMULAS_F — provides the FORMULA_NAME for the due-date formula referenced by ACTN_TYP_DUE_DT_RL.
- FND_USER — resolves LAST_UPDATED_BY to a user name.
Every join to these objects is an outer join (the (+) operator). In addition, the joins to BEN_PGM_F, BEN_PL_F, and FF_FORMULAS_F include effective-date range predicates between PAT.EFFECTIVE_START_DATE and the referenced object's effective start/end dates, ensuring that the descriptions returned are the ones valid as of the row's effective date. The HR_API package is also listed among referenced objects, reflecting the standard Benefits effective-dating logic embedded in the underlying base table.
Key Columns
- ROW_ID — the ROWID of BEN_POPL_ACTN_TYP_F, useful for uniquely identifying the physical row.
- POPL_ACTN_TYP_ID — primary key of the population action type configuration record.
- EFFECTIVE_START_DATE / EFFECTIVE_END_DATE — the date range during which the configuration is active.
- NAME (ACTN_TYP.NAME) — the action type name; multiple NAME columns appear in the projection for action type, program, and plan, so aliasing is required in queries.
- MEANING — the translated meaning of the due-date lookup code.
- FORMULA_NAME — the Fast Formula that derives the action due date.
- LAST_UPDATE_DATE / LAST_UPDATED_BY — audit columns, with the latter joined to FND_USER.
Common Use Cases and Queries
The most frequent use is reviewing which action types are configured for a program or plan, and what due-date logic applies. For example:
SELECT pap.NAME AS action_type,
pgm.NAME AS program_name,
pl.NAME AS plan_name,
pap.MEANING AS due_dt_meaning,
pap.FORMULA_NAME,
pap.EFFECTIVE_START_DATE,
pap.EFFECTIVE_END_DATE
FROM apps.ben_popl_actn_typ_d pap
WHERE TRUNC(SYSDATE) BETWEEN pap.EFFECTIVE_START_DATE AND pap.EFFECTIVE_END_DATE
ORDER BY pap.NAME;
A second common scenario is locating the formula behind a specific due-date rule, or auditing recently changed configurations by filtering on LAST_UPDATE_DATE. Because all lookup joins are outer, records with missing lookup codes or formulas still return with NULL descriptions, which is useful for identifying incomplete setup. Analysts should note that the view returns no rows from effective-dated child tables when the effective ranges do not overlap, so date-bounded predicates should always be applied when investigating point-in-time behavior.