Results for “pay_au_process_parameters_u1”

AI-generated from documented ETRM metadata — verify critical details on the linked pages.

Overview

The HR.PAY_AU_PROCESS_PARAMETERS table is a seed data object within the Oracle E-Business Suite Australian Payroll (PAY_AU) module. It defines the parameters accepted by a given process that may be invoked through the generic code caller framework. Each row associates a named parameter (an internal name and its data type) with a parent process defined in PAY_AU_PROCESSES, along with an enabled flag that controls whether the parameter is active. The table resides in the APPS_TS_SEED tablespace, consistent with its role as a controlled reference/seed object rather than transactional data.

In Data Vault modeling terms, its heuristic classification is satellite-leaning. The table carries descriptive attributes (INTERNAL_NAME, DATA_TYPE, ENABLED_FLAG) and standard who-columns attached to a parent business entity (PAY_AU_PROCESSES), which is the classic profile of a satellite hanging off a hub or link. Modeling it as a satellite keyed to the process entity is a reasonable design suggestion, though the presence of its own surrogate primary key (PAY_AU_PROCESS_PARAMETERS_PK on PROCESS_PARAMETER_ID) also supports treating it as an independent detail entity.

Key Information Stored

The columns below represent the functionally significant content of the table. The remaining columns are standard audit and concurrency controls.

• PROCESS_PARAMETER_ID — NUMBER(15), system-generated surrogate primary key. This is the unique identifier enforced by the PAY_AU_PROCESS_PARAMETERS_PK constraint.
• PROCESS_ID — NUMBER(15), foreign key to HR.PAY_AU_PROCESSES. Identifies the parent process to which the parameter belongs. This is the principal business relationship column.
• INTERNAL_NAME — VARCHAR2(80), the internal (developer-facing) name of the process parameter.
• DATA_TYPE — VARCHAR2(30), the data type of the parameter value.
• ENABLED_FLAG — VARCHAR2(30), indicates whether the parameter is currently enabled.
• OBJECT_VERSION_NUMBER — system-generated version counter that increments with each row update, used for optimistic locking.
• ZD_EDITION_NAME — VARCHAR2(30), the editioning column supporting Oracle EBS 12.2 online patching (edition-based redefinition).
• CREATED_BY / CREATION_DATE — standard who-columns recording the user and timestamp of row creation.
• LAST_UPDATED_BY / LAST_UPDATE_DATE / LAST_UPDATE_LOGIN — standard who-columns recording the most recent modification, its timestamp, and the operating system login context.

The documented business-key candidate is the unique index PAY_AU_PROCESS_PARAMETERS_U1 on the composite of PROCESS_PARAMETER_ID and ZD_EDITION_NAME. Notably, this unique index keys on the surrogate identifier together with the editioning column rather than on INTERNAL_NAME plus PROCESS_ID, which is the combination a user might expect to be the natural business key. Practitioners searching for "pay_au_process_parameters_u1" are typically locating this index in the data dictionary.

Common Use Cases and Queries

Typical scenarios involve interrogating which parameters a given Australian payroll process exposes, validating that a process is correctly configured before invoking it through the generic code caller, and auditing changes to parameter definitions.

To list all enabled parameters for a specific process, join to the parent table on PROCESS_ID and filter on ENABLED_FLAG:

• SELECT p.PROCESS_ID, p.INTERNAL_NAME, p.DATA_TYPE, p.ENABLED_FLAG FROM HR.PAY_AU_PROCESS_PARAMETERS p WHERE p.PROCESS_ID = :process_id AND p.ENABLED_FLAG = 'Y';

To resolve the parameter metadata for the current edition, constrain on ZD_EDITION_NAME or rely on the editioning view (PAY_AU_PROCESS_PARAMETERS#) that exposes only the rows visible to the active edition. Auditors commonly query the who-columns to trace recent configuration changes:

• SELECT PROCESS_PARAMETER_ID, LAST_UPDATED_BY, LAST_UPDATE_DATE, OBJECT_VERSION_NUMBER FROM HR.PAY_AU_PROCESS_PARAMETERS ORDER BY LAST_UPDATE_DATE DESC;

Reverse lookups from results tables are equally common, joining QA_RESULTS or QA_RESULTS_INTERFACE back to this table on PROCESS_PARAMETER_ID to attribute a result value to its defining parameter.

Related Objects

Dependency tracing identifies several objects directly tied to this table:

• HR.PAY_AU_PROCESSES — the parent table, joined via PAY_AU_PROCESS_PARAMETERS.PROCESS_ID = PAY_AU_PROCESSES.PROCESS_ID. This is the primary reference relationship (child to parent).
• HR.PAY_AU_PROCESS_PARAMETERS# — the editioning view generated for the table under the EBS 12.2 online patching model; applications read and write through this view rather than the base table directly.
• QA_RESULTS — references this table via QA_RESULTS.PROCESS_PARAMETER_ID, storing collected result values that correspond to the defined parameters.
• QA_RESULTS_INTERFACE — the interface table for QA_RESULTS, also referencing PROCESS_PARAMETER_ID, used to stage result data before validation and loading.

The table does not reference any object beyond PAY_AU_PROCESSES, and no other HR objects are documented as depending on it. The combination of the seed tablespace, the editioning column, and the two quality-result consumers confirms its role as a low-volume, configuration-oriented parent of parameter-driven result data.