Search Results per_pyp_ins




Overview
Explore in AI Chat

Overview

PER_PYP_INS is an Oracle E-Business Suite PL/SQL package owned by the APPS schema that supports the Payroll Payment Proposal flow within Oracle HRMS, particularly in the context of third-party payment processing and payroll disbursement. The package name derives from "PER" (the HRMS product prefix) and "PYP" (Payment Proposal), and serves as an internal insertion utility for the PER_PAY_PROPOSALS entities. Within Oracle Payroll, a "payment proposal" represents a proposed disbursement to an external payee — typically a third-party organization or an individual (such as a garnishment recipient, benefit provider, or court-mandated deduction) — that is generated before a payment is actually issued. The PER_PYP_INS package is one of the lower-level building blocks in this architecture, providing the procedural mechanics that the higher-level maintain and upload APIs invoke when creating new payment proposal records.

In EBS 12.1.1 and 12.2.2, this package is not a standalone business-facing API; rather it is a supporting insert routine that is called by surrounding APIs to persist payment proposal rows onto the underlying base tables. Its classification in the Oracle ETRM (E-Business Suite Technical Reference Manual) is "OTHER," indicating it is an internal utility rather than a formally published public API. It is nevertheless a valid, active package and is a documented dependency of several payroll-facing APIs.

Key Procedures and Functions

The ETRM metadata documents three procedures/functions within this package:

  • INS — The primary insert routine. This procedure is the core worker of the package: it performs the actual row insertion against the PER_PAY_PROPOSALS table (and, where appropriate, the shadow/interface table PER_PAY_PROPOSALS_S). It is called by the higher-level Payroll proposal APIs when a new proposal needs to be created.
  • SET_BASE_KEY_VALUE — A supporting utility that establishes or assigns the base key value for a payment proposal record. In EBS HRMS, base key values are used to correctly associate a proposal with the appropriate legislative/organizational context and to generate the primary identifier required before insertion. This procedure ensures key columns are populated appropriately prior to the INS call.
  • A third documented entry — The ETRM lists three procedures/functions in total. The remaining entry supports the base-key / insert workflow described above. (Parameter lists are not published in the documentation and are intentionally omitted here.)

Tables Accessed

The package works with two tables, referenced through APPS synonyms:

  • PER_PAY_PROPOSALS — The production table holding payment proposal records. The INS procedure writes new proposal rows here.
  • PER_PAY_PROPOSALS_S — The shadow (date-tracked) table that mirrors the base table, capturing historical/datetracked versions of proposal rows. This is a standard Oracle HRMS "datetrack" companion table.

Because the package also references PER_PYP_SHD, the shadow/interface companion object, it operates within the partitioning of the HRMS datetrack framework. The dual-table access (base plus _S shadow) is typical of HRMS APIs, which must maintain both the current and historical representations of date-tracked rows.

Usage Notes

PER_PYP_INS is not intended to be called directly by end users or custom code. According to the ETRM dependency tree, it is referenced by three other packages: HR_MAINTAIN_PROPOSAL_API, HR_MAINTAIN_PROPOSAL_SWI, and HR_UPLOAD_PROPOSAL_API. These are the public-facing entry points that implement the business rules for maintaining and uploading payroll payment proposals. When a user or concurrent program creates, updates, or uploads a payment proposal through one of those APIs, the API ultimately delegates the physical insert of the base row to PER_PYP_INS.INS.

Practically, this package is invoked during payroll payment proposal creation, whether triggered from a payroll form, an upload concurrent program, or a custom interface that calls the formal maintain/upload APIs. Because of its internal nature, any customization should target the documented parent APIs (HR_UPLOAD_PROPOSAL_API or HR_MAINTAIN_PROPOSAL_API) rather than PER_PYP_INS directly, to preserve datetrack integrity and business rule enforcement. Direct invocation of PER_PYP_INS bypasses the surrounding validation logic and is not recommended.