Search Results per_qh_maintain_update




Overview
Explore in AI Chat

Overview

PER_QH_MAINTAIN_UPDATE is an Oracle E-Business Suite PL/SQL package owned by the APPS schema. It belongs to the Oracle Human Resources (PER) product family and operates within the "QH" naming convention, which is associated with the compensated absence and accrual plan functionality used by Oracle HRMS. The package provides a programmatic maintenance layer for records that are generated and consumed by the absence/accrual processing engine, allowing data held against accrual plan entries to be inserted, modified, and locked through a controlled PL/SQL interface rather than through direct table manipulation.

The package is documented as VALID in the ETRM repository for release 12.1.1 and 12.2.2, and is classified as an "OTHER" API rather than a public, supported interface. Its principal value is internal: it centralises the DML logic required to keep the multiple HR tables that participate in a maintain operation consistent, and it serialises concurrent updates through an explicit locking routine. Because the package is referenced by only one other package and does not itself appear as a Form-attached or concurrent-program-registered API, it is best understood as a low-level utility used by the absence and accrual maintenance processes.

Key Procedures and Functions

  • INSERT_MAINTAIN_DATA — Creates a new maintain record. It is the entry point used when a maintain operation must persist a fresh row of absence or accrual related data, deriving or validating the surrounding HR context as part of the insert.
  • UPDATE_MAINTAIN_DATA — Modifies an existing maintain record. It applies changes to previously stored data, preserving referential integrity with the person, assignment, and period records that the row depends upon.
  • LOCK_MAINTAIN_DATA — Acquires a lock on the target maintain record so that a subsequent insert or update is performed under exclusive control. It is the concurrency-control primitive that prevents two sessions from mutating the same maintain data simultaneously.

The documented interface exposes three procedures and no functions. The metadata does not publish parameter lists, so callers should treat these routines as internal and reference the package body for their exact signatures. The three procedures follow the conventional Oracle HR pattern of lock-then-mutate: LOCK_MAINTAIN_DATA is expected to be invoked before INSERT_MAINTAIN_DATA or UPDATE_MAINTAIN_DATA when the calling process requires a consistent read-modify-write cycle.

Tables Accessed

The package references a broad set of HR tables through APPS synonyms. The core person and assignment entities are represented by PER_ALL_PEOPLE_F and PER_ALL_ASSIGNMENTS_F, which supply the identity and employment context for every maintain operation. Supporting person-level data is drawn from PER_ADDRESSES, PER_PHONES, PER_PERSON_TYPES, PER_APPLICATIONS, and PER_CHECKLIST_ITEMS.

Assignment and placement lifecycle information is sourced from PER_ASSIGNMENT_STATUS_TYPES, PER_PERIODS_OF_SERVICE, PER_PERIODS_OF_PLACEMENT, and PER_DEPLOYMENT_FACTORS. Pay and grade related data is read from PER_PAY_PROPOSALS, PAY_GRADE_RULES_F, and PAY_PEOPLE_GROUPS. HR_SOFT_CODING_KEYFLEX is referenced for key flexfield validation of the HR soft coding segments. Collectively these tables supply the validation, defaulting, and derivation logic required before maintain data is committed.

Usage Notes

PER_QH_MAINTAIN_UPDATE is an internal, non-public package and is not directly registered against a form or concurrent program. It is most likely invoked indirectly by the single dependent package that references it, which in turn is called from the compensated absence and accrual maintenance flows within Oracle HRMS. Custom code should not call this package directly; supported integrations should use the public Oracle HRMS APIs instead.

When extension is unavoidable, developers must invoke LOCK_MAINTAIN_DATA before the insert or update routines, perform the operation within a single transaction, and commit only after all related HR records have been updated. The package runs under the APPS schema, is not documented for multi-org or security-group bypass, and should be tested against both 12.1.1 and 12.2.2 because the dependent object set may differ between these releases. Because dependencies are not guaranteed across patches, any custom usage should be re-validated after applying HRMS patches.