Search Results check_rollback




Overview
Explore in AI Chat

Overview

PSP_NON_ORCL_RLBK_PKG is a PL/SQL package owned by the APPS schema in Oracle E-Business Suite. It is classified as an OTHER API within the ETRM repository, indicating that it is not one of the standard public, supported interfaces such as those published under the Oracle HRMS or Payroll application programming interface families. The package is declared with AUTHID CURRENT_USER, meaning that its SQL statements execute with the privileges and, for name resolution, the schema of the invoking user rather than the defining APPS schema.

The package name indicates its purpose: it supports rollback processing for non-Oracle payroll data. In the Oracle EBS Payroll architecture, data loaded from external or third-party payroll sources into the payroll interface tables must be validated and, where necessary, reversed or backed out before final processing. This package provides the logic that determines whether such a rollback operation is permissible for a given payroll batch, business group, and set of books. The header comment identifies the source file as PSPNORBS.pls, last shipped at version 115.8, reflecting an established maintenance history.

Key Procedures and Functions

The ETRM metadata documents a single callable unit in this package.

  • check_rollback — This is the sole documented procedure. It is a standard concurrent-program style entry point, as evidenced by its errbuf and retcode OUT parameters, which are the conventional reporting parameters used by Oracle concurrent managers to capture completion status and error messages. The procedure also accepts a batch name, a business group identifier, and a set of books identifier, which together identify the payroll data set under consideration. Its purpose is to evaluate whether the specified payroll interface batch can be rolled back and to return an outcome through the standard concurrent program return values. This is the procedure a user would identify when searching for "check_rollback."

The package specification additionally contains a commented-out declaration for a procedure named change_records, which is not implemented in the shipped version and therefore is not part of the active API surface.

Tables Accessed

The package references four payroll interface tables through APPS synonyms. These tables represent the staging and control structures for externally sourced payroll data.

  • PSP_PAYROLL_CONTROLS — Holds the control and header information for each payroll batch, including the batch name. This is the primary table used to identify and validate the batch targeted by check_rollback.
  • PSP_PAYROLL_INTERFACE — The main interface table into which external payroll records are loaded before processing.
  • PSP_PAYROLL_LINES — Stores the individual payroll line-level detail associated with the interface records.
  • PSP_PAYROLL_SUB_LINES — Stores the lowest-level sub-line detail beneath the payroll lines.

Together these tables form a hierarchical staging model. A rollback check must verify the presence and state of records across all four levels before declaring a batch eligible for reversal, since incomplete or partially processed data at any level could render a rollback unsafe.

Usage Notes

Because check_rollback follows the concurrent program parameter convention, it is typically invoked as a concurrent program rather than called directly from a form or ad hoc SQL session. A concurrent program definition would register PSP_NON_ORCL_RLBK_PKG.check_rollback as its executable entry point, with the batch name, business group, and set of books supplied as program parameters. Submission through the concurrent manager ensures proper logging of the errbuf and retcode values.

The package is referenced by zero other packages according to the ETRM metadata, confirming that it sits at the outer layer of the call stack rather than acting as a shared utility. Customizations that extend external payroll rollback handling should preserve the documented procedure signature and treat the package as a supported external entry point. The AUTHID CURRENT_USER clause warrants attention in any environment where the invoking schema differs from APPS, as object resolution depends on synonyms or grants available to that user.