Search Results pay_upgrade_parameters




Overview
Explore in AI Chat

Overview

PAY_UPGRADE_PARAMETERS is a Payroll (PAY) module table owned by the HR schema in Oracle E-Business Suite 12.1.1 and 12.2.2. As its ETRM description states, it "holds additional parameters to define an upgrade process." In practice, this table functions as a flexible name/value store: each row supplies a single configuration parameter that controls or tunes how a payroll-related upgrade definition behaves. Rather than hard-coding options into upgrade logic, Oracle stores them here so that individual upgrade runs can be parameterized without schema change.

The table is tightly coupled to PAY_UPGRADE_DEFINITIONS through the UPGRADE_DEFINITION_ID foreign key, meaning parameters have no meaning in isolation — they exist only in the context of a parent upgrade definition. Because it is a child attribute table rather than an independent business entity, the heuristic Data Vault classification mined from its FK structure is standalone. From a modeling perspective, it is best treated as a satellite-like structure hanging off the PAY_UPGRADE_DEFINITIONS hub, where the composite business key and the parameter value constitute the descriptive payload.

Key Information Stored

The documented physical schema contains 9 columns, all listed below with their principal roles:

  • UPGRADE_DEFINITION_ID — Foreign key to PAY_UPGRADE_DEFINITIONS; identifies the parent upgrade definition whose behavior this parameter affects. It is a component of the primary/unique key.
  • PARAMETER_NAME — The identifier of the parameter being supplied (for example, a control flag or mode setting). This is a business-key candidate and part of the unique index.
  • PARAMETER_VALUE — The value assigned to the named parameter; this is the core descriptive payload of the row.
  • ZD_EDITION_NAME — Editioning column used by the EBS 12.2 online patching (Edition-Based Redefinition) architecture. It is also part of the unique index.
  • LAST_UPDATE_DATE, LAST_UPDATED_BY, LAST_UPDATE_LOGIN — Standard WHO audit columns capturing when, by whom, and in which login session the row was last changed.
  • CREATED_BY, CREATION_DATE — Standard WHO creation audit columns recording the row's origin.

The surrogate key is enforced by PAY_UPGRADE_PARAMETERS_PK, whose columns are (PARAMETER_NAME, UPGRADE_DEFINITION_ID, ZD_EDITION_NAME). Note that this is a composite key that includes the editioning column; the business identity of a parameter is therefore the pairing of PARAMETER_NAME and UPGRADE_DEFINITION_ID within a given edition.

Common Use Cases and Queries

This table is consulted primarily during upgrade execution and by developers diagnosing upgrade behavior. Typical scenarios include enumerating all parameters for a specific upgrade definition, checking whether a particular control parameter is set, and auditing who last modified a parameter.

A representative query joining to the parent definition:

  • SELECT p.PARAMETER_NAME, p.PARAMETER_VALUE FROM HR.PAY_UPGRADE_PARAMETERS p WHERE p.UPGRADE_DEFINITION_ID = :upgrade_id;

To inspect a single parameter and its audit trail:

  • SELECT PARAMETER_VALUE, LAST_UPDATED_BY, LAST_UPDATE_DATE FROM HR.PAY_UPGRADE_PARAMETERS WHERE PARAMETER_NAME = :name AND UPGRADE_DEFINITION_ID = :id;

Reporting use cases are limited, since the table is configuration metadata rather than transactional data. It is most valuable for troubleshooting why an upgrade behaved in a particular way, and for verifying that expected parameter overrides were applied before or after an upgrade cycle.

Related Objects

The table participates in a narrow but well-defined set of relationships:

  • PAY_UPGRADE_DEFINITIONS — The direct parent referenced by the UPGRADE_DEFINITION_ID foreign key. Joined on UPGRADE_DEFINITION_ID, it supplies the definition-level context for each parameter.

Beyond this documented FK, downstream dependencies are indirect: upgrade execution logic and concurrent programs in the PAY module read PAY_UPGRADE_DEFINITIONS and then resolve its parameters from PAY_UPGRADE_PARAMETERS by passing the same UPGRADE_DEFINITION_ID. Because the table is classified as standalone and holds no further outbound foreign keys, its only mandatory join path is to PAY_UPGRADE_DEFINITIONS; other payroll objects reference it only through that parent. Any query reconstructing the effective configuration of an upgrade should therefore start from PAY_UPGRADE_DEFINITIONS and outer-join to PAY_UPGRADE_PARAMETERS on UPGRADE_DEFINITION_ID.