Results for “instance_id”

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

Overview

PAY_ACTION_INTERLOCKS is a reference and control table in the Oracle E-Business Suite Payroll (PAY) module, owned by the HR schema. Its documented purpose is to hold assignment action interlock definitions that govern rollback processing. In practical terms, the table declares which assignment actions must block, or be blocked by, other assignment actions when the payroll engine attempts to reverse or roll back prior processing results. This interlocks mechanism protects data integrity by preventing contradictory or sequence-dependent rollbacks from executing against the same assignment.

Under the heuristic Data Vault classification mined from its foreign key structure, PAY_ACTION_INTERLOCKS models as a link table. The suggestion arises because the table contains no descriptive attributes of its own beyond its key columns and instead resolves a many-to-many relationship between two rows of the same parent entity, PAY_ASSIGNMENT_ACTIONS. In a Data Vault design, such a structure would typically be represented as a link between two instances of the same hub.

Key Information Stored

The documented physical schema for ETRM 12.2.2 records three columns, two of which form the composite primary key.

• LOCKING_ACTION_ID — A foreign key to PAY_ASSIGNMENT_ACTIONS identifying the action that performs the locking, that is, the action whose presence or prior execution prevents another action from being rolled back.
• LOCKED_ACTION_ID — A foreign key to PAY_ASSIGNMENT_ACTIONS identifying the action that is held back, or locked, when the locking action is present.
• INSTANCE_ID — The instance discriminator column present in the documented schema. In EBS 12.1.1 and 12.2.2 multi-organization and multi-instance deployments, this column isolates interlock definitions belonging to a specific business group or legislative instance context.

The primary key, PAY_ACTION_INTERLOCKS_PK, is documented as the composite (LOCKING_ACTION_ID, LOCKED_ACTION_ID). Because this unique index also enumerates the two business-meaningful columns, the primary key itself acts as the business-key candidate; there is no separate surrogate key column documented. Each row therefore expresses exactly one directed interlock pairing, and the uniqueness constraint ensures that any given locking/locked combination is defined only once.

Common Use Cases and Queries

The primary consumer of this table is the payroll rollback and reversal logic, which consults the interlocks before permitting a reversal to proceed. Functional and technical users also query it to understand why a particular rollback is being rejected, and to audit which action pairs are configured to conflict.

A representative query to inspect all interlocks with their action meanings joins the table twice to PAY_ASSIGNMENT_ACTIONS:

• SELECT i.LOCKING_ACTION_ID, a1.ACTION_TYPE AS locking_action, i.LOCKED_ACTION_ID, a2.ACTION_TYPE AS locked_action FROM HR.PAY_ACTION_INTERLOCKS i, HR.PAY_ASSIGNMENT_ACTIONS a1, HR.PAY_ASSIGNMENT_ACTIONS a2 WHERE i.LOCKING_ACTION_ID = a1.ACTION_ID AND i.LOCKED_ACTION_ID = a2.ACTION_ID ORDER BY 2, 4;
• To isolate definitions for a given instance: SELECT * FROM HR.PAY_ACTION_INTERLOCKS WHERE INSTANCE_ID = :p_instance_id;
• To find every action that is blocked by a specific locking action: SELECT LOCKED_ACTION_ID FROM HR.PAY_ACTION_INTERLOCKS WHERE LOCKING_ACTION_ID = :p_action_id;

Reporting use cases include documenting rollback restriction matrices and verifying that configured interlocks align with legislative and business-group requirements after a patch or upgrade.

Related Objects

The documented foreign keys establish the most significant relationships, both pointing to the assignment action repository.

• PAY_ASSIGNMENT_ACTIONS — Referenced twice, via LOCKING_ACTION_ID and LOCKED_ACTION_ID. This is the principal parent table and the source of all action definitions used by the interlocks.
• PAY_ACTION_INTERLOCKS_PK — The documented composite primary key index, enforcing uniqueness of each locking/locked pairing.
• PAY_ASSIGNMENT_ACTIONS (alias a1 for locking, a2 for locked) — Used in self-join form in the queries above to resolve action types and descriptions.
• Payroll run and reversal processes in the PAY module — These runtime components consume the interlocks table to validate rollback requests, making the table a dependency for reversible payroll processing.

Given the limited documented relationships, the table is best understood as a tightly scoped control construct whose functional significance derives almost entirely from its association with PAY_ASSIGNMENT_ACTIONS.