Search Results process_step_save




Overview
Explore in AI Chat

Overview

HR_PROCESS_ASSIGNMENT_STEP_SS is a server-side PL/SQL package in the Oracle E-Business Suite HRMS schema (APPS) that supports the processing of assignment grade step placements, including the associated salary proposals, during placement and grade step changes. The package acts as a supplemental save processor for the assignment step business object, complementing the base HR assignment step API. Its primary consumers are the Compensation Workbench and grade step progression flows that must create or update a spinal point step placement on a worker's assignment while simultaneously propagating salary data and posting workflow notifications.

The package is defined with AUTHID CURRENT_USER, meaning it executes with the privileges of the calling user rather than the definer. The date-format constant g_date_format set to RRRR-MM-DD reflects the package's tolerance for string-based date input, which is typical of packages driven from a web-based (self-service) stack where parameters arrive as character strings from the middle tier.

Key Procedures and Functions

  • CREATE_STEP — Creates a new step placement record for an assignment. It accepts validation, effective-date, business-group, assignment, placement, step, and object-version parameters, along with effective start/end dates and a reason. It returns a GSP post-process warning and passes a salary proposal table (sshr_sal_prop_tab_typ) and page-level error variables by reference.
  • UPDATE_STEP — Performs a datetracked update to an existing step placement. In addition to the create-step inputs it accepts a datetrack update mode (default UPDATE), supporting correction and update modes in line with HRMS datetrack conventions. It likewise returns GSP warnings and salary proposal/page-error data.
  • PROCESS_STEP_SAVE — The higher-level orchestrator invoked from the self-service save path. It receives workflow context (item type, item key, activity ID, login person), effective-date options, assignment, placement, step, grade, and grade-ladder program identifiers, then coordinates the underlying create/update processing and salary handling.
  • PROCESS_API — Wraps the API-level processing logic used by the save flow, providing a consolidated entry point for performing the step transaction and returning status to the caller.
  • GET_TRANSACTION_DATA — Retrieves the transaction data required by the step-processing flow. This is the routine most directly relevant to callers searching on this name; it is used to fetch persisted or pending placement/step/pay transaction records so the save logic can evaluate what has changed before committing the step update.
  • DELETE_PAY_STEP — Removes a pay step association tied to the placement, ensuring that obsolete salary step data is not retained when a placement is reversed or superseded.

Tables Accessed

  • PER_ALL_ASSIGNMENTS_F — The assignment datetrack entity that the step placement is attached to.
  • PER_SPINAL_POINTS and PER_SPINAL_POINT_STEPS_F — Define the valid grade step values and their effective-dated definitions.
  • PER_SPINAL_POINT_PLACEMENTS_F — Holds the placement of an assignment on a spinal point step; this is the record created or updated by CREATE_STEP and UPDATE_STEP.
  • PER_PAY_TRANSACTIONS — Stores the salary/pay transaction rows generated or removed as a result of the step change.
  • BEN_PGM_F and WF_ITEMS — Support the benefits program association and the workflow notification/post-processing context referenced in the GSP post-process warning and item-key parameters.

Usage Notes

The package is normally invoked indirectly rather than called directly by end users. It is exercised through the self-service grade step and placement pages, which pass the workflow item type, item key, and activity identifiers into PROCESS_STEP_SAVE; the Oracle Compensation Workbench and grade step progression processes similarly drive the create and update paths. Custom code should call CREATE_STEP and UPDATE_STEP within an HRMS API wrapper that supplies a valid effective date and business group, honors the p_validate flag for dry-run checking, and inspects p_page_error, p_page_error_msg, and p_gsp_post_process_warning for outcomes. Because the ETRM metadata lists no dependent packages referencing it, integration points should be treated as inbound only, and any direct use should respect datetrack modes and the salary proposal table contract.