Results for “ben_opt_info_types”

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

Overview

BEN_OPT_INFO_TYPES is a configuration table within the Oracle Advanced Benefits (BEN) product family, holding the definition of Options Information Types. In Oracle EBS 12.1.1 and 12.2.2, this object serves as a reference and setup entity that classifies the categories of information collected against benefit program options, plan options, and related enrollment constructs. Each row defines one information type that the Advanced Benefits engine can associate with an option, controlling whether the type is currently usable and whether multiple occurrences are permitted during enrollment or maintenance.

From a data-modeling perspective, the ETRM metadata classifies this object heuristically as a standalone entity within a Data Vault framework. This classification should be treated as a modeling suggestion rather than a definitive architectural statement: the table carries no mined foreign-key dependencies in the documented FK structure, meaning it functions as an independent reference hub from which dependent transactional and configuration tables draw their values. Its primary key, BEN_OPT_TYPE_INFO_TYPES_PK, is defined on the INFORMATION_TYPE column, which also serves as the unique business-key candidate documented in the physical schema.

The table is owned by the BEN schema and is reported as VALID in the EBS data dictionary. The documented physical schema for 12.2.2 lists 15 columns, reflecting a compact configuration footprint typical of lookup-style setup tables in Advanced Benefits.

Key Information Stored

The column set divides naturally into business attributes, legislative attributes, and standard EBS audit/WHO columns.

• INFORMATION_TYPE — The primary key and business-key candidate. It uniquely identifies each option information type and is the value referenced by dependent configuration or enrollment tables.
• ACTIVE_INACTIVE_FLAG — Controls whether the information type is available for use in benefit configuration and enrollment. Inactive types remain in the table for historical reference but are excluded from current processing.
• MULTIPLE_OCCURENCES_FLAG — Governs whether more than one occurrence of the information type can be captured against a given option. This directly influences how the enrollment and data-collection screens behave for participants.
• DESCRIPTION — The user-facing name or explanation of the information type, used in setup forms and reports.
• LEGISLATION_CODE — Ties the information type to a specific legislative context, enabling country- or region-specific behavior in a multi-legislation implementation.
• OBJECT_VERSION_NUMBER — Supports optimistic locking and concurrency control for the row, a standard feature of EBS 12.2.2 tables.
• LAST_UPDATE_DATE, LAST_UPDATED_BY, LAST_UPDATE_LOGIN — Standard WHO audit columns capturing when and by whom the record was most recently changed.
• CREATED_BY, CREATION_DATE — Standard WHO columns recording the original creation of the row.
• REQUEST_ID, PROGRAM_APPLICATION_ID, PROGRAM_ID, PROGRAM_UPDATE_DATE — Concurrent program context columns populated when the row is created or modified by a batch process, enabling traceability back to the originating request.

The surrogate primary key (INFORMATION_TYPE) is not a system-generated sequence in the conventional sense; it is a meaningful identifier that also carries business semantics. No separate unique index beyond BEN_OPT_INFO_TYPES_PK is documented, so INFORMATION_TYPE is the sole documented uniqueness constraint.

Common Use Cases and Queries

The most frequent requirement is to list the currently enabled information types for a legislation so that configuration or enrollment logic can be validated. A typical pattern restricts on the active flag and legislation:

• SELECT information_type, description, multiple_occurences_flag FROM ben.ben_opt_info_types WHERE active_inactive_flag = 'Y' AND legislation_code = :p_legislation;
• Reporting on which information types permit multiple occurrences, to audit enrollment screen behavior: SELECT information_type, description FROM ben.ben_opt_info_types WHERE multiple_occurences_flag = 'Y';
• Audit queries that reconcile setup changes using the WHO columns, for example filtering on last_update_date and last_updated_by to identify who altered a given information type.
• Diagnostic joins to dependent option or enrollment tables (referenced by the INFORMATION_TYPE value) to determine whether an information type is in use before deactivating it.

Because the table has no documented foreign keys, queries against it are inexpensive and can be used freely in lookup validation, value-set definitions, and concurrent report logic without concern for cascading dependencies.

Related Objects

The documentation does not expose mined foreign-key relationships for this object, so related objects are inferred from the Advanced Benefits domain and the INFORMATION_TYPE reference value rather than from explicit constraints. Significant objects that reference or depend on BEN_OPT_INFO_TYPES include:

• BEN_OPT_INFO_TYPES_TL or equivalent translation tables, where multilingual descriptions are stored, joined on INFORMATION_TYPE.
• Option and plan option configuration tables within the BEN schema that consume INFORMATION_TYPE as a lookup value when defining collected information.
• Enrollment and election tables (for example, participant-level option information tables) that store INFORMATION_TYPE to record which information type a participant response belongs to.
• Benefit program and plan setup objects that reference the information type when constructing option definitions used during eligibility and enrollment processing.
• Advanced Benefits concurrent programs and APIs that read this table to resolve valid information types during enrollment data collection.
• FND value sets and lookup definitions that may be validated against INFORMATION_TYPE in setup forms.

Because the entity is standalone in the documented schema, joins to these objects should be driven by the INFORMATION_TYPE value rather than by a documented foreign-key column, and implementations should verify the actual constraint structure in their specific 12.1.1 or 12.2.2 instance before relying on referential integrity.