/SCWM/TU_SR_ACT
transactionMixed keyTransportation 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
The activity is the grain, not the transportation unit — one trailer visiting twice in a week is two rows, and a per-TU count is not a count of visits
The dwell-time table of the yard: planned-against-actual arrival and departure are both here, in UTC, with the time zone beside them for localizing a shift boundary. The DDIC page carries 59 columns; this catalog curates the arrival, departure, carrier, and weight columns that carry analytical meaning and leaves the freight-document, dimension, and change-control columns out. Statuses are not on this row — they are a separate long, narrow table keyed by the same activity.
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
19 fields · 3 key
19 fields.
| # | Field | Description | Type | Flags |
|---|---|---|---|---|
| 1 | MANDT | Client | CLNT(3) | Key |
| 2 | TU_NUM | Internal transportation unit number the activity belongs to | CHAR(18) | Key |
| 3 | TU_SR_ACT_NUM | Shipping-and-receiving activity number — one visit of this transportation unit | NUMC(10) | Key |
| 4 | ACT_ID | GUID of the shipping-and-receiving activity — the same identifier the vehicle and door activity tables carry | RAW(16) | |
| 5 | ACT_TYPE | Activity type — what is being done during the visit | CHAR(1) | |
| 6 | ACT_CAT | Activity category | CHAR(1) | |
| 7 | ACT_DIR | Direction of the activity — inbound against outbound | CHAR(1) | |
| 8 | START_PLAN_TSTFR | Earliest planned start of the activity — the open end of the arrival window | DEC(15) | |
| 9 | START_PLAN_TSTTO | Latest planned start — the close of the arrival window; against the actual start this is the arrival-punctuality measure | DEC(15) | |
| 10 | START_ACTUAL | Actual start of the activity | DEC(15) | UTCFilter date |
| 11 | START_TZONE | Time zone the start times are read in locally — the stored values are UTC | CHAR(6) | |
| 12 | END_PLAN_TSTFR | Earliest planned end of the activity — the open end of the departure window | DEC(15) | |
| 13 | END_PLAN_TSTTO | Latest planned end of the activity — the close of the departure window | DEC(15) | |
| 14 | END_ACTUAL | Actual end of the activity — with the actual start, the dwell time of the visit | DEC(15) | |
| 15 | END_TZONE | Time zone the end times are read in locally | CHAR(6) | |
| 16 | TSP_CURR | Carrier actually serving this visit, which can differ from the one on the transportation unit master | CHAR(10) | |
| 17 | TU_WEIGHT | Weighed total weight of the transportation unit for this visit | QUAN(15,3) | |
| 18 | TU_WEIGHT_UOM | Unit the weighed weight is expressed in | UNIT(3) | |
| 19 | YARD | Warehouse number of the yard the activity takes place in, where the yard is modeled as its own warehouse | CHAR(4) |
Field provenance: hand-curated. 3 key fields.
Boilerplate SQL
Starting point for reading the replicated copy of /SCWM/TU_SR_ACTon 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.
5 parameters not filled: <catalog>, <schema>, <client>, <TS_FROM>, <TS_TO>
-- ============================================================
-- Table : /SCWM/TU_SR_ACT — Transportation 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
-- Purpose: Column-selected read of /SCWM/TU_SR_ACT — auto-generated from field metadata
-- Grain : One row per client + TU_NUM + TU_SR_ACT_NUM
-- Caution: The activity is the grain, not the transportation unit — one trailer visiting twice in a week is two rows, and a per-TU count is not a count of visits
-- Notes : Auto-generated skeleton for SAP EWM data replicated into your lakehouse — it reads the replicated copy, not the SAP database. Source table /SCWM/TU_SR_ACT; slashes aren't legal in unquoted Databricks identifiers, so replication targets conventionally land it as scwm_tu_sr_act — 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.TU_NUM AS "Internal transportation unit number the activity belongs to",
t.TU_SR_ACT_NUM AS "Shipping-and-receiving activity number — one visit of this transportation unit",
t.ACT_ID AS "GUID of the shipping-and-receiving activity — the same identifier the vehicle and door activity tables carry",
lower(hex(t.ACT_ID)) AS "GUID of the shipping-and-receiving activity — the same identifier the vehicle and door activity tables carry (hex)", -- display rendering of the RAW16 GUID — join on the raw column; see quirks guide #guid-keys
t.ACT_TYPE AS "Activity type — what is being done during the visit",
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 activity — the open end of the arrival window", -- UTC
t.START_PLAN_TSTTO AS "Latest planned start — the close of the arrival window; against the actual start this is the arrival-punctuality measure", -- UTC
t.START_ACTUAL AS "Actual start of the activity", -- 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 activity — the open end of the departure window", -- UTC
t.END_PLAN_TSTTO AS "Latest planned end of the activity — the close of the departure window", -- UTC
t.END_ACTUAL AS "Actual end of the activity — with the actual start, the dwell time of the visit", -- UTC
t.END_TZONE AS "Time zone the end times are read in locally",
t.TSP_CURR AS "Carrier actually serving this visit, which can differ from the one on the transportation unit master",
t.TU_WEIGHT AS "Weighed total weight of the transportation unit for this visit",
t.TU_WEIGHT_UOM AS "Unit the weighed weight is expressed in",
t.YARD AS "Warehouse number of the yard the activity takes place in, where the yard is modeled as its own warehouse"
FROM <catalog>.<schema>.scwm_tu_sr_act t
WHERE
t.MANDT = '<client>' -- client filter — drop on single-client systems
-- AND t.START_ACTUAL >= <TS_FROM> -- UTC yyyymmddhhmmss — convert warehouse-local dates first (#utc-timestamps)
-- AND t.START_ACTUAL <= <TS_TO>
ORDER BY t.TU_NUM;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_tu_sr_act.MANDT = scwm_tunit.MANDT AND scwm_tu_sr_act.TU_NUM = scwm_tunit.TU_NUM -- many visits per transportation unit — a per-TU count is not a count of visitsmany visits per transportation unit — a per-TU count is not a count of visits
ON scwm_tu_status.MANDT = scwm_tu_sr_act.MANDT AND scwm_tu_status.TU_NUM = scwm_tu_sr_act.TU_NUM AND scwm_tu_status.TU_SR_ACT_NUM = scwm_tu_sr_act.TU_SR_ACT_NUM -- a status sidecar, not a header/item pair — one row per status type per activity, so filter STATUS_TYPE before joining or the activity fans outa status sidecar, not a header/item pair — one row per status type per activity, so filter STATUS_TYPE before joining or the activity fans out
ON scwm_tu_dlv.MANDT = scwm_tu_sr_act.MANDT AND scwm_tu_dlv.TU_NUM = scwm_tu_sr_act.TU_NUM AND scwm_tu_dlv.TU_SR_ACT_NUM = scwm_tu_sr_act.TU_SR_ACT_NUM -- the exact-grain parent: an assignment belongs to one visit of the transportation unit, not to the unit itself — the TU master is one hop further onthe exact-grain parent: an assignment belongs to one visit of the transportation unit, not to the unit itself — the TU master is one hop further on
ON 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/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
- /SCWM/VEH_SR_ACTVehicle activities — the same shipping-and-receiving activity shape for a vehicle: planned and actual times, activity type and direction, the driver, the carrier, and the weighed weight
- /SCWM/VEHICLEVehicles — the tractors and trucks that move transportation units through the yard, with the means of transport, carrier, license plate, and the flag that marks a permanently coupled transportation unit
- /SCWM/DOOR_SRACTDoor activities — the shipping-and-receiving activities assigned to a warehouse door, with the planned and actual occupancy window
- /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