Search Results check_control
Overview
APPS.PAY_USER_CHECK is a user hook package in the Oracle E-Business Suite Payroll (PAY) module. Its purpose is to provide a controlled extension point through which implementers can inject site-specific validation logic into the batch element entry upload process. The package body header, dated 27-Apr-1995 and authored by S.Toor, describes its role as a process "for allowing the user to carry out any additional checks on the uploaded element entries." The package is classified as OTHER in the ETRM metadata for release 12.2.2, indicating it is not a standard public API but rather a customization framework package. All three documented procedures are delivered as stubs — the body of validate_header is null — meaning Oracle ships the signatures and calls the procedures at defined points in the upload flow, but performs no validation itself until a customer implements the logic. This allows payroll administrators to enforce organization-specific business rules (for example, cost center restrictions, element eligibility, or balancing checks) without modifying Oracle-owned code.
Key Procedures and Functions
The package exposes three documented procedures, each corresponding to a stage of batch element entry processing:
- VALIDATE_HEADER — Given a batch identifier, carries out additional user-defined checks on the batch header. Depending on the outcome, it returns an appropriate status and, if necessary, a message for the batch header. This is the procedure targeted by the search term "validate_header" and is the entry point for header-level rule enforcement.
- CHECK_CONTROL — Given a batch identifier, performs user-defined control checks on the batch. A status and, where applicable, a message are returned for each type of control check carried out.
- VALIDATE_LINE — Completes the set by applying user-defined validation to individual batch lines, following the same status-and-message return convention as the header and control procedures.
All three procedures are empty stubs in the delivered package body; implementers supply the actual validation logic. The metadata does not document parameter lists beyond those visible in the source excerpt, so parameter details should be confirmed against the deployed package specification.
Tables Accessed
The ETRM metadata lists no tables referenced through APPS synonyms for this package. This is consistent with its role as a stub: the shipped body performs no DML and no queries. Any tables read or written will be those introduced by the customer's implementation of the stub procedures, which typically query element, element entry, batch header, and batch line tables in the PAY schema (such as PAY_ELEMENT_ENTRIES_F, PAY_BATCH_HEADERS, and PAY_BATCH_LINES) to evaluate the custom rules. Because no table dependencies are declared by Oracle, implementations should be validated for performance and must avoid direct writes to core Payroll tables outside supported APIs.
Usage Notes
PAY_USER_CHECK is invoked indirectly by the standard batch element entry upload process rather than being called directly by end users. In a typical flow, a user uploads element entries through the Batch Element Entry form or the associated concurrent program; that process calls validate_header, check_control, and validate_line at the appropriate stages, passing the batch identifier and receiving back a status and message. A non-approving status causes the batch or line to be flagged, and the returned message is surfaced to the user for correction. Because the delivered procedures are stubs, any customization must be applied carefully: edits to this package body are overwritten by patching, so changes should be preserved as a documented custom version and reapplied after upgrades. The package is referenced by one other package within the application, confirming it is wired into the payroll batch processing chain at both 12.1.1 and 12.2.2. Testing after implementation should cover all three hook points, and error messages returned should be meaningful enough for payroll users to resolve rejections.
-
PACKAGE BODY: APPS.PAY_USER_CHECK
12.1.1
-
PACKAGE BODY: APPS.PAY_USER_CHECK
12.2.2
-
PACKAGE BODY: APPS.PAY_STANDARD_CHECK
12.2.2
-
PACKAGE BODY: APPS.PAY_STANDARD_CHECK
12.1.1
-
PACKAGE: APPS.PAY_STANDARD_CHECK
12.1.1
-
PACKAGE: APPS.PAY_STANDARD_CHECK
12.2.2
-
PACKAGE: APPS.PAY_USER_CHECK
12.2.2
-
PACKAGE: APPS.PAY_USER_CHECK
12.1.1
-
APPS.PAY_STANDARD_CHECK dependencies on PAY_STANDARD_CHECK
12.1.1
-
APPS.PAY_STANDARD_CHECK dependencies on PAY_STANDARD_CHECK
12.2.2
-
APPS.PAY_STANDARD_CHECK dependencies on HR_UTILITY
12.1.1
-
APPS.PAY_USER_CHECK dependencies on PAY_USER_CHECK
12.2.2
-
APPS.PAY_USER_CHECK dependencies on PAY_USER_CHECK
12.1.1
-
APPS.PAY_STANDARD_CHECK dependencies on HR_UTILITY
12.2.2
-
APPS.PAY_STANDARD_CHECK dependencies on STANDARD
12.2.2
-
APPS.PAY_STANDARD_CHECK dependencies on STANDARD
12.1.1
-
APPS.PAY_STANDARD_CHECK dependencies on STANDARD
12.2.2
-
APPS.PAY_STANDARD_CHECK dependencies on STANDARD
12.1.1