Most modules of R/3 provide mechanisms to enhance the master object through customization. New fields can be added and new views can be created, or existing views can be extended. When this enhancement is done on the master object, effectively speaking, R/3 modifies the R/3 tables involved in that master object. Care has to be taken that corresponding data transfer structures are also enhanced as per the guidelines provided in SAP documentation for enhancing that particular object.

For example, in the material master, the tables MARA, MARC, and so on, change after the customized enhancement of the material master object is complete. But the corresponding data transfer structures BMM00, BMMH1, and so on, are not automatically modified. When customizing the material master, the Online Service System note #0038229 has to be applied.

Field Values Arrive in the Wrong Place in the Batch Input Session

If the data in a flat file appears fine, but when the BI is processed you notice that values appear in the wrong fields:

<        Make sure that the record structures you use correspond to the business object.

Refer to chapter 2, Using Data Transfer Programs, for help.

<        Make sure the fields are in the right place in the record.

Since the fields have a fixed length, you could have shifted everything by inserting a character.

There is no Batch Input Session

Many times, when using ‘SM35’ you many not find sessions that R/3 standard load programs claimed were successfully created. Check if you are working in the same login client as the ‘mandt’ field of the data file. Please note that the client in which the session is created is confronted by the value of ‘mandt’ of the data file and not by your login client.

Authorizations and User Master Defaults

While processing the BI session, you get an error message telling you that some authorizations are missing:

<        Make sure that the user who processes the BI sessions has all the necessary authorizations.

While processing the BI session, you get an error message saying there are inappropriate date or number formats used.

<        Make sure that the user who creates the BI session and the one that actually processes the session uses the same user defaults for date and number formats.

External and Internal Format

Most programs require the data in the flat file as you see it on the screen; however, there are some programs that require data in the internal (language and format independent) format. In such cases, you will receive a message to provide data in an internal format.

Remember to provide the data in the appropriate format (for dates it is YYYYMMDD; for units of measure it is sometimes the German abbreviation, for example, ST for PC).

Problem with RMDATING

If you added a new field to MARA (or an append-structure for MARA or another table of the material master) you always have to run program RMDATING to generate the corresponding data definitions for the data transfer program. If you delete the field again, restart RMDATING and receive an error message saying that SAPLMGAD contains syntax errors. The quickest fix is to put an ‘*’ in front of all lines that contain the field, save it and re-start RMDATING.

Typical Mapping Problems

The following are some examples of problems that could arise when mapping fields from your legacy system to the appropriate flat file field.

The Legacy System Provides Other Values than Needed in R/3

The unit of weight ‘lb’ in the legacy system is represented by the number ‘01’ and you want to use ‘lb’ in the R/3 System. The unit of weight is stored in a field called ‘WGHT’ on the legacy system.

To transfer the legacy data, you have to map the field ‘WGHT’ to the R/3 field ‘GEWEI’ and convert the value ‘01’ to ‘lb’.

Different Organizational Structures

In the legacy system you have different organizational structures. Two “old” plants of the legacy system have to be matched with five “new” plants in the R/3 System.

Depending on other legacy data that is available for the conversion program, you will have to write an ABAP routine that fills in the plant data in the flat file correctly. If that data is not there, you have to change it manually.

Inconsistent Source Data

A typical problem is inconsistent source data. For example, the address data is not correctly stored in separate fields, but in one field in the legacy database. For example, your legacy system stores the street, state, and ZIP code in one field—separated by commas—and you want to map this data to three different R/3 fields.

If fields are not in the correct format in your legacy data, you must convert the format before you can export the data to R/3.