SAP Mass Material Master Update with MM02

The fields you have to map

A material master change file needs less than people expect. It needs enough to identify the record uniquely, enough to say which segment the change belongs to, and the new value.

Three of those columns deserve more attention.

The material number

Material numbers are stored internally with leading zeros for numeric ranges. A material displayed as 100234 may be 000000000000100234 in the table. A spreadsheet that stores the column as a number destroys the leading zeros silently, and the resulting error says the material does not exist. Store material columns as text, and check a known value before the run rather than after it.

Systems configured with alphanumeric material numbers avoid this problem and introduce a different one: case sensitivity and trailing spaces both matter, and both are invisible on screen.

The plant column

Plant is required for plant-level fields and meaningless for client-level ones. A file that carries plant on every row when the change is client level will still work, but it will apply the same change once per plant row, which inflates the run and the log for no benefit. Split the file by level when the change touches both.

The old value

This column is not required by SAP and is the most important one in the file. Carrying the current value beside the new value gives you three things at once: a validation check, because a row whose old value is unexpected is a row worth pausing on; an audit record showing exactly what changed; and a rollback file, because reversing the run means posting the old column back.

Extract before you change

A mass change is destructive. There is no undo, no reversal document, and no equivalent of FB08. Once the new value is written, the old one exists only where you kept it.

This is why the first stage of a material master mass change is not building the change file. It is extracting the current state. Pull the material, the plant, the view and the current value of every field you intend to touch, for every record in scope, and keep that file untouched.

The extract does four jobs:

• It is the rollback. If the change was wrong, the extract posted back restores the previous state. Without it, restoration means reconstructing values from memory or from a backup nobody wants to restore.
• It validates scope. If the extract returns three thousand nine hundred rows and the request said four thousand materials, the difference is worth understanding before the change rather than after.
• It reveals the unexpected. Materials whose current value is already the target value, materials whose view is missing, materials with values nobody expected. All of this shows up in the extract and all of it is cheaper to handle before the run.
• It is the audit evidence. Before and after, in one file, produced by the person who ran the change.

The eight stages of a controlled MM02 run

The sequence below follows the discipline in the SAP mass upload pillar guide, adjusted for the fact that a change overwrites rather than creates.

Validation: six checks before a single material changes

The checks above are ordered by how early they fail. Existence and extension problems are structural and affect whole groups of rows. Lock problems are transient and affect individual rows at random. Knowing which class a failure belongs to tells you whether to fix the file or simply re-run.

Why the value check matters more than it seems

Most material master fields are checked against configuration tables. A purchasing group has to exist in the purchasing group table. An MRP type has to be defined. A material group has to be in the material group hierarchy. These are exactly the values that get typed into a spreadsheet by someone who knows what they mean but not how they are coded.

The failure mode is subtle: a value that is valid in one system and not another. A file prepared against development configuration will fail in production if the configuration was never transported, and the error will look like a data problem when it is a transport problem.

Rows that are already correct

In almost every real population, some materials already hold the target value. There is no error in changing a field to the value it already has, and there is also no benefit. It writes a change document, adds a row to the log, and makes the audit trail harder to read. Filter them out during validation and note the count, because a large number of already-correct rows usually means the scope was drawn too wide.

Errors, and what they are telling you

Locks behave differently from the other three

Three of the four errors above are file problems: fix the data and the row will post. Lock errors are timing problems. A material is locked because someone has it open in MM02, or because a background job is touching it, and the fix is to wait rather than to change anything.

This matters for how you run large changes. A run started at ten in the morning will hit locks from users working normally. The same run at seven in the evening will not. Where a population is large enough that lock collisions are likely, schedule around the people rather than fighting them, and design the run so failed rows can simply be re-sent.

Running the whole sequence inside Excel

MM01, MM02 and MM17: choosing the right route

MM17 is SAP's own mass maintenance transaction and it deserves a fair hearing. For a simple sweep across a field it exposes, it is free, it is standard, and it works. Teams should try it first.

Its limits appear quickly. The field set it exposes is a subset, the selection screen makes it awkward to drive from an external list of materials, and there is no natural place to keep the before-and-after record. When the field you need is not there, or when the population comes from a spreadsheet rather than a selection, a mapped load through MM02 logic is the route.

MM01 creates. If part of your population needs views extended rather than fields changed, that is an MM01 job and it runs first. Mixing the two in one file is the most common structural mistake in material master work.

What changes when the run replaces the keying

The comparison above understates one thing. The manual route does not just cost more hours; it produces a different quality of evidence. When four thousand materials are changed by hand over three weeks, the record of what changed is the change documents in SAP, read one material at a time. When the same change runs from a file, the record is the file: every material, its old value, its new value, and the result, in one artefact that a reviewer can read in a minute.

Material master in ECC and S/4HANA

The object survives the conversion largely intact, which is one reason material master mass work is a good place to build capability before a migration rather than after it. The differences that matter for a mass change are few but sharp.

The material number field is longer. S/4HANA extends MATNR to forty characters. Systems that have switched on the extended length will accept material numbers a file built against ECC would truncate, and files built against the extended length will fail on an ECC system. Know which you are pointed at.

MARD and MARC still exist. The simplification programme removed several aggregate and index tables, but the segment structure a mass change relies on is unchanged. A mapping built for ECC generally works on S/4HANA without redesign, which is not true of a screen recording built against the old MM02 screens.

Fiori apps sit alongside the transaction. S/4HANA offers app-based material maintenance, and some organisations lock the classic transaction. This does not affect a load that posts through the published interface, because the interface is the same underneath. It does affect a recording, which is another reason recordings are a poor choice for master data at volume.

Business partner does not apply here. The customer and vendor consolidation into Business Partner is the headline master data change in S/4HANA, and it leaves material master alone. If you are planning both, treat them as separate exercises with separate files. The vendor master guide covers what changes on that side.

The fields people actually sweep, and what each one breaks

Some fields are routine to change at volume. Others carry consequences that are not obvious from the field name. This is the practical division.

Usually safe to sweep

• Purchasing group. Reporting and workflow routing. Changing it does not disturb existing documents.
• Material group. Reporting hierarchy. Confirm downstream reports before a large sweep, but the change itself is contained.
• Planned delivery time. Feeds future planning runs. No effect on existing orders.
• Reorder point and safety stock. Planning parameters that take effect on the next run.
• Storage conditions and handling indicators. Warehousing attributes with narrow blast radius.

Change with the business in the room

• MRP type. Switching between reorder point, forecast and MRP planning changes how the material is planned entirely. A sweep across a product family will change what the next planning run proposes, sometimes dramatically.
• Lot size procedure. Interacts with MRP type and can produce order proposals nobody expected.
• Valuation class. Drives account determination. Changing it with stock on hand has accounting consequences that finance must agree in advance.
• Procurement type. Moving a material between in-house production and external procurement changes which documents the system will create.

Frequently not changeable at all

• Base unit of measure. Locked once stock or documents exist. This is the field behind most M3 897 errors.
• Material type. Requires a dedicated conversion path, not a field change.
• Price control. Constrained by stock and period status.

The pattern is consistent: fields that describe the material are easy, fields that drive behaviour need agreement, and fields that anchor accounting or stock are often locked by design. Sorting your sweep into those three buckets before building the file saves a round of failed rows and an awkward conversation.

Governance, approval, and change documents

Material master is master data, which means it is usually governed, which means a mass change touches a control framework that was designed around individual edits.

• Change documents still happen. A change written through standard logic produces the same change documents as a manual edit, visible in MM04 and the standard change display. Mass upload does not create a blind spot.
• Approve the file. The reviewable artefact is the spreadsheet: which materials, which field, from what to what. That is a better review object than four thousand individual approvals.
• Run as a named user. The change should carry the identity and authorisations of the person who ran it. Shared accounts remove the trail that makes the run defensible.
• Keep the before extract. It is both the rollback and the evidence. Store it with the change request.
• Reconcile after. A fresh extract compared to the intended state, confirming that what changed is what was meant to change and nothing else moved.

Where a data governance function exists, involve it in the first run rather than the third. The conversation is short when the evidence is good, and the evidence here is better than the manual process it replaces.

Volume, batching, and lock contention

Material master changes are usually faster than document postings because the work per record is smaller. The constraint is rarely throughput; it is contention.

• Batch by plant or product family. A batch that fails should be describable in one sentence, and plant is usually the natural boundary.
• Run outside working hours for large populations. Not for system load, but to avoid users holding materials open.
• Expect a lock tail. A small percentage of rows will fail on locks. Design for a second pass rather than treating it as an exception.
• Avoid running during planning jobs. MRP runs and other batch jobs hold materials, and a change colliding with them fails in ways that look mysterious.
• Split client-level and plant-level changes. Different granularity, different row counts, different failure modes. One file each is clearer than one file doing both.

From a one-off sweep to a maintained template

Material master changes recur more than any other mass task, because the fields that need sweeping are the fields the business tunes. The same MRP parameter change comes back every time supply strategy shifts.

• Save the mapping with the view logic. Which fields sit at which level is the part that takes the thinking.
• Ship a template to the requesters. If planning submits its changes in a sheet with material, plant, field and new value already in the right shape, most of the preparation disappears.
• Keep the validation rules attached. The check tables that caught you once will catch you again.
• Record what configuration it was proven against. Which plants, which material types, which views.
• Always include the old value column. Make it part of the template so nobody has to remember to add it.

Common mistakes and how to avoid them

• Running without extracting first. A wrong mass change with no before file is genuinely unrecoverable. This is the only mistake on this list that cannot be fixed afterwards.
• Mismatching granularity to the field level. One row per material when the field is plant level leaves most plants unchanged and the inconsistency invisible.
• Assuming the view exists. A change updates a view. It never creates one. Extend first, in a separate run.
• Letting material numbers lose their leading zeros. Store the column as text and verify a known value before the run.
• Preparing against development configuration. Values valid in a sandbox fail in production when the configuration was never transported.
• Changing fields that are already correct. Harmless individually, but it fills the change log with noise and hides the changes that mattered.
• Treating a lock failure as a data error. It is a timing problem. Wait and re-send the failed rows.

The complete MM02 mass update reference

The reference sheet below collects everything above into one image you can share with a team before a sweep.

Go deeper

Frequently asked questions