Search Results per_vgr_shd




Overview
Explore in AI Chat

Overview

PER_VGR_SHD is an Oracle E-Business Suite package body owned by the APPS schema that provides a shadow (shadow-table) maintenance layer for the PER_VALID_GRADES entity within the Oracle Human Resources (PER) product family. In Oracle EBS, "_SHD" suffixed packages are generated or seeded shadow packages that support the Row-By-Row (RBR) shadow-table processing model used by the HR date-tracked (datetrack) framework. Valid Grades define the intersection of a Grade and a Grade Ladder, and — like most HR datetracked entities — they are subject to surrogate-key and versioning logic that must be persisted through shadow tables before the base tables are updated.

The package is classified in the ETRM repository as an OTHER API type rather than a public Business API, meaning it is not intended for direct customer invocation and does not carry the same upward-compatibility guarantees as a formal HR_API package. Its status is VALID in both the 12.1.1 and 12.2.2 releases, and it depends on APPS.HR_API, APPS.HR_UTILITY, APPS.PER_VALID_GRADES, and the SYS.STANDARD package. The ETRM dependency report indicates that PER_VGR_SHD is not referenced by any other database object, confirming its role as a leaf-level utility invoked only at runtime through the shadow framework rather than as a reusable dependency.

Key Procedures and Functions

The ETRM metadata documents five procedures and functions within this package body:

  • RETURN_API_DML_STATUS — Returns the DML status accumulated by the shadow processing, allowing the caller to determine whether the pending shadow operations have resulted in inserts, updates, or no change to the underlying Valid Grades data.
  • CONSTRAINT_ERROR — Handles constraint-violation conditions encountered while applying shadow rows, providing a controlled error path rather than allowing an unhandled Oracle exception to propagate.
  • API_UPDATING — Signals or tracks that an API-driven update is in progress, typically used to suppress or route behaviour that would otherwise trigger during direct table maintenance.
  • LCK — Performs the locking operation required to serialise concurrent shadow processing against the same Valid Grades rows, preventing lost updates in multi-user HR transactions.
  • CONVERT_ARGS — Normalises or converts the argument set passed into the shadow routines so that the internal calls conform to the expected datatypes and datetrack parameters.

No parameter lists are documented in the ETRM repository; the procedures should be treated as internal implementation details of the shadow framework.

Tables Accessed

The only documented table referenced through APPS synonyms is PER_VALID_GRADES. This is the base table holding Valid Grade records, and the shadow package reads from and writes to it as part of applying the validated shadow rows. Because the package is a shadow handler, it operates in tandem with the corresponding shadow table for the entity, but the ETRM dependency extract lists only PER_VALID_GRADES explicitly. All access is performed under the APPS schema via synonyms, consistent with standard EBS seed data conventions.

Usage Notes

PER_VGR_SHD is not exposed as a callable Business API and is not referenced by any documented database object. It is invoked indirectly by the HR datetrack / shadow processing engine whenever Valid Grades records are created, updated, or deleted through supported HR forms and APIs. Typical invocation paths include the Grade and Grade Ladder maintenance windows in the Oracle HRMS Forms application and any concurrent or batch process that manipulates Valid Grades through the HR_API layer.

Because the package is registered as an OTHER API, custom code should not call its procedures directly; doing so bypasses the surrounding validation, security, and date-tracking logic that HR_API and HR_UTILITY provide. Customisations that need to affect Valid Grades should use the documented HR Valid Grades Business API instead, allowing this shadow package to be driven internally as designed. Sites upgrading between 12.1.1 and 12.2.2 can rely on the package remaining VALID and unchanged in its documented interface, as it is seeded Oracle code rather than a customer-owned object.