Search Results hr_wip_transactions




Overview
Explore in AI Chat

Overview

HR.HR_WIP_TRANSACTIONS is an Oracle E-Business Suite work-in-process (WIP) staging table within the PER — Human Resources product family. It stores transaction information and the current processing state of HR-related work items as they move through the application's transaction framework. Each row represents a discrete unit of transactional work — a record that the HR transaction manager is queuing, validating, or committing — together with the metadata needed to route that work to the correct business logic and to reflect its progress back to the user.

The table is registered in ETRM with status VALID and owner schema HR. In Oracle EBS 12.1.1 and 12.2.2 the physical definition is consistent: 15 documented columns. Heuristic Data Vault classification mined from the foreign-key structure identifies this object as standalone, meaning it carries no declared outbound FK relationships. As a modeling suggestion, a standalone transactional staging table of this shape is best treated as a satellite-like structure keyed on its own surrogate identifier rather than as a hub or link, because its business keys are enforced internally through unique indexes rather than through parent references.

Key Information Stored

The documented physical schema contains the following significant columns. The surrogate primary key is TRANSACTION_ID, enforced by HR_WIP_TRANSACTIONS_PK. Two additional unique indexes define business-key candidates: HR_WIP_TRANSACTIONS_U1 (TRANSACTION_ID) and HR_WIP_TRANSACTIONS_U2 (ITEM_TYPE, ITEM_KEY). The U2 index is the meaningful composite key that identifies a work item by the type of item and its natural key value. A system LOB index SYS_IL0000202793C00008$$ accompanies the table.

  • TRANSACTION_ID — Surrogate primary key uniquely identifying each WIP transaction row.
  • ITEM_TYPE — Classifies the work item being processed; paired with ITEM_KEY as the composite business key.
  • ITEM_KEY — The natural key value of the item within its item type.
  • FUNCTION_ID — Identifies the function or business process invoked for the transaction.
  • STATE — The current processing state of the transaction (for example, staged, validated, or completed).
  • SUB_STATE — A finer-grained status indicator within the parent state.
  • VO_CACHE — Cached value-object payload associated with the transaction context.
  • CONTEXT_DISPLAY_TEXT — User-facing descriptive text shown in the transaction context.
  • DML_MODE — Indicates the DML operation semantics applied when the transaction is committed.
  • CREATOR_USER_ID — The user who originated the transaction.
  • Audit columns — CREATED_BY, CREATION_DATE, LAST_UPDATED_BY, LAST_UPDATE_DATE, and LAST_UPDATE_LOGIN provide standard EBS who/when auditing.

Common Use Cases and Queries

Typical scenarios include diagnosing stuck or failed HR transactions, auditing who initiated a transaction and when, and reporting on volume by state. Monitoring pending work is the most frequent operational pattern:

  • SELECT TRANSACTION_ID, ITEM_TYPE, ITEM_KEY, STATE, SUB_STATE FROM HR.HR_WIP_TRANSACTIONS WHERE STATE = :p_state ORDER BY CREATION_DATE;
  • SELECT ITEM_TYPE, STATE, COUNT(*) FROM HR.HR_WIP_TRANSACTIONS GROUP BY ITEM_TYPE, STATE;
  • SELECT * FROM HR.HR_WIP_TRANSACTIONS WHERE ITEM_TYPE = :p_item_type AND ITEM_KEY = :p_item_key; — resolves a specific work item through the U2 business key.
  • SELECT TRANSACTION_ID, CREATOR_USER_ID, DML_MODE, LAST_UPDATE_DATE FROM HR.HR_WIP_TRANSACTIONS WHERE LAST_UPDATED_BY = :p_user_id;

Because the object is standalone, reporting joins must be constructed against the item key and function identifier rather than through declared foreign keys.

Related Objects

No outbound foreign keys are documented for this table, so dependency relationships are inferred rather than enforced. The most significant related objects and the columns linking them are:

  • HR_LOOKUPS — referenced via ITEM_TYPE and STATE/SUB_STATE to resolve lookup meaning.
  • FND_USER — referenced via CREATOR_USER_ID, CREATED_BY, and LAST_UPDATED_BY for user identification.
  • FND_LOGINS — referenced via LAST_UPDATE_LOGIN for session tracing.
  • HR_OPERATING_UNITS — related by the business context of the item being processed.
  • PER_ALL_PEOPLE_F — the typical subject of HR transactions staged here.
  • HR_WIP_TRANSACTIONS_PK / _U1 / _U2 — the primary and unique indexes governing access paths.
  • HR WIP processing APIs and concurrent programs — the transaction manager logic that reads, mutates, and clears rows in this table.

Absence of declared foreign keys means integrity for these relationships is maintained at the application layer, and any reporting built on HR_WIP_TRANSACTIONS should account for orphaned or historical keys.