Search Results wsh_transactions_history




Overview
Explore in AI Chat

Overview

WSH_TRANSACTIONS_HISTORY is a Shipping Execution (WSH) table owned by the WSH schema in Oracle E-Business Suite 12.1.1 and 12.2.2. It stores the transaction history records and functions as the auditing and traceability store for the shipping transaction lifecycle, capturing the discrete events and status transitions that occur against shipping documents as they move through the fulfillment and delivery process.

The table contains 44 documented columns and is validated as part of the ETRM 12.2.2 physical schema. From a Data Vault modeling perspective, the metadata classifies this object heuristically as standalone. Because it documents historical state changes and events, it behaves conceptually like a satellite or event-history table rather than a hub or link. Modelers designing an analytical warehouse adjacent to EBS may therefore treat WSH_TRANSACTIONS_HISTORY as a source for event-sourced satellite structures keyed by the transaction identity.

Key Information Stored

The table's surrogate primary key is the unique index WSH_TRANSACTIONS_HISTORY_U1, defined on TRANSACTION_ID. The most significant columns fall into several logical groups:

Common Use Cases and Queries

Typical uses include reconstructing the history of a delivery or shipment, auditing who changed a transaction status and when, and diagnosing EDI/e-commerce message handling failures via ECX_MESSAGE_ID and EVENT_NAME. A common query pattern retrieves the history for a document number:

  • SELECT TRANSACTION_ID, DOCUMENT_NUMBER, DOCUMENT_TYPE, TRANSACTION_STATUS, ACTION_TYPE, EVENT_NAME, CREATION_DATE FROM WSH.WSH_TRANSACTIONS_HISTORY WHERE DOCUMENT_NUMBER = :p_doc_num ORDER BY CREATION_DATE;
  • Status-transition reporting filters on TRANSACTION_STATUS and groups by ACTION_TYPE to measure throughput.
  • Audit tracing joins USER_ID to FND_USER and RESPONSIBILITY_ID to FND_RESPONSIBILITY to resolve actors and responsibilities.
  • Bulk reconciliation extracts rows by PROGRAM_ID or REQUEST_ID to verify what a concurrent program processed.

Because the table records history rather than current state, reports should always filter by date ranges or document identifiers to limit volume.

Related Objects

The ETRM metadata documents this object as a standalone table with a single unique index and no enforced foreign keys to other objects; the relationship classification is therefore heuristic rather than FK-driven. Logical relationships commonly exploited in reporting include:

These joins are logical conventions supported by shared column names; referential integrity is enforced functionally rather than by declared constraints.