MCHA table — Batch Master Data at Plant Level

One row in MCHA represents the plant-level master data for a single batch of a single material in a single plant. It exists because batch numbers are created once at client level in MCH1, but each plant that uses the material can hold its own attributes for that same batch, such as whether the batch is currently usable (restricted or unrestricted) and whether it has been flagged for deletion at that plant. MCHA does not carry any stock quantity. It is pure master data describing the batch's status and administrative history at a given plant, and it must exist before movements against that material/plant/batch combination can post cleanly.

Always restrict on MANDT, MATNR, WERKS and CHARG together; each of these fields individually has poor selectivity on its own, and MATNR alone can return thousands of rows across all plants and batches. WERKS plus MATNR narrows the set to a manageable range before adding CHARG for a single batch. Do not attempt a full table scan in a productive system, MCHA can carry every batch ever created for every batch-managed material. When investigating a specific incident, start from the material and plant named in the error message, not from the batch number alone, since batch numbers are frequently reused or look similar across materials.

Symptom: a goods movement fails with the batch reported as blocked or restricted for use. Select MCHA with MATNR, WERKS and CHARG from the failing document. Check CADKZ: a value indicating restricted use confirms the batch is genuinely blocked at that plant, independent of quantity. Cross-check LVORM to rule out the batch being flagged for deletion rather than restricted, since both produce similar posting failures but require different fixes.

MCHA continues to exist as a database table in S/4HANA and can still be read directly for diagnostic purposes. Batch master maintenance transactions and the underlying data model for plant-level batch attributes are essentially unchanged from ECC. Newer Fiori batch master applications and reporting typically read through compatibility views layered on top of the classic tables rather than querying MCHA directly, but the table itself has not been withdrawn or restructured in a way that changes its key or its role.

Batch master data quality is an MM master data ownership question, usually the same team that owns material master extension to plants. Restricted-use status changes are frequently a QM process outcome, so a batch stuck in restricted use is a QM inspection lot question before it is an MM data question. Deletion flag handling is governed by whoever runs periodic batch cleanup.

MCH1 holds the client-level batch header that MCHA extends per plant. MCHB holds the actual stock quantities per material, plant, storage location and batch, and is the table to check for available quantity. MARC and MARA supply the surrounding material master context. Batch maintenance transactions such as the batch create/change/display group write to MCH1 and MCHA, while goods movement transactions update MCHB and post the accounting and material documents separately.