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

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

To report this post you need to login first.


You must be Logged on to comment or reply to a post.

  1. Sudeep A

    Hi Jurgen,

    Nice blog…!!  really informative as usual… Didn’t get time to go through fully, bookmarked for future reference.. 🙂



  2. Vivek S

    Thanks sir and it’s very excellent document and good in delivery.

    This is life long reference document.



  3. Tamas Gal

    Hello Jürgen,
    thank you for your blog, it contains extremely valuable information. I just have a similar case where I decided to use INFREC IDOCs sent from ME18 transaction code in the source System, since most of the inforecord data is identical in the source and the target System (except for a few fields like LIFNR that I handle in the ABAP). The interesting thing I bumped into right now is that there are certain PIRs in the source System that are only created on Purchasing org. level (but NOT on plant level). These are usually automatically created during PO creation. Since these PIRs has no plant in the EINE record, the standard IDOC I generate in ME18 will not contain the WERKS value. The real problem is that it seems the standard IDOC processing FM cannot handle these cases in the target System, the error message (Material xxx is not created or not active) is set for my IDOC. I checked it in debug mode, and it seems the plant code is a mandatory parameter for my FM when it comes to PIR creation. How is it connected to you post?
    1. I would really like to hear your opinion if you have some time 🙂
    2. this restriction is not mentioned at all among the “INREF IDOC list of restrictions” note that you posted (Note 327083 – INFREC: Data transfer of purchasing info Records)

    Thank you in advance,

    1. Jürgen L Post author

      I am very certain that we have no uniform info records, we usually have this mix of info records at purchasing org level only and  at purchasing org/plant  level  too, in any of our systems.

      The message refers to the material in your target system.
      Since all Idocs are created with ME18 I would not expect anything wrong in the IDoc, especially not if you did not touch/exchange the material number field in the IDoc.

      From this point of view I would first compare if the material number is really technically identical (leading zeros) in info record Idoc and material master of target system.
      Then I would check if the purchasing view exists at all for your material in the target system, MARA-PSTAT and MARC-PSTAT should contain a “E” among other characters.
      Then I would check if the material master has a deletion indicator.
      And finally check if the material master has a plant specific or cross plant material status which prevents the usage of the material and hence blocks creating info records.

  4. Tamas Gal

    Hello Jürgen,
    many thanks, I just discovered myself too that the leading zeros is the key, in the source System I had it without leading zeros, but the target System expected them to have leading zeros.
    Thank you very much!!


Leave a Reply