Search Results hr_ben_benefit_contribution_id




Overview

The APPS.HR_BEN_BENEFIT_CONTRIBUTIONS package is a PL/SQL API within the Oracle E-Business Suite Benefits module. It is declared with AUTHID CURRENT_USER, meaning its SQL statements execute with the privileges of the invoking user rather than the definer, which is the standard convention across Oracle HRMS seeded APIs. The package provides the server-side logic required to validate and register benefit contribution records held in the BEN_BENEFIT_CONTRIBUTIONS_F and BEN_BENEFIT_CONTRIBUTIONS_S tables, and to create and manage the payroll element entries that represent those contributions. Its historical header (pebenpbc.pkh) traces back to 1993–1997, reflecting its lineage as a long-standing, stable component of the Benefits and Payroll integration. The object is classified as an OTHER API in the ETRM documentation for 12.2.2, indicating that it is not one of the primary, fully published business APIs, but rather an internal utility package supporting the Benefit Contributions maintenance process.

Key Procedures and Functions

The package exposes four documented procedures, each performing a distinct validation or key-generation role:

  • HR_BEN_BENEFIT_CONTRIBUTION_ID — Retrieves the surrogate key for a benefit contribution from the underlying table's sequence. It accepts the contribution identifier as an IN OUT parameter so the newly generated value is returned to the caller. This is the procedure most directly referenced by the search term hr_ben_benefit_contribution_id.
  • HR_BEN_CHK_DUPLICATE_CONT — Checks whether the contribution record being inserted already exists or overlaps other contribution records, based on element type, coverage type, effective start and end dates, and business group. Its arguments include the benefit contribution identifier, element type, coverage type, and the effective date range. The identifier is deliberately passed in/out to avoid unnecessary network traffic, since the procedure is called from insert and update processing.
  • HR_BEN_CHK_FUTURE_CONTS — Validates future-dated contribution entries, ensuring that prospective records are consistent with the benefit rules in force at that time.
  • HR_BEN_REF_CHK — Performs reference checking against benefit rules, enforcing the stricter Type A benefit rules introduced in a 1995 modification. A p_validation_end_date parameter was added in 1996 to constrain validation to a defined date range.

Tables Accessed

The package operates against the benefit contributions base and synonym tables — BEN_BENEFIT_CONTRIBUTIONS_F for the dated entity and BEN_BENEFIT_CONTRIBUTIONS_S for the associated sequence/identifier — which hold the contribution definitions. Through APPS synonyms it also references PAY_ELEMENT_TYPES_F, PAY_ELEMENT_LINKS_F, PAY_INPUT_VALUES_F, and PAY_ELEMENT_ENTRIES_F together with PAY_ELEMENT_ENTRY_VALUES_F. These payroll tables are accessed because a benefit contribution is ultimately implemented as a payroll element entry; the package verifies the element type, its link configuration, and its input values before creating or amending the corresponding element entry. DUAL is used for sequence lookups and simple validations.

Usage Notes

The package is invoked indirectly by the Oracle Benefits forms and by the seeded concurrent processes that maintain benefit contributions; the hr_ben_benefit_contribution_id procedure in particular is called during insert/update processing to supply the surrogate key. Because the identifier is bundled and copied across the network via IN OUT parameters, the design assumes a tight integration with the calling form or program rather than standalone invocation. The package is referenced by one other documented package, confirming its subordinate position in the Benefits processing chain. Customizations should treat these routines as internal: they are not a published, extensible business API, and callers requiring benefit contribution maintenance should prefer the supported Benefits APIs. Direct use in custom code is feasible for validation and key generation, but must respect the effective-dating and duplicate-check semantics enforced by HR_BEN_CHK_DUPLICATE_CONT and HR_BEN_CHK_FUTURE_CONTS.