DME file after unicode conversion

Hi gurus!
we have a problem with DME visualization after we passed to unicode system.
if we want to create new DME with a ZF110 (copy of F110 ) the DME have incorrect character if we try to see it in transaction FDTA or in ZF110.
i tryed with parameter 'DCP' but is the same.
any suggest?
best regards

Hi,
You need to compare the programs called by ZF110 and F110.
I think Z110 is calling Z program which are copy of SAP standard program.
In this case compare the Z program with the respective original program.
You will find some difference here and you need to modify Z program with respect to original program.
We had a same issue and solved by adjusting Z payment run program with SAP standard program.
Regards
Rahul

Similar Messages

After unicode conversion Variant missing

Dear All,
After unicode conversion in transaction S_ALR_87013611 and
S_ALR_87013613 variant is missing.
We checked in table VARIT - "Variant Texts" data is missing.
Kindly suggest.
Thanks and regards,
Joseph

Hello
Did you discover the reason for this? We are now facing the same issue and we cannot find the reason.
I don't think that note 987914 can be the answer.
Can it be something connected to the procedure for conversion or caused by a wrong-executed step?
Every suggestion can help,
Thanks
Luca

SAP Data File size considerably reduced after Unicode Conversion

Hello Experts
I have just performed a CUUC (Upgrade along with unicode conversion) from R/3 4.7 to ECC 6.0 EHP5. The data size that i earlier had was close to 463 GB (MSSQL MDF, LDF Files), after the data export to be converted to unicode the size was 45 GB (10% of actual data size, i feel this is normal after heterogeneous system copy), but after the import again the DATA file size is only 247 GB, is this normal ? or have i lost some data ? For ex, I tried checking tables like MSEG and the number of entries have reduced from 15,678,790 to 15,290,545.
Could you kindly let me know if there is a way to check from Basis perspective if i have not lost any data ? I have followed all the procedures as per SAP Standards.
Waiting for your quick reply.
Best Regards
Pritish

Hi Nicholas
Data is compressed during the new R3load procedure is understood, but why number of table entries have reduced is something which is still a question to me (in some cases increased as well) ? For example
                             Source          Target
STPO                  415,725          412,150
STKO                 126,710          126,141
PLAF                 74,671                   78,336
MDKP                 193,487          192,747
MDPB                 55,329                   63,557
Any suggestions or ideas ?
Best Regards
Pritish

SRM can not open attachment after unicode conversion

Hi,
Our system is SRM4.0, last week we do a unicode conversion project.
After we convert to unicode, some attachment in SC and PO can not be openned, these attachment file name include some chinese. If the attachment file name is all English, no problem to open it.
I think it is the cause by unicode conversion, do you have any idea what is the root of this problem?
Thanks.

Hi,
Please check in table :BBP_PDATT
If you have created a shopping cart with attachment. The attachment will be in the above table
Regards
G.Ganesh Kumar

U00C9 becomes u00C3 after unicode conversion

Hi all,
After the unicode conversion in ECC 6.0 server, when we download a file from SAP to unix, the character É becomes Ã in the file,
1 When cat the file, it shows as
1. cat testzzz
TRÃSOR
2. When more the same file, it displays a different character # more testzzz
TRM-CM-^ISOR
3. When we download the same file to our PC and open it in the notepad it looks ok.
TRÉSOR
4. In the SAP also this displays correctly as below
TRÉSOR
So when I was checking the locale parameter at unix level, I could see that its "C".
1. locale
LANG=
LC_CTYPE="C"
LC_COLLATE="C"
LC_MONETARY="C"
LC_NUMERIC="C"
LC_TIME="C"
LC_MESSAGES="C"
LC_ALL=
From my understanding "C" doesn't support unicode, so we tried "univ.utf8" & fi_FI.utf8 for LC_CTYPE but no luck.
Did anyone faced this problem earlier.
Our OS HPUX 11.31 - IA64
Thanks & Regards
Senthil

Hi Senthil,
what terminal software are you using. I use putty and when I switch my terminal window translation settings to UTF-8, I get the correct text. Therefore I assume that your problem is your terminal emulation.
Regards
Ralph

RFUMSV00 (Tax report) wrong generation of DME file in Unicode system

Hello gurus,
I've a problem running the program RFUMSV00 (Advance Return for Tax on Sales/Purchases) transaction S_ALR_87012357 when "Create DME file" check box is selected and a format tree and a file name are specified.
On 4.7 it was working properly but now on ECC6.0, that is unicode compliant, does not work correctly because each char of each field on the downloaded table into Unix directory has preceeded by an hash (#).
So 1234 becomes #1#2#3#4...
The problem seems to be related to codepages and I found in debug that the RFUMSV00 program calls from the include I_RFUMS_DME_FORMS the following routine at line 119: PERFORM write_file_to_system USING lt_dme_file.
This form contains a call to the following function:
    CALL FUNCTION 'FI_PAYM_FILE_OPEN'
              EXPORTING
              i_temse_name = par_tems
              i_file_name = l_file_name.
without specifying the codepage as further parameter so the function open the dataset for output in binary mode (and here the problem) because i_codepage is initial
Pls see below.
    IF i_codepage IS INITIAL.
      OPEN DATASET i_file_name FOR OUTPUT   "Open File to write
                               IN BINARY MODE.
    ELSEIF i_codepage = '4110' AND
           cl_abap_char_utilities=>charsize > 1. " UTF-8 and Unicode
      OPEN DATASET i_file_name IN TEXT MODE FOR OUTPUT
                                       ENCODING DEFAULT.
    ELSEIF i_codepage = '4102' OR i_codepage = '4103' OR i_codepage = '4110'.
      OPEN DATASET i_file_name FOR OUTPUT
                               IN BINARY MODE.
    ELSE.
      OPEN DATASET i_file_name FOR OUTPUT   "Open File to write
                               IN LEGACY BINARY MODE
                               CODE PAGE i_codepage
                               IGNORING CONVERSION ERRORS.
Putting '4110' on i_codepage all is working magically perfect.
Does anybody know where set the code page (4110) or how to solve this problem ?
Thanks a lot in advance & best regards
Tony

Hello Rob,
thanks for your reply.
Yes I did a check of the OSS notes and I found that OSS 1365764 (Pls see below) describes exactly the problem I have but it is relevant only for payments and DME files created with this purpose.
Also the DCP parameter (that has to be specified at user level) is only relevant for RFFO* programs.
Note 1365764 - Codepage of DME file
https://service.sap.com/sap/support/notes/1365764
Also the two following notes
Note 911190 - PMW: Entering the code page when writing and downloading
https://service.sap.com/sap/support/notes/911190
Note 899205 - RFUMSV00: DMEE format tree with additional parameters
https://service.sap.com/sap/support/notes/899205
So to be honest I do not really know how to look at to solve the issue.
Thanks again for your reply & best regards
Tony
Edited by: Antonio Lanza on Nov 9, 2010 9:33 AM

Job logs from the original system after Unicode conversion.

Dear Globalization experts,
We are doing Unicode conversion and would like to know, if the Job logs from the batch jobs, executed before conversion (system with a 1100 code page), would be readable in the Unicode system after the conversion. We will move job log files from the source to the target system. I . Thank you in advance for your help.
Best regards,
Alik Shapiro

Hi Alik,
I have strong doubts that this will work ...
From SAP notes 842767 and 901004 you can see, that spool data will not be converted properly by default.
In general this is valid for data stored in TemSe, as this is by definition temporary data (see for example http://help.sap.com/saphelp_nw70/helpdata/en/d9/4a8f9c51ea11d189570000e829fbbd/content.htm ).
However I actually did not test it, so I am not 100% sure.
Best regards,
Nils Buerckel
SAP AG

Some character display incorrect after unicode conversion

Dear Experts,
Currently we upgrade our SAP system from 4.6B NU to ECC6.0 UN.
in 4.6B system we had implemented Simple Chinese and French language package to the system. after upgrade to ECC6.0 no-unicode system. we perform a MDMP unicode conversion.currently system running with ECC6.0 unicode interface with language 1EFD. SUMG releated tasks had been finished. Chinese and French language checked OK in ECC6 UN system.
Our issue is. in the past time. some Spanish local end user typing some spanish character in some master date field when they login in 4.6B GUI choice english as login language.these kind of spanish characters could not display correct in current unicode environment.
could you please given us some suggestion for how to fix this issue.
I also sent this message in the Netweaver administrator forums with below links.
Spanish display incorrect after unicode conversion

Hello,
I doubt that the data shown by you in the link was caused by Spanish users logged on in EN.
I think this was rather caused by utf-8 data uploaded into the Non-Unicode system.
In this case, you need to repair the according texts manually, I do not know any automatic repair.
Best regards,
Nils Buerckel
SAP AG

Alignment all out after unicode conversion

The system is now unicode compliant.
The purchase order, invoice that has Chinese text as line item are all printed out of alignment.
It had pushed the next field towards the right.
I understand it is becuase of the unicode character / bytes difference.
Can someone shared with me how can I modified the sapscript to get it back in alignment?
Please provide a sample.
Thanks
bye

Hi,
I have read the thread before. It doesn't help in my case.
To share it with you,
I realised that I can place a length field after the field.
Previously I could use &EKPO-TZX01(40)&. Now I had to remove it to &EKPO-TZX01&.
it works for some but not all sapscripts.
For those that doesn't work, I will have to changed it as well as setting the tab using a separate paragraph.
So much to change after this unicode conversion.
Thanks

Unreadable characters in SM21 after Unicode Conversion

Hi all,
After upgrading from BW 3.1 content to BI 7.0, I did unicode conversion.
Now in tcode SM21, all log messages are in unreadable characters.
I tried applying SAP Notes 688089 and 45580, but no use.
Pls give me some inputs on this regard
Thanks
Karthikeyan

Issue got resolved.
Have to delete a logfile generated OS level in global folder then restart the SAP instance.

Error with PS text after Unicode conversion

Hi, we are having problem after doing unicode conversion with special
character not displayed correctly in a Web interface. In SAP
(transaction CN04) everything is OK, but if the PS text is displayed
through a Web interface (BSP for instance) some characters are
displayed wrong. One of these characters is the apostrophe in French
language ('). Is there an available tool to perform a conversion of
existing PS text after performing unicode upgrade ?

Hima ... try this
http://<server>/Lighthammer/JCOProxy?Mode=Reset

Spanish display incorrect after unicode conversion

Dear Experts,
Currently we upgrade our SAP system from 4.6B NU to ECC6.0 UN.
in 4.6B system we had implemented Simple Chinese and French language package to the system. after upgrade to ECC6.0 no-unicode system. we perform a MDMP unicode conversion.currently system running with ECC6.0 unicode interface with language 1EFD. SUMG releated tasks had been finished. Chinese and French language checked OK in ECC6 UN system.
Our issue is. in the past time. some Spanish local end user typing some spanish character in some master date field when they login in 4.6B GUI choice english as login language.these kind of spanish characters could not display correct in current unicode environment.
could you please given us some suggestion for how to fix this issue.

Hello Anil,
Below items we checked between MDMP 46B and Unicode ECC6 with production client table SKAT. some Spanish display not correct.
Unicode ECC6.0     46B
Short Text     Short Text
Ant a prov - Gto imp     Ant a prov - Gto imp
Regal¨ªas     Regalías
Prov Herramentales     Prov Herramentales
Provisi¨®n de SLA     Provisión de SLA
Prov Fin Vida (EOL)     Prov Fin Vida (EOL)
Gtos de imp     Gtos de imp
Mat dañado o perdido     Mat dańado o perdido
Papeleria e insumos     Papeleria e insumos
Gastos Vtas-Diseño     Gastos Vtas-Diseńo
Ganancia p fluc camb     Ganancia p fluc camb
Aj anual p inf     Aj anual p inf
Depreciaci¨®n fiscal     Depreciación fiscal
Best Regards
Key

Wrong text in ADRC and LFA1 table after Unicode conversion

Hello,
We are doing MDMP to Unicode on SAP 4.7 system.
In post unicode activities,we had corrected the garbage characters in
table ADRC
by converting to target langauage ZH using SUMG t-code.
Condition used for addind table ADRC in SUMG is LANGU ='1' and
LANGU_CREA = 'EN'
But after converting and saving the data,most of the records have
incorrect character in word.
and text field of search term/company name/city in table LFA1 are also
wrong in correspond field in table ADRC.
Thanks
Harshavardhan

Hi Harshavardhan,
Assumption: You have Chinese entries in table ADRC with ADRC-LANGU_CREA = EN
Now you have to distinguish two problems:
1) Chinese texts are stored in ADRC fields, which are NOT used for search help texts (most of the fields - e.g. ADRC-NAME1):
These texts can be handled in two ways:
a) Change LANGU_CREA = EN to LANGU_CREA = ZH for these entries (e.g. where ADRC-COUNTRY = CN) before the Unicode conversion (by the way, I would not use ADRC-LANGU, since this is the communication language, which does not necessarily comply with the code page of the entry).
This needs to be done in a similar way as shown in z-reports described in SAP Note 634839 ( although this specific fool-the-system case is not covered there - you have to adapt those examples)
b) Use SUMG to repair the entries using language ZH (as you already did)
My favourite would be a), as this can be done before the conversion (Note that SUMG ineeds to be executed during downtime !)
2) Chinese texts are stored in ADRC fields, which are used for search help texts (e.g. ADRC-MC_NAME1):
a) If these entries were inserted / changed with logon language ZH, then point 1) applies
b) If users logged on with logon language EN and created the entries, then most of these texts are destroyed already in Non-Unicode system. Then there is no automatic repair possible (at least point 1 does not work). Here my statement from before is valid:
Those entries need to be generated again - e.g. if you do a dummy change on the name.
According to my knowledge, this is a manual effort (either before or after the conversion) - but maybe it can be automized ...
Best regards,
Nils Buerckel
SAP AG

Print Servers Impact after unicode conversion

Hi
We are performing an CUUC from 4.6C to ECC 6.0
Our customer has around 4-5 windows special print servers which are used for chinese, japanese, korean printing..etc.
After the upgrade & unicode conversion
- Do we still need to use all these 4-5 special print servers for each languages seperatly? or
- We shall consolidate all these print servers into one print server? Or
- We don't need to have any print servers, all the print queues can be pointed to unix print queues and then to the printers directly.
Kindly advise
Thanks & Regards
Senthil

I would think you could consolidate the print servers, but you still need the separate printers/device types in SAP. We use a single print server for EN/DE/ZH but have different SAP printers (usinging different device types) for EN/DE & ZH printers.

Corrupted Number Ranges After Unicode Conversion

Hello Gurus,
Has anyone had corrpted number ranges after UC conversion
After a Unicode conversion the number ranges are no longer valid?
We are doing a Unicode conversion from Informix to DB6 unicode on AIX.
Kind Regards
Lawrence Brown

Hi Lawrence,
I never heard from any Unicode conversion customer that number ranges did not work anymore after the Unicode conversion. Maybe the DB migration plays a role here ?
Best regards,
Nils Buerckel
SAP AG

DME file after unicode conversion

Similar Messages

Maybe you are looking for