Search Results pay_action_parameter_groups




Overview
Explore in AI Chat

Overview

The PAY_ACTION_PARAMETER_GROUPS table is a Payroll (PAY) module reference object owned by the HR schema in Oracle E-Business Suite 12.1.1 and 12.2.2. As its description indicates, it stores groups of Pay Action Parameters — the configurable parameter groups that payroll administrators use when defining and controlling how payroll actions (such as QuickPay, Calculate Payroll, PrePayments, and Month-End Accrual) are executed. Each row represents a named grouping that can be referenced by action parameter definitions, allowing the same set of parameter behaviors to be reused consistently across multiple payroll runs and legislative configurations.

Within a heuristic Data Vault classification mined from its foreign-key structure, the object is described as standalone. This suggests that, in a Data Vault modeling exercise, PAY_ACTION_PARAMETER_GROUPS would most naturally be treated as a reference satellite or a small standalone hub rather than a link table, because it participates in no documented outbound foreign-key relationships. Its role is to hold descriptive, low-volatility reference data rather than transactional intersections.

Key Information Stored

The documented physical schema for 12.2.2 defines two columns, both of which are significant:

  • ACTION_PARAMETER_GROUP_ID — the surrogate primary key column that uniquely identifies each parameter group row within the HR schema. Application code and child tables typically carry this numeric identifier.
  • ACTION_PARAMETER_GROUP_NAME — the descriptive, user-facing name of the parameter group, and the documented business-key candidate.

It is important to distinguish these two identifiers. The unique index PAY_ACTION_PARAMETER_GROUPS_UK is defined on ACTION_PARAMETER_GROUP_NAME, establishing the group name as the unique business key. The surrogate key ACTION_PARAMETER_GROUP_ID is the internal, system-generated handle. Because the documented schema lists only these two columns, no additional descriptive, date-tracking, or audit columns are confirmed by the ETRM metadata; any such attributes should be verified against the live data dictionary before reliance in custom code.

Common Use Cases and Queries

Typical usage centers on resolving the group name to its surrogate ID, or listing available groups for reporting and validation of payroll action configuration.

To list all parameter groups:

  • SELECT action_parameter_group_id, action_parameter_group_name FROM hr.pay_action_parameter_groups ORDER BY action_parameter_group_name;

To look up the surrogate key for a specific group:

  • SELECT action_parameter_group_id FROM hr.pay_action_parameter_groups WHERE action_parameter_group_name = :group_name;

For reconciliation or impact analysis, analysts join this table to the action parameter definitions that reference the group by ACTION_PARAMETER_GROUP_ID to determine which payroll actions consume a given grouping. Reporting scenarios include auditing which parameter groups exist, verifying naming conventions across legislations, and validating migrated configuration during upgrades from 12.1.1 to 12.2.2.

Related Objects

Given the standalone classification, the most significant relationships flow inward (child tables referencing this parent) rather than outward. The objects most commonly associated include:

  • PAY_ACTION_PARAMETERS — the primary dependent table; individual parameter rows reference the group via ACTION_PARAMETER_GROUP_ID.
  • PAY_ACTION_PARAMETER_GROUP_USAGES — where present, maps groups to the actions that use them.
  • PAY_ACTION_PARAMETER_VALUES — stores captured parameter values resolved through the group and parameter definitions.
  • PAY_ACTION_PARAMETER_GROUPS_UK — the unique index enforcing the ACTION_PARAMETER_GROUP_NAME business key.
  • PAY_ACTION_INFORMATION_CATEGORIES and PAY_ACTION_INFORMATION_TYPES — adjacent action-configuration reference objects frequently queried alongside groups.
  • Payroll action definition tables (for example, FND/PAY action descriptors) that resolve parameter groups at runtime.
  • Public PL/SQL APIs such as PAY_ACTION_PARAMETER routines used to read group membership programmatically.

Because FK evidence is limited, join columns beyond ACTION_PARAMETER_GROUP_ID should be confirmed against the live dictionary before use in production queries.