Search Results check_termination

Overview

PAY_AU_REC_DET_ARCHIVE is an Oracle E-Business Suite package owned by the APPS schema and classified under the "OTHER" API category. It is a legislative-specific archive package for Australian payroll, designed to support the retention and archival of detailed payroll records. The package operates as a set of payroll action callback routines, meaning it is invoked by the Oracle Payroll processing engine at defined points during a payroll run or a post-run archival task. Its central purpose is to extract, process, and preserve assignment-level payroll results — element entries, run results, and action information — so that historical payroll data can be retained for audit, reconciliation, and statutory reporting obligations without relying on the live transactional tables.

The package declares an AUTHID CURRENT_USER specification, so all SQL executes with the privileges of the calling schema. The source header shows a long change history extending from 2003 to 2008, with significant revisions such as the addition of termination checking, the delete_actions parameter, and the element payment hours and rate functions.

Key Procedures and Functions

The package exposes eight documented routines. The first four are standard payroll action callback entry points:

• RANGE_CODE — defines the range of assignments or actions that the payroll action processes.
• INITIALIZATION_CODE — performs setup before the main processing pass.
• ASSIGNMENT_ACTION_CODE — processes actions at the individual assignment level.
• ARCHIVE_CODE — carries out the core archival logic, persisting detail records.

The remaining routines provide utility and reporting support:

• SPAWN_ARCHIVE_REPORTS — submits concurrent report requests associated with the archive process.
• CHECK_TERMINATION — evaluates an assignment's termination status, added to ensure terminated employees are handled correctly during archival.
• GET_ELEMENT_PAYMENT_HOURS — added in version 1.4 (bug 5603254), this function returns payment hours associated with an element for the assignment being processed. This is the routine most closely associated with the search term "get_element_payment_hours."
• GET_ELEMENT_PAYMENT_RATE — added in version 1.8, returns the corresponding payment rate for an element.

Tables Accessed

The package reads and writes a broad set of payroll and HR tables through APPS synonyms. Transactional payroll data flows through PAY_ASSIGNMENT_ACTIONS, PAY_ELEMENT_ENTRIES_F, PAY_RUN_RESULTS, and PAY_INPUT_VALUES_F, which supply the element entries and calculated results being archived. PAY_PAYROLL_ACTIONS and PAY_ACTION_INFORMATION (with its _S shadow table) drive action context and parameters. PAY_ELEMENT_TYPES_F and PAY_ELEMENT_CLASSIFICATIONS qualify the elements whose hours and rates are retrieved. Employee identity and status come from PER_ALL_PEOPLE_F and PER_ASSIGNMENT_STATUS_TYPES. Organization and coding context is drawn from HR_ALL_ORGANIZATION_UNITS and HR_SOFT_CODING_KEYFLEX. FND_CONCURRENT_REQUESTS is referenced to track spawned concurrent report submissions. Shadow tables PAY_ASSIGNMENT_ACTIONS_S and PAY_ACTION_INFORMATION_S support concurrent-safe access.

Usage Notes

This package is not intended for direct invocation by end users or ad hoc custom code. It is registered as a payroll action or archive process and is driven by the Oracle Payroll engine, which calls each callback in sequence during a payroll run. The SPAWN_ARCHIVE_REPORTS routine interacts with the concurrent manager, so its execution is typically tied to a concurrent program definition. The GET_ELEMENT_PAYMENT_HOURS and GET_ELEMENT_PAYMENT_RATE functions are commonly referenced by custom payroll reports or archival extracts that need element-level hours and rates for Australian legislative reporting. Because the package uses AUTHID CURRENT_USER, any custom caller must ensure that the invoking schema has appropriate grants on the underlying payroll tables. The presence of version-specific change history indicates the package evolved alongside statutory requirements, and implementers should confirm that the version deployed in their 12.1.1 or 12.2.2 instance includes the routine they intend to call.