Solman 4.0 RFC to Unicode systems not Unicode

[Former Member]

Generating RFCs out of SMSY will not put a Unicode-Flag in the RFC destination, neither in the three generated nor in the <solman>_BACK destination.

We recently converted all our non-UC systems to UC, does that now mean, that we have to adapt them manually in all systems and for all systems?

--

Markus

[former_member854227]

Why do you want to maintain these settings? Did you experience any problems related to these settings? Can you give us an example?

I had a look into the online documentation and this is what I found in the area "Settings for Special Code Pages".

AFAIK you usually don't need to maintain these flags. Only when the default assignment list for languages to code pages in MDMP systems does not fit your needs you need to maintain that.

For systems as off WebAS 6.20 and kernel patch level 375, i.e. all UNICODE systems, the system automatically finds the appropriate settings.

[markus_doehr2]

> Why do you want to maintain these settings? Did you

> experience any problems related to these settings?

> Can you give us an example?

Not as of now...

>

> I had a look into the online documentation and this

> is what I found in the area "Settings for Special

> Code Pages".

>

> AFAIK you usually don't need to maintain these flags.

> Only when the default assignment list for languages

> to code pages in MDMP systems does not fit your needs

> you need to maintain that.

>

> For systems as off WebAS 6.20 and kernel patch level

> 375, i.e. all UNICODE systems, the system

> automatically finds the appropriate settings.

No, that's true for external RFCs, that are built using the RFC-SDK 6.40 - but definitely not for data exchange.

Given the fact, that we have users in the R/3 backend system, that have no Latin-1 "Name" and "Surename" but chinese or russian characters. What will happen if I "Create businesspartners" using the non-rfc destination?

--

Markus

[markus_doehr2]

Additional info: I opened an OSS call for that, let's see what the support will tell me.

I migrated 5 MDMP systems each with 12 languages in the last 7 months from NUC to UC and that flag HAS an impact on data transfer.

If we do load data e. g. from an R/3 system into BI and that flag is NOT set to Unicode, all non Latin-1 data (everything but ASCII 7-bit characters to be exact) will become corrupted, so you won't have any äöü, and even not polish/hungarian diacritics nor russian and/or chinese characters.

Since all systems beyond ERP 2005 will be Unicode only it's crucial to have those settings correct - or either omit that tab completely if they are not necessary

--

Markus

[former_member186439]

We had a Unicode RFC destination problem. Unfortunately, all I can seem to remember is that it had to do with the "Landscape Fetch" job pulling landscape data from SLD. If my memory is correct, that would mean that it was the SAPSLDAPI RFC destination that had the problem.

[markus_doehr2]

> We had a Unicode RFC destination problem.

> Unfortunately, all I can seem to remember is that it

> had to do with the "Landscape Fetch" job pulling

> landscape data from SLD. If my memory is correct,

> that would mean that it was the SAPSLDAPI RFC

> destination that had the problem.

Thank you for the hint!

There exists two of them, one UC and one NUC, I wonder, which one is picked.

However, in that special case the system was created from scratch without using SLD so that can't be the reason (I at least assume that).

--

Markus