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
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.
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.
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
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
User | Count |
---|---|
3 | |
2 | |
2 | |
2 | |
2 | |
2 | |
2 | |
2 | |
1 | |
1 |