Search Results get_update_param

Overview

PER_SSHR_CHANGE_PAY is an Oracle E-Business Suite PL/SQL package owned by the APPS schema that provides the server-side logic underpinning the Salary and Pay-related change functions of Oracle Self-Service Human Resources (SSHR). It is the transaction engine that allows an employee or manager, working through the SSHR web interface, to propose, validate, and commit changes to an assignment's pay — for example a salary change, a change of payroll, or a change to a salary basis. The package captures the proposed values as HR API transactions, converts them into the intermediate "step" and "value" rows used by the HR transactional framework, and then calls the standard Oracle Payroll and Human Resources APIs to apply the change to the underlying assignment, element entry, and payroll records.

The package is classified as OTHER in the ETRM and holds a VALID status in both 12.1.1 and 12.2.2. It forms part of the SSHR processing stack together with the concurrent/request-layer objects that call it, and it is documented as referencing the SYS.STANDARD package and being referenced by two other APPS packages.

Key Procedures and Functions

The package exposes eighteen documented procedures and functions, which collectively cover the full lifecycle of a pay change transaction.

• PROCESS_API and PROCESS_PAY_API — the principal entry points that drive a pay transaction through validation and commit, invoking the underlying HR and Payroll APIs.
• PROCESS_NEW_HIRE — handles the pay component of a new-hire transaction, applying default payroll, salary basis, and proposal values.
• CREATE_SALARY_BASIS_CHG_STEP and CHECK_SALARY_BASIS_CHANGE — create and validate the transaction step required when an assignment is moved between salary bases.
• CHECK_GSP_MANUAL_OVERRIDE — determines whether a manual override of grade/step progression (GSP) pay values is permitted.
• UPDATE_TRANSACTION, UPDATE_COMPONENT_TRANSACTION, and DELETE_TRANSACTION — maintain the header and component rows of the pending transaction as the user edits it.
• ROLLBACK_TRANSACTIONS — reverses uncommitted transaction rows when a change is abandoned or fails validation.
• GET_TRANSACTION_STEP and GET_PAY_TRANSACTION — retrieve the current step and transaction context for a given change.
• GET_CREATE_DATE, GET_CREATE_DATE_OLD, and GET_UPDATE_PARAM — resolve effective dates and update parameters used to date-stamp the transaction.
• GET_PAYROLL_PERIOD, GET_COMP_FLEX, and GET_FTE_FACTOR — supply supporting derivation values: the applicable payroll period, the compensation flexfield structure, and the full-time-equivalent factor for proration.

Tables Accessed

The package reads and writes across the HR and Payroll core tables, referenced through APPS synonyms. Transaction state is held in HR_API_TRANSACTIONS, HR_API_TRANSACTION_STEPS, and HR_API_TRANSACTION_VALUES (and its _S sequence/substitution table). Assignment and pay data are drawn from PER_ALL_ASSIGNMENTS_F, PER_ASSIGNMENT_BUDGET_VALUES_F, PER_PAY_BASES, PER_PAY_PROPOSALS, and PER_PAY_PROPOSAL_COMPONENTS. Payroll configuration is resolved from PAY_ALL_PAYROLLS_F, PAY_ELEMENT_ENTRIES_F, PAY_ELEMENT_TYPES_F, PAY_INPUT_VALUES_F, and BEN_PGM_F, with HR_ORGANIZATION_INFORMATION supplying organizational context. Writes to these tables are performed principally through the standard HR/Payroll APIs invoked by PROCESS_API and PROCESS_PAY_API.

Usage Notes

PER_SSHR_CHANGE_PAY is not intended for direct invocation by end users or ad-hoc SQL. It is called by the SSHR salary and pay change flows, and the ETRM records that it is referenced by the HR_PROCESS_ASSIGNMENT_SS and HR_PROCESS_ASSIGNMENT_STEP_SS packages, which manage the assignment change process and its steps. It is also shown as self-referencing, reflecting internal calls between its own procedures. Customizations that need to create or modify a salary change should preferably use the supported HR and Payroll APIs rather than calling this package directly, because it depends on the SSHR transaction framework and the ordering of its step rows. All processing occurs server-side within the APPS schema, and the package must remain VALID and compiled for SSHR salary change functionality to operate correctly after patching or upgrade.