MM02 — Change Material Master Data
MM02 changes existing material master records: base unit, purchasing data, plant data, valuation, sales views, and more. It is also the transaction used to extend a material to a new plant, storage location, or sales organization, because the org level entered on the initial screen determines which views and which existing or new records open.
MM02 is the standard transaction for maintaining an existing material master record across its organizational views. This page covers the view-selection logic that trips up most beginners, which tables the save actually writes, and the recurring diagnostic categories behind locked, greyed-out, or missing fields.
Reviewed by an ERPClimb SAP consultant on 15 Sept 2026· 1,276 words
Purpose
MM02 opens an existing material master record for change. The material master is not one flat record but a set of views spread across organizational levels: general data at client level, plant data per plant, valuation per valuation area, sales data per sales organization and distribution channel, storage data per storage location, warehouse data per warehouse number. The one fact that explains most confusion: a view only opens if the material has already been extended to that organizational level, or if the user explicitly requests extension by entering that level on the initial screen and confirming the extension dialog. Selecting a view without the right org level either shows nothing or silently creates a new record at that level, which is a different action than 'changing' and carries its own authorization and reference-material logic.
When it is used
MM02 is reached whenever an existing material needs a data correction that is not itself a transactional posting: unit of measure conversion, purchasing group reassignment, price control change, tax classification, deletion flag or block, MRP parameters, or extending a material into a new plant or sales area ahead of a rollout. It sits upstream of purchasing and sales document creation, since PO and sales order default values are pulled from this master data at document creation time, not re-read afterward. Fiori apps cover a subset of these changes for simpler day-to-day maintenance, but MM02 remains the tool of choice when several views need to change together, when extension to a new org level is required, or when the change needs to be scripted through batch input or LSMW for a mass update.
How to use it in practice
- Enter the material number on the initial screen.
- Enter the organizational levels relevant to the change: plant, storage location, sales organization and distribution channel, warehouse number. Leaving these blank suppresses the corresponding views.
- Select the views to maintain from the view selection popup; if a requested view does not exist yet at that org level, confirm the extension when prompted.
- If multiple org levels are entered and the material already exists at more than one, an 'organizational levels' dialog appears to pick which combination to maintain in this session.
- Change the required fields on each view tab, moving through with Enter or the tab strip.
- Save. Watch the status bar for warnings about incomplete mandatory fields per view before assuming the save went through cleanly.
Key data objects
- MARA - client-level general data: base unit of measure, material group, material type, industry sector, gross and net weight.
- MARC - plant-level data: MRP type, purchasing group, lot size, procurement type, deletion flag at plant level.
- MBEW - valuation data: price control, moving average or standard price, valuation class, price unit.
- MVKE - sales organization data: delivering plant, sales unit, item category group, sales status.
- MARD - storage location data: unrestricted, blocked and other stock category quantities per storage location.
- MLGN and MLGT - warehouse number and storage type data for warehouse-managed materials.
- MEAN - external and internal EAN or UPC assignments.
- MARM - alternative units of measure and conversion factors.
- CDHDR and CDPOS - change document header and item, recording who changed which field and its old and new value.
How to prove it in the data
To confirm what actually changed and when, query CDHDR filtered on object class MATERIAL and the material number, joined to CDPOS on the change document number, filtered on the table name and field name in question, for example MARC and field DISMM for MRP type or MBEW and field VPRSV for price control. This gives the exact old value, new value, user, and timestamp, which settles disputes about whether a change was made through MM02 versus through a background job or interface. Cross-check the current live value in MARC or MBEW directly by material and plant to see if it matches the last change document entry.
ECC vs S/4HANA
MM02 continues to exist unchanged in S/4HANA and remains the transaction used for complex or multi-view changes. A Fiori app for material master maintenance is available and covers common single-view changes with a cleaner interface, but it does not replace MM02 for extension to new organizational levels or for mass changes driven by batch tools. Underlying tables and the view-per-org-level structure are the same as in ECC.
Common pitfalls and how to diagnose them
- View not offered in the selection popup: the material type or industry sector configuration does not assign that view, or the user profile parameter for default views is filtering it out, or the org level needed for that view (plant, sales area, warehouse) was not entered on the initial screen. Re-enter the initial screen with the correct org levels before assuming the view is unavailable.
- Field greyed out on an open view: a status set at a higher org level (plant deletion flag, valuation block) can lock fields underneath it; a field selection group in configuration can mark the field display-only for this material type or transaction; an active standard cost estimate can block manual price changes on MBEW. Check the material status fields on MARA and MARC first, then check field selection configuration.
- Material is locked: another user has the record open in change mode, or a background job such as a costing run, MRP run, or batch input session is holding the enqueue lock. Use the lock entry check before killing sessions; the lock usually clears itself once the other process finishes.
- Extension to a new plant or sales area fails or produces unexpected defaults: the reference plant or reference material used to copy defaults does not match what was intended, or the view combination requested is not valid for the material type. Confirm the reference material and reference org level entered in the extension dialog before re-running.
- Change saved but not reflected in open documents: purchase orders, sales orders, and existing MRP elements created before the change keep the old values because master data changes are not retroactive to document line items. This is expected behavior, not a bug; existing documents need manual repricing or MRP re-run.
- Authorization failure on save: object checks for plant (M_MATE_WRK) or sales organization (M_MATE_VKO) can silently prevent a view from opening even when the material has data there. The symptom looks identical to 'view not extended'; the fix is an authorization trace, not another extension attempt.
Whose problem this is
Functional MM or inventory management consultant owns this transaction for day-to-day maintenance and view configuration questions. Basis is involved for enqueue lock cleanup and authorization object assignment. A good handover includes the material number, the org levels involved, the exact field and view affected, the error or missing-view symptom, and whether the change was attempted directly in MM02 or through a batch tool.
Related SAP objects
Reviewed pages this object connects to in the ERPClimb knowledge graph.
Source: ERPClimb — https://erpclimb.com/sap-tcodes/mm02ERPClimb is an independent platform and is not affiliated with SAP SE. Reference pages are written and reviewed by SAP consultants for learning and troubleshooting.