Search Results hr_s_benefit_classifications

Overview

HR_S_BENEFIT_CLASSIFICATIONS is a Human Resources (PER) module table in the Oracle EBS database, owned by the HR schema and documented as VALID in both 12.1.1 and 12.2.2. The ETRM record carries the note "- Retrofitted," which indicates the object was reconstructed into the ETRM repository from an existing database rather than authored natively by the documentation generator. It is therefore best treated as a physical-schema reference rather than a fully annotated functional specification.

Functionally, the table stores the definition of benefit classifications — the configurable categories Oracle Advanced Benefits uses to group and process benefit offerings. In Oracle EBS terminology, a "benefit classification" (also called a benefit program classification in the compensation-objects framework) determines how a benefit is priced, who may enroll, whether dependents or beneficiaries are permitted, and how the benefit behaves at termination. Because these definitions are reused across multiple benefit plans and programs within a business group, the table acts as a central reference for benefit configuration.

The ETRM metadata records a heuristic Data Vault classification of standalone. This should be read as a modeling suggestion only: the table sits only on the referencing side of its foreign-key relationships and is not itself joined to by other tables in the mined relationship graph, so it does not behave as a classic hub or link in the supplied metadata. In practice it functions as a configurable reference entity scoped by business group and legislation.

Key Information Stored

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

• BENEFIT_CLASSIFICATION_ID — the surrogate primary key, and the foreign key target referenced from other tables. It is the join key used throughout benefit configuration.
• BUSINESS_GROUP_ID — the partitioning key that scopes each classification to a single business group, ensuring configuration is isolated per enterprise.
• LEGISLATION_CODE — identifies the country/legislation under which the classification is valid, driving statutory behavior and validation.
• BENEFIT_CLASSIFICATION_NAME — the user-facing name displayed in configuration and enrollment screens; the principal descriptive identifier.
• BENEFIT_CLASSIFICATION_TYPE — classifies the record into the supported benefit category, which governs downstream processing rules.
• ACTIVE_FLAG — controls whether the classification is available for selection in new plan or program definitions.
• BENEFICIARY_ALLOWED_FLAG — indicates whether beneficiaries may be designated for enrollments in this classification.
• DEPENDENTS_ALLOWED_FLAG — indicates whether dependents may be covered.
• CHARGEABLE_FLAG — determines whether charges (costs or credits) are applied to the benefit.
• COBRA_FLAG — marks whether the classification is subject to COBRA continuation coverage rules, relevant for US legislation.
• CONTRIBUTIONS_USED — indicates whether employee contributions are gathered and used in processing.
• DFLT_PROCESSING_TYPE and DFLT_POST_TERMINATION_RULE — default processing behavior and how the benefit is treated after termination.
• BEN_CLASS_PROCESSING_RULE — the classification-level processing rule applied during eligibility and enrollment cycles.
• COMMENTS — free-text notes maintained by the implementer.

The audit columns (LAST_UPDATE_DATE, LAST_UPDATED_BY, LAST_UPDATE_LOGIN, CREATED_BY, CREATION_DATE) follow Oracle's standard WHO-column convention and are populated automatically. The metadata lists a single unique index, SYS_IL0000044076C00020$$. Although its name follows the system-generated LOB/XML index convention and exposes no meaningful column list, it is the only documented unique-index candidate; no separate business-key unique constraint is recorded, so BENEFIT_CLASSIFICATION_ID remains the effective identifier for integration purposes.

Common Use Cases and Queries

Typical usage centers on configuration validation and reporting. Administrators and analysts commonly list all active classifications for a business group and legislation:

• SELECT benefit_classification_id, benefit_classification_name, benefit_classification_type FROM hr.hr_s_benefit_classifications WHERE business_group_id = :bg AND active_flag = 'Y' ORDER BY benefit_classification_name;
• Filter by dependent or beneficiary eligibility to audit enrollment options: WHERE dependents_allowed_flag = 'Y' AND beneficiary_allowed_flag = 'Y'.
• Identify COBRA-relevant classifications for US legislation: WHERE legislation_code = 'US' AND cobra_flag = 'Y'.
• Detect stale configuration using the audit columns: WHERE last_update_date < :cutoff.

Because the table is a reference source keyed by BENEFIT_CLASSIFICATION_ID, migration scripts and reconciliation reports typically extract all rows for a business group and compare them against source or target instances. Results are often joined to benefit plan tables on the surrogate key to confirm coverage.

Related Objects

The ETRM relationship data records one foreign key: HR_S_BENEFIT_CLASSIFICATIONS.BENEFIT_CLASSIFICATION_ID references BEN_BENEFIT_CLASSIFICATIONS. The following related objects are significant in this functional area:

• BEN_BENEFIT_CLASSIFICATIONS — the referenced parent, joined on BENEFIT_CLASSIFICATION_ID; the primary relationship documented in the metadata.
• BEN_BENEFIT_PROGRAMS and BEN_BENEFIT_PLANS — configuration tables that consume benefit classifications when defining programs and offerings.
• BEN_PGM_FOR_BENFT_CLASSES — associates classifications with programs.
• BEN_ELIG_PER_ELCTBL_CHC and related eligibility tables — use the classification when resolving who may enroll.
• PER_BUSINESS_GROUPS — supplies the BUSINESS_GROUP_ID context.
• FND_TERRITORIES — validates LEGISLATION_CODE.
• HR_S_BENEFIT_CLASSIFICATIONS is exposed through corresponding _TL and view layers where translated names are required.

Implementations should confirm the exact join path against the customer instance, since the retrofitted ETRM record documents only a single FK and a single unique index.