T001W table — Plant Master Table T001W
T001W stores one record per plant: its name, address pointer, the valuation area it belongs to, the default purchasing organization, and, for intercompany scenarios, the customer and vendor numbers used to represent that plant as a business partner. It is the anchor table for plant-level logistics configuration across MM, PP, and SD.
T001W is the plant master table underlying every plant-dependent material, stock, and valuation record in MM. This page covers its key fields, the joins consultants actually write against MARC, MARD, MBEW and EKPO, and the recurring misreadings of the intercompany and purchasing organization fields that lead to wrong conclusions during incidents.
Published 15 Sept 2026· 973 words
What it stores
One row represents a single plant as a logistics and organizational unit. The row carries the plant's descriptive name, the valuation area it is assigned to (almost always itself, but not guaranteed), the purchasing organization proposed for that plant, and optional customer and vendor numbers that let the plant act as a business partner in intercompany stock transfer and billing. It also carries an address reference and a factory calendar key used for scheduling. It does not carry stock quantities, storage location detail, or material-specific plant data - those live one level down or in separate objects. T001W is configuration-grade master data, maintained through plant customizing, not transaction-level data entered by end users.
Key fields
- MANDT - client
- WERKS - plant key, the primary identifier joined against throughout MM, PP and SD
- NAME1 - plant descriptive name
- BWKEY - valuation area assigned to the plant, used to join to valuation tables
- EKORG - default purchasing organization proposed for the plant
- KUNNR - customer number representing the plant, populated only for intercompany or cross-company stock transfer setups
- LIFNR - vendor number representing the plant, same intercompany use case as KUNNR
- ADRNR - address number pointing into the central address management tables
- LAND1 - country key of the plant
- FABKL - factory calendar key used for plant-level scheduling
How it joins the data model
- T001W-WERKS = MARC-WERKS, plant segment of the material master
- T001W-WERKS = MARD-WERKS, storage location stock at the plant
- T001W-BWKEY = MBEW-BWKEY, material valuation records for the plant's valuation area
- T001W-WERKS = EKPO-WERKS, receiving plant on a purchase order item
- T001W-WERKS = T001L-WERKS, storage locations defined under the plant
How to read it safely
T001W is small, typically a few hundred rows in a large landscape, so full scans are cheap and selectivity rules that matter for transaction tables do not apply here. Always restrict by MANDT even though most reads go through a client-dependent view automatically. The real trap is not performance but interpretation: WERKS is the only field guaranteed to be populated and meaningful for every row. KUNNR, LIFNR, and FABKL are optional and blank on most plants, so a query that filters on them will silently exclude the majority of the plant list rather than returning an error.
How to prove it in the data
Symptom: an intercompany stock transport order fails with the receiving plant not recognized as a customer. Select T001W where WERKS equals the receiving plant and check KUNNR. If KUNNR is blank, the plant has never been set up as a business partner for intercompany billing and the transport order configuration cannot resolve a sold-to party, independent of anything wrong in the order itself. The same check with LIFNR confirms the supplying side for the matching intercompany purchase order.
ECC vs S/4HANA
T001W survives unchanged as a transparent table in S/4HANA and continues to be maintained through the same plant customizing activities. There is no compatibility view replacing it because plant master data was not restructured in the MM data model simplification, unlike the material document tables. The field set and semantics are the same as in ECC, so joins and interpretation carried over from an ECC-era investigation remain valid.
Common pitfalls
- Assuming BWKEY always equals WERKS. Standard SAP configuration usually sets valuation at plant level, but the field is independent, and in landscapes with valuation grouped above plant level BWKEY points elsewhere. Joining MBEW on WERKS instead of BWKEY produces wrong or empty valuation results.
- Treating a blank KUNNR or LIFNR as a data error. These fields exist only to support intercompany and cross-company stock movement; a purely domestic plant is correctly blank in both and needs no fix.
- Reading EKORG as the only purchasing organization that can buy for the plant. It is the default proposed on new purchase order creation, not a restriction. Purchasing org to plant assignment as a valid combination is governed by configuration elsewhere, and a plant can legitimately receive purchase orders from a purchasing organization different from the one stored here.
- Pulling address details directly from STRAS, ORT01 and related fields when the system has moved plant addresses under central address management. On many systems those fields are empty or stale and the current address lives behind ADRNR in the address tables, so a direct field read gives a false impression of missing or wrong address data.
- Confusing the plant level with the storage location level when investigating a stock discrepancy. T001W has no quantity or bin information; a discrepancy that looks like a plant-level problem is almost always resolved one level down in storage location or batch tables.
Whose problem this is
Plant master configuration is owned by the MM or logistics configuration team, not by a functional key user. Address content is often owned separately by whoever maintains central business partner or address data, since ADRNR points outside the pure MM domain. Intercompany KUNNR and LIFNR assignments are a joint MM and FI-AR/AP setup decision made once during intercompany process design, not something changed reactively during an incident.
Related SAP objects
Reviewed pages this object connects to in the ERPClimb knowledge graph.
Source: ERPClimb — https://erpclimb.com/sap-tables/t001wERPClimb is an independent platform and is not affiliated with SAP SE. Reference pages are written and reviewed by SAP consultants for learning and troubleshooting.