Search Results delete_program

Overview

APPS.BEN_PROGRAM_API is a public PL/SQL API belonging to the Oracle E-Business Suite Advanced Benefits (OAB) module. Its principal business function is to provide a controlled, programmatic interface for the creation, maintenance, and removal of benefit program definitions, which are stored in the BEN_PGM_F table. A benefit program represents the highest-level grouping of benefit offerings that an organization makes available to a population of eligible employees, and it serves as the anchor record to which plans, options, eligibility profiles, and enrollment rules are subsequently attached.

The package isolates callers from the underlying table structure and the date-tracked (datetrack) business rules that govern effective-dated records in Oracle HRMS. Rather than permitting direct DML against BEN_PGM_F, the API enforces validation, effective-date continuity, and object-version consistency. The package body header identifies it as version 120.0.12020000.2, shipped July 2012, which is consistent with its availability across the 12.1.1 and 12.2.2 releases. It is classified as an API in the ETRM repository, owned by APPS, and is referenced by seven other packages, confirming its role as a foundational component of the benefits object hierarchy.

Key Procedures and Functions

• CREATE_PROGRAM — Inserts a new benefit program definition into BEN_PGM_F. It accepts a broad set of program attributes, including the program name, program type, status code, dependant designation and coverage rules, enrollment coverage end-date rules, maximum dependant and spouse percentage contribution limits, activity reference period, IVR identifier, and various eligibility and default-enrollment flags. The procedure returns the newly generated program identifier and the effective start and end dates of the created row. It supports a validation-only mode through the p_validate parameter, allowing callers to test input without committing data.
• UPDATE_PROGRAM — Modifies an existing benefit program record. It applies the same attribute set as creation, together with the target program identifier, and manages the datetracked update so that prior versions of the program are preserved in accordance with Oracle HRMS date-tracking conventions.
• DELETE_PROGRAM — Removes or logically terminates a benefit program definition. In keeping with datetracked entities, deletion is normally expressed as an end-dating operation that closes the effective end date of the record rather than performing a physical row removal, thereby preserving the historical record and any dependent plan associations.
• LCK — A locking routine used to serialize concurrent access to a program record. It is typically invoked at the start of an update or delete operation to guarantee that the record has not been modified by another session before the change is applied.

Tables Accessed

The package operates against BEN_PGM_F, the base table holding benefit program definitions. All four documented procedures ultimately read from or write to this table. CREATE_PROGRAM inserts a new row and returns its surrogate key and effective dates; UPDATE_PROGRAM modifies the attributes of an existing row while maintaining date-tracked history; DELETE_PROGRAM end-dates or removes the row; and LCK acquires a row-level lock on the target program record. The table is referenced through the APPS synonym layer, so the package is not schema-qualified to the BEN schema in client code.

Usage Notes

BEN_PROGRAM_API is normally invoked indirectly. The Benefits program setup forms call the API when a user defines or amends a program through the standard user interface, and concurrent programs that load or migrate benefit configuration may also depend on it. Because the package is referenced by seven other packages within the benefits object model, customizations that manipulate programs directly should use this API rather than issuing DML against BEN_PGM_F, ensuring that validation and date-tracking logic remain intact. Typical custom usage passes p_validate as TRUE first to confirm that inputs satisfy the API's business rules, then re-invokes with validation disabled to persist the change. Callers should always supply a valid program identifier and effective date context and should expect the API to raise standard application errors when mandatory attributes are missing or when an effective-date conflict is detected.