Search Results create_event_value_change




Overview
Explore in AI Chat

Overview

APPS.PAY_EVENT_VALUE_CHANGES_API is a public Oracle E-Business Suite PL/SQL API that manages event value change records in Oracle Payroll (Payroll). Event value changes define how an employee's payroll processing behaves when a qualifying event affects a particular payroll element or value, allowing the system to determine the correct "from" and "to" values, proration style, and qualifier values that should apply when the event occurs. The package provides a controlled, datetracked interface for maintaining these rules rather than permitting direct DML against the underlying schema objects.

In the ETRM classification this package is registered as an API under the APPS schema. It is an internal building block used by the Payroll event-processing model. The header comment indicates a historical revision ($Header: pyevcapi.pkb 120.0), and the object behaves consistently across both Oracle EBS 12.1.1 and 12.2.2; the 12.2.2 metadata confirms the same three documented procedures and the same referenced table.

Key Procedures and Functions

The package exposes three documented procedures, one for each of the standard maintenance operations:

  • CREATE_EVENT_VALUE_CHANGE — Inserts a new event value change definition. It accepts the effective date, event qualifier, default event, valid event, optional datetracked event identifier, business group, legislation code, from and to values, proration style, and qualifier value. It returns the new event value change identifier, object version number, and effective start and end dates. The procedure uses a savepoint so that a validation-only call can roll back cleanly using the p_validate convention.
  • UPDATE_EVENT_VALUE_CHANGE — Modifies an existing event value change record, applying datetrack-aware updates and returning the new object version number together with the revised effective dates. It is the supported route for correcting from/to values, proration style, or qualifier values without writing directly to the table.
  • DELETE_EVENT_VALUE_CHANGE — Removes or end-dates an existing event value change record, again respecting date-tracked effective dating. Like the other entry points, it enforces the object version number check to prevent lost updates.

All three procedures follow the standard EBS API conventions: validate mode, effective date, OUT parameters for the primary key, object version number, and effective dates, and the use of HR_UTILITY.SET_LOCATION for debugging trace.

Tables Accessed

The only documented table referenced is PAY_EVENT_VALUE_CHANGES_F, reached through its APPS synonym. This is the datetracked entity table that stores the event value change definitions themselves. CREATE_EVENT_VALUE_CHANGE inserts into this table, UPDATE_EVENT_VALUE_CHANGE updates the current and future date-tracked rows, and DELETE_EVENT_VALUE_CHANGE removes or end-dates rows. The OUT parameters mirror the table's primary key, object version number, and effective start and end date columns. Because the table is date-tracked, callers must supply a meaningful effective date; the API truncates the time component from all inbound dates before processing.

Usage Notes

This package is an internal Payroll API and is not a form-level end-user entry point. It is typically invoked from PL/SQL batch logic, from Payroll event and element configuration routines, and occasionally from custom code performing bulk maintenance of event value change rules. Because it is "referenced by 0 other packages" in the documented metadata, no shipped Payroll package depends on it as a public contract; it should be treated as a supported but narrowly scoped interface.

When invoking the API, developers should pass p_validate = true first to confirm the data will be accepted, then re-execute with validation disabled to commit. Callers must supply an effective date aligned with the existing datetracked rows, provide either a business group or legislation context, and capture the OUT object version number for any subsequent update or delete. Direct DML against PAY_EVENT_VALUE_CHANGES_F should be avoided, since doing so bypasses validation and the object version number check that the API enforces.