Search Results pqh_documents_api




Overview
Explore in AI Chat

Overview

APPS.PQH_DOCUMENTS_API is a public PL/SQL API belonging to the Oracle HRMS (PQH) product family, classified in the ETRM repository as an API. It provides the supported programmatic interface for creating, maintaining, and removing document definitions within Oracle E-Business Suite. In functional terms, a "document" in this context is a configured template or report definition — for example, a printed document type such as a letter, notification, or statement — that is stored against the PQH_DOCUMENTS_F entity and made available to downstream HRMS processes and Oracle XML Publisher (XDO) rendering. The package header carries a header revision of $Header: pqdocapi.pkh 120.1 2005/09/15 14:14:40 rthiagar noship $, and version checks confirm the same interface remains in use across 12.1.1 and 12.2.2. Its procedures are declared as public, meaning they are the sanctioned entry points for both Oracle-delivered code and customer extensions.

The user search term referencing type=BUSINESS_EXCEPTION with errorReasonCode=RESIDENT_QC_POI_DOCUMENT_NOT_APPROVED is relevant because document definitions governed by this package feed the approval and quality-control checks used in resident/POI processing flows. When a required document is not approved, the calling process raises the business exception described above; this package is the layer through which the underlying document records are validated and maintained.

Key Procedures and Functions

The package exposes six documented procedures, organized as three paired create/update/delete operations, each provided in a print-document variant and a standard document variant:

  • CREATE_PRINT_DOCUMENT — Creates a print-oriented document definition. It accepts an effective date, short name, document name, file and formula identifiers, an enable flag, a document category, and — per the XDO-related additions in the header — a LOB code, language, and territory. It returns the new document ID, object version number, and effective start/end dates.
  • CREATE_DOCUMENT — Creates a standard (non-print) document definition using the core set of parameters: effective date, short name, document name, file ID, formula ID, enable flag, and document category, returning the document ID and version/date outputs.
  • UPDATE_PRINT_DOCUMENT — Maintains an existing print document definition, applying changes against the OVN for optimistic locking.
  • UPDATE_DOCUMENT — Maintains an existing standard document definition.
  • DELETE_PRINT_DOCUMENT — Removes a print document definition (typically a logical/date-effective termination).
  • DELETE_DOCUMENT — Removes a standard document definition.

All procedures follow the standard HRMS API convention of supporting a p_validate mode, allowing callers to exercise the business logic in a rollback-only fashion before committing.

Tables Accessed

The documented table reference is PQH_DOCUMENTS_F, accessed via an APPS synonym. This is the date-effective ("_F") base table that stores document definitions, including the short name, document name, associated file and formula references, enable flag, category, and validity dates. Because the table is date-tracked, the create/update/delete procedures operate under the effective-dating model: creations insert a new dated row, updates may split the date range to preserve history, and deletes terminate the range rather than physically removing records. Output parameters such as p_effective_start_date and p_effective_end_date reflect this behaviour.

Usage Notes

PQH_DOCUMENTS_API is typically invoked from HRMS forms, from concurrent programs that seed or migrate document definitions, and from custom PL/SQL that needs to register a report or letter definition for XML Publisher rendering. The extended LOB code, language, and territory parameters on the print variant exist to support XDO multi-language and multi-territory output. The package is referenced by two other packages, meaning its procedures are consumed indirectly by higher-level HRMS or payroll document flows. When integrating, callers should always pass p_object_version_number on updates, handle the date-effective outputs, and be prepared to surface business exceptions such as RESIDENT_QC_POI_DOCUMENT_NOT_APPROVED when a referenced document is not in an approved state.