SAP Master Data Migration and Upload Templates

The standard interface for creating and changing material master data. The same BAPI serves MM01, MM02 and MM17.

What to watchEvery data structure has a partner X structure, and the X structure is what makes a field count. Send PLANTDATA-DISMM without setting PLANTDATAX-DISMM to X and the value is silently ignored. On a change that means nothing happens. On a create it means the field comes out empty.

Step by step MM01 upload guide

The same interface as MM01. On a change, the X structures do the real work: they are what separates a field you are changing from one you are leaving alone.

What to watchEvery data structure has a partner X structure, and the X structure is what makes a field count. Send PLANTDATA-DISMM without setting PLANTDATAX-DISMM to X and the value is silently ignored. On a change that means nothing happens. On a create it means the field comes out empty.

Step by step MM02 upload guide

MM17 on screen and this BAPI reach the same place. The BAPI route gives you per-row validation and a per-row result, which the screen does not.

What to watchEvery data structure has a partner X structure, and the X structure is what makes a field count. Send PLANTDATA-DISMM without setting PLANTDATAX-DISMM to X and the value is silently ignored. On a change that means nothing happens. On a create it means the field comes out empty.

The same interface as material create. Extending is just sending the organisational key with the views you want and nothing else.

What to watchAn extension is not a separate operation in SAP. You call the same create interface, send the material number with only the new organisational key, and flag only the views you are adding. Send a view flag without its X structure and nothing is written for that view. Send data for a view you did not flag on HEADDATA and it is ignored without a message.

The same interface as any material change. The deletion flag is an ordinary field, which means it needs its X flag like any other.

What to watchThe deletion flag is an ordinary field, so it obeys the ordinary rule: without its X flag set it is silently ignored. A deletion run that reports success and flags nothing is almost always this. And the level matters: a client level flag affects every plant, a plant level flag affects one.

A compact interface. Note that BATCH and BATCHATTRIBUTES genuinely appear on both the importing and exporting side, which is legal and confirmed by working code.

What to watchClassification does not happen unless you ask for it. BATCHCONTROLFIELDS-DOCLASSIFY and -CLASS_NUM are what create the classification values. Leave them out and the BAPI creates the batch record cleanly and silently skips the characteristics, which is usually the whole point of the batch.

This is a function module, not a BAPI. It predates the BAPI conventions entirely, has no RETURN table, and raises a classic ABAP exception instead.

What to watchThere is no RETURN table on this module, so the usual BAPI error handling finds nothing and treats every failure as a success. Failures raise the ERROR exception, so SY-SUBRC must be checked. And commit works differently: the module carries its own FL_COMMIT_AND_WAIT flag, which defaults to blank, so with the default the caller must commit. Samples that omit both are why many BOM loads appear to succeed and persist nothing.

Step by step CS01 upload guide

An API function module rather than a BAPI, which means no BAPIRET2, no X structures, and a commit that happens by default.

What to watchThe quantity and date fields here are batch input character fields, not typed numbers and dates. COMP_QTY is CHAR 18, COMP_SCRAP is CHAR 6 and VALID_FROM is CHAR 10, all on data elements whose names end in _BI. They have to be formatted in the calling user's own decimal and date notation, so twelve and a half is 12,5 for one user and 12.5 for another, and a date is 24.09.2026 rather than 20260924.

The classification interface. Allowed values are split across separate tables by data type, which is the thing that catches people.

What to watchAllowed values are split across three tables by data type, and their descriptions sit in a fourth. A single allowed-values column routed to the wrong table for the declared data type produces a characteristic with no value list and no error. This template carries a Data Type column on the header so the loader can route correctly.

Three value tables, and which one a value goes in depends on the characteristic's own data type, not on what the value looks like.

What to watchThe three value tables split by the characteristic's data type in CT04, not by how the value looks in your sheet. CHAR and BOOL go to the character table, CURR to the currency table, and NUM, DATE and TIME all go to the numeric table, whose VALUE_FROM field is a floating point number. A date characteristic therefore cannot be sent as 20260924. Pipe everything into the character table and every numeric, date and currency characteristic is lost.

A condition interface with its own naming convention, its own operation codes, and one field that is unlike anything else in SAP.

What to watchVARKEY is a flat 100 character field into which the entire key of the target condition table has to be packed, in the exact field sequence and exact lengths of that table, with no delimiters. It is not a list of fields. Get the packing wrong by one character and the record lands against the wrong key with no error.

Step by step VK11 upload guide

A list-based BAPI. You pass a table of cost centers and one controlling area for the whole call.

What to watchTwo things to know before you run: CONTROLLINGAREA is passed once for the whole call, so every row in the file must belong to the same controlling area. And VALID_FROM and VALID_TO are per-row with no default, so a blank validity interval creates an unusable record rather than defaulting to something sensible.

Step by step KS01 upload guide

The change counterpart to the create BAPI. It works differently from most change interfaces, and the difference matters.

What to watchThis BAPI has NO X structures. Most SAP change interfaces use paired X structures to say which fields you mean. This one uses a single RESET_FILLED_FIELDS switch for the entire call instead. A template built on the usual X-column mental model will be wrong here, and the wrong switch setting either wipes populated fields or refuses to clear them.

A list-based CO interface. Note the real function module name is BAPI_COSTELEM_CREATEMULTIPLE, not BAPI_COSTELEMENT_CREATEMULTIPLE, which exceeds the 30 character ABAP limit and does not exist.

What to watchThis structure uses ABAP field names, not the English BAPI style. The cost element is KSTAR, the validity is DATAB and DATBI, the name is KTEXT and the description is KLTXT. Building the template by analogy with the cost center BAPI, which uses COSTCENTER, VALID_FROM, NAME and DESCRIPT, produces columns that map to nothing.

A list-based CO interface. The real function module name is BAPI_ACTTYPE_CREATEMULTIPLE, not BAPI_ACTIVITYTYPE_CREATEMULTIPLE, which exceeds the 30 character ABAP limit and does not exist.

What to watchThe allocation cost element must already exist. It has to be a secondary cost element of category 43, in the same controlling area, with a validity window that covers the activity type's own. Loading activity types and their cost elements in the same run, in the wrong order, fails here and the message does not always say why.

Four parallel data tables joined by a fifth index table. This is the shape of the whole CO planning family and it is the thing people get wrong.

What to watchINDEXSTRUCTURE is not bookkeeping, it is the join. The four data tables are not matched by position. Each row of INDEXSTRUCTURE names one COOBJECT row, one value row and one CONTRL row by their index numbers. Supply the data tables without it and the call returns cleanly having planned nothing.

The same four table plus index shape as activity price planning, but with different table types. They are not interchangeable.

What to watchThe two planning BAPIs look interchangeable and are not. INDEXSTRUCTURE is BAPIACPSTRU in both, but the object, value and control tables here are the BAPIPCP types, not the BAPIACP types, and the field sets genuinely differ. BAPIPCPOBJ has an order and a WBS element; BAPIACPOBJ has neither. A template built for one will not feed the other.

An unusually small interface. Note the I_ and E_ prefixes on the master data parameters, which are not the usual BAPI convention and are frequently mistyped.

What to watchThe parameter names carry I_ and E_ prefixes, which almost no other BAPI does. It is I_MASTER_DATA going in and E_MASTER_DATA coming back, not MASTER_DATA in both directions. A mapping written from the usual convention will not bind.

A method driven interface with paired update tables. Every data table has a twin whose fields are all flags, and the twin has no key of its own.

What to watchThe update table has no key. Its first field, confusingly called WBS_ELEMENT, is itself a CHAR 1 flag rather than a WBS identifier, so nothing in that table says which element a row of flags belongs to. It is matched against the data table positionally, row for row. Filter, sort or skip a row in one table and not the other and the flags land on the wrong elements, silently, because every value involved is a valid X or blank.

The asset master interface. Almost everything is an importing structure with a paired X structure, and the depreciation areas are the only real table.

What to watchTwo X traps on this one. Every data structure needs its X partner flagged or the value is silently ignored. And in DEPRECIATIONAREASX the first field AREA is NOT a flag: it stays NUMC 2 and must carry the real depreciation area number, so the X row can be matched to its data row.

Step by step AS01 upload guide

A compact interface with no TABLES parameters at all. General technical object data and functional location specific data are two separate importing structures.

What to watchA documented SAP behaviour worth knowing before you load a hierarchy. When you set DATA_SPECIFIC-SUPFLOC, the BAPI marks the data origin of maintenance plant, planning plant, cost center and company code as maintained directly, not inherited from the superior location. The child looks correct but is permanently detached from the parent's data propagation. SAP KBA 1704117 documents this.

The sibling of the functional location BAPI, sharing the same general data structure. Installation is handled by its own structure, not by the specific data.

What to watchDo not map a functional location column to DATA_SPECIFIC-READ_FLOC or superior equipment to -READ_SUPEQ. The READ_ prefix marks those as output only fields. Installation is driven by DATA_INSTALL and VALID_DATE. A template that maps to the READ_ fields creates unattached equipment with no error message at all.

A small interface with no TABLES parameters. The whole address structure is only 11 fields.

What to watchRETURN on this BAPI is an exporting structure, not a table. Code written from the usual BAPI pattern that passes TABLES return will not bind, and an error handler that loops a message table finds nothing and treats every failure as a success.

Not a BAPI. A function module with an untyped record parameter, a single message back, and a commit that happens unless you switch it off.

What to watchThe parameter texts for the two validity dates are transposed in SAP standard: the parameter typed ENDDA is described as the validity begin and the one typed BEGDA as the validity end. The types are right and only the descriptions are wrong, so anyone generating column headings from the SE37 documentation labels the two date columns the wrong way round. Go by BEGDA and ENDDA, never by the description.

Step by step PA30 upload guide