Enterprise Resource Planning Blogs by Members
Gain new perspectives and knowledge about enterprise resource planning in blog posts from community members. Share your own comments and ERP insights today!
cancel
Showing results for 
Search instead for 
Did you mean: 
JL23
Active Contributor

Based on the subject  it is easily to guess that I am not a friend of LSMW recording....for material master

I wonder at all why this is the 1st choice for so many user who start using LSMW for data migration. It may be understandable for people in my age who had to use batch input recording in the ancient times before LSMW was released, but looking at the Avatars here in SCN I see mainly young people....having trouble with their LSMW recording.

Why do they use recordings if SAP has already provided import methods? Did they miss to read the documentation?

from: SAP Library - Legacy System Migration Workbench
You can use the recording function to create a new object (or a new "import method") if neither a standard batch input program nor a standard direct input program nor the BAPI/IDoc method is available for a data object.


No, I do not want to demonize LSMW recording. I use it too, for data objects where SAP has not provided any import method, and as well for some quick and dirty mass changes on 1 or 3 fields. I have even used it for material master, in case the change was in the initial screen and in Z-fields which are not available in standard import methods.


But let me try to explain why the recording method is not suitable for a material master.


The LSMW recording is a static method. The program which is generated from a recording does exactly the same screen sequence as earlier recorded. It puts the cursor into the same fields like in your recording. It expects the same error cases. Just the data itself can be variable.

The material master is rather dynamic, depending on the material type customizing you may have different views to maintain, you may even have different or additional fields in the same view, eventually having different field attributes  (mandatory/optional).


In short using a static method for a dynamic data object is like doing a break-dance with a full body plaster cast.


Here the proof with some screen shots.

A recording is made for a spare part material. Only Basic data view, Purchasing view, MRP1 view  and General Plant data / Storage 2 view is selected.


in the recording this selection is technically made like shown below, you just have 4 selection indicators, which has the position from the pop-up in brackets. You can count above, 01 = Basic Data 1, 04 = Purchasing , 07 is MRP1  and 12 is Storage 2 view.



You do all the LSMW steps, I don't want to explain them again, there are many documents in SCN showing in pictures what you have to do step by step (just the explanation why you have to do it this or that way is a little lacking - no wonder why we can find 140 hits for: LSMW recording MM01 problem) and finally you created the batch input session and executed it.


You did not have any issue with your ERSA materials, as you did the recording for them, but in the moment the session wants to create a FERT material the trouble starts. You may find error messages in the log like "Formatting error in the field xxxxx"  (87 hits in SCN for this error).

But why did you get this error? The material master for FERT has additional fields active in the Basic data screen, e.g. the division and this field is even mandatory while it was not visible at all for the ERSA material in your recording.

What do we learn? You have to create an extra recording for each material type. Is this then really time saving compared to work with standard SAP given import methods?


Let's move on to next issue and other errors. If you have to load about 80000 materials like I had in my last migration, then you could see an awful big error log. For this example here I just continued with this single material processing it in foreground. The same errors can be seen in the status bar  which would have been listed in the error log in case of background processing.


Look at the first picture above, which has the view selection from your ERSA material and compare it with the next screen shot which is our FERT material to be created:



The view 01, 04, 07 and 12 are selected like in our recording. But look at the text, view 04 was the purchasing view, now it is the Sales Org Data 1 view. Position 07 was the MRP1 view, now it is Foreign Trade, position 12 was storage 2 view, now it is MRP1.

The static recording has just remembered the position, it did not record what view is assigned to this position. Because this is dynamic information, retrieved from customizing during runtime.


What happens now?

First SAP reaches the Basic Data 1 view,  but as you can see, there are more mandatory fields for which we do not have values in our template,  fields which were not even recorded before. I enter the values manually to get further.


The static program continues from Basic Data 1 view to the 4th view (Sales Org Data 1) and wants enter the purchasing value key. But there is no field for purchasing value key in the Sales view, hence the next error is logged:

127 hits in SCN for: Field "does not exist in the screen"  batch input


continuing to the next screen, to catch the next error:

We are now on the foreign trade view, this view SAPLMGMM 4004 was not at all in our recording. SAP just came to this view because of view selection 07.  We haven't recorded this screen, we have no data for this screen, right now we have data for MRP1 view to insert, but we cannot do this in Foreign trade view. Continue


Now we are at the MRP1 view (actually view 12 from the recording), and we see again an error:


But why does SAP complain about no batch input data? We had data for MRP1 view in the session. Yes, but our MRP1 view field values were already processed in the foreign trade view. Now we are in this view but do not have anymore the data for this view. Bad luck.



As you see the static recording method is not suitable if you cannot ensure the same static sequence and fields like in the recording.

You would need an extra recording for any variance (including unexpected error messages).




Alternative recording:

There is a way to record the views instead of just the position of the view. At least this can be used if you only want maintain data for those views. It is still not  flexible to  process sales views for FERT material and purchasing view for ERSA.


In the recording select only the Basic data view, this is usually the first view an in most material types available (we have some material types without basic data view, this situation is possible).

Then select the other views from within the material master via the pull down menu on top right:



This way SAP remembers the view names instead of the position and you can at least process all 4 views from this example.

However, the extra mandatory fields for FERT materials are still not in if you use ERSA material for the recording. And you do not have screen fields in ERSA materials when you record FERT materials instead, which causes then another error.


Further alternatives are the transactions MMZ1 Create and MMZ2 Change Materials master  from SAP's stone age. They have a static view selection with boxes to be flagged. But they are really historic and you have to check carefully if you can get all needed fields.


The better option is to get used to the SAP given import methods. The BAPI method is explained in my blog LSMW Material master by BAPI method - Part 1




8 Comments
Labels in this area