Search Results create_sf52_for_mass_changes

Overview

GHR_MASS_CHANGES is an Oracle HRMS PL/SQL package owned by the APPS schema that supports the mass change functionality within Oracle E-Business Suite. Mass changes allow HR administrators to apply a single set of modifications — such as salary adjustments, assignment updates, or job changes — to a defined group of employees simultaneously, rather than processing each record individually. The package acts as a programmatic layer that translates a mass change request into the underlying records required for Oracle Payroll and HR processing. Specifically, it creates the payroll action request records and supporting remarks that drive the downstream processing of a batch mass change. The package is classified as OTHER in the ETRM repository, indicating it is an internal component used primarily to support the Oracle Payroll and HR mass change flows rather than a formally published public API. It is documented in EBS 12.1.1 and 12.2.2 and is referenced by six other packages, confirming its role as a shared dependency in the mass change processing chain.

Key Procedures and Functions

The package exposes two documented procedures:

• CREATE_SF52_FOR_MASS_CHANGES — This procedure creates the SF52 (a payroll action request type) records associated with a mass change operation. It accepts a mass action type indicator and operates on a GHR_PA_REQUESTS record, which is passed as an IN OUT NOCOPY parameter so that the procedure can both read and update the request row. It also returns the standard concurrent manager error buffer and return code parameters (p_errbuf, p_retcode), indicating that it is designed to be called from a concurrent program context where errors must be logged and status reported back to the request framework.
• CREATE_REMARKS — This procedure creates remark records associated with a payroll action request. It accepts a GHR_PA_REQUESTS record (by reference) and a remark code derived from GHR_REMARKS.CODE. The remark code identifies the type or category of the remark to be attached, allowing the mass change to record explanatory or audit information against the generated request. Because the user search term is "create_remarks," this procedure is the primary entry point of interest for developers investigating how mass change remarks are generated.

Tables Accessed

The package reads and writes a set of HRMS and payroll tables through APPS synonyms. GHR_PA_REQUESTS is the central table, holding payroll action request headers that are created or updated during mass change processing. GHR_REMARKS supplies valid remark codes referenced by CREATE_REMARKS, while GHR_PA_REMARKS stores the remarks actually written against a request. GHR_PA_ROUTING_HISTORY records the routing and approval history of the action request. Supporting configuration and lookup tables include GHR_MASS_SALARIES (mass salary definitions), GHR_FAMILIES and GHR_NOA_FAMILIES (mass change family groupings), GHR_NATURE_OF_ACTIONS (action type definitions), GHR_GROUPBOXES and GHR_POIS (mass change selection criteria and points of interest), and PAY_USER_TABLES for user-defined payroll table lookups. FND_SESSIONS is referenced for session context, and DUAL is used for scalar expressions.

Usage Notes

GHR_MASS_CHANGES is typically invoked through the Oracle HRMS mass change forms or the associated concurrent programs that submit mass change batches. The presence of the standard concurrent manager parameters (p_errbuf, p_retcode) in CREATE_SF52_FOR_MASS_CHANGES confirms it is intended to run in a concurrent processing context, where the request is submitted and processed in the background. CREATE_REMARKS is more likely called as a subordinate step within mass change processing, attaching remarks to a request after it has been created. Because the package is classified as OTHER and is referenced by six other packages, customizations should avoid modifying it directly. Developers integrating with mass change functionality should call the documented procedures from custom concurrent programs or wrapper packages rather than altering the package body. As with all APPS-owned HRMS packages in 12.1.1 and 12.2.2, any extension should be validated against the specific patch level, since object definitions can change between releases.