Search Results create_exception_report

Overview

The APPS.PQP_EXR_API package body is a public Oracle E-Business Suite PL/SQL API that provides a controlled, business-rule-validated interface for the creation and maintenance of exception report definitions. Exception reports are a feature of Oracle Human Resources and Oracle Payroll that allow administrators to identify payroll and assignment records that deviate from a defined norm — for example, balances or dimensions that fall outside a specified variance threshold. Rather than permitting rows to be written directly to the underlying base table, this API enforces the validation rules, security checks, and localization logic required by the ETRM (Enterprise Transaction Resource Model) framework.

The source header (pqexrapi.pkb 120.0.12010000.2, dated 2008/08/08) indicates that the implementation has been stable across the 12.1.1 and 12.2.2 release lines. The package follows the standard Oracle HRMS API architecture, including its own private package globals prefix (g_package := ' pqp_exr_api.'), HR_UTILITY.SET_LOCATION instrumentation for runtime tracing, and a savepoint-based rollback strategy. Each public procedure is a thin wrapper that delegates persistence to the corresponding pqp_exception_report_bk1 table-handler procedure after performing validation and invoking any registered Before Process user hook.

Key Procedures and Functions

• CREATE_EXCEPTION_REPORT — Inserts a new exception report definition into the repository. The procedure accepts the report name and a series of optional qualifying attributes — legislation code, business group, currency, balance type, balance dimension, variance type and value, comparison type and value, output format type, and variance operator — together with a language code defaulting to the session language. The p_validate flag permits a caller to exercise all validation logic in a savepoint-rolled-back transaction, returning validated primary key and version identifiers via the p_exception_report_id and p_object_version_number OUT parameters. The procedure validates the language code, issues a savepoint named create_exception_report, calls the Before Process user hook, and then delegates to pqp_exception_report_bk1.create_exception_report_b.
• UPDATE_EXCEPTION_REPORT — Applies changes to an existing exception report definition. It preserves the object version number for optimistic locking and routes through the corresponding _bk1 update handler after hook execution and validation.
• DELETE_EXCEPTION_REPORT — Removes an exception report definition, subject to the same validation and hooks, and deletes the associated row from PQP_EXCEPTION_REPORTS.

All three procedures are documented as public API classification, and the package is referenced by two other packages in the ETRM model, indicating its role as a foundational dependency for exception-reporting consumers.

Tables Accessed

The package operates against PQP_EXCEPTION_REPORTS (accessed through the APPS synonym), which stores the master definitions of exception reports, including the name, owning business group and legislation, and the variance/comparison criteria that drive evaluation. The API itself does not read transactional payroll data; it maintains only the definitional metadata that subsequent reporting processes consume. All inserts, updates, and deletes are performed by the _bk1 business logic layer, ensuring that row-level auditing and WHO columns and object version numbers are handled consistently.

Usage Notes

PQP_EXR_API is typically invoked by the Exception Reports form in Oracle HRMS, by concurrent programs that copy or seed report definitions between business groups, and by custom PL/SQL code that programmatically provisions exception reports during implementation or migration. Callers should always pass p_validate => TRUE first to confirm the definition is valid before committing, supply the language code explicitly when operating outside the default session language, and handle the HR_API exceptions raised by the validation layer. In keeping with standard ETRM practice, direct DML against PQP_EXCEPTION_REPORTS should be avoided so that user hooks and versioning remain intact.