Search Results per_spp_ins




Overview
Explore in AI Chat

Overview

APPS.PER_SPP_INS is a PL/SQL package in the Oracle E-Business Suite (EBS) Human Resources (HR) module, classified under the "Other" API category. Its name follows Oracle naming conventions: the PER prefix identifies the HR schema area, SPP denotes Salary Placement / Spinal Point Placement, and INS indicates its role as an insert-oriented DML package for placement records. The package serves as the low-level insert layer for the Salary Placement (SPP) business process, in which an employee's assignment is mapped to a specific spinal point and step on a grade spine — the pay progression structure used in public-sector and grade-based compensation models (for example, UK NHS Agenda for Change style pay spines).

In ETRM the object is listed as VALID and is documented as referencing the shadow/audit table PER_SPP_SHD at the package level, confirming that the insert operations are associated with the SPP table family's soft-delete and audit mechanism. Within the broader API stack, PER_SPP_INS acts as a subordinate component rather than a public, user-facing interface: it sits beneath the higher-level HR_SP_PLACEMENT_API and is invoked indirectly by the sibling packages PER_SPP_UPD and, recursively, by itself.

Key Procedures and Functions

The documented package exposes three procedures/functions in total. Two are named in the ETRM metadata:

  • INSERT_DML — the general-purpose DML entry point for the package. Although its parameter list is not documented, its naming and classification indicate it performs the core row-insert logic against the SPP base and shadow tables, handling the standard Oracle DML housekeeping (WHO columns, audit shadowing, and — where applicable — date-tracked effective-dated insertion).
  • INS — the abbreviated insert routine, typically a thin wrapper or specific-use variant of INSERT_DML intended for the standard single-row insert of a spinal point placement. Consistent with Oracle's pairing conventions (such as INS/UPD/DEL across the SPP family), it is the routine most commonly called by sibling packages.

A third documented procedure/function exists but is not itemised in the ETRM excerpt; per the metadata, three total are defined. Because per-parameter signatures are not documented, no parameter lists should be assumed; integrators should obtain the actual specification from the database (via ALL_ARGUMENTS or the package specification source) before invoking these units directly.

Tables Accessed

The documented tables are reached through APPS synonyms and represent the SPP and grade structures that the package populates and validates against:

  • PER_SPINAL_POINT_PLACEMENTS_F and PER_SPINAL_POINT_PLACEMENTS_S — the effective-dated base table and its non-dated/primary-key pair, which are the principal targets of the insert operations.
  • PER_SPP_SHD — the shadow table that receives the audit/version copy of each inserted row, validating the package's DML-shadowing role.
  • PER_SPINAL_POINT_STEPS_F — the step definitions within a spine, read for validation of the step being placed.
  • PER_GRADE_SPINES_F and PER_GRADES — the grade-to-spine configuration read to confirm that the placement is valid for the employee's grade and to determine spine membership.
  • PER_ALL_ASSIGNMENTS_F — the assignment table, read to associate the placement with the correct employee assignment and effective date context.

These accesses are read-heavy against the grade/spine configuration tables and write-oriented against the three SPP tables, matching the package's insert mandate.

Usage Notes

PER_SPP_INS is not intended as a standalone public API. Documented callers/upward references are HR_SP_PLACEMENT_API, PER_SPP_INS itself, and PER_SPP_UPD. Practical invocation therefore occurs in three patterns:

  • Via the SPP API stack — HR_SP_PLACEMENT_API is the business-level entry point; it delegates row creation to PER_SPP_INS after performing higher-level validations.
  • Via PER_SPP_UPD — the update package calls PER_SPP_INS when a change requires a new dated row rather than an in-place update, reflecting standard Oracle date-tracked maintenance.
  • Via custom code — only with caution. Because the package manipulates effective-dated (_F/_S) plus shadow tables, direct invocation from custom concurrent programs or forms requires supplying correct effective dates and handling the shadow row, and — in 12.2.2 — correct handling of the multiple-org (MOAC) and business-group context. Oracle strongly recommends routing through HR_SP_PLACEMENT_API instead.

The package operates identically in 12.1.1 and 12.2.2; the primary difference lies in the surrounding security and data-access framework rather than in the package logic itself. Customisations should never modify the APPS-owned package directly; wrapper APIs or views are the supported extension path.