Search Results delete_user_structure

Overview

The APPS.PAY_ELEMENT_TEMPLATE_API package body is a PL/SQL API in the Oracle E-Business Suite Payroll (PAY) module. Its specific purpose is to manage element templates — predefined blueprints used to rapidly generate multiple payroll elements that share a common structure (for example, a set of earnings, deductions, or voluntary deductions with consistent input values, balances, and costing rules). Element templates allow a payroll administrator to define a skeleton once and roll out many concrete elements without manually repeating the configuration of every input value and fed balance.

According to the ETRM metadata, the object resides in the APPS schema, carries the classification API, and reports a status of VALID on both Oracle EBS 12.1.1 and 12.2.2. The package body exposes five documented program units and references several supporting objects, notably HR_API, HR_UTILITY, PAY_ELEMENT_TEMPLATE_GEN, PAY_ELEMENT_TEMPLATE_UTIL, and the shadow table PAY_ETM_SHD. These dependencies confirm that the API is a thin orchestration layer that delegates heavy lifting to the template generator and utility packages while relying on HR foundation utilities for common datatypes and error handling. It is referenced by 26 other database objects, indicating it is a central hub for template-driven element creation rather than a leaf utility.

Key Procedures and Functions

The package body documents five program units:

• CREATE_USER_STRUCTURE — Establishes a user-defined structure within the template framework, allowing the template's element layout to be shaped around a customer-specific grouping or hierarchy.
• GENERATE_PART1 — Performs the first phase of template generation, typically the initial creation or validation pass over the template definition before the element records are materialized.
• GENERATE_PART2 — Completes the generation process begun by GENERATE_PART1, creating the element, input value, and balance records that stem from the template.
• DELETE_TEMPLATE — Removes an element template and its associated definition, ensuring the template no longer participates in generation logic.
• DELETE_USER_STRUCTURE — Removes a previously created user structure, reversing the operation performed by CREATE_USER_STRUCTURE.

Together these units cover the full template lifecycle: creating structures, generating template-derived elements in two stages, and deleting templates or user structures. The two-part generation design suggests the process is broken into logical steps (definition/validation, then persistence) to keep transactions manageable in a large element rollout.

Tables Accessed

The ETRM extract does not enumerate the base tables directly, but the dependency list is instructive. The package interacts with element template metadata maintained through PAY_ELEMENT_TEMPLATE_GEN and PAY_ELEMENT_TEMPLATE_UTIL, and it touches the shadow table PAY_ETM_SHD, which stores template-related configuration in a form the API can consume. The presence of HR_API and HR_UTILITY indicates that element and input value records are written through the standard HR datetracked APIs rather than by direct DML, preserving Oracle HRMS date-tracking and validation rules. Reads and writes are therefore directed at the underlying element template, element type, input value, and balance tables, all mediated by these supporting packages.

Usage Notes

PAY_ELEMENT_TEMPLATE_API is an internal API, not a public entry point for end users. It is typically invoked from the Payroll element template setup forms, from the template generation concurrent programs, and from custom code that programmatically provisions payroll elements from a template. Because it depends on the datetracked HR APIs and on the template utility packages, callers should invoke it within the standard EBS initialization context (FND_GLOBAL.APPS_INITIALIZE) and observe the two-phase GENERATE_PART1/GENERATE_PART2 sequence so that validation completes before records are created. Deletion routines should be used with caution, as removing a template does not automatically clean up elements already generated from it. The package is referenced by 26 other objects, so changes to its behavior should be evaluated against all dependent code before deployment.