Search Results create_balance_type

Overview

APPS.PER_BF_BALANCE_TYPES_API is a public PL/SQL API package belonging to the Oracle HRMS (People) product family. Its business purpose is to provide a controlled, server-side interface for defining and maintaining balance types within the Oracle EBS balance framework. Balance types are the classifications that determine how a measurable value — such as hours worked, leave accrued, or a monetary amount — is stored, validated, and reported by the HRMS balance and accrual functionality, including the accrual plan and absence management features.

The package encapsulates the business rules, validation, and row-level security that would otherwise have to be duplicated by every client. It performs its inserts, updates, and deletes against the underlying table through the standard API mechanism, invoking the before-process and after-process user hooks supplied by the corresponding table handler (PER_BF_BALANCE_TYPES_BK1) and giving callers a single, supported entry point. The header comment identifies the implementation file as pebbtapi.pkb, version 115.6, carrying the earlier company identifier (noship), which places the package among the long-standing HRMS balance APIs delivered across the 12.1.1 and 12.2.2 releases.

Key Procedures and Functions

The documented API exposes three procedures, all classified as API-level entry points intended for external invocation:

• CREATE_BALANCE_TYPE — Creates a new balance type row in the balance types table. It returns the newly generated primary key and the object version number as OUT parameters, and accepts the descriptive and controlling attributes of the balance type, including the business group that owns it, the displayed and internal names, the unit of measure, the currency, the category, and the effective start and end dates. A validation-only mode allows the caller to test the input for correctness without committing any data.
• UPDATE_BALANCE_TYPE — Applies changes to an existing balance type. The caller identifies the target row and supplies the attributes to be modified; the procedure performs the required validation and, upon success, updates the row and advances the object version number to support optimistic locking.
• DELETE_BALANCE_TYPE — Removes an existing balance type. The procedure validates that deletion is permissible before removing the record, guarding against the removal of balance types that are still referenced by other HRMS data.

Each procedure accepts a business group context and an effective date, and each follows the standard HRMS API pattern of a savepoint at entry, a call to the table handler's before-process hook, the DML operation, and invocation of the after-process hook.

Tables Accessed

The package operates on a single documented table, PER_BF_BALANCE_TYPES, referenced through its APPS synonym. This table is the master repository for balance type definitions and holds the columns corresponding to the parameters of the API. CREATE_BALANCE_TYPE inserts into it, UPDATE_BALANCE_TYPE modifies rows within it, and DELETE_BALANCE_TYPE removes rows from it. All access is mediated by the companion table handler PER_BF_BALANCE_TYPES_BK1, which supplies the before- and after-process user hooks that enforce the base-table business rules.

Usage Notes

PER_BF_BALANCE_TYPES_API is typically invoked from Oracle Forms in the HRMS balance setup windows, from concurrent programs that load balance type configuration, and from custom PL/SQL that must create or maintain balance types during implementation or data migration. Oracle EBS development standards direct developers to call this API rather than issuing direct DML against PER_BF_BALANCE_TYPES, because the package enforces validation, derives the object version number, and triggers the table handler hooks.

Callers should honor the p_validate convention to perform a dry run before committing, always pass an accurate p_business_group_id and p_effective_date so that date-tracked rules and security apply correctly, and never supply a value for the OUT parameters. Because the package is referenced by one other package, dependencies in both directions must be considered when patching or upgrading. The object version number returned by the create and update operations must be retained and returned on subsequent updates to prevent lost changes.