Search Results pay_action_classifications_pk

Overview

HR.PAY_ACTION_CLASSIFICATIONS is a seed data table within the Oracle E-Business Suite Payroll (PAY) schema, owned physically by the HR schema and exposed to applications through the APPS synonym PAY_ACTION_CLASSIFICATIONS. Its documented purpose is to define action type classifications — that is, to associate a given payroll or assignment action type with one or more functional classifications that govern how the action is processed. The ETRM excerpt notes, for example, that a PREPAID action is one processed by the pre-payments process, and that assignment level interlock rules for a process are also controlled by values held in this table. The object resides in the APPS_TS_SEED tablespace with PCTFREE 10, consistent with its role as a reference/seed table rather than a high-volume transactional table.

Under the heuristic Data Vault classification supplied in the metadata, this object is designated as standalone. In modeling terms, this suggests treating the table as a simple reference or lookup hub-like structure keyed on the combination of action type and classification name, without a documented parent link to a separate hub. No foreign key relationships are documented for this object; the dependency information states that HR.PAY_ACTION_CLASSIFICATIONS does not reference any database object, and that it is referenced by the APPS and PUBLIC synonyms of itself.

Key Information Stored

The documented metadata exposes only three columns, reflecting the deliberately narrow, code-lookup nature of the table:

• ACTION_TYPE (VARCHAR2, 30, mandatory) — identifies the type of action being classified, such as a payroll action or assignment action.
• CLASSIFICATION_NAME (VARCHAR2, 30) — the classification assigned to that action type, for example the PREPAID designation used by the pre-payments process.
• ZD_EDITION_NAME — the editioning column present in the 12.2.2 physical schema, used by the Edition-Based Redefinition infrastructure.

The documented business key is the composite unique index PAY_ACTION_CLASSIFICATIONS_PK, whose columns in the ETRM schema trace are ACTION_TYPE, CLASSIFICATION_NAME, and ZD_EDITION_NAME. The search term "pay_action_classifications_pk" therefore refers to this primary key / unique index rather than to a surrogate sequence-generated identifier. Because the table is a seed table with no surrogate key, the primary key effectively coincides with the business key: the pair of ACTION_TYPE and CLASSIFICATION_NAME. There is no separate system-generated ID column documented for this object.

Common Use Cases and Queries

Typical uses of this table include validating which classifications are attached to a given action type, driving conditional logic in payroll pre-payment processing, and controlling assignment level interlock rules for a process. A simple lookup query follows the pattern documented in the ETRM excerpt:

• SELECT ACTION_TYPE, CLASSIFICATION_NAME FROM HR.PAY_ACTION_CLASSIFICATIONS;
• Filter by classification, for example WHERE CLASSIFICATION_NAME = 'PREPAID', to find all action types routed to the pre-payments process.
• Join to related payroll action or process definition views on ACTION_TYPE to enrich reporting with classification context.

Because the table is small and static, it is well suited for use in concurrent program validation sets, value sets, and reporting lookups where a fast reference list of valid action type classifications is required.

Related Objects

The ETRM dependency data documents that this table does not reference any other database object, and that it is referenced only by its own APPS and PUBLIC synonym definitions. Consequently, there are no FK-based relationships to enumerate. Practically, the most significant related objects are:

• APPS.PAY_ACTION_CLASSIFICATIONS — the APPS synonym through which application code and SQL access the table.
• PUBLIC.PAY_ACTION_CLASSIFICATIONS — the public synonym for the same table.
• The HR.PAY_ACTION_CLASSIFICATIONS_PK index on ACTION_TYPE, CLASSIFICATION_NAME (and ZD_EDITION_NAME in 12.2.2).

Where relationships to payroll action and process objects exist, they are resolved at the application layer rather than through database foreign keys, so functional joins should be validated against the corresponding PAY action type and process definition views rather than assumed from constraints.