Search Results pay_restriction_parameters




Overview
Explore in AI Chat

Overview

PAY_RESTRICTION_PARAMETERS is an HR-schema table within the Oracle E-Business Suite Payroll (PAY) product family. It stores the definition of row-level restrictions applied to records retrieved by customized Oracle EBS forms. When a form is customized to limit the rows a user can view or act upon, this table supplies the parameters that drive those restrictions, keyed by the application and the form on which the restriction applies. The object resides in the HR schema in both release 12.1.1 and 12.2.2, and its documented status is VALID.

Because the table is a standalone object with no foreign-key dependencies on other business entities, the heuristic Data Vault classification mined from its FK structure is standalone. In modeling terms, this suggests treating PAY_RESTRICTION_PARAMETERS as a small reference or configuration table rather than a hub, link, or satellite in a Data Vault sense; no parent-child relationships are implied by the documented schema.

Key Information Stored

The table holds eleven documented columns. The most significant are:

  • APPLICATION_ID — identifies the Oracle application (product) that owns or invokes the restricted form; part of the primary key.
  • FORM_NAME — the name of the customized form to which the restriction applies; part of the primary key.
  • RESTRICTION_CODE — the identifier of the specific restriction logic configured for the form; the third component of the primary key and the column the user searched for.
  • MULTIPLE_RESTRICTIONS_FLAG — indicates whether more than one restriction may be active or combined for the given form.
  • EXCLUDE_ALLOWED_FLAG — indicates whether an exclusion-style restriction is permitted alongside the primary restriction.
  • ZD_EDITION_NAME — the editioning column used by the E-Business Suite edition-based redefinition (EBR) infrastructure to distinguish editioned rows.
  • Standard audit columns: LAST_UPDATE_DATE, LAST_UPDATED_BY, LAST_UPDATE_LOGIN, CREATED_BY, and CREATION_DATE.

Two unique indexes are documented. The primary key is PAY_RESTRICTION_PARAMETERS_PK over (APPLICATION_ID, FORM_NAME, RESTRICTION_CODE). The editioned unique index extends that candidate business key with ZD_EDITION_NAME, yielding the effective business-key candidate (APPLICATION_ID, FORM_NAME, RESTRICTION_CODE, ZD_EDITION_NAME). No separate surrogate key column is documented; the composite primary key serves as the row identifier.

Common Use Cases and Queries

The principal use case is diagnosing or configuring form-level row restrictions during a payroll or HR customization. A typical lookup returns all restrictions defined for a given form:

  • Find restrictions by form: SELECT APPLICATION_ID, FORM_NAME, RESTRICTION_CODE FROM HR.PAY_RESTRICTION_PARAMETERS WHERE FORM_NAME = :form_name;
  • Retrieve a single restriction: SELECT * FROM HR.PAY_RESTRICTION_PARAMETERS WHERE APPLICATION_ID = :app_id AND FORM_NAME = :form_name AND RESTRICTION_CODE = :restriction_code;
  • Inventory configured restrictions for an application: SELECT FORM_NAME, RESTRICTION_CODE FROM HR.PAY_RESTRICTION_PARAMETERS WHERE APPLICATION_ID = :app_id;

Reporting scenarios include producing a catalogue of customized forms and their restriction codes for audit or upgrade impact analysis, and verifying whether multiple or exclusion restrictions are enabled for a form via the MULTIPLE_RESTRICTIONS_FLAG and EXCLUDE_ALLOWED_FLAG columns. Because the table is small and configuration-oriented, queries are typically simple predicates on the composite key columns rather than joins.

Related Objects

Given the standalone classification, no foreign-key relationships to other business tables are documented. Related objects are therefore referenced through shared key attributes rather than enforced constraints:

  • PAY_RESTRICTION_PARAMETERS_PK — the primary-key index over (APPLICATION_ID, FORM_NAME, RESTRICTION_CODE); the primary access path for this table.
  • The editioned unique index over (APPLICATION_ID, FORM_NAME, RESTRICTION_CODE, ZD_EDITION_NAME) — supports edition-aware lookups under EBR.
  • FND_APPLICATION — joinable via APPLICATION_ID to resolve the owning application name.
  • FND_FORM — joinable via FORM_NAME and APPLICATION_ID to resolve form metadata.
  • Customized payroll and HR form definitions that consume the restriction codes stored here at runtime.

These associations are implied by the shared APPLICATION_ID and FORM_NAME business-key columns; the metadata documents no enforced foreign keys.