SAP Master data

• Material master (table MARA and others), everything about a product.
• Customer / vendor master, now unified as Business Partner in S/4HANA.
• GL accounts, cost centers, profit centers, the finance/controlling reference data.
• Bill of materials, routings, in manufacturing.

Master data is created once and reused across many transactions; transaction data records individual business events that reference it. A purchase order (transaction) references a material and a vendor (master). This reuse is why master-data quality is so critical, one bad material record poisons every order that uses it.

A single material master, for example, is maintained in views by area, basic data, purchasing, sales, accounting, each owned by a different function. This mirrors SAP’s integration: one object, many departments contributing data.

Each object has its own create, change and display transactions, and the pattern is worth learning once. A material is MM01, MM02 and MM03. A general ledger account is FS00. Customers and vendors are both maintained through BP in S/4HANA, where they used to have separate transactions.

The tables show the structure directly. Material general data is MARA, one row per material for the whole company. Plant data is MARC, one row per material and plant. Sales data is MVKE, one row per material and sales area. Customers repeat the idea: KNA1 is general, KNB1 is per company code, KNVV is per sales area. Vendors use LFA1 and LFB1.

That repetition is the whole design. General attributes live once. Anything that can legitimately differ by plant, company code or sales area lives at that level, because a material really can have a different valuation in two plants and a customer really can have different payment terms in two company codes.

Fifteen minutes, and it makes the organisational structure concrete in a way reading about it does not.

1. Open a material with MM03. On the view selection screen, note how many views are offered and that the system asks for a plant before it shows you purchasing or MRP data.
2. Choose the Basic Data view and note a field such as base unit of measure. That is general.
3. Go back in, choose a Plant view, and change the plant. The purchasing group or MRP type can be different for the same material.
4. Now read SE16N on MARA for that material number. One row. Read MARC for the same number. One row per plant it is extended to.
5. Try to sell the material in a sales area it has no MVKE row for. It fails, and the message is about the sales area rather than the material.

Step five is the one worth remembering. Most "the material is not working" tickets are a missing view, and the error text rarely says so plainly. See SAP MM for how the purchasing views are maintained and SAP SD for the sales side.

• Who owns which view. Purchasing owns the purchasing view, finance owns accounting, sales owns sales. Deciding this early prevents the common failure where a material is created by one team, unusable by another, and nobody is accountable.
• Internal or external number ranges. Letting the system assign numbers is clean. Carrying numbers over from a legacy system keeps people able to find things. Most projects do both, by material type.
• Central creation or local. A central team gives consistency and a queue. Local creation gives speed and drift. Which one you choose shows up in data quality within a year.
• How much to govern. A workflow-driven tool such as SAP MDG is worth it when records are created constantly and mistakes are expensive, and is overhead when they are not.

Because master data is shared and long-lived, organisations govern it carefully (often with SAP MDG). Clean, well-governed master data is one of the highest-leverage investments in any SAP programme.

Most people meet master data properly for the first time during a migration, and it is where the consequences of a bad design become visible all at once.

The work splits into three. Extraction pulls records out of the legacy system, and immediately raises the question of what to bring: every material ever created, or only those transacted in the last two years. Bringing everything is easier to justify and guarantees you carry old mistakes forward.

Cleansing is where duplicates are merged, obsolete records dropped and missing fields filled. This is unglamorous and it is the part that determines whether reporting works after go-live. It also needs the business, because only they know which of two similar materials is the one still bought.

Loading happens in dependency order, and the order is not negotiable. Company codes and plants before anything that references them. General material data before plant data, because a MARC row cannot exist without its MARA row. Customers before sales orders. Getting this wrong produces a load that fails halfway with thousands of records committed.

Validate by counting and by sampling. Counts prove nothing was silently dropped. Sampling proves the values landed in the right fields, which counts cannot show. Then run a real transaction end to end on migrated data before anyone declares the load successful.

A practical point that saves a lot of ticket ping-pong. Master data problems arrive described as transaction problems: an order will not save, a posting went to the wrong account, a material cannot be sold. The fix is almost never in the transaction.

Work backwards. Read the error, identify which object it is complaining about, then open that object and check whether the level it needs exists. A missing sales view, an unextended plant, a customer without an account assignment group. Then find who owns that view, because they make the change, not you.

The habit worth building is checking master data before configuration. Configuration errors affect everyone doing that thing. Master data errors affect one material, one customer, one plant, and that is usually the shape of the complaint.

• Treating master data casually, errors propagate everywhere.
• Incomplete views, a material without an accounting view cannot be posted.
• No governance, duplicates and inconsistencies accumulate.

• Extending a material to a plant but not to the sales area, then wondering why it can be bought and not sold.
• Assuming a duplicate is harmless. Two records for one real thing splits stock, splits spend reporting, and is far harder to merge later than to prevent now.
• Loading legacy data without cleaning it. A migration is the one cheap chance to delete what should not come across.

The largest change is that customers and vendors became Business Partners. One partner carries a customer role and a supplier role, so a company that is both is one record rather than two, and customer vendor integration keeps the underlying tables in step. New builds maintain everything through BP. Material master data kept its structure, while material documents moved into MATDOC. See SAP modules for how the rest of the suite moved with it.

Reading master data is straightforward, and designing the views, ownership and number ranges for a real client is the part you do in the course.

The habit to take away is smaller than the topic sounds: before blaming a transaction, open the master record it is complaining about and check which level is missing.