Search Results all_records

Overview

PSP_VALID_NON_ORCL_PKG is an Oracle EBS Applications (APPS) schema PL/SQL package that performs validation of non-Oracle sub-lines within the Oracle Payroll and Oracle Time and Labor context. The package header, identifiable by its source revision marker PSPNONS.pls and revision number 115.6 dated 2003/07/24, defines a single public interface exposed through a Procedure All_Records. The declared AUTHID CURRENT_USER clause indicates that the package executes with the privileges of the invoking user rather than the definer, which is significant for a validation routine that must be called from multiple module contexts while respecting caller-level security on payroll and assignment data.

The documented purpose, captured in the embedded comment "package created by Al for validating Non Oracle Sub lines," establishes this object as a rule-checking utility for sub-lines that are not sourced from Oracle to Oracle integrations. In ETRM terms it is classified as an OTHER API, meaning it is not registered as a standard Open Interface or public Web Service API but remains a callable validation routine. It is referenced by one other package, confirming it participates in a larger payroll processing chain rather than operating standalone.

Key Procedures and Functions

The ETRM metadata documents a single procedure:

• ALL_RECORDS — The sole documented entry point. Its role is to validate non-Oracle sub-lines supplied to the payroll interface. The procedure accepts a batch name, business group identifier, set of books identifier, precision and extended precision values, and a currency code, which collectively scope the validation to a specific payroll batch and ledger context. The batch name identifies the set of records under examination, the business group and set of books determine the operating context, the precision parameters control numeric comparison tolerances, and the currency code governs monetary validation. No return value is declared, so the procedure communicates results through the underlying interface tables or through exceptions raised on validation failure. Parameter lists are not reproduced here beyond what the header documents; consumers should treat the signature as defined by the source and never assume additional parameters.

Tables Accessed

The package references the following tables through APPS synonyms, reflecting a read-mostly validation posture:

• PAY_ELEMENT_TYPES_F — Element definitions used to confirm that sub-lines correspond to valid payroll elements.
• PER_ALL_ASSIGNMENTS_F — Assignment records, providing the employee-to-assignment linkage needed to validate the party a sub-line applies to.
• PER_TIME_PERIODS — Payroll time periods, used to verify that the period referenced by an incoming record is open and valid.
• PSP_ELEMENT_TYPES — Oracle Payroll process-specific element types, the core reference for classification of processed elements.
• PSP_PAYROLL_INTERFACE — The payroll interface staging/validation table where incoming non-Oracle sub-lines reside and where validation outcomes are surfaced.
• PSP_PAYROLL_SOURCES — Payroll source definitions, used to identify the origin of records and to distinguish non-Oracle sources from Oracle-originated ones.

Usage Notes

Because PSP_VALID_NON_ORCL_PKG is classified as OTHER and is cited as referenced by one other package, it is typically invoked programmatically from a parent payroll processing package rather than directly from a form or a standalone concurrent program. In a 12.1.1 or 12.2.2 environment it is reached as part of the payroll interface validation cycle, where a batch identified by v_Batch_Name is checked against the business group and ledger context before sub-lines are accepted. Custom extensions or inbound integrations that populate non-Oracle payroll sub-lines should call ALL_RECORDS after staging data into PSP_PAYROLL_INTERFACE and before the records are consumed by downstream payroll run logic. Developers referencing the "all_records" code path should note that the package is dated and carries no modern editioning or wrapping changes; validation behaviour should be verified against the exact patch level in use, and any custom invocation must supply a consistent business group, set of books, precision, and currency to avoid false validation errors.