Search Results eoy_control

Overview

PAY_GB_EYCTL is a PL/SQL package in the APPS schema that implements the End of Year control process for Oracle HRMS Payroll (Oracle Payroll) in the United Kingdom legislative context. The package predates the modern Oracle EBS release cycle, with its header record dating to 1995, and it has been carried forward largely unchanged into Oracle EBS 12.1.1 and 12.2.2 as part of the GB localization codebase. Its name follows the Oracle naming convention for GB payroll objects: PAY for HRMS Payroll, GB for the United Kingdom localization, and EYCTL for End of Year Control.

The core business function is to prepare, validate, and control the transition of payroll data across a UK tax year boundary. In the UK, the tax year runs from 6 April to 5 April, and employers must complete statutory end-of-year reporting to HM Revenue & Customs. Within Oracle Payroll, that reporting is driven by processes that assemble year-end values, verify permit numbers and tax district references, and produce the final year-end returns. PAY_GB_EYCTL is the package that exposes the control procedure used to drive this sequence, applying the parameters supplied by the calling process to determine which permit, tax year, and processing mode are in effect.

Key Procedures and Functions

The package contains a single documented procedure, EOY_CONTROL. It is declared as a public procedure that accepts the standard concurrent program style output parameters ERRBUF (OUT VARCHAR2) and RETCODE (OUT NUMBER), together with a set of IN parameters that configure the end-of-year run. These include the employer permit number (p_permit_no), the tax year being processed (p_tax_year), the end-of-year processing mode (p_eoy_mode), the business group identifier (p_business_group_id), and the tax district reference (p_tax_dist_ref).

A group of sort order parameters, p_sort_order1 through p_sort_order7, controls the ordering in which the end-of-year output is presented or written, allowing the caller to tailor the layout of the resulting year-end records. The p_align parameter governs alignment formatting of the output, and p_ni_y_flag carries a National Insurance year indicator that distinguishes the NI year treatment from the tax year treatment where the two differ. The procedure returns status information through ERRBUF and RETCODE, permitting the calling concurrent manager to record success or report an error message.

Tables Accessed

The ETRM metadata for this package does not enumerate any tables accessed directly through APPS synonyms, and no dependent packages are recorded as referencing it. The procedure operates against the GB payroll data model, but the documented metadata does not identify the specific base tables or views. Where table access is required, it is expected to occur through APPS synonyms resolved at runtime under the AUTHID CURRENT_USER declaration, which means privileges are evaluated against the invoking user rather than the package owner.

Usage Notes

EOY_CONTROL is designed to be invoked as the entry point of a concurrent program. Because the parameters follow the Oracle concurrent program conventions for ERRBUF and RETCODE, the procedure is compatible with registration as a PL/SQL stored procedure concurrent program, with the IN parameters supplied as concurrent program parameters or as arguments passed from a Forms-based submission screen. The procedure may also be called from custom PL/SQL code, provided that all mandatory configuration parameters, particularly the business group, tax year, permit number, and processing mode, are supplied consistently with the employer's registration details.

Because the package is AUTHID CURRENT_USER, it is best invoked with the APPS schema as the effective user, as is typical for HRMS concurrent programs. The sort order and alignment parameters should only be varied when there is a specific reporting layout requirement, since incorrect ordering can misalign year-end records against the expected statutory presentation. Change history notes in the source confirm that error handling was added in 1996 and that the declarative style was adjusted for the earlier release, indicating that the package's error signalling is implemented through ERRBUF and RETCODE rather than through raised exceptions.