SAP Material master

A single material master record describes a material across the enterprise, but its data is organised into views owned by different areas: basic data, purchasing, sales, MRP, accounting, storage, quality. Each function maintains its view, embodying SAP’s integration, one object, many departments.

• Basic data: description, unit of measure, material type.
• Purchasing: for procurement (MM).
• Sales: for selling (SD).
• MRP: for planning (PP).
• Accounting/Costing: valuation (FI/CO).

One field inside the accounting view deserves separate mention because it reaches further than any other: the valuation class. Account determination reads it to decide which stock and consumption accounts a movement posts to. Two materials with different valuation classes post to different accounts from the same movement type, which is how a business separates raw materials from finished goods in the ledger without anybody choosing an account.

This is the structure that explains almost every material master problem, and it is worth learning as levels rather than as a list of views.

Client level data is true everywhere: the description, the base unit of measure, the material type, the material group. One row in MARA, no matter how many plants exist.

Plant level data can differ by site: the MRP type, the purchasing group, the procurement type, the availability check. One row per plant in MARC, which is why the same material can be bought at one plant and made at another.

Valuation level holds the price and the valuation class, in MBEW. It is usually per plant, and the valuation class is what account determination reads to decide which general ledger account a movement hits.

Sales area level holds what selling needs, in MVKE: the sales organisation, the distribution channel, the delivering plant, the tax classification.

Storage location level is the lowest, in MARD, holding stock figures.

The consequence is the thing to remember: extending a material to a plant does not extend it to a sales area, and a material that can be bought and not sold is missing an MVKE row rather than being broken.

Twenty minutes, and it turns a confusing error message into an obvious one.

1. Create a material with MM01, selecting only Basic Data and the Purchasing view for one plant.
2. Raise a purchase order for it. It works.
3. Try to create a sales order for it. It fails, naming the sales area rather than the material, because there is no sales view.
4. Extend the material with MM01 again, this time choosing Sales views and the sales area. The same material number; you are adding a level, not creating a new record.
5. Create the sales order again. It works.
6. Now try a goods receipt without the Accounting view maintained. It fails on valuation, because there is no valuation class to determine an account from.

Doing this deliberately once means recognising the pattern for good: the error names the process, and the answer is a missing level on the master record.

Almost every logistics and finance process uses the material master. Incomplete views cause failures, a material without an accounting view cannot be valued/posted, without a purchasing view cannot be ordered in a plant. Clean, complete material master data (governed via MDG) is foundational to a working system.

It also decides who has to be involved to create one. Purchasing owns the purchasing view, sales owns the sales view, finance owns accounting, planning owns MRP. A material created by one team is routinely unusable by another, which is why material creation is usually a workflow rather than a transaction, and why master data governance exists as a discipline.

• Material types. They control which views are available, whether the material is valuated, and the number range. Raw material, semi-finished, finished, trading goods and non-valuated each behave differently, and choosing wrongly is corrected by creating a new material rather than by editing.
• Valuation class per material type. This is what sends postings to the right accounts, and it is agreed with finance rather than decided in procurement.
• Internal or external numbering. System-assigned numbers are clean; carrying legacy numbers keeps people able to find things.
• How many units of measure. A base unit plus order and sales units with conversion factors handles buying by pallet and selling by piece, and every extra unit is another place a conversion can be wrong.

The material type is chosen once at creation and it constrains everything afterwards, so it deserves more thought than it usually gets.

ROH, raw material, is bought and consumed in production. It has purchasing views and no sales views, because you do not sell it.

HALB, semi-finished, is produced and consumed internally. It has production views and usually neither purchasing nor sales.

FERT, finished, is produced and sold. Production and sales views, and usually no purchasing.

HAWA, trading goods, is bought and sold without transformation. Purchasing and sales, no production.

DIEN, services, has no stock at all, which is why a service cannot be received into a warehouse.

UNBW and NLAG cover non-valuated and non-stock materials, where quantity is tracked without value or not at all.

Each type carries its permitted views, its number range, its valuation behaviour and its account determination. That is why a material created as the wrong type cannot simply be corrected: the fields you now need may not exist for that type, and the fix is a new material and a decision about the stock sitting on the old one.

Individual maintenance is fine for a handful. Real work is usually bulk, and there are proper tools for it.

MM17 is mass maintenance, changing a field across a selection of materials in one run. It is powerful and unforgiving, so it is done in a test system first with a small selection, and the selection is checked before the change is applied.

Extending rather than changing is the other bulk task: taking existing materials and adding a plant or a sales area. It is a different operation, and doing it by copying a material produces duplicates instead.

Migration tooling handles the initial load and is also the right route for a large one-off change, because it validates before writing.

The safety habit that matters: always export the current values before a mass change. If the run does something unintended, the export is what lets you put it back, and there is no undo.

• Missing views blocking a process in a plant.
• Wrong material type, wrong behaviour/valuation.
• Poor governance, inconsistent/duplicate materials.

• Creating a duplicate because the first one could not be found. Two records for one real item splits stock and spend reporting permanently.
• Changing the base unit of measure after stock exists. It is effectively impossible, and the workaround is a new material.
• Extending views without the owning team. See how to create a material for the mechanics and MM configuration for where material types are defined.

• Mass changes run without exporting first. There is no undo, and the export is the only route back.
• Material type chosen for convenience. It decides which views exist at all, and it cannot be changed later.

Creating a material is straightforward, and designing material types, views and ownership so a real business can maintain them is the part you do in the course.

The habit worth building is checking the view list before anything else. Most "the material is not working" reports are a missing level on the record, and the error message names the process rather than the gap.