Search Results ben_ler_info_types_pk

Overview

BEN.BEN_LER_INFO_TYPES is a reference configuration table in the Oracle E-Business Suite Benefits (BEN) module. It defines the catalogue of Information Types that can be associated with a Life Event, supporting the Life Event Rule (LER) framework used to trigger and validate benefit eligibility changes when an employee experiences a qualifying life event such as marriage, birth, or a change in dependent status. In Oracle EBS 12.1.1 and 12.2.2, the table resides in the APPS_TS_TX_DATA tablespace with a PCT Free of 10 and is registered under the FND Design Data application as BEN.BEN_LER_INFO_TYPES. Its status is VALID across both releases.

From a Data Vault modeling perspective, the metadata classifies this object heuristically as standalone. That classification suggests it is best treated as a hub-style reference object carrying a durable business key, rather than a transactional link or a frequently-updated descriptive satellite. The table is essentially a code-value lookup whose rows are relatively stable and are referenced by downstream configuration and processing logic.

Key Information Stored

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

• INFORMATION_TYPE (VARCHAR2 40, mandatory) — the code or name of the information type. This is both the business identifier and the primary key column of the unique index BEN_LER_INFO_TYPES_PK on tablespace APPS_TS_TX_IDX. In this table the primary key coincides with the business key candidate, since no separate surrogate key column is defined.
• ACTIVE_INACTIVE_FLAG (VARCHAR2 30) — governs whether the information type is available for use on life events.
• MULTIPLE_OCCURENCES_FLAG (VARCHAR2 30) — indicates whether a person may hold more than one instance of this information type.
• DESCRIPTION (VARCHAR2 240) — a human-readable description displayed in setup and inquiry screens.
• LEGISLATION_CODE (VARCHAR2 30) — the legislation under which the information type applies, enabling country-specific configuration.
• OBJECT_VERSION_NUMBER (NUMBER) — the optimistic locking counter incremented on each row update.
• Standard WHO columns — LAST_UPDATE_DATE, LAST_UPDATED_BY, LAST_UPDATE_LOGIN, CREATION_DATE, CREATED_BY, plus the concurrent program audit columns REQUEST_ID, PROGRAM_APPLICATION_ID, PROGRAM_ID, and PROGRAM_UPDATE_DATE.

Common Use Cases and Queries

The most frequent access pattern is a simple lookup of active information types filtered by legislation, for example:

• Retrieve all enabled types for a country: SELECT INFORMATION_TYPE, DESCRIPTION FROM BEN.BEN_LER_INFO_TYPES WHERE ACTIVE_INACTIVE_FLAG = 'A' AND LEGISLATION_CODE = :p_legislation;
• List types permitting repeated entry: SELECT INFORMATION_TYPE FROM BEN.BEN_LER_INFO_TYPES WHERE MULTIPLE_OCCURENCES_FLAG = 'Y';
• Audit recently maintained setup rows using LAST_UPDATE_DATE and LAST_UPDATED_BY.

Reporting scenarios include benefits configuration audits, life event setup validation, and data migration extracts where the INFORMATION_TYPE values are used to reconcile installed reference data. Because the table is standalone and small, it is typically joined to life event rule tables rather than queried for transactional volumes.

Related Objects

The supplied metadata states that BEN.BEN_LER_INFO_TYPES does not reference any database object and is referenced by dependent objects through the LER rule framework. Significant related objects in the Benefits schema include:

• BEN_LER_RULES_F and BEN_LER_RULES — life event rule definitions that consume INFORMATION_TYPE values to determine required user input.
• BEN_LER_F and BEN_LER_TL — the life event repository whose setup links information types to events.
• BEN_PTIP_OPT_F — plan-type-in-program options that may reference information types in eligibility processing.
• BEN_LER_INFO_TYPES_TL, where multilingual translations exist in some releases, joining on INFORMATION_TYPE.
• Concurrent programs such as the Benefits setup validation processes that validate ACTIVE_INACTIVE_FLAG consistency.

Developers and support analysts searching on ben_ler_info_types_pk are generally investigating key constraint violations, duplicate INFORMATION_TYPE inserts, or index rebuild activity on that primary key index. Verifying the index on APPS_TS_TX_IDX and confirming that ACTIVE_INACTIVE_FLAG and LEGISLATION_CODE values conform to expected lookup codes resolves the majority of configuration issues associated with this table.