Search Results per_ctc_del




Overview
Explore in AI Chat

Overview

APPS.PER_CTC_DEL is a technical PL/SQL package within the Oracle E-Business Suite Human Resources (PER) module responsible for the deletion of contract records stored in the Contracts (PER) data model. In Oracle EBS 12.1.1 and 12.2.2, contract data is maintained primarily in the PER_CONTRACTS_F table, which is a date-tracked (datetracked) entity that holds contract header information for employees and contingent workers. Because this table participates in datetracking and is protected by business rules governing effective dates and audit history, deletion operations cannot be performed with a simple DML statement against the base table.

PER_CTC_DEL serves as the internal deletion layer that encapsulates the logic required to remove or logically terminate contract rows in a manner consistent with Oracle HRMS datetrack semantics. It is classified as an OTHER API, meaning it is not a public, supported interface routine intended for direct customer invocation, but rather an internal building block used by higher-level contract APIs and concurrent processing. The package is statically dependent on PER_CONTRACTS_F, the base table, and PER_CTC_SHD, the shadow/audit table that preserves historical row images for datetracked entities. It is referenced by PER_CTC_UPD, the sibling update package, and by HR_CONTRACT_API, the supported public API for contract maintenance, as well as by itself through internal subprogram calls.

Key Procedures and Functions

The ETRM documentation records four callable subprograms within the package. The exact parameter signatures are not enumerated in the available metadata, so the descriptions below are limited to purpose.

  • DELETE_DML — The core data manipulation routine. It performs the physical or logical removal of contract rows, applying the DML statements needed against the underlying table and its shadow records. It is the lowest-level routine in the package and is typically called by the other deletion entry points.
  • DEL — The primary deletion entry point exposed by the package. It orchestrates the deletion of a contract by validating business rules and then delegating the actual DML to DELETE_DML. Higher-level packages such as PER_CTC_UPD and HR_CONTRACT_API invoke this routine when a contract must be removed.
  • DELETE_ROW — A row-scoped deletion routine that removes an individual contract row. It supports the processing of single-record deletions, distinct from any set-based handling that may occur elsewhere in the package.
  • (Fourth subprogram) — The metadata indicates four callable subprograms in total, with three named above. The remaining entry point follows the same deletion-oriented naming family and supports the package's internal DML and validation flow.

Tables Accessed

PER_CTC_DEL references two documented objects. PER_CONTRACTS_F is the Contracts (PER) base table, a datetracked table storing contract header rows keyed to a person and assignment. The package writes to this table to remove contract records. PER_CTC_SHD is the corresponding shadow table, which holds the audit image of each datetracked row. Because datetracking requires that the history of changes be preserved, the deletion routines must interact with the shadow table to maintain consistency between current and historic row versions. No other application tables are documented as direct dependencies, and the package relies on the SYS.STANDARD package for basic PL/SQL constructs.

Usage Notes

PER_CTC_DEL is an internal technical package and is not intended to be called directly from custom code. In standard Oracle EBS 12.1.1 and 12.2.2 operation, contract deletion is initiated through the HR_CONTRACT_API public API or through the Contracts form, which then routes the request into the PER_CTC_DEL deletion routines. Because PER_CTC_DEL is referenced by HR_CONTRACT_API and PER_CTC_UPD, any customization that bypasses these supported interfaces and calls PER_CTC_DEL directly risks violating datetrack integrity, leaving orphaned shadow records, or producing inconsistent contract history. Customizations should therefore always use the documented public API. The package executes with the privileges of the APPS schema and, as with all seeded EBS code, should be treated as Oracle proprietary and confidential.