Search Results ben_startup_actn_typ




Overview
Explore in AI Chat

Overview

BEN_STARTUP_ACTN_TYP is a seeded reference table within the Oracle Advanced Benefits (BEN) module. It stores the definitive list of startup action types that the Benefits engine recognizes during plan configuration, enrollment processing, and life-event handling. The object resides in the BEN schema and is classified as VALID in the ETRM 12.1.1 / 12.2.2 data dictionary. Because it is a seed-data table, its rows are delivered by Oracle and are not intended for routine end-user maintenance; they define the controlled vocabulary that drives Benefits startup behavior.

From a dimensional modeling perspective, the mined Data Vault classification for this object is standalone. In other words, no foreign-key relationships were detected linking BEN_STARTUP_ACTN_TYP to other tables, so the modeling suggestion is to treat it as an isolated reference (code) table rather than as a hub, link, or satellite. Its single-column primary key makes it a natural candidate for a simple lookup dimension in reporting marts.

Key Information Stored

The table contains nine documented columns. The most important are:

  • TYPE_CD — The primary key and the seeded code that uniquely identifies each startup action type. This is the business-meaningful identifier referenced by application logic.
  • NAME — The user-facing name of the action type, displayed in Benefits setup and configuration screens.
  • DESCRIPTION — A longer textual explanation of what the action type represents or when it is triggered.
  • ZD_EDITION_NAME — The editioning column introduced under the 12.2 Online Patching architecture. It is part of the unique index along with TYPE_CD.
  • LAST_UPDATE_DATE — Audit timestamp of the most recent modification to the row.
  • LAST_UPDATED_BY — The application user who performed the last update.
  • LAST_UPDATE_LOGIN — The login session that performed the last update.
  • CREATED_BY — The user credited with creating the seed row.
  • CREATION_DATE — The date the row was initially inserted.

Regarding keys: the surrogate primary key is defined by BEN_STARTUP_ACTN_TYP_PK on TYPE_CD. The documented unique index — and therefore the business-key candidate — is BEN_STARTUP_ACTN_TYP_PK (TYPE_CD, ZD_EDITION_NAME). The addition of ZD_EDITION_NAME reflects the edition-based redefinition model introduced in EBS 12.2, allowing multiple editions of the same logical row to coexist during online patching cycles. The audit columns (LAST_UPDATE_DATE, LAST_UPDATED_BY, LAST_UPDATE_LOGIN, CREATED_BY, CREATION_DATE) follow the standard EBS WHO-column convention and support change tracking and troubleshooting.

Common Use Cases and Queries

Because the table is small and static, its principal use is to resolve TYPE_CD values into readable labels for reporting, diagnostics, and setup verification. Typical scenarios include validating that expected action types are present after an upgrade, joining to transactional Benefits tables to label startup events, and confirming edition-specific rows during patching.

A representative query to list all seeded action types is:

  • SELECT type_cd, name, description FROM ben.ben_startup_actn_typ ORDER BY type_cd;

To inspect the editioning behavior introduced in 12.2, filter on the edition column:

  • SELECT type_cd, name, zd_edition_name FROM ben.ben_startup_actn_typ WHERE zd_edition_name = 'ORA$BASE';

In reporting marts, the table is commonly joined as a lookup so that downstream consumers see descriptive names rather than raw codes. An audit-oriented pattern uses the WHO columns to detect non-Oracle modifications:

  • SELECT type_cd, name, last_updated_by, last_update_date FROM ben.ben_startup_actn_typ WHERE last_updated_by != 1;

Related Objects

The ETRM relationship mining classified this table as standalone, meaning no foreign-key dependencies were detected in either direction within the documented FK structure. Consequently, the table is not joined via declared constraints to other BEN objects. In practice, related objects that consume or parallel its coding scheme include the Benefits startup and plan configuration entities within the BEN schema, such as startup action and processing rule definitions, as well as the standard BEN lookup and validation views used in the configuration workbench. Because joins are governed by application logic rather than enforced referential integrity, implementers should confirm the correct joining column (typically TYPE_CD) against the specific consuming object when building custom extracts. No child tables declare a foreign key to BEN_STARTUP_ACTN_TYP_PK.