Search Results hr_assignment_bed




Overview

HR_ASSIGNMENT_BED is a PL/SQL package owned by the APPS schema in Oracle E-Business Suite, valid in both 12.1.1 and 12.2.2. It forms one half of a Business Event (BE) handler pair used by Oracle HRMS to manage assignment-related business events. In Oracle Workflow terminology, a Business Event handler is normally implemented as a matched pair: a "BED" package (the Business Event Definition parent, containing the specification of the handler and its registration logic) and a "BKD" package (the Business Event Definition child, containing the implementation body invoked when the event fires). HR_ASSIGNMENT_BED therefore serves the specification and definition role for assignment events, with the associated HR_ASSIGNMENT_BKD package providing the executable body.

The broader business purpose of this package family is to publish and process HRMS business events such as assignment termination, so that subscriptions configured in Oracle Workflow can react to changes in an employee assignment — for example, notifying approvers, synchronizing downstream applications, or triggering payroll and benefits processes. The package is therefore part of the integration surface of Oracle HRMS rather than a user-facing feature.

Key Procedures and Functions

The documented metadata for the 12.2.2 release lists a single procedure or function within this package:

  • TERMINATE_APL_ASG_A — the sole documented entry point. Its naming follows Oracle HRMS conventions: "TERMINATE" indicates the operation concerns assignment termination, "APL" is the standard HRMS abbreviation for the Applicant/Assignment entity family, and the trailing suffix marks it as the routine that raises or handles the business event for the termination of an assignment. Its role is to generate/raise the assignment termination business event (and/or its associated event-handler definition) so that Oracle Workflow subscriptions can be executed.

No parameter lists, return types, or overload signatures are published in the ETRM metadata, and they should not be assumed. The package is classified as "OTHER" in the API classification scheme, meaning it is not a supported public Open Interface or Open API; it is an internal HRMS event-definition component.

Tables Accessed

The documented objects referenced by HR_ASSIGNMENT_BED — resolved through APPS synonyms — are:

  • PER_WF_EVENTS_S — the HRMS table used to define and register Workflow business events for the PER (People/HR) product group. This is the primary data store the package interacts with, holding the event definitions and raise-time data that the handler publishes.
  • DBMS_LOB — the Oracle-supplied large-object PL/SQL package, typically used to read or write CLOB/BLOB columns such as event payloads or message bodies.
  • DUAL — used for single-row computations, sequence-friendly expressions, or simple conditional checks in the package body.

Because the package references PER_WF_EVENTS_S, its operations are fundamentally about the lifecycle of HR business-event definitions — creating, enabling, or raising the event records that Workflow subscriptions consume.

Usage Notes

HR_ASSIGNMENT_BED is an internal HRMS Workflow integration package. It is not intended to be called directly from custom forms, concurrent programs, or user code. Instead, it is invoked by the Oracle HRMS runtime when an assignment is terminated — for example, when a termination is entered and saved through the People > Assignment form or processed by a supported termination API. At that point the HRMS event framework executes the termination routine, which in turn uses this package to raise the corresponding business event.

The package is referenced by one other package (HR_ASSIGNMENT_BED's own body in the dependency listing, and the paired HR_ASSIGNMENT_BKD), confirming its tight coupling to the BKD implementation. For customization or extension purposes, the correct approach is to subscribe to the raised business event in Oracle Workflow rather than to modify or call HR_ASSIGNMENT_BED directly. Direct invocation is unsupported, as any change in signature or behavior between 12.1.1 and 12.2.2 is not documented and is subject to change.