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!
Showing results for 
Search instead for 
Did you mean: 
Active Contributor

My migration season is over for this year. Time to blog about certain difficulties and things I learned and want share with the community, my colleagues and myself (in case I forget until i have my next migration).

Among the last activities in my task list was the migration of purchasing info records.

But let me first talk a bit about the project. Due to the companies history we have many different SAP ERP systems and on the long term almost all shall be consolidated into one big ERP system. We are doing this already for some years and have still some more years in front of us. Aside of these big merger projects we have as well carve outs and smaller roll outs to companies that are not yet on any SAP system. While those big mergers have a project time of 1 or 1,5 years, those smaller projects are usually done in a few weeks or months.

In this last project we had to migrate data from 2 ERP systems into our target system.

In numbers: 14 companies, 36 plants, 23 purchasing organisations

Along with this migration an organisation change was executed, several companies had a legal merger into 1 company, others kept their independence.

Purchasing organisations got reorganized, in both directions, from n:1 and some from 1:3

Not to forget that the data had to be harmonized, thousands of vendors and customers and materials existed in all 3 systems, and even within a system some vendors and customers existed multiple times and had to become just one in the target system.

This was enough to scare you, and I  think even the most naive person can imagine that such a  data migration cannot be executed with a LSMW-Mickey-Mouse-recording with just 10 fields in a flat file.

Yes, here we are already at the first decision: which import method will be used. BAPI method is not available, so we have the option of IDOC, SAP given batch input and own recording.

My preferred migration method is LSMW with IDOC import method. I extract the data from the source system using the standard ALE scenarios as it usually saves me the work for an extra extraction program. You can read in detail  about the setup of an ALE for such a migration in my blog LSMW migration with IDOC method  and using IDOC as source  Part1: Extract by ALE

Another advantage is that I can already create a mapping old info record to new info record number during the conversion. IDOC method allows to create new info records with pre-assigned numbers. In batch input methods the info record number is only known after posting and creation of a mapping list very tedious.

Recording is always only the last option, if no SAP given method is given, as recording is a static method which does here not give the needed flexibility to migrate info records with an unknown number of purchasing organisation views.

So the decision had to be made between standard batch input and IDOC method.

Here I want emphasize on the specific issues to the info records migration using IDOCs as data carrier and import method

  • The extraction was planned to be done with transaction ME18  but we did not have a role with this transaction, as distribution of info records is not in our process model. So I had to use SE38 to execute report RBDSEINF to send the info records into a file which I later use as my source file.

  • How the field mapping for a huge file full with Idocs is done was already explained in my blog LSMW migration with IDOC method and using IDOC as source Part2: Import The field mapping is actually not an issue, however, one stumbling block is even here.  We usually know what fields we use in our process, so we focus on those fields and may not map the other fields in the field mapping or may just assign an initial value to such a "not used" fields. Due to historic reasons there is one field which is too short: Export/import procedure for foreign trade , and SAP added another field with a bigger length at the end of the IDOC. From the name you actually focus on the short field, and if you forget to map this second field too then you only migrate a truncated  value to the target system

  • The real trouble starts with the extraction, with sending the IDOCs by ALE. This IDOC is not really made for migrations (even SAP says in OSS note 327090 it is not made for data transfers), it is just made to distribute info records from a central system to satellite systems. And for such process you need to have an ISO code assigned to any unit of measure used in an info record. If you do not have such a process, then you eventually haven't ISO codes in all units. If you send the info records in foreground then SAP stops with a hard error message when it reaches an info record that has a unit without ISO Code.

You can just click Exit at the error message, and you are taken back to the menu. You do not know at which IDOC it stopped, you do not know vendor nor material.

To avoid such situations I create a small Quickview joining table EINA and EINE, listing info record number, vendor, material and all unit of measure fields. Sort this by the units and then check table T006 if each used unit has an ISO code. Based on the number of occurrences we decide if we do additional customizing for units and ISO codes, or if we exclude those info records from the automatic migration and create them manually - if needed at all.

  • And for the sake of an unreleased function module, this INFREC Idoc does not work like you can expect from a BAPI. The defaults are not taken from material master if you do not transfer the data for reminder days and Under- and Overdelivery tolerance in the IDoc. OSS note 327090 has a modification to make this possible if you want. And even you have the values for reminder days and tolerances in your IDOC you may still experience a surprise. In case the reminder days are set to zero, defaults are taken from purchasing value key entered to the material group in Customizing of Entry Aids for Items Without a Material Master

This a real case, however, it has quite inconsistent data. material master has purchasing value key 1210, entry aids have PVK 6001, and the info record even a 3rd variant. We have to ask ourselves if such inconsistency should be carried over, or if it is better to have the data in unique fashion again, according to the design of the target system.

  • The next difficulty I faced was a typical beginner mistake, I almost want to say an error because of plagiarism. I admit I am lazy, I copy the LSMW object from my last project and just concentrate on new mapping. Since many materials got new units we have to re-calculate Standard Quantity and Minimum Quantity. For this I make use of a standard SAP function module MB_UNIT_CONVERSION. I never had any problem in past migrations, but there is always a first time. My conversion step dumped. And because it worked the last years I did not check the coding in my program, I suspected the error in the data. Finally I found that I had just missed to catch the Exceptions when calling the function module. There were 7 materials (manually created) that had not the expected alternative units to allow a unit conversion.

  • Still this was not the last stumbling block.  We met situations where the material master in the target system had a material status that does not allow procurement activities. And even vendor masters with a block.  Since we mapped to existing master data where possible this situation caused posting errors. You cannot create info records if you have a materials status with procurement block. Hence you cannot create info records with the IDOC either.

No real issues for me but in any case good to know: you have to care about the info record number, if you leave it blank and let SAP automatically create a number when posting then the info record texts are not created. If you just map the number fields and MOVE the old number, then you either create info records outside your number range, or even worse you overwrite existing info records.  But I had chosen the IDOC method to create the info record number already in the conversion routine especially for the mapping which I need for the subsequent step of pricing condition load with COND_A Idoc.

About this more in my next blog: Difficulties in price condition load for purchasing info records with COND_A IDoc method

If you work the first time with a new import method, then you should search for OSS notes and read especially the consulting notes, but even error correction notes have a lot good info and may explain the SAP design.

Below you find some notes as reference for the above mentioned "trouble" , but there are many more about INFREC in http://service.sap.com/notes

832669 - INFREC: Export/import procedure code has only five digits

326028 - INFREC: Infosätze werden doppelt (EINA) angelegt

481034 - FAQ: Data transfer (batch input) in purchasing

327090 - INFREC: Default data is not transferred

327083 - INFREC: Data transfer of purchasing info records