WSH_DELIVERY_DETAILS
Product: WSHtransactionBU-striped (ORG_ID)Per inventory orgThe atomic shipment line — one row per shippable unit of demand, tracking the source order line, item, warehouse, and the requested/picked/shipped quantity lifecycle through pick, stage, and ship confirm
Lines split as they process (SPLIT_FROM_DELIVERY_DETAIL_ID points at the original) — one order line commonly fans out to several rows
The catalog's first dual-anchored table: ORG_ID is the business unit and ORGANIZATION_ID the ship-from inventory org — both anchors render in the generated SQL. Unlike EBS there are NO container rows here — packing goes through license plate numbers (PARENT_LPN_ID). SOURCE_LINE_ID is polymorphic across source documents, so no shipping→order edge is drawn; RELEASED_STATUS codes are not enumerated in the dictionary and ship undecoded.
What the badges mean
- master
- Data class: what the table holds — master data, transaction documents, control/configuration, interface/staging, or a documented view.
Extract access
The delivered surfaces that reach this table — the BICC extract data store (PVO) for bulk extraction and the OTBI subject areas for real-time queries. There is no SQL path to the SaaS database.
- FscmTopModelAM.ScmExtractAM.WshBiccExtractAM.DeliveryLineExtractPVOOTBI: Shipping Real Time
Shipment Lines data store — keyed on DeliveryLinePEODeliveryDetailId, mirroring DELIVERY_DETAIL_ID.
Oracle data-store documentation →
Fields
18 fields · 1 key
| # | Field | Description | Type | Flags |
|---|---|---|---|---|
| 1 | DELIVERY_DETAIL_ID | Surrogate key of the shipment line | NUMBER | Key |
| 2 | ORG_ID | The business unit associated to the row — one of the table's two org anchors | NUMBER | |
| 3 | ORGANIZATION_ID | Ship-from inventory organization — the other org anchor | NUMBER | |
| 4 | INVENTORY_ITEM_ID | Item being shipped | NUMBER | |
| 5 | SOURCE_HEADER_ID | Source document header (a sales order header, most commonly) | NUMBER | |
| 6 | SOURCE_LINE_ID | Source line id — polymorphic across order/WIP/PO sources, so no order edge is drawn | NUMBER | |
| 7 | SOURCE_DOCUMENT_TYPE_ID | Which document type fed the row | NUMBER | |
| 8 | RELEASED_STATUS | Line lifecycle status (ready, released, staged, shipped, backordered) — single-character codes, not enumerated in the dictionary | VARCHAR2 | |
| 9 | REQUESTED_QUANTITY | Quantity to ship | NUMBER | |
| 10 | REQUESTED_QUANTITY_UOM | UOM of the quantity columns | VARCHAR2 | |
| 11 | PICKED_QUANTITY | Quantity picked | NUMBER | |
| 12 | SHIPPED_QUANTITY | Quantity shipped, in the requested-quantity UOM | NUMBER | |
| 13 | CANCELLED_QUANTITY | Quantity canceled by the source system | NUMBER | |
| 14 | DATE_SCHEDULED | Scheduled date for the line | DATE | Filter date |
| 15 | SHIP_TO_PARTY_ID | Ship-to customer party (TCA) | NUMBER | |
| 16 | PARENT_LPN_ID | The license plate (container) the line is packed into — packing goes through LPNs, not container rows | NUMBER | |
| 17 | SPLIT_FROM_DELIVERY_DETAIL_ID | The original line this row split from | NUMBER | |
| 18 | TRACKING_NUMBER | Carrier tracking number for the line | VARCHAR2 |
Field provenance: hand-curated. 1 key field.
Boilerplate SQL
Starting point for reading the BICC-landed copy of WSH_DELIVERY_DETAILSon Databricks — real DATE columns need no conversion, and the org anchor and the LAST_UPDATE_DATE watermark (the column incremental BICC extracts key on) are already in place. Set your Unity Catalog location, schema, and org values below; they’re substituted into the SQL and the copy button.
-- ============================================================
-- Table : WSH_DELIVERY_DETAILS — The atomic shipment line — one row per shippable unit of demand, tracking the source order line, item, warehouse, and the requested/picked/shipped quantity lifecycle through pick, stage, and ship confirm
-- Purpose: Column-selected read of WSH_DELIVERY_DETAILS — auto-generated from field metadata
-- Grain : One row per inventory org (ORGANIZATION_ID) + DELIVERY_DETAIL_ID
-- Caution: Lines split as they process (SPLIT_FROM_DELIVERY_DETAIL_ID points at the original) — one order line commonly fans out to several rows
-- Notes : Auto-generated skeleton for Oracle Fusion Cloud data landed in your lakehouse by a BICC extract — there is no SQL path to the SaaS database. Column names follow Oracle's table documentation — if your landed data still carries PVO attribute headers, map names first; see quirks #pvo-drift. Dates are real DATE/TIMESTAMP columns — no conversion needed. WHO audit columns omitted (see the quirks guide); the optional LAST_UPDATE_DATE watermark filter supports incremental extracts.
-- ============================================================
SELECT
t.DELIVERY_DETAIL_ID AS "Surrogate key of the shipment line",
t.ORG_ID AS "The business unit associated to the row — one of the table's two org anchors",
t.ORGANIZATION_ID AS "Ship-from inventory organization — the other org anchor",
t.INVENTORY_ITEM_ID AS "Item being shipped",
t.SOURCE_HEADER_ID AS "Source document header (a sales order header, most commonly)",
t.SOURCE_LINE_ID AS "Source line id — polymorphic across order/WIP/PO sources, so no order edge is drawn",
t.SOURCE_DOCUMENT_TYPE_ID AS "Which document type fed the row",
t.RELEASED_STATUS AS "Line lifecycle status (ready, released, staged, shipped, backordered) — single-character codes, not enumerated in the dictionary",
t.REQUESTED_QUANTITY AS "Quantity to ship",
t.REQUESTED_QUANTITY_UOM AS "UOM of the quantity columns",
t.PICKED_QUANTITY AS "Quantity picked",
t.SHIPPED_QUANTITY AS "Quantity shipped, in the requested-quantity UOM",
t.CANCELLED_QUANTITY AS "Quantity canceled by the source system",
t.DATE_SCHEDULED AS "Scheduled date for the line",
t.SHIP_TO_PARTY_ID AS "Ship-to customer party (TCA)",
t.PARENT_LPN_ID AS "The license plate (container) the line is packed into — packing goes through LPNs, not container rows",
t.SPLIT_FROM_DELIVERY_DETAIL_ID AS "The original line this row split from",
t.TRACKING_NUMBER AS "Carrier tracking number for the line"
FROM <catalog>.<schema>.WSH_DELIVERY_DETAILS t
WHERE
t.ORG_ID = <business_unit_id> -- business unit — Fusion _ALL means BU, not the EBS operating unit; see quirks guide #all-means-bu
AND t.ORGANIZATION_ID = <inventory_org_id> -- inventory org, NOT the business unit — see quirks guide #item-org-striping
-- AND t.DELIVERY_DETAIL_ID = <DELIVERY_DETAIL_ID>
-- AND t.DATE_SCHEDULED >= DATE '<DATE_FROM>'
-- AND t.DATE_SCHEDULED <= DATE '<DATE_TO>'
-- AND t.LAST_UPDATE_DATE >= TIMESTAMP '<watermark>' -- the column incremental BICC extracts key on
ORDER BY t.DELIVERY_DETAIL_ID;8 parameters not filled: <catalog>, <schema>, <business_unit_id>, <inventory_org_id>, <DELIVERY_DETAIL_ID>, <DATE_FROM>, <DATE_TO>, <watermark>
Relationships
1-hop neighbors — click a table to navigate there. FND lookup decode and translation edges are highlighted; they’re the joins newcomers most often get wrong.
Join details
ON WSH_DELIVERY_ASSIGNMENTS.DELIVERY_DETAIL_ID = WSH_DELIVERY_DETAILS.DELIVERY_DETAIL_IDON WSH_DELIVERY_ASSIGNMENTS.PARENT_DELIVERY_DETAIL_ID = WSH_DELIVERY_DETAILS.DELIVERY_DETAIL_IDON WSH_DELIVERY_DETAILS.INVENTORY_ITEM_ID = EGP_SYSTEM_ITEMS_B.INVENTORY_ITEM_ID AND WSH_DELIVERY_DETAILS.ORGANIZATION_ID = EGP_SYSTEM_ITEMS_B.ORGANIZATION_IDON WSH_DELIVERY_DETAILS.ORGANIZATION_ID = INV_ORG_PARAMETERS.ORGANIZATION_IDON WSH_DELIVERY_DETAILS.ORG_ID = FUN_ALL_BUSINESS_UNITS_V.BU_ID