Search Results ben_ler_info_types




Overview
Explore in AI Chat

Overview

BEN_LER_INFO_TYPES is a configuration table in the Oracle Advanced Benefits (BEN) module, documented as "Life Event Reasons Information Types." It defines the classification of information types that can be associated with life event reasons in Oracle EBS Release 12.1.1 and 12.2.2. Life events such as marriage, birth, or termination frequently require the capture of supporting data — documentation dates, dependent details, or coverage elections — and this table provides the metadata-driven catalog that governs which categories of information a given life event reason may collect.

The table resides in the BEN schema and is classified as VALID in the ETRM repository. From a Data Vault modeling perspective, the heuristic classification supplied in the metadata is standalone. This suggests the table functions as a reference or lookup structure, similar in shape to a hub for the INFORMATION_TYPE business concept, with no documented foreign-key dependencies to other tables. Its columns such as ACTIVE_INACTIVE_FLAG and LEGISLATION_CODE reinforce its role as a controlled reference list rather than a transactional or link entity.

Key Information Stored

The table contains 15 documented columns. The most significant are:

  • INFORMATION_TYPE — the primary key, defined by the unique index BEN_LER_INFO_TYPES_PK and by the constraint BEN_LER_TYPE_INFO_TYPES_PK. It also serves as the sole business-key candidate, uniquely identifying each information type record.
  • ACTIVE_INACTIVE_FLAG — controls whether the information type is available for selection in life event reason configuration.
  • MULTIPLE_OCCURENCES_FLAG — indicates whether more than one occurrence of the information type may be recorded for a single life event reason.
  • DESCRIPTION — the user-facing name or explanation of the information type.
  • LEGISLATION_CODE — restricts the information type to a specific legislative jurisdiction, supporting country-specific benefits rules.
  • OBJECT_VERSION_NUMBER — supports optimistic locking for concurrent updates, standard in the OAF-based R12 stack.

Audit columns — REQUEST_ID, PROGRAM_APPLICATION_ID, PROGRAM_ID, PROGRAM_UPDATE_DATE, LAST_UPDATE_DATE, LAST_UPDATED_BY, LAST_UPDATE_LOGIN, CREATED_BY, and CREATION_DATE — follow the standard Oracle Applications WHO column convention and capture the concurrent program context and user identity for each insert or update. The presence of these columns confirms the table is maintained through the standard EBS DML framework rather than by direct manipulation.

Common Use Cases and Queries

The primary use case is validating and reporting on the set of information types available when configuring life event reasons in the Advanced Benefits setup. A typical query retrieving active, legislation-specific information types is:

  • SELECT information_type, description FROM ben_ler_info_types WHERE active_inactive_flag = 'Y' ORDER BY information_type;
  • SELECT information_type, description, multiple_occurences_flag FROM ben_ler_info_types WHERE legislation_code = 'US';

Reporting scenarios include auditing which information types permit multiple occurrences, verifying legislative coverage gaps, and reconciling configuration transported between environments via FNDLOAD or the Configuration Workbench. Administrators also use the table to troubleshoot life event reason setup where an expected information type is unavailable, which is commonly caused by an inactive flag or a mismatched legislation code.

Related Objects

The ETRM metadata classifies this table as standalone, with no documented foreign-key relationships to other objects. In practice, the INFORMATION_TYPE value is referenced logically by life event reason configuration tables within the BEN schema, and the table's WHO columns reference standard EBS audit infrastructure. Significant related objects include:

  • BEN_LER_INFO_TYPES_PK — the primary key constraint enforcing uniqueness of INFORMATION_TYPE.
  • BEN_LER_TYPE_INFO_TYPES_PK — the alternate documented constraint referencing the same column.
  • FND_APPLICATION / FND_CONCURRENT_PROGRAMS — joined through PROGRAM_APPLICATION_ID and PROGRAM_ID for audit lineage.
  • FND_USER — joined through CREATED_BY and LAST_UPDATED_BY to resolve user identities.
  • FND_TERRITORIES — reference source for LEGISLATION_CODE values.

Because no explicit foreign keys are documented, joins to life event reason tables should be treated as application-enforced relationships and validated carefully during custom reporting.