Search Results ghr_dut_del




Overview
Explore in AI Chat

Overview

The APPS.GHR_DUT_DEL package body is a specialized deletion utility within the Oracle E-Business Suite (EBS) Human Resources (HR) module, specifically associated with the GHR (Global Human Resources) product family. Its primary business function is to manage the controlled removal of duty station records from the Oracle HRMS schema. In EBS release 12.1.1 and 12.2.2, duty stations are location-based entities used to define where employees are primarily assigned, often tied to regulatory and payroll requirements in localized or international deployments. Because these records may be referenced by other components—such as assignments, payroll definitions, or legislative data—direct deletion is unsafe. GHR_DUT_DEL therefore encapsulates the full deletion lifecycle, ensuring that referential integrity is preserved, dependent records are handled appropriately, and audit or runtime validation rules are honored before the physical or logical removal occurs.

The ETRM metadata classifies this API as "OTHER," indicating it is not a standard public interfaces package (such as an HR_API or business process API), but rather an internal utility invoked by higher-level processes. It is documented as a valid package body owned by the APPS schema and is referenced by two other packages, confirming it serves as a shared deletion engine within the GHR duty station domain.

Key Procedures and Functions

The ETRM documentation lists three documented procedures or functions within this package body:

  • DELETE_DML — This procedure performs the core Data Manipulation Language operations required to delete a duty station record. It is the internal workhorse that executes the actual DELETE against the underlying table, typically after validation and dependency checks have been satisfied by the calling logic.
  • DEL — This is the primary public-facing entry point of the package. It orchestrates the deletion request by validating input, invoking prerequisite business checks, and then delegating to DELETE_DML for the physical row removal. Callers outside the package would normally invoke DEL rather than the lower-level DML routine.
  • Third documented routine — The metadata records three total procedures/functions; the excerpt names DELETE_DML and DEL. The third routine is not separately detailed in the provided excerpt. Parameter lists are intentionally not reproduced here, as the metadata does not expose them.

Together these routines separate the "request" concern (DEL) from the "execute" concern (DELETE_DML), a common defensive pattern that allows validation and security logic to be centralized before any destructive operation is performed.

Tables Accessed

The only fully documented table reference is GHR_DUTY_STATIONS_F, accessed via an APPS synonym. The _F suffix indicates this is a date-tracked (datetracked) or "frozen" table in the HRMS datetrack model, meaning rows carry effective start and end dates. Deletion against such a table must respect datetrack rules—records are often logically terminated rather than physically removed. The package body also depends on a set of companion GHR objects, including GHR_DUT_BUS (business rules), GHR_DUT_RKD (likely referential/key data handling), GHR_DUT_SHD (possibly a shadow or history table handler), and DT_API (the datetrack API). These dependencies indicate that GHR_DUT_DEL coordinates with datetrack and business-rule packages when manipulating GHR_DUTY_STATIONS_F.

Usage Notes

GHR_DUT_DEL is an internal utility rather than a user-facing API. It is most commonly invoked programmatically by the two packages documented as referencing it—typically higher-level duty station maintenance or setup packages—rather than directly through an Oracle Forms screen or a standalone concurrent program. In practice, a user deleting or end-dating a duty station through the HRMS duty station form causes the form's underlying logic to call this package's DEL routine. Custom code should avoid calling DELETE_DML directly, since it bypasses the validation layer. Because the package is owned by APPS and depends on datetrack infrastructure, any custom invocation must run with the appropriate APPS privileges and must honor datetrack context (session date and effective date) to avoid corrupting temporal data. The package is reported as not referenced by any database object directly, confirming its role is confined to the GHR duty station subsystem.