MARC table — Plant Data for Material

One row in MARC represents the attributes of a single material at a single plant. Where MARA holds the material's global, client-independent attributes (base unit, material type, industry sector), MARC holds everything that can legitimately differ from plant to plant: how the material is planned, who plans it, how it is procured, how long it takes to arrive, what lot size rules apply, and whether it is currently blocked for use at that plant. A material only exists usefully at a plant once its MARC record has been created, which is why 'extending a material to a plant' in practice means creating this row. Production, MRP, and purchasing all read MARC before they read MARA for anything operational.

Always filter by client via MANDT in a raw SQL trace, though in ABAP the open SQL layer handles this automatically. The real key discipline is MATNR plus WERKS: never select from MARC by material number alone in a multi-plant landscape, the same material can have wildly different DISMM, BESKZ, or MMSTA values at different plants and pulling one row at random gives a wrong answer that looks plausible. If the investigation is plant-scoped, lead with WERKS to cut the result set before adding MATNR. MARC is far smaller than MSEG or EKBE, but in a landscape with hundreds of plants and hundreds of thousands of materials it is still large enough that an unrestricted select is a bad idea in production.

Symptom: MRP is not generating planned orders for a material at a specific plant even though stock is below the reorder point. Select MARC for that MATNR and WERKS and check three fields together: DISMM must not be blank or set to a type that excludes the planning run, LVORM must not be set, and MMSTA must not carry a status that blocks planning. If DISMM is populated correctly but the material still does not plan, the problem is elsewhere, typically in the MRP run parameters or in a status set higher up on MARA.

MARC remains the underlying persistence table for plant-level material data in S/4HANA. There is no compatibility view replacing MARC itself in the way some financial tables were replaced, because it continues to be populated directly by material master maintenance transactions. Consumption in Fiori apps and CDS-based reporting typically goes through composite material views that pull MARC alongside MARA, MARD, and MBEW, but the table's structure and key have not materially changed for standard use.

Material master governance, usually sitting inside the MM team, owns the plant extension process and the core planning fields like DISMM and DISPO. Purchasing group and delivery time fields are often maintained or requested by the procurement team, and MRP controller assignment by demand or production planning. A discrepancy at one plant is rarely a technical defect, it is almost always a master data maintenance gap and should be routed to whichever functional team owns that specific field before anyone touches configuration.

MARA holds the global material attributes MARC extends per plant. MARD holds storage location stock one level below MARC. MBEW holds valuation data keyed via the plant's valuation area. T001W is the plant master MARC references through WERKS. The plant view of the material master is created and changed through the standard material maintenance transactions, and mass plant extensions typically run through a dedicated mass maintenance transaction rather than one material at a time.