/SCWM/DOOR_SRACT
transactionMixed keyDoor activities — the shipping-and-receiving activities assigned to a warehouse door, with the planned and actual occupancy window
Door occupancy, not dock throughput — a row says the door was reserved for an activity between two stamps, and overlapping planned windows are the door-scheduling problem this table exposes
The one activity table keyed by warehouse number, because doors are only unique within a warehouse; the transportation-unit and vehicle activity tables key on their own object number instead. The door itself is configuration and resolves against the door table in the warehouse-structure module. ACT_ID shares its data element with the transportation-unit activity's, which is what lets a door occupancy be tied to the trailer standing at it.
What the badges mean
- master
- Data class: what the table holds — master data, transaction documents, configuration, an organizational object, or a language-striped text companion.
- Semantic key
- Every non-client key column is readable business data —
LGNUMplus a bin, task, or order number. Joins run on the columns you can see (see the quirks guide). - GUID key
- Every non-client key column is a GUID —
RAW(16)on the /SCWM, /SCDL, /LIME, and /SCMB tables, and theCHAR(22)compressed form on the product master. Join the raw column; a hex rendering is for reading only, and the two encodings need converting between (see the quirks guide). - Mixed key
- The key mixes readable and GUID columns in either direction — a product GUID inside an otherwise-readable bin key, or a readable status type inside an otherwise-GUID key. Check which side of a join you are on (see the quirks guide).
- DOCCAT: PDO
- A /SCDL delivery table holds several document categories in one table — inbound and outbound requests, the inbound delivery, the outbound delivery order, and the final outbound delivery — discriminated by
DOCCAT. The chips list the categories this table carries; anchor the one you mean or documents of every kind come back together (see the quirks guide). - Embedded S/4HANA only
- Deployment: shown only when a table does not exist in both embedded S/4HANA EWM and decentralized EWM. No table in this wave is deployment-specific, so the badge stays absent until one is.
Structural facts — how the table is keyed, not a trap by itself
Join & extract hazards — verify before you rely on this
Fields
16 fields · 4 key
16 fields.
| # | Field | Description | Type | Flags |
|---|---|---|---|---|
| 1 | MANDT | Client | CLNT(3) | Key |
| 2 | LGNUM | EWM warehouse number — doors are unique only within it | CHAR(4) | Key |
| 3 | DOOR | Warehouse door the activity is assigned to | CHAR(4) | Key |
| 4 | DOOR_SR_ACT_NUM | Activity number at that door — one occupancy of the door | NUMC(10) | Key |
| 5 | ACT_ID | GUID of the shipping-and-receiving activity — the same identifier the transportation unit's activity row carries, which is how a door occupancy is tied to the trailer standing at it | RAW(16) | |
| 6 | ACT_TYPE | Activity type | CHAR(1) | |
| 7 | ACT_CAT | Activity category | CHAR(1) | |
| 8 | ACT_DIR | Direction of the activity — inbound against outbound | CHAR(1) | |
| 9 | START_PLAN_TSTFR | Earliest planned start of the door occupancy | DEC(15) | |
| 10 | START_PLAN_TSTTO | Latest planned start of the door occupancy | DEC(15) | |
| 11 | START_ACTUAL | Actual start of the door occupancy | DEC(15) | UTCFilter date |
| 12 | START_TZONE | Time zone the start times are read in locally — the stored values are UTC | CHAR(6) | |
| 13 | END_PLAN_TSTFR | Earliest planned end of the door occupancy | DEC(15) | |
| 14 | END_PLAN_TSTTO | Latest planned end of the door occupancy — the pair of planned windows is what a door-scheduling conflict is measured against | DEC(15) | |
| 15 | END_ACTUAL | Actual end of the door occupancy | DEC(15) | |
| 16 | END_TZONE | Time zone the end times are read in locally | CHAR(6) |
Field provenance: hand-curated. 4 key fields.
Boilerplate SQL
Starting point for reading the replicated copy of /SCWM/DOOR_SRACTon Databricks — the client anchor is already in place, the namespaced name is rendered as the underscore bronze name replication targets conventionally land it under, and any RAW16 GUID column selects a hex rendering alongside the raw value. Set your Unity Catalog location, schema, and filter values below; they’re substituted into the SQL and the copy button.
7 parameters not filled: <catalog>, <schema>, <client>, <LGNUM>, <DOOR>, <TS_FROM>, <TS_TO>
-- ============================================================
-- Table : /SCWM/DOOR_SRACT — Door activities — the shipping-and-receiving activities assigned to a warehouse door, with the planned and actual occupancy window
-- Purpose: Column-selected read of /SCWM/DOOR_SRACT — auto-generated from field metadata
-- Grain : One row per client + LGNUM + DOOR + DOOR_SR_ACT_NUM
-- Caution: Door occupancy, not dock throughput — a row says the door was reserved for an activity between two stamps, and overlapping planned windows are the door-scheduling problem this table exposes
-- Notes : Auto-generated skeleton for SAP EWM data replicated into your lakehouse — it reads the replicated copy, not the SAP database. Source table /SCWM/DOOR_SRACT; slashes aren't legal in unquoted Databricks identifiers, so replication targets conventionally land it as scwm_door_sract — adjust to your landing convention (see quirks #namespace-slashes). RAW16 GUID columns are joined raw; the hex aliases are for display only (#guid-keys). Timestamps flagged UTC are DEC(15) yyyymmddhhmmss values in UTC, not warehouse local time (#utc-timestamps).
-- ============================================================
SELECT
t.MANDT AS "Client",
t.LGNUM AS "EWM warehouse number — doors are unique only within it",
t.DOOR AS "Warehouse door the activity is assigned to",
t.DOOR_SR_ACT_NUM AS "Activity number at that door — one occupancy of the door",
t.ACT_ID AS "GUID of the shipping-and-receiving activity — the same identifier the transportation unit's activity row carries, which is how a door occupancy is tied to the trailer standing at it",
lower(hex(t.ACT_ID)) AS "GUID of the shipping-and-receiving activity — the same identifier the transportation unit's activity row carries, which is how a door occupancy is tied to the trailer standing at it (hex)", -- display rendering of the RAW16 GUID — join on the raw column; see quirks guide #guid-keys
t.ACT_TYPE AS "Activity type",
t.ACT_CAT AS "Activity category",
t.ACT_DIR AS "Direction of the activity — inbound against outbound",
t.START_PLAN_TSTFR AS "Earliest planned start of the door occupancy", -- UTC
t.START_PLAN_TSTTO AS "Latest planned start of the door occupancy", -- UTC
t.START_ACTUAL AS "Actual start of the door occupancy", -- UTC
t.START_TZONE AS "Time zone the start times are read in locally — the stored values are UTC",
t.END_PLAN_TSTFR AS "Earliest planned end of the door occupancy", -- UTC
t.END_PLAN_TSTTO AS "Latest planned end of the door occupancy — the pair of planned windows is what a door-scheduling conflict is measured against", -- UTC
t.END_ACTUAL AS "Actual end of the door occupancy", -- UTC
t.END_TZONE AS "Time zone the end times are read in locally"
FROM <catalog>.<schema>.scwm_door_sract t
WHERE
t.MANDT = '<client>' -- client filter — drop on single-client systems
-- AND t.LGNUM = '<LGNUM>'
-- AND t.DOOR = '<DOOR>'
-- AND t.START_ACTUAL >= <TS_FROM> -- UTC yyyymmddhhmmss — convert warehouse-local dates first (#utc-timestamps)
-- AND t.START_ACTUAL <= <TS_TO>
ORDER BY t.LGNUM;Verified August 2026
Landing conventions differ — see namespaced names in a lakehouse.
Relationships
Diagram of 1-hop neighbors — join details below. GUID joins and text-table joins are highlighted; they’re the joins newcomers most often get wrong.
Join details
ON scwm_door_sract.MANDT = scwm_tdoor.MANDT AND scwm_door_sract.DOOR = scwm_tdoor.DOOR AND scwm_door_sract.LGNUM = scwm_tdoor.LGNUMON scwm_door_sract.MANDT = scwm_tu_sr_act.MANDT AND scwm_door_sract.ACT_ID = scwm_tu_sr_act.ACT_ID -- RAW16 GUID equality — join raw; hex is for display/conformance only · both pages type this column on the same shipping-and-receiving activity identifier, which is what ties a door occupancy to the trailer standing at it; one activity can occupy more than one door over a visit, so this is not a 1:1both pages type this column on the same shipping-and-receiving activity identifier, which is what ties a door occupancy to the trailer standing at it; one activity can occupy more than one door over a visit, so this is not a 1:1
Transaction codes that touch this table
Curated: the EWM transactions an analyst would trace back to these rows, and how each one touches them.
R read · W write · R/W read + write
More Yard & Material Flow tables
- /SCWM/TMFSCPCommunication points — the identification points, scanners, and segments of the conveyor network a controller reports against, each mapped to a storage bin, with its capacity and the clarification point faults are routed to
- /SCWM/TMFSPLCProgrammable logic controllers — the material flow system's definition of each controller EWM exchanges telegrams with, including the warehouse process types used for conveyor putaway, fault handling, and stock transfer
- /SCWM/TU_DLVTransportation unit assignments — one row per delivery or handling unit loaded onto (or unloaded from) a transportation unit for one shipping-and-receiving activity
- /SCWM/TU_SR_ACTTransportation unit activities — one row per shipping-and-receiving activity of a transportation unit, carrying the planned and actual start and end times, the activity type, category and direction, the carrier of the day, and the weighed weight
- /SCWM/TU_STATUSTransportation unit activity statuses — one row per activity per status type, with its value, the posting time, and a reason code
- /SCWM/TUNITTransportation units — the trailers, containers, and swap bodies goods are loaded into, with the internal and external number, the means of transport, the carrier, and the license plate