Skip to Content
avatar image
Former Member

combined upgrade and unicode conversion

I am doing an upgrade from a 46C ERP system using MDMP to ECC6 unicode on Solaris 10 and Oracle 10.2. I have finished the prepare and I'm confused as to when to run SPUM4 for the unicode conversion prep. Does it come before the upgrade to ECC6 or after? A speedy response would be appreciated.


Add comment
10|10000 characters needed characters exceeded

  • Follow
  • Get RSS Feed

2 Answers

  • Best Answer
    Feb 14, 2007 at 08:29 PM

    Hi Vicki,

    You will have to prepare your system before you upgrade. SPUM4 is the conversion preparation tool in SAP R/3 4.6C. Please don't underestimate the time this will take to do a comprehensive preparation. You will probably have to involve language experts to help with the vocabulary definition unless you are fluent in all the languages in your system. (i.e. this can take days!). So the time to execute SPUM4 for the first time is not just before the upgrade itself.

    The full process is documented in the unicode conversion guides found at

    You need the combine upgrade and unicode conversion guide (CU&UC).

    I hope this helps,


    Add comment
    10|10000 characters needed characters exceeded

    • > Hi Markus,


      > I'm curious about the resources you needed for the

      > vocabulary definition. Was this 13 native language

      > speakers working 70 hours each on defining/validation

      > the translations (~120 man days work). Was this

      > process complicated by users not following the MDMP

      > golden rules when entering/maintaining language

      > fields?

      I'll try to say it this way: We were in fact five persons who did that.

      Those were our languages







      Latin-2: Polish, Hungarian

      Latin-5/KOI-8: Russian

      GB2312: chinese simplified

      KSC5601: Korean

      TIS-620: Thai

      BIG5:chinese traditional

      The Latin-1 was easy, it doesn't matter whether you specify Spanish as German or vice versa, just the codepage matters. So seeing a word with "c+cedille" was either portugues (which we had a lot in the system although the language was not imported) or french - so Latin-1 was right.

      For polish and hungarian this is the same, I can read (and understand) some polish and was able to classify about 75 % of that, the rest was done by a polish collegue in an hour.

      I am able to read cyrillc so we didn't have the necessity to organize one, logging in in Russian I could classify 100 % of the russian data just because of reading it and deciding, whether it makes sense or not.

      Thankfully we had a (SAP-) consultant from the I18 group who lives in Korea and he was able to do it the same way with Korean, so he also tried to read it and distinguish, if it may be a sensefull word or not.

      We will abandon chinese traditional since from our chinese unit only one person uses it effectively in Taiwan and it's just too much effort to maintain it in the system - so we didn't care whether it's GB2312 or BIG5, we classified everything with GB2312.

      Thai was easily detectable because it's very different from all other languages and here goes the same as said above for BIG5.

      > I just trying to understand your comparison to the

      > effort for you initial implementation as this would

      > be a big concern - if the MDMP vocabulary definition

      > is a difficult as a re-implementation.

      There were two problems:

      Our system was MDMP since 3.0E (or 3.0F, I don't remember exactly); it was installed initially with 2.1C and upgraded to 2.2D. At this time only a few tables had language fields so the system did not really care about and just displayed "as is".

      One of the worst table was (classically) "ADRC" since the language field there exists since 4.5A I think. All other adresses didn't have a LANGU_CREA entry. In fact, that table was the biggest problem since we couldn't decide wheter to set the language flag or not, the data was filled only by 45 %. Of course we also had cases, where someone logged on in German, entered a customer address in XD03 and then logged on again in polish and "corrected" the addresse with polish diacritics. So basically he did right but the LANGU_CREA was DE - because it's written at time of creation and never changed.

      The second issue was table SWW_CONT. We used the Office functionality in earlier times as our main Mailsystem (incoming and outgoing) and that tables doesn't have a language flag either so all mails that were sent in the four years we used it, every word had to be classified in the vocabs.

      A third problem are the line items in orders. If you enter an order in transaction VA01 and add line items, the language text of the material is just copied over into the material text field in the customer defined language without a language entry. There may be e. g. a customer in Russia, that gets his order confirmations in english and that order is entered in Poland using a polish logon. The system is unable to distinguish that and you can't create a hint for this because too many data needs to be read and the hint will run endlessly. So we decided to do that also manually.

      Eventually we were told, that the scan "Tables with language informaition" should not be used, instead the vocabulary should be maintained manually because wrong data may be used. We followed that advise.

      Sure, there were violations of the MDMP rules but those were few cases. In most cases that much vocabulary is just because the system was not initially designed to have language flags everywhere and that text is often just copied over without caring of the language - because it has never been necessary. This is very cumbersome for the customers and quite frustrating - but I'm also aware of the fact, that this can't and certainly won't change in 4.7 or below.

      Another thing to mention is the "nametab" story. If you ever implemented ST/A-PI in your system you will SURELY run into nametab generation problems of /SSF*-tables. Those can be "ignored" but will prevent the system during export to finish correctly. You need to modify the .TSK-files manually. That's why we decided to no more ever import those kind of "monitoring" plugins, that are only used once before the upgrade for an Early Watch.

      For the export/import we had 6 full runs, many, many others with interruptions and changes of the number of processes. We needed a bit of database parameter changes (we use MaxDB) and finally did a parallel export and import with the manual migration monitors over X-mas with a total runtime of 42 hours.

      After that time all RFCs in SM59 needed to be adapted, HR infotypes needed to be regenerated, all S*-statistics table update programs needed regeneration etc. We started effectively at 2nd of january and had dozens of small issue with programs without the Unicode-Flag (who were not or too less used to find out), Query-Info-Set regenerations, some adapting of interfaces, who use the filesystem (UTF-8 vs. ASCII-files). We actually still have some issues with Excel exports (Office 2000) but those will be abandoned by implementing Office 2003 successively.

      All in all it was feasible, but only with a HUGE amount of work. Total project runtime: I can't say exactly but > 6 months before we ran the first UCCHECK.

      I can only advise everyone to NOT start with an MDMP installation if possible. Even if you only have two codepages, it will be a lot of frustrating and humdruming work, especially, if you need external consultants or people able to understand the language.

      Ah - and I totally forgot, we did the same with our CRM system (CRM 3.0 to 5.0 - then Unicode conversion) - 65.000 words. That was done at the same time parallel to the R/3 conversion (including the upgrade).

      So - I haven't had X-Mas this year, maybe this year (if ERP 2005 will not come) 😉

      Hope, I haven't flooded too much - just get back to me if you need more information.



  • avatar image
    Former Member
    Feb 16, 2007 at 06:17 PM

    Thank you Markus for your wealth of information, it will help me in presenting to my management the level of resources and the time it takes!

    Add comment
    10|10000 characters needed characters exceeded

    • Hi Markus,

      Thanks for the additional comments and information. I think it helps to get as many experiences as possible when planning a conversion. Your SAP R/3 conversion is a really interesting story, I enjoyed it and felt the pain and challenges you documented. I hope you have Christmas off this year 😊