DOO_HEADERS_ALL
Product: DOOtransactionBU-striped (ORG_ID)The sales order header — one row per orchestration order, carrying the order number, source-system references, sold-to customer, currency, and the status the whole order-to-cash cycle hangs off; business-unit striped
Draft rows share the table — filter SUBMITTED_FLAG = 'Y' for real orders. There is no order-total amount column on the header (totals live in a separate totals table, not yet cataloged), and the hold indicator is spelled ON_HOLD, not ON_HOLD_FLAG. SOURCE_ORDER_* columns carry the originating capture system's identifiers.
What the badges mean
- master
- Data class: what the table holds — master data, transaction documents, control/configuration, interface/staging, or a documented view.
Header & line
DOO_HEADERS_ALL is the header for its lines in DOO_LINES_ALL.
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.DooBiccExtractAM.HeaderExtractPVOOTBI: Order Management - Order Headers Real Time
Sales Order Headers data store — keyed on HeaderId, mirroring the header's key.
Oracle data-store documentation →
Fields
18 fields · 1 key
| # | Field | Description | Type | Flags |
|---|---|---|---|---|
| 1 | HEADER_ID | Surrogate key of the orchestration order | NUMBER | Key |
| 2 | ORDER_NUMBER | The sales order number used with fulfillment systems | VARCHAR2 | |
| 3 | ORG_ID | The business unit owning the order — Fusion's BU stripe, not the EBS operating unit | NUMBER | |
| 4 | SOURCE_ORDER_SYSTEM | Which capture system the order came from | VARCHAR2 | |
| 5 | SOURCE_ORDER_ID | Order id in the originating capture system | VARCHAR2 | |
| 6 | SOURCE_ORDER_NUMBER | Order number in the originating capture system | VARCHAR2 | |
| 7 | SOLD_TO_PARTY_ID | Sold-to customer party (TCA) | NUMBER | |
| 8 | CUSTOMER_PO_NUMBER | The customer's purchase order reference | VARCHAR2 | |
| 9 | STATUS_CODE | Orchestration order status code | VARCHAR2 | |
| 10 | OPEN_FLAG | Y while the order is not closed or canceled | VARCHAR2 | |
| 11 | CANCELED_FLAG | Y when the order is canceled — canceled orders keep their rows | VARCHAR2 | |
| 12 | ON_HOLD | Order not accepting further processing — note the name has no _FLAG suffix | VARCHAR2 | |
| 13 | SUBMITTED_FLAG | N = draft, Y = submitted — filter to Y for real orders | VARCHAR2 | |
| 14 | ORDER_TYPE_CODE | Type of order placed | VARCHAR2 | |
| 15 | TRANSACTIONAL_CURRENCY_CODE | Order header currency | VARCHAR2 | |
| 16 | ORDERED_DATE | When the items were ordered | DATE | Filter date |
| 17 | REQUEST_SHIP_DATE | The customer's originally requested ship date (header default) | DATE | |
| 18 | SUBMITTED_DATE | When the order was validated and submitted | TIMESTAMP |
Field provenance: hand-curated. 1 key field.
Boilerplate SQL
Starting point for reading the BICC-landed copy of DOO_HEADERS_ALLon 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 : DOO_HEADERS_ALL — The sales order header — one row per orchestration order, carrying the order number, source-system references, sold-to customer, currency, and the status the whole order-to-cash cycle hangs off; business-unit striped
-- Purpose: Column-selected read of DOO_HEADERS_ALL — auto-generated from field metadata
-- Grain : One row per business unit (ORG_ID) + HEADER_ID
-- 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.HEADER_ID AS "Surrogate key of the orchestration order",
t.ORDER_NUMBER AS "The sales order number used with fulfillment systems",
t.ORG_ID AS "The business unit owning the order — Fusion's BU stripe, not the EBS operating unit",
t.SOURCE_ORDER_SYSTEM AS "Which capture system the order came from",
t.SOURCE_ORDER_ID AS "Order id in the originating capture system",
t.SOURCE_ORDER_NUMBER AS "Order number in the originating capture system",
t.SOLD_TO_PARTY_ID AS "Sold-to customer party (TCA)",
t.CUSTOMER_PO_NUMBER AS "The customer's purchase order reference",
t.STATUS_CODE AS "Orchestration order status code",
t.OPEN_FLAG AS "Y while the order is not closed or canceled",
t.CANCELED_FLAG AS "Y when the order is canceled — canceled orders keep their rows",
t.ON_HOLD AS "Order not accepting further processing — note the name has no _FLAG suffix",
t.SUBMITTED_FLAG AS "N = draft, Y = submitted — filter to Y for real orders",
t.ORDER_TYPE_CODE AS "Type of order placed",
t.TRANSACTIONAL_CURRENCY_CODE AS "Order header currency",
t.ORDERED_DATE AS "When the items were ordered",
t.REQUEST_SHIP_DATE AS "The customer's originally requested ship date (header default)",
t.SUBMITTED_DATE AS "When the order was validated and submitted"
FROM <catalog>.<schema>.DOO_HEADERS_ALL 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.HEADER_ID = <HEADER_ID>
-- AND t.ORDERED_DATE >= DATE '<DATE_FROM>'
-- AND t.ORDERED_DATE <= DATE '<DATE_TO>'
-- AND t.LAST_UPDATE_DATE >= TIMESTAMP '<watermark>' -- the column incremental BICC extracts key on
ORDER BY t.HEADER_ID;7 parameters not filled: <catalog>, <schema>, <business_unit_id>, <HEADER_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 DOO_HEADERS_ALL.HEADER_ID = DOO_LINES_ALL.HEADER_ID AND DOO_HEADERS_ALL.ORG_ID = DOO_LINES_ALL.ORG_IDON DOO_FULFILL_LINES_ALL.HEADER_ID = DOO_HEADERS_ALL.HEADER_ID AND DOO_FULFILL_LINES_ALL.ORG_ID = DOO_HEADERS_ALL.ORG_IDON DOO_HEADERS_ALL.ORG_ID = FUN_ALL_BUSINESS_UNITS_V.BU_IDON DOO_HOLD_INSTANCES.DOO_HEADER_ID = DOO_HEADERS_ALL.HEADER_ID