Search Results is_salary_in_range_int

Overview

APPS.PER_PYP_BUS is the business-layer PL/SQL package body that encapsulates the server-side logic for the Pay Proposals entity in Oracle EBS Human Resources (Payroll/Pay Proposals). The package implements the row-handling business rules generated for the PER_PAY_PROPOSALS table and its associated API framework, providing validation, derivation, and lifecycle operations for pay proposal records. Pay proposals represent proposed changes to an assignment's salary or pay basis, commonly originating from salary administration, performance reviews, or mass salary update processes.

The package follows the standard EBS Business (BUS) package pattern: it exposes validation routines used by the corresponding API (the "PYP" entity prefix), maintains a private global record and package name for diagnostic tracing via HR_UTILITY, and enforces the principle that key identifying columns of an existing pay proposal must not be updated. The header comment identifies the source as pepyprhi.pkb, version 120.24, dated 28-SEP-2011.

Key Procedures and Functions

The ETRM metadata documents 16 procedures and functions. Principal items include:

• IS_SALARY_IN_RANGE_INT — the internal (INT) validation function that determines whether a proposed salary value falls within the valid range defined for the relevant grade, grade step, or salary range. This is the object the user searched for; it is the core range-checking logic invoked during proposal validation.
• CHK_PROPOSED_SALARY — validates the proposed salary figure, typically delegating to IS_SALARY_IN_RANGE_INT and other salary checks.
• CHECK_NON_UPDATEABLE_ARGS — compares the incoming record against the cached old record and raises an error if a non-updateable attribute (for example business_group_id, assignment_id, or pay_proposal_id) has been altered.
• CHK_ASSIGNMENT_ID_CHANGE_DATE, CHK_PAY_BASIS_CHANGE_DATE, CHK_NEXT_SAL_REVIEW_DATE, CHK_CHG_NEXT_SAL_REVIEW_DATE — date-effective validation routines that ensure assignment, pay-basis, and salary-review date fields are consistent with effective-dating rules before insert or update.
• CHK_APPROVED, CHK_FORCED_RANKING, CHK_PERFORMANCE_REVIEW_ID — enforce approval status, forced-ranking, and performance-review integrity constraints.
• INSERT_VALIDATE, UPDATE_VALIDATE, DELETE_VALIDATE — the API lifecycle entry points that coordinate all row-level validations for each DML operation.
• GEN_LAST_CHANGE_DATE — derives the last change date attribute.
• RETURN_LEGISLATION_CODE — returns the legislation code governing the record, driving legislation-specific behavior.

No parameter lists are documented for these routines in the available metadata, and they should not be assumed.

Tables Accessed

The package reads and writes through APPS synonyms. PER_PAY_PROPOSALS is the primary table; PER_PAY_PROPOSAL_COMPONENTS holds the component breakdown of a proposal. PER_ALL_ASSIGNMENTS_F supplies assignment, pay-basis, and grade context. PER_PAY_BASES and PAY_ELEMENT_TYPES_F, PAY_ELEMENT_ENTRIES_F, PAY_ELEMENT_LINKS_F, PAY_INPUT_VALUES_F, and PAY_LINK_INPUT_VALUES_F provide payroll element and input-value definitions used in salary-range and pay-basis checks. PAY_GRADE_RULES_F supplies grade-rate (range) definitions consulted by IS_SALARY_IN_RANGE_INT. HR_ALL_ORGANIZATION_UNITS, HR_ALL_POSITIONS_F, and HR_ORGANIZATION_INFORMATION support organizational context; PER_PERFORMANCE_REVIEWS backs performance-review validation; and PER_ASSIGNMENT_STATUS_TYPES supports assignment status checks.

Usage Notes

PER_PYP_BUS is normally invoked indirectly. The Salary Administration and Pay Proposal forms, and the Row Handlers generated for the Pay Proposals API, call these validation routines on insert, update, and delete, so end users rarely invoke it directly. It is also called by concurrent processes that create or modify pay proposals in bulk, and by other PL/pgSQL or PL/SQL custom code that manipulates pay proposals programmatically. Because five other packages reference it, customizations should call the documented APIs rather than bypassing validation. Access is typically via APPS and requires the HR_UTILITY tracing facility for diagnostics.