Search Results delete_person_extra_info




Overview

APPS.HR_PERSON_EXTRA_INFO_BK3 is a generated PL/SQL package body that participates in the Oracle HRMS API pre-processor architecture used by Oracle E-Business Suite 12.1.1 and 12.2.2. Its primary business function is to serve as a backward-compatibility (BK) integration layer for the Person Extra Information API, ensuring that customer extensions, legacy hooks, and third-party code invoke their logic at the correct point in the base table handler's transaction flow. The package header comment identifies it as "Code generated by the Oracle HRMS API Hook Pre-processor" and dates the generated source to 2013/08/13, corresponding to the R12.x code line shipped with later 12.1.1 and 12.2.2 releases.

The naming convention is significant: the _BK3 suffix denotes a specific versioned hook layer in the HRMS Business API (HR_API) framework. When the base HR_PERSON_EXTRA_INFO_API processes a delete operation, HR_API dispatches to the appropriate BK layer based on configuration, allowing pre- and post-processing logic to be applied without modifying Oracle's seeded code. The parameter of interest in the user's search, p_person_extra_info_id, is the primary key of the PER_PERSON_EXTRA_INFO row being processed and is passed through both documented procedures as the row identifier.

Key Procedures and Functions

  • DELETE_PERSON_EXTRA_INFO_A — The "A" variant is the application-level hook routine. It accepts the person extra information identifier and the object version number, records the current commit unit via hr_api.return_commit_unit, and — when hr_api.call_app_hooks evaluates to true — delegates execution to the corresponding procedure in HR_PERSON_EXTRA_INFO_BE3. After hook execution it closes the multi-message validation set and validates the commit unit with the operation tag AP.
  • DELETE_PERSON_EXTRA_INFO_B — The "B" variant is the business/legislation hook routine. It similarly captures the commit unit and, when hr_api.call_leg_hooks is true, determines the legislation code by calling PE_PEI_BUS.return_legislation_code with the supplied p_person_extra_info_id. For Chinese legislation records (CN), it invokes PER_CN_EXTRA_PER_INFO_LEG_HOOK.CHECK_EXTRA_INFORMATION_EXISTS to enforce country-specific validation constraints before the delete proceeds. It then validates the commit unit using the BP operation tag.

Both procedures use hr_utility.set_location to emit entry and exit trace markers for debugging and are instrumented with a local legislation code variable declared but unused in the "A" variant.

Tables Accessed

The documented metadata for this object does not list direct table references through APPS synonyms. This is consistent with the design of a hook package: the actual DML against PER_PERSON_EXTRA_INFO and related base tables occurs in the core HR_PERSON_EXTRA_INFO_API and _BE3 implementation packages, not here. The procedure does indirectly read the person extra information record through PE_PEI_BUS.return_legislation_code, which resolves the legislation code associated with the identified row, thereby deriving business rules that govern whether the deletion is permitted.

Usage Notes

This package is not intended for direct invocation by developers. It is called automatically by the HR_API framework when HR_PERSON_EXTRA_INFO_API.DELETE_PERSON_EXTRA_INFO is executed from the Person Extra Information form, from concurrent processes, or from custom integration code that uses the supported API. Customers who need to extend delete behavior should implement their logic in a custom hook registered against the appropriate BK layer rather than modifying this seeded package, since the code is regenerated by the API Hook Pre-processor and any manual edits will be overwritten on patching. Support personnel should treat p_person_extra_info_id as the authoritative row key when tracing failures logged by this package.