Lesson 5 of 6
Data model note: one table for material documents
9 min
Business users can skip table names most of the time, but one inventory change in SAP S/4HANA explains a lot of behavior and a lot of conversion work: material documents are now stored in a single table, MATDOC, and stock quantities are calculated from it.
Before and after
| Topic | SAP ECC | SAP S/4HANA |
|---|---|---|
| Material document header | MKPF | MATDOC (header and item data together) |
| Material document items | MSEG | MATDOC |
| Stock quantities | Stored totals in aggregate tables (per plant, storage location, batch, special stock) | Calculated from MATDOC on the fly |
| Reading old tables | Direct | Through compatibility views that return the same structure |
| Goods movement transactions | MIGO plus MB1A, MB1B, MB1C and others | MIGO and Fiori apps; the old MB posting transactions are replaced by MIGO |
In ECC every goods movement wrote a header row, item rows, and then updated stock totals in several aggregate tables. Those updates were a bottleneck for high-volume postings because each total row had to be locked. In SAP S/4HANA a goods movement inserts rows into MATDOC, and stock is derived from the material documents when someone asks for it. SAP positions this as simpler and faster for posting.
What this means for custom reports and programs
Because compatibility views exist, many custom reports that read MKPF, MSEG or stock aggregate tables keep working. Three kinds of custom code need attention:
- Programs that write directly to stock or material document tables. They must be redesigned to use standard posting functions.
- Programs that read large volumes through compatibility views in loops, which can be slow; they may need to read MATDOC or CDS views directly.
- Programs that depend on specific aggregate tables or fields that no longer behave the same way.
During conversion, historical material documents are migrated into MATDOC, so the material document history is still there after go-live. That migration is part of the technical conversion and its runtime is significant for companies with many years of movements. Archiving old material documents before conversion can shorten it.
- Before conversionCustom code checkFind code reading or writing MKPF, MSEG and stock aggregate tables
- Before conversionArchivingArchive old material documents to reduce migration volume
- ConversionData migrationMKPF/MSEG history moved into MATDOC
- After conversionReconciliationStock quantities and values compared with pre-conversion figures
What would you do?
A developer says Contoso's custom stock report must be rewritten because "MSEG doesn't exist anymore in S/4HANA." Is that accurate?
For day-to-day users little changes: MIGO, MMBE and the Fiori stock apps work as before, and material document numbers keep their format. The difference shows in conversion work and in technical reports. If your team owns custom stock reports, interfaces that read goods movements or extracts to a data warehouse, list them now and ask for each: does it only read, how much data does it read, and has its output been compared after conversion?
- Material documents are stored in MATDOC; MKPF and MSEG are replaced.
- Stock quantities are calculated from material documents, not stored in aggregate tables.
- Compatibility views keep many reads working; direct writes must be redesigned.
- Reconcile stock quantities, values and custom reports across the conversion.
Check your understanding · not graded
Lesson check
1. Which table stores material documents in SAP S/4HANA?
2. How are stock quantities determined in SAP S/4HANA?
3. Which custom code needs the most urgent redesign?
4. What happens to historical material documents at conversion?