09-30-2008 7:20 PM
Hello
We are in the Project Plan Phase of Unicode Conversion. (We are on ECC 5.0. We are planning to do the Unicode Conversion only, No Upgrade).
We have Asian sapscripts , especially forms in Japanese, and Korean. We are currently on MDMP. (6300, 8500).
In the current system, for eg, for sapscript ZINVOICE, we have a copy in English(EN) and another one in Japanese(JA). This JA form has all Japanese characters .
For eg, 'Ship-to Address' will be printed in japanese characters in this form. 日本語フォーラム
So what happen to these forms when we do unicode conversion ?
1. Do we have to still maintain multiple forms (one for english, another for Japanese, thrid one for Korean) after unicode conversion ?
2. What steps do we have to take in case of this forms during/before/after Unicode Conversion. ?
OR is it like, just do nothing...keep the forms as it is, everything will print fine, as it is doing now, in non unicode system, even after the conversion ?
Please share your knowledge. Any tips would be of great help for me.
Thank you so much
10-02-2008 6:06 PM
11-20-2008 5:58 PM
Hi Sujamol,
We faced alignment issue the scripts and forms during the non-unicode to unicode conversion. But we have done the unicode conversion from 4.7 to ECC 6.0. Please check the OSS note 1176182 and its pre-requsite OSS notes. Because this OSS note was created when we raised the alignment issue in the unicode converted system. This correction is not available in ECC 6.0 EHP 3.0 also.
And if you have any barcodes in the forms that barcode will take more space than the non-unicode system, but there would be any problem when reading the barcode.
If you have any Korean forms and PDF conversion that also should be taken care.
Language assignment is more important (SUMG). If should be done correctly.
Regards,
Saravanan V
11-20-2008 7:30 PM
As long as your print programs are made Unicode compatible you'll probably be able to use your current SAPScripts without modification.
You'll still want your forms with separate languages but you can now mix languages inside a sapscript without trouble which is nice.