Search Results per_pyp_upd




Overview
Explore in AI Chat

Overview

PER_PYP_UPD is a PL/SQL package body owned by the APPS schema that forms part of the Oracle E-Business Suite Payroll pay proposal infrastructure. Its name follows the EBS convention for packages that perform row-level update operations on a specific entity type: the PER_PYP prefix identifies it as a Pay Proposal component, while the UPD suffix indicates that its primary responsibility is the maintenance of existing rows. In practice, PER_PYP_UPD serves as the internal update engine for the PER_PAY_PROPOSALS entity, providing the procedural logic that recalculates, refreshes, and persists changes to pay proposal records when underlying payroll data changes.

The package is classified under ETRM as an OTHER-type API, with a documented status of VALID. Because it is an internal implementation package rather than a public API, it is not intended for direct invocation by external or custom code. Instead, it is layered beneath the business and shadow logic maintained in PER_PYP_BUS, PER_PYP_SHD, and the row-knowledge-update package PER_PYP_RKU, forming a coordinated stack that separates declarative row handling from procedural business rules.

Key Procedures and Functions

  • UPD — The principal update routine of the package. It applies modifications to existing pay proposal records and is the procedure through which the package's core write behaviour is exposed to the surrounding pay proposal stack. It is designed to be called by the package's companion business and shadow packages rather than from application code directly.
  • CONVERT_DEFS — A definition-conversion routine. It supports the migration or normalisation of pay proposal definitions, allowing stored proposal definitions to be translated into a form consistent with the current configuration or processing context. This procedure supports backward-compatible handling of proposal definition data.

The ETRM documentation records three total documented procedures or functions for this package body. No parameter lists are documented, and callers should not assume parameter signatures from external sources; the authoritative interface is the deployed package specification, which is not itself part of this object's metadata.

Tables Accessed

  • PER_PAY_PROPOSALS — the single documented table referenced via APPS synonyms. This is the base table holding pay proposal rows. PER_PYP_UPD reads and writes it in order to apply updates and to persist converted definitions. All row-level DML performed by the package is directed against this table through the APPS synonym, preserving the schema-independence required within EBS.

In addition to the documented table, the dependency list shows extensive reliance on other PL/SQL units rather than further base tables. These include the business rules package PER_PYP_BUS, the shadow package PER_PYP_SHD, the row knowledge update package PER_PYP_RKU, the public API layer HR_API, and utility packages HR_GENERAL and HR_UTILITY. Benefit-related units BEN_EXT_CHLG and BEN_PRO_LER are also referenced, indicating that pay proposal updates interact with benefit eligibility and challenge processing logic. Direct SQL dependency is limited to the STANDARD/SYS constructs used by the generated package code.

Usage Notes

PER_PYP_UPD is not referenced by any other database object and is not exposed as a public interface. It is typically invoked indirectly, as the inner update layer called by PER_PYP_BUS, PER_PYP_SHD, and PER_PYP_RKU when pay proposal data must be recalculated or refreshed. This occurs during payroll processing flows, when users modify pay proposals through the corresponding Oracle Payroll forms, and during concurrent processes that regenerate or correct proposal values. Because the package is marked VALID and documented in ETRM 12.2.2, it is identical in purpose across Oracle EBS 12.1.1 and 12.2.2, with any differences confined to compiled code rather than documented behaviour. Custom code should never call PER_PYP_UPD directly; the supported entry points for pay proposal maintenance remain the public HR_API or the business package layer. Any modification to this package would invalidate the dependent PER_PYP_BUS, PER_PYP_RKU, and PER_PYP_SHD packages, so it must be treated as internal infrastructure and left untouched by customer extensions.