Results for “delete_a_person”

AI-generated from documented ETRM metadata — verify critical details on the linked pages.

Overview

HR_PERSON_DELETE is an Oracle Human Resources (Oracle HRMS) PL/SQL package body owned by the APPS schema and classified under the ETRM API classification OTHER. Its stated purpose, drawn from the package header comment, is to declare the procedures required to delete people from Oracle Human Resources. The package encapsulates the referential and business-level validation logic that must execute before a person record and its associated child rows are physically removed, and it performs the dependent deletions required to keep related HR, Payroll, and Benefits data consistent.

The header explicitly notes that this package does not include the extra validation supplied by calling programs such as screen QuickPicks and HRLink validation, nor the validation enforced by database constraints and triggers held against individual tables. Identification of a person eligible for deletion therefore remains the responsibility of the caller, while HR_PERSON_DELETE supplies the pre-deletion checks and the cascading delete logic. The package is delivered in both EBS 12.1.1 and 12.2.2; the current source header (peperdel.pkb 120.9.12010000.2) dates from 2009.

Key Procedures and Functions

• PRODUCT_INSTALLED — Determines whether a given Oracle application product is installed, based on the FND product installation data. It allows the deletion logic to conditionally execute product-specific steps, such as payroll or benefits cleanup, only when the relevant module is present.
• WEAK_PREDEL_VALIDATION — The least restrictive pre-deletion check. It applies the minimum conditions that must hold before a person can be considered for deletion.
• MODERATE_PREDEL_VALIDATION — An intermediate validation tier applying a broader set of checks than the weak variant.
• STRONG_PREDEL_VALIDATION — The most restrictive validation tier, enforcing the full set of prerequisites before deletion proceeds. Earlier change history records that weak and strong validation were extended to prevent deletion of a person who has a contact with COBRA enrollments related to that person's assignment.
• CHECK_CONTACT — Performs contact-specific checks on the person being deleted, supporting the contact and COBRA-related restrictions enforced elsewhere in the package.
• DELETE_A_PERSON — The central delete routine that removes the person and cascades deletion to dependent records. Change history indicates this routine was extended so that COBRA enrollment records are removed when a contact is removed.
• PEOPLE_DEFAULT_DELETES — Executes the standard set of dependent deletions associated with removing a person.
• APPLICANT_DEFAULT_DELETES — Executes the dependent deletions specific to removing an applicant (a person with an applicant assignment).

Tables Accessed

The package reads and writes a broad set of APPS synonyms. FND_PRODUCT_INSTALLATIONS and FND_APPLICATION support PRODUCT_INSTALLED checks; FND_USER relates the person to an application user. HR objects include HR_API_TRANSACTIONS and HR_API_TRANSACTION_STEPS (deletion is logged as an API transaction), HR_ASSIGNMENT_SET_AMENDMENTS, HR_QUEST_ANSWERS and HR_QUEST_ANSWER_VALUES. Payroll-related cleanup touches PAY_ASSIGNMENT_ACTIONS, PAY_ASSIGNMENT_LATEST_BALANCES, PAY_ASSIGNMENT_LINK_USAGES_F, PAY_COST_ALLOCATIONS_F, and PAY_ELEMENT_ENTRIES_F. Benefits cleanup references BEN_COVERED_DEPENDENTS_F and BEN_EXT_CHG_EVT_LOG. Notably, the package does not reference PAY_US_CITY_TAX_RULES_F; that table belongs to the Payroll city tax rules schema and is unrelated to person deletion.

Usage Notes

HR_PERSON_DELETE is not an end-user entry point. It is invoked by Oracle HRMS forms and by other packages when a person or applicant record is removed, providing the validation tier selection and the cascading child-row deletions. The ETRM metadata records that it is referenced by two other packages and exposes eight procedures. Custom code requiring person deletion should call this package rather than issuing direct DML, thereby preserving the ordering of dependent deletes across HR, Payroll, and Benefits tables and ensuring that an HR_API_TRANSACTIONS record captures the operation. Because validation tiers are exposed separately, integrations should confirm which tier matches the deletion scenario in use. As the source notes, callers remain responsible for screen-level and constraint-level validation that the package does not itself perform.