Search Results per_pay_proposals_s

Overview

PER_PYP_INS is an Oracle E-Business Suite PL/SQL package body owned by the APPS schema. Its name derives from the Payroll (PER) and Pay Proposal (PYP) subject areas, and it functions as the internal insert-handler for the PER_PAY_PROPOSALS entity — the table that stores pay proposals generated during the payroll processing cycle. The package is classified as an "OTHER" API rather than a public, customer-facing interface, confirming that it exists to support Oracle's own internal processing logic rather than to be called directly by end users or integrators.

The package operates within the broader PER_PYP family of objects. It works alongside PER_PYP_BUS (the business logic layer), PER_PYP_RKI (the row-level insert handler), and PER_PYP_SHD (the shadow/audit handler). This layered structure is characteristic of Oracle HRMS entity APIs: the RKI performs row-level work, the INS package coordinates the insert as a whole, and the BUS package orchestrates business rules. Because the object status is VALID in the ETRM repository, the package compiles cleanly against both Oracle EBS 12.1.1 and 12.2.2 environments.

Key Procedures and Functions

The ETRM metadata documents three procedures or functions within the package body:

• SET_BASE_KEY_VALUE — Establishes the surrogate primary key value used when inserting a new pay proposal record. Pay proposals in PER_PAY_PROPOSALS are keyed by a system-generated identifier, and this routine derives or assigns that base key value so that the subsequent insert has a valid, unique primary key. It enforces the key-generation convention used throughout the PER_PYP object family.
• INS — The primary insert procedure. It accepts the attributes of a pay proposal, performs any required defaulting and validation, invokes SET_BASE_KEY_VALUE to obtain the primary key, and then writes the row to the underlying table through the row-level insert handler PER_PYP_RKI. It also coordinates with PER_PYP_SHD so that the shadow (audit) table is populated consistently with the base record.
• A third documented procedure or function supports this insert flow, consistent with the three documented entry points in the ETRM record.

Detailed parameter signatures are not published in the ETRM excerpt and should not be assumed; integrators needing exact signatures should inspect the compiled package in the database. The documented dependencies on HR_API and HR_UTILITY indicate that the procedures apply standard HRMS validation and key-generation utilities rather than custom logic.

Tables Accessed

The package references the following tables through APPS synonyms:

• PER_PAY_PROPOSALS — The base table holding pay proposal records. PER_PYP_INS inserts new rows here via the PER_PYP_RKI handler. This is the primary write target of the package.
• PER_PAY_PROPOSALS_S — The shadow (audit trail) table corresponding to PER_PAY_PROPOSALS. The package writes here in coordination with the base insert so that historical tracking of pay proposal records remains complete. This is the table the user's search term "per_pay_proposals_s" points to, and it is a documented direct dependency of PER_PYP_INS.

Additional dependencies include FND_MESSAGE (used to raise translatable, standardized error messages), DUAL and STANDARD (infrastructure utilities), and the HRMS packages BEN_EXT_CHLG, BEN_PRO_LER, HR_GENERAL, and HR_UTILITY, which supply validation, external challenge, and general-purpose HR functions.

Usage Notes

PER_PYP_INS is not referenced by any database object according to the ETRM dependency data, meaning it is not invoked directly by stored procedures, views, or triggers. It is instead called from within the Oracle HRMS/Payroll application code — typically during payroll processing when the system generates pay proposals, and potentially from any older PL/SQL form or concurrent program that inserts proposals via the supported entity API path. Because the third documented entry point and surrounding family members (PER_PYP_BUS, PER_PYP_RKI) handle the surrounding workflow, customizations should call the higher-level business API rather than PER_PYP_INS directly. Direct calls risk bypassing validation and shadow-table maintenance. For troubleshooting, note that the user search term "per_pay_proposals_s" resolves to the shadow table written by this package.