Results for “internal_control_number”

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

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:

• Document identity: DOCUMENT_TYPE, DOCUMENT_NUMBER, ORIG_DOCUMENT_NUMBER, DOCUMENT_REVISION, and DOCUMENT_DIRECTION identify the shipping document and its direction (for example, outbound versus inbound).
• Transaction classification: TRANSACTION_STATUS and ACTION_TYPE describe the state reached and the action that triggered the history entry.
• Entity and partner context: ENTITY_NUMBER, ENTITY_TYPE, and TRADING_PARTNER_ID link the transaction to the trading partner or organizational entity involved. ITEM_TYPE provides an item-level classification.
• Event information: EVENT_NAME, EVENT_KEY, INTERNAL_CONTROL_NUMBER, and ECX_MESSAGE_ID tie the record to the business event and any associated EDI/e-commerce message processing.
• Audit and responsibility: USER_ID, RESPONSIBILITY_ID, and APPLICATION_ID capture who performed the action and under which responsibility, while CREATION_DATE, CREATED_BY, LAST_UPDATE_DATE, LAST_UPDATED_BY, and LAST_UPDATE_LOGIN provide standard EBS audit columns.
• Concurrent program context: REQUEST_ID, PROGRAM_APPLICATION_ID, PROGRAM_ID, and PROGRAM_UPDATE_DATE identify the concurrent request or program that created the record.
• Flexfield support: ATTRIBUTE_CATEGORY and ATTRIBUTE1 through ATTRIBUTE15 provide the standard DFF storage.

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:

• WSH_DELIVERY_DETAILS and WSH_DELIVERY_ASSIGNMENTS — joined by document number or delivery identifier to correlate history to delivery lines.
• WSH_TRIPS and WSH_TRIP_STOPS — joined where the transaction concerns trip execution.
• FND_USER and FND_RESPONSIBILITY — joined on USER_ID and RESPONSIBILITY_ID for actor resolution.
• FND_CONCURRENT_REQUESTS — joined on REQUEST_ID for program-execution tracing.
• ECX_OUTBOUND_MESSAGES / ECX-related views — joined on ECX_MESSAGE_ID for EDI message diagnostics.

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