Search Results chk_pay_basis_change_date

Overview

PERWSEPY_PKG is an Oracle E-Business Suite PL/SQL package owned by the APPS schema and classified under the OTHER API category. In Oracle EBS 12.1.1 and 12.2.2, its principal business function is to support the Salary Proposal (Pay Proposal) processing logic used by Oracle Payroll and the associated Salary Management forms. A salary proposal records a proposed change to an employee's pay — an amount change, a percentage change, or a change to the assignment's pay basis — and must be validated before it can be approved and applied to the assignment. PERWSEPY_PKG encapsulates the validation and calculation routines that the older Salary form invokes to enforce these business rules.

The package declares AUTHID CURRENT_USER, so its unqualified references to PER_PAY_PROPOSALS, PER_PAY_PROPOSAL_COMPONENTS and PER_ALL_ASSIGNMENTS_F resolve through APPS synonyms rather than through definer's-rights privileges. The header comment indicates that several routines were copied from PER_PYP_BUS, the pay proposal business package, and that some restrictions were deliberately reinstated here for the legacy Salary form.

Key Procedures and Functions

The package exposes seventeen documented procedures and functions. The calculation group comprises CHECK_LENGTH, CALCULATE_PERCENTS_P, COMPONENT_AMOUNT_P and COMPONENT_PERCENT_P, which derive amounts from percentages and percentages from amounts for a proposal component, validate the supplied currency and unit of measure, and reconcile the old and new values. The proposal-entry group includes PROPOSED_SALARY_P, CHANGE_AMOUNT_P, CHANGE_PERCENT_P, CHANGE_DATE_P, NEXT_SAL_REVIEW_DATE_P, APPROVED_P, COMPONENT_APPROVED_P and CHECK_FOR_UNAPROVED, which handle the proposed salary figure, the change amount/percent/date fields, the next salary review date, approval flags, and detection of unapproved proposals.

The validation group includes the procedure the user searched for, CHK_ASSIGNMENT_ID_CHANGE_DATE, which verifies that the assignment identified on a pay proposal is valid for the supplied change date and business group, and returns a payroll warning flag when a conflict exists. CHK_PAY_BASIS_CHANGE_DATE performs the analogous check for a pay basis change date, while CHECK_START_END_ASS_DATES validates assignment start and end dates. CHK_DEL_PAY_PROPOSAL, CHK_DELETE_COMPONENT and CHECK_FOR_UNAPROVED guard deletion and approval operations by returning warning flags instead of raising hard exceptions.

Tables Accessed

The package reads and writes three documented base tables through APPS synonyms. PER_PAY_PROPOSALS holds the salary proposal header, including pay_proposal_id, business_group_id, assignment_id, change_date and object_version_number; the validation procedures query it to confirm the row exists, matches the assignment and business group, and carries the expected object version for optimistic locking. PER_PAY_PROPOSAL_COMPONENTS stores the individual pay components attached to a proposal and is used by COMPONENT_AMOUNT_P, COMPONENT_PERCENT_P, CHK_DELETE_COMPONENT and COMPONENT_APPROVED_P. PER_ALL_ASSIGNMENTS_F is the effective-dated assignment table, queried to confirm that the assignment was active on the proposal's change date and to validate assignment start and end dates.

Usage Notes

PERWSEPY_PKG is typically invoked from the Oracle Payroll Salary Management form when a user enters, modifies, approves or deletes a salary proposal or one of its components. Because the package is not referenced by any other documented package, it is a terminal caller rather than a shared library, and its procedures are designed to be called directly from form-level PL/SQL triggers. The p_payroll_warning and p_salary_warning OUT parameters follow the EBS convention of returning a Boolean warning to the form rather than raising an application error, allowing the user to acknowledge and continue. Custom code that manipulates pay proposals should call these validation procedures before committing, and should pass the current object_version_number so that concurrent updates are detected. On R12.2.2, the package resides on the application tier and is patched through the standard ADOP cycle.