Search Results create_per_deplymt_eit_a




Overview
Explore in AI Chat

Overview

The PL/SQL package body APPS.HR_PER_DEPLYMT_EIT_BK1 is an Oracle HRMS API hook pre-processor artifact associated with the Person Deployment Extra Information Type (EIT) business object. In the Oracle E-Business Suite 12.1.1 and 12.2.2 data model, deployment EITs capture user-defined descriptive information attached to a person's deployment record, stored through the PER_DEPLYMT_EIT entity and its related deployment and extra information structures. This package is generated automatically by the Oracle HRMS API Hook Pre-processor, which is responsible for producing the "BK1" (backup/before-processing) layer of the API stack. Its business purpose is to provide the procedural shell into which customers may place custom business logic that executes at defined points during the creation of a person deployment EIT record, without modifying Oracle-seeded code. The header comment (hrpdeapi.pkb, version 120.0, generated "noship") and the generated creation timestamp of 2007/01/03 confirm that this is machine-generated boilerplate rather than hand-authored logic, and the ETRM classification of OTHER reflects that it is internally consumed rather than exposed as a public API entry point.

Key Procedures and Functions

Two procedures are documented within the package:

  • CREATE_PER_DEPLYMT_EIT_A — the primary creation hook invoked during the insertion of a person deployment EIT record. Its signature receives identifiers for the person deployment, the person extra information record, the deployment EIT itself, and an object version number for optimistic concurrency control. The documented body contains only location tracing calls (hr_utility.set_location) marking entry and exit, confirming the procedure is a placeholder intended to be extended with customer-specific logic.
  • CREATE_PER_DEPLYMT_EIT_B — the corresponding secondary creation hook. Its documented signature receives only the person deployment identifier and the person extra information identifier. This is the procedure returned by the search term "create_per_deplymt_eit_b". Like the "_A" variant, its body consists solely of entry, meaning only the entry and exit trace statements are present in the released code.

Both procedures are stubs in the delivered product; the naming convention of paired "_A" and "_B" entry points is characteristic of the HRMS API hook framework, where each pair allows extension at different stages of the create operation.

Tables Accessed

No table references are documented for this package in the ETRM metadata. The absence of documented accesses is consistent with the generated source, which performs no SQL operations of its own. The persistence of deployment EIT data is handled by the parent API layer (the underlying HR_PER_DEPLYMT_EIT_API family and the view/table synonyms such as PER_DEPLYMT_EIT and its _F/_TL variants); this backup package only offers hook points during that process. Consequently, any custom code added to these procedures must itself observe the surrounding API's transaction and validation conventions when querying or updating EIT data.

Usage Notes

This package is not intended for direct invocation by end users, forms, or concurrent programs. It is called indirectly by the Oracle HRMS API hook infrastructure whenever a person deployment EIT is created through the standard API path. Customization is performed by editing the generated body (typically through the "API hook" customization mechanism) so that customer logic is layered on top of the seeded tracing statements. Because the package is listed as referenced by one other package, it participates in a well-defined call chain within the deployment EIT API stack. Developers extending it should preserve the existing hr_utility.set_location trace calls for diagnostics, avoid committing or rolling back inside the hooks, and treat the object version number parameter in CREATE_PER_DEPLYMT_EIT_A as authoritative for concurrency checks. During upgrades, generated code of this type is subject to regeneration, so customizations should be maintained in a way that survives patch application.