SAP Mass Maintenance: MM17, MASS, XD99 and XK99

SAP mass maintenance is the family of standard transactions for changing one or more fields on many existing records at once: MM17 for material master, XD99 and XK99 for customer and vendor master, MEMASSPO for purchase orders, and the generic MASS transaction behind all of them. They exist because the alternative, opening MM02 three thousand times, is not an option, and they are the right first answer to "we need to change the MRP controller on every material in plant 1200".

This guide explains how each one works, what it can and cannot change, the mistakes that turn a mass maintenance into a mass correction, and what to reach for when the change is outside what the standard transaction covers. It is written for the functional consultant or master data lead who has the change in a spreadsheet already and needs to know whether MM17 will do it.

How SAP mass maintenance works

Every mass maintenance transaction is the same three screens with a different object behind them.

Screen 1, the object and the tables. You choose the business object (material, customer, purchase order) and the tables within it whose fields you want to change: for a material, MARA general data, MARC plant data, MARD storage location data, MBEW valuation, MVKE sales data and so on. The tables you choose decide the organisational level of the change: a field in MARC is changed per plant, a field in MARA is changed for the material everywhere.

Screen 2, the selection. You select the records to change, by key (a list of material numbers pasted from Excel) or by selection criteria (all materials of type ROH in plant 1200 with MRP type PD). The selection is the step that decides whether the run is right, and it is the step done fastest.

Screen 3, the change. The selected records are shown in a table, one row per record and organisational level, with the fields you chose as columns. You enter the new value once and apply it to all rows, or edit individual cells, then save. SAP runs the update for each record through the object's update logic, writes change documents where the object supports them, and shows a log of what succeeded and what did not.

MASS is the generic transaction. MM17, XD99, XK99 and the MEMASS* transactions are MASS started with the object already chosen.

The mass maintenance transactions

The object list in MASS varies by release. The reliable way to know what can be mass changed in your system is to open MASS, press F4 on the object type, and look.

MM17 step by step

MM17 is the one worth knowing in detail, because material master carries the most mass changes in most companies and because every other mass transaction works the same way.

1. 1

   Step 1. Choose the tables

   On the first screen, tick the tables whose fields you will change. For an MRP controller change that is MARC. For a material group change it is MARA. Tick only what you need; each table adds a row per organisational level to the change screen and slows the run.

2. 2

   Step 2. Select the records

   Enter the material numbers, pasted from the spreadsheet through the multiple selection button, and the plant if a plant level table was chosen. Or use the selection fields to pick by attribute: material type, MRP type, material group. A selection by attribute is quick and is also how the wrong 400 materials get changed, so for anything that matters, select by key from a list that someone has reviewed.

3. 3

   Step 3. Enter the new values

   The change screen lists the selected records with the fields you chose. Enter the new value in the header row and use "carry out a mass change" to apply it to every selected row, or type values into individual cells where records need different values. The second approach works, but for more than a few dozen records with different values it is slower and more error prone than the alternative in the section on where mass maintenance stops.

4. 4

   Step 4. Save, and read the log

   Save. SAP updates each material through the material master update logic, so the same checks MM02 would apply are applied, and a record that fails a check is reported in the log and not changed. Read the log to the end; a run that changed 2,960 of 3,000 materials has 40 records to deal with, and the log is the only place they are listed.

5. 5

   Step 5. Verify with a fresh extract

   Do not trust the log alone. Pull the changed field for the selected materials into Excel (the material master report does this in one run) and compare to the intended values. This is where a wrong organisational level or a selection that was wider than intended shows up.

6. 6

   Step 6. Keep the before values

   MM17 writes change documents, so the old value is recoverable per material through the change document display, one at a time. For a mass change that may need reversing, the practical record is a spreadsheet with material, old value and new value, extracted before the run. The mass change procedure starts from exactly that extract, for this reason.

A worked example: the MRP controller change

Plant 1200 reorganises its planning team, and 3,000 materials move from MRP controller 001 to 007. This is the case MM17 was built for: one field, one value, one plant, existing records.

In MM17: tick MARC, paste the 3,000 material numbers from the planning team's list into the material selection, enter plant 1200, execute. On the change screen, enter 007 in the MRP controller header cell, carry out the mass change, save. The log shows 2,988 changed and 12 errors: 9 materials do not exist in plant 1200 (the list was built from another plant's report), 3 are flagged for deletion. Twenty minutes, including reading the log, plus the extract before and the verification report after.

Now change the example slightly. The same reorganisation, but the new MRP controller depends on the material group: 007 for raw materials, 008 for packaging, 009 for the rest. In MM17 that is three runs with three selections, or one run with 3,000 cells edited by hand. The planning team's list already has the material and the new controller side by side, so the load should read it: a sheet with material, plant and MRP controller per row, mapped to PLANTDATA-DISPO with PLANTDATAX-DISPO set, validated row by row (the 9 missing plant extensions and 3 deletion flags come back as messages before anything changes), and posted through BAPI_MATERIAL_SAVEDATA with the result beside each row. Same twenty minutes, one run, and a sheet with old value, new value and result for the change record.

The dividing line is not the volume. It is whether the value is the same for every row.

Where mass maintenance stops

The standard transactions do one thing well: set a field to a value across a selection. Six situations fall outside that, and they are the situations most mass changes turn into once someone looks at the spreadsheet.

What to use past that point

Three routes, and the right one depends on which of the six situations above you hit.

Stay in the standard transaction and split the work. If the only problem is that the change touches two objects, run two mass transactions. If it is a small number of per row values, edit the cells. Mass maintenance is fast when it fits.

A BAPI based load from Excel. For creates, for fields outside the mass object, for a value per row, and for validation before anything changes, the load reads the spreadsheet and posts each row through the object's BAPI: BAPI_MATERIAL_SAVEDATA for materials, BAPI_COSTCENTER_CHANGEMULTIPLE for cost centers, BAPI_PO_CHANGE for purchase orders. The BAPI applies the full business logic, the value per row comes from the sheet, and the result comes back per row.

That is what PostNow.ai does, from inside Excel. The extract of current values is the starting sheet, the new values are typed or formula driven beside them, every row is validated against the live SAP system before posting is available, and the change posts through the BAPI under the user's own login with the SAP result written back beside each row. The sheet with old value, new value and result is the run log the standard transactions do not produce. The MM17 style material mass maintenance template, the MM02 change template and the cost center change template are free and name the BAPI field for every column.

LSMW or a recording. On ECC, an LSMW object on the MM02 recording was the traditional route for changes outside MM17. In S/4HANA it still works where the screens did not change and does not where they did; the LSMW guide has the list.

Mass maintenance in S/4HANA

MM17 and MASS are present in S/4HANA on-premise and work as in ECC. Two changes matter.

Customer and vendor master data are Business Partner data. General data (name, address, search terms) is maintained on the Business Partner, and the mass maintenance route for it is not XD99 and XK99 as they were in ECC. Check the object list in MASS on your release, and plan on the BAPI route for anything on the Business Partner itself.

Fiori has mass maintenance apps for some objects, the product master among them, alongside the GUI transactions. They are built on the same principle, a selection and a value, and the same limits apply.

Mistakes that turn a mass change into a mass correction

1. Selecting by attribute for a change that matters. "All materials in plant 1200 with MRP type PD" sounds precise and includes the 40 you did not mean. Select by key from a reviewed list.
2. The wrong organisational level. Changing a MARC field with the plant left blank changes it in every plant the material exists in.
3. Not reading the log to the end. Partial success is normal. The log is the only list of what did not change.
4. No before extract. Change documents exist, per record. A run level record of old values does not, unless you made one.
5. Running in production first. Mass transactions have no test system built in. The quality system is the test.
6. Using mass maintenance for a create. It will not create, and the time spent discovering that is time the load could have run.

Frequently asked questions