Search Results create_event_group




Overview
Explore in AI Chat

Overview

APPS.PAY_EVENT_GROUPS_API is a public PL/SQL API package in Oracle E-Business Suite Payroll (PAY) that provides the supported programmatic interface for maintaining payroll event groups. An event group is a named configuration object that associates payroll events — such as a payroll run, a balance adjustment, or a costing process — with a proration rule and, optionally, a time definition, so that the payroll engine knows how to treat those events during processing. The package body (pyevgapi.pkb, header revision 120.2) encapsulates all insert, update, and delete logic against the PAY_EVENT_GROUPS table, insulating callers from the underlying schema and from the business rules that govern valid event group definitions.

The package is classified as an API in the ETRM repository, owned by APPS, and is referenced by three other packages. It forms part of the standard datetracked (effective-dated) API family in Oracle HRMS and Payroll, which is significant because event group definitions are date-effective: a change to an event group takes effect from a specified effective date rather than overwriting history.

Key Procedures and Functions

The package exposes three documented procedures.

  • CREATE_EVENT_GROUP — Creates a new event group row in PAY_EVENT_GROUPS. Documented parameters include p_validate (default false), which allows the caller to exercise the API in validation-only mode so that the business rules are checked and no data is committed; p_effective_date, the date from which the event group is valid; p_event_group_name and p_event_group_type; p_proration_type; p_business_group_id; p_legislation_code; p_time_definition_id; and the two OUT parameters p_event_group_id and p_object_version_number, which return the surrogate key of the created row and its object version number for subsequent optimistic-locking updates. The body wraps the core insert with a savepoint and a call to the before-hook procedure PAY_EVENT_GROUPS_BK1.CREATE_EVENT_GROUP_B, the standard API user-hook mechanism that permits customer extensions without modifying Oracle code.
  • UPDATE_EVENT_GROUP — Modifies an existing event group, identified by event group ID and object version number, applying the same validation and user-hook pattern.
  • DELETE_EVENT_GROUP — Removes or end-dates an event group, subject to referential and datetrack validation.

All three procedures follow the HRMS API conventions of validation mode, effective dating, object version numbering, and business group or legislation scoping.

Tables Accessed

The only table documented as accessed through APPS synonyms is PAY_EVENT_GROUPS. This is the base table holding the event group definition, including the event group name, type, proration type, business group, legislation code, and time definition reference. The API reads it to enforce uniqueness and datetrack rules, and writes to it for inserts, updates, and deletes. The surrogate primary key is EVENT_GROUP_ID, and OBJECT_VERSION_NUMBER provides optimistic locking. Related validation data — such as valid lookup values for event group type and proration type — is resolved through the standard Oracle lookups and HRMS date-tracked validation infrastructure rather than through direct table access documented in this package.

Usage Notes

PAY_EVENT_GROUPS_API is the supported entry point whenever event group data must be created or maintained programmatically, for example from a custom form, a concurrent program, a data conversion or migration script, or a downstream integration seeded from a legacy payroll system. Because the package is effective-dated and version-numbered, callers should always pass a meaningful effective date and retain the returned object version number for later updates. In practice the procedures are invoked inside a caller-controlled transaction: the CREATE_EVENT_GROUP body issues a savepoint, delegates to the before-hook, performs the insert, and relies on the caller to commit or roll back. Running with p_validate set to true is the recommended way to perform pre-load checks in conversion scripts so that validation failures are collected before any data is written. Direct DML against PAY_EVENT_GROUPS should be avoided, since bypassing the API skips the user hooks and the datetrack and validation logic that the three referencing packages and the payroll engine depend upon.