Results for “outermost_lpn_id”

50+ results




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

Overview

WMS_SHIPPING_TRANSACTION_TEMP is a temporary staging table owned by the WMS schema in Oracle E-Business Suite (verified in 12.1.1 and 12.2.2). Its documented purpose is to hold data during mobile ship confirmation processing, the workflow through which warehouse operators confirm outbound shipments from RF (radio frequency) mobile devices. When a user confirms a delivery, trip, or license plate from a mobile shipping page, the application populates this table with the transaction lines to be processed, and a concurrent or server-side process consumes those rows to perform the actual ship confirmation against Oracle Shipping execution tables. Because the table is transient in nature, records are typically inserted, processed, and purged within the same transaction lifecycle, making it unsuitable as a permanent reporting source.

From a modeling perspective, the ETRM metadata heuristically classifies this object as a link in a Data Vault sense. That classification is a modeling suggestion rather than a documented Oracle attribute: the table does not carry its own natural business key but instead resolves many-to-many intersections among deliveries, trips, LPNs, items, and dock doors. Any downstream warehouse model should treat it as a relationship carrier with a short retention window.

Key Information Stored

The documented physical schema comprises 24 columns. The most significant include:

No surrogate primary key is documented in the ETRM metadata; the object operates as a link rather than an entity hub, and uniqueness is enforced implicitly by the mobile confirmation process rather than by a declared single-column key.

Common Use Cases and Queries

Because the table is transient, the primary diagnostic use case is troubleshooting stuck or failed mobile ship confirmations. Rows remaining in the table after a confirmation run typically indicate an aborted mobile session or an error in the consuming process.

  • Identifying incomplete confirmations: SELECT DELIVERY_ID, DELIVERY_NAME, COUNT(*) FROM WMS.WMS_SHIPPING_TRANSACTION_TEMP GROUP BY DELIVERY_ID, DELIVERY_NAME;
  • Comparing requested versus confirmed quantities to detect shortages: SELECT DELIVERY_DETAIL_ID, REQUESTED_QUANTITY, QUANTITY FROM WMS.WMS_SHIPPING_TRANSACTION_TEMP WHERE REQUESTED_QUANTITY <> QUANTITY;
  • Auditing LPN-level activity by joining on PARENT_LPN_ID or OUTERMOST_LPN_ID to WMS_LICENSE_PLATE_NUMBERS.
  • Monitoring aging rows using CREATION_DATE to detect sessions that never completed.

Reporting should generally be directed at the permanent shipping tables (WSH_DELIVERY_DETAILS, WSH_NEW_DELIVERIES) rather than this staging object.

Related Objects

The documented foreign keys define the principal relationships:

  • WSH_NEW_DELIVERIES — joined on DELIVERY_ID.
  • WSH_DELIVERY_DETAILS — joined on DELIVERY_DETAIL_ID.
  • WSH_TRIPS — joined on TRIP_ID.
  • WMS_LICENSE_PLATE_NUMBERS — referenced twice, via PARENT_LPN_ID and OUTERMOST_LPN_ID.
  • WMS_LPN_CONTENTS — referenced via LPN_CONTENT_ID.
  • MTL_SYSTEM_ITEMS_B — joined on INVENTORY_ITEM_ID and ORGANIZATION_ID.
  • MTL_ITEM_LOCATIONS — joined on DOCK_DOOR_ID and ORGANIZATION_ID, resolving dock door and staging lane context.

These relationships confirm the table's role as the mobile-side intersection of shipping execution and warehouse LPN structures.