Search Results get_table_bands

Overview

PAY_KW_GENERAL is a general-purpose PL/SQL utility package in the Oracle EBS Payroll (PAY) application, owned by APPS and declared AUTHID CURRENT_USER. Despite its Kuwait-specific naming convention (the "KW" token), the package exposes a set of widely applicable helper routines used across payroll processing, legislative reporting, and assignment validation. Its header, shipped under pykwgenr.pkh at version 120.1.12010000.1 (2008), indicates the package has been stable since the early R12 release and remains available in both 12.1.1 and 12.2.2.

The package addresses three broad concerns: nationality rules for local versus expatriate workers, message and parameter retrieval for payroll logic, and assignment-level calculations that aggregate payroll data. In the ETRM classification it is tagged OTHER rather than as a published business API, meaning it is intended primarily for internal product use, seeded fast formulas, and reporting logic, though customers may call it from custom code with appropriate caution.

Key Procedures and Functions

Nine documented routines make up the public interface:

• LOCAL_NATIONALITY_NOT_DEFINED — Determines whether a local nationality has been configured for a given business group, allowing payroll logic to branch when setup is incomplete.
• LOCAL_NATIONALITY_MATCHES — Evaluates whether an assignment's nationality matches the configured local nationality as of a specified date earned, supporting differentiation of local versus expatriate treatment.
• GET_LOCAL_NATIONALITY — Returns the configured local nationality value for use in downstream comparisons and reporting.
• GET_MESSAGE — Retrieves a translatable message by product and message name, with up to three optional substitution tokens, enabling consistent, localized error and information text.
• GET_TABLE_BANDS — Returns a band value from a named table for a given date earned and requested return type, typically used for progressive tax or contribution banding.
• GET_PARAMETER — Fetches a stored parameter value, providing a central lookup for configurable payroll constants.
• CHK_MULTIPLE_ASSIGNMENTS — The routine users most often search for; it checks whether a person holds multiple assignments, a prerequisite for correct proration, aggregation, and eligibility logic.
• GET_COUNT — Returns a count of qualifying records for the calling context, used to detect duplicates or measure population size.
• GET_SUM — Returns an aggregated numeric total over qualifying records, used in balance and payment calculations.

Tables Accessed

The package reads from several core HR and Payroll tables via APPS synonyms. Assignment and person data come from PER_ALL_ASSIGNMENTS_F and PER_ALL_PEOPLE_F, with PER_ASSIGNMENT_STATUS_TYPES supplying status context. Organization and legislative context are drawn from HR_ALL_ORGANIZATION_UNITS and HR_ORGANIZATION_INFORMATION, which hold business group and organization classifications relevant to nationality rules. Payroll processing data is sourced from PAY_ASSIGNMENT_ACTIONS, PAY_PAYROLL_ACTIONS, and PAY_PRE_PAYMENTS, supporting aggregation and action-history checks. User-defined table structures are read through PAY_USER_TABLES and PAY_USER_ROWS_F, which back the GET_TABLE_BANDS routine. In combination these reads allow CHK_MULTIPLE_ASSIGNMENTS, GET_COUNT, and GET_SUM to operate over live assignment and payroll data without duplicating query logic in each caller.

Usage Notes

PAY_KW_GENERAL is not a forms-attached API; it is invoked from seeded fast formulas, payroll concurrent programs, and reporting logic that requires nationality checks, message retrieval, or assignment aggregation. Because it is AUTHID CURRENT_USER, callers must have the necessary object privileges on the underlying APPS synonyms. Two other packages reference it, indicating reuse within the payroll codebase. Custom developers calling CHK_MULTIPLE_ASSIGNMENTS or the aggregation routines should be aware that results depend on effective-dated assignment and payroll action data and should pass appropriate date parameters. Given its OTHER classification, Oracle does not guarantee upward compatibility of the signature, so custom code should be validated after any patch or upgrade.