Search Results insert_pay_proposal
Overview
APPS.PER_SALADMIN_UTILITY is a Salary Administration utility package within the Oracle E-Business Suite Human Resources (PER) module. It provides a consolidated library of PL/SQL functions and procedures that support the salary administration and payroll proposal workflow, most notably the Salary Administration and Grade/Step (GSP) processing performed from the Compensation Management forms. The package encapsulates reusable business logic for computing salary values, resolving grade and grade ladder thresholds, deriving currency and annualization information, and generating payroll proposals. In Oracle EBS 12.1.1 and 12.2.2 the package resides under the APPS schema and is classified by ETRM as an "OTHER" API, meaning it is a supporting internal utility rather than a formal public interface. Its 40 documented procedures and functions are referenced by 18 other packages, indicating that it functions as a shared service layer relied upon by salary administration, grade step progression, and related compensation components. Because the package manipulates pay proposals and assignment salary attributes, it is tightly coupled to the salary administration data model and to the payroll proposal framework.
Key Procedures and Functions
The documented entry points fall into several functional clusters. Proposal management is handled by GET_SAL_ON_BASIS_CHG, which derives the salary effect of a payroll basis change, ADJUST_PAY_PROPOSALS, which reconciles existing proposals for an assignment, and INSERT_PAY_PROPOSAL, which creates a new pay proposal record. GSP support is provided by CHECK_GSP_MANUAL_OVERRIDE, which validates whether a manual override is permitted, along with GET_GRD_MAX_PAY and GET_GRD_MIN_PAY, which return the maximum and minimum pay boundaries for a grade.
- GET_QUERY_ONLY returns a VARCHAR2 indicator used to determine whether the calling context should operate in query-only (read-only) mode.
- GET_CURRENCY_FORMAT and GET_BASIS_CURRENCY_CODE resolve currency display formatting and the currency associated with a pay basis.
- GET_ANNUALIZATION_FACTOR, GET_ANNUAL_SALARY, and GET_FTE derive normalized salary values from assignment and frequency data.
- GET_PAY_BASIS_FREQUENCY, GET_UOM, and GET_LOOKUP_DESC retrieve frequency, unit-of-measure, and lookup descriptions.
- GET_NEXT_SAL_REVIEW_DATE and GET_PREVIOUS_PROPOSAL_DT calculate review and prior proposal dates.
- DECODE_GRADE_LADDER, GET_GRADE, and GET_GRADE_CURRENCY resolve grade ladder and grade attributes.
Two global variables, g_proposal_rec and g_new_sal_value, persist proposal and salary context across calls within a session.
Tables Accessed
The package reads and writes salary administration and payroll data primarily through APPS synonyms. PER_PAY_PROPOSALS and PER_PAY_PROPOSAL_COMPONENTS are the core proposal tables, corresponding to the global proposal record and the insert/adjust procedures. Assignment data is drawn from PER_ALL_ASSIGNMENTS_F, PER_ASSIGNMENT_BUDGET_VALUES_F, and PER_ASSIGNMENT_STATUS_TYPES for effective-dated assignment and budget context. Pay basis and time period logic uses PER_PAY_BASES and PER_TIME_PERIOD_TYPES. Grade and GSP boundaries rely on PAY_GRADE_RULES_F. Payroll processing context is supplied by PAY_ALL_PAYROLLS_F, PAY_PAYROLL_ACTIONS, PAY_ASSIGNMENT_ACTIONS, PAY_ELEMENT_ENTRIES_F, PAY_ELEMENT_TYPES_F, and PAY_INPUT_VALUES_F. Benefit program information is referenced through BEN_PGM_F. These reads and writes support salary calculation, validation, and proposal generation.
Usage Notes
PER_SALADMIN_UTILITY is typically invoked indirectly by Salary Administration forms, GSP concurrent processes, and other compensation packages rather than being called directly by end users. Because it is classified as an "OTHER" API, Oracle does not guarantee its signature across releases, and customizations should avoid direct dependency where a supported API exists. In both 12.1.1 and 12.2.2 the package behavior is driven by effective dates and business group context, so callers must supply valid effective dates and assignment identifiers. Custom code invoking GET_QUERY_ONLY or the salary derivation functions should run within the correct assignment and payroll context to avoid inconsistent proposal results.