Language input incorectly for TABCAT1 tables

[Former Member]

Dear Gurus,

We are performing Unicode Conversion for SAP ECC system by using CUUC approach. Project team successfully delivered Sandbox system, and we found a big issue for TABCAT1 tables which have language key information.

Let me describe it in detail:

System is configured as EN/ZH(Simplified Chinese)/ZF(Traditional Chinese).

Here is an scenario, for example, in EN form, user input Simplified Chinese in that form. We know form is language dependent and get its language key. During unicode conversion, system translate those text from 1100 to Unicode, but unfortunately, Simplified Chinese is out of 1100 range, which can not be transfer to Unicode correctly.

We've got another scenario, for example, material Basis view information is stored in STXL table which also gets language key, some user also input Chinese in EN key.

So here is the question:

1)  Is there a way to check the mismatch between language key and text, for example, if language key = 1100 but text includes Chinese, than it should be selected out.

2) If a customized report can be developed for this purpose, how long does it take? For sandbox, it takes about 7 days with 5 parallel run for SPUMG scans (7 steps)

3) How to correct this error? The possible solution could be:

3.1) Change before unicode conversion. The challenge is we need know all those mismatch then we get back to application/business team to fix one by one.

3.2) Change after unicode conversion. Such as SUMG and report UMG_ADJUST_STXL. Challenge for SUMG: it can not records the change which can be used for PRD conversion. Challenge for UMG_ADJUST_STXL, we need find the solution one by one (form, material, etc...)

3.3) Change during unicode conversion. We confirm there are only ZF/ZH languages are used from biz point of view. 95% of them is ZH. If we set EN.1100 to ZH.8400 for all TABCAT1 tables, then MOST of those error can be avoided. The Challenge is we do not know how to control this as SPUMG will not process TABCAT1 tables. In addition, does it cause other issue, such as German language issue (even we NEVER care German language).

Thanks for any advice in advance.

James

[nils_buerckel]

Hi James,

I would recommend to set EN as ambiguous language in SPUMG. Then the EN entries in the language dependent tables are treated the same way as entries in  language independent tables. Hence all the Chinese data will end up in the vocab and you can assign them the same way as the other entries in the vocab.

However this means you need to repeat the SPUMG scan (you can of course reuse e.g. vocabulary).

As far as I know, this is the only way to resolve your problem properly ...

Best regards,

Nils Buerckel

[Former Member]

Thanks Nils for your prompt recommendation!

We understand this approach, but we have some more questions:

1) "all Chinese Data will end up in the vocab", will all EN (or very few ZF data) in those fields will end up in the vocab as well?

2) More data will end up in vocab, this will cause longer vocab maintenance time, this is easy to understand. The questions is does it cause a longer SPUMG scan time as well?

3) Is there a flag which will indicate those data comes from ambiguous EN field?

4) "this is the only way to resolve your problem properly", my understanding is that this approach solves the problem on system level for all scenarios. If we keep our current approach, we must find solutions for all scenarios one by one, such as form, material, etc, that is impossible in a short period, is my understanding right?

I am OK for this approach for ZH/ZF language in EN field. One more question:

5) Does this error apply to ZH in ZF filed, or vise verse?

We've got 20T database, 8M vocab without language key (2M after duplicated filtered), 200,000 with manual assignment. We need treat the challenge carefully.

Thanks for your advice in advance.

James

[nils_buerckel]

Hi James,

1) this is the same as for all language independent tables - words containing Non-7-bit-ASCII data are added to the vocab. Hence words without special characters (most EN words do not contain special characters) do not reach the vocabulary. For you this basically means, that ZH and ZF words will end up in the vocabulary.

2) Yes, SPUMG times will also increase (SPUMG has to scan language dependent data with language key EN).

3) Yes. Entries from ambiguous language scan do have "filled by" = A attribute once they are added. However this will be e.g. changed to M once the word is assigned manually.

4)Yes, I think this is correct. In addition there will be a high probability that you miss same wrongly converted data and find it later when the converted system is already productive.

5) No. This approach is restricted to entries with language key EN. If you would like to find ZF words in ZH entries, you would need to set ZH also as ambigous. However this will likely "blow up" the number of words in the vocab and therefore I strongly recommend to not set ZH as ambiguous !

Due to the fact that you need a lot of time for every trial scan I would recommend to really think about any changes you make in SPUMG. This might include to engage an experienced consultant who has done this with large systems.

Best regards,

Nils

[Former Member]

Dear Nils,

After deep analysis, I have to say some information I provided above is not exactly correct.

Basis administrator has set OS/EN/Country=Null codepage to ZH/8400 in year of 2008, which means if client login with EN, codepage data input and data convert is Simplified Chinese! In short, we force treat EN as ZH. So, I do NOT think set EN as ambiguous is helpful. Sure, if there is 8300 char in EN field, this can help to manually assign those word as ZF, anyway, this is not a normal situation, or we can convince biz to accept this because those words are corrupted in source non-unicode.

So far the corrupted words are found for below scenarios:

1) Text in Index Table, for example, form in STXL. SAP provides UMG_ADJUST_STXL to find this kinds of issue.

2) Incorrect maintenance of long text, such as MM01 for material (or FS00 for GL account). For example, the master data owner maintain the description of material for both ZH/ZF, but in tcode MM01, the description was copy+paste from one(ZH) to another(ZF). In this situation, the screen in MM01 is correct but actually, when user login to ZF in Non-Unicode, the master data description in ZF is corrupted. We realize this can only be correctly in source system.

Based on above facts, we decided NOT to add EN as ambiguous language.

Will update any change....

Thanks again for your kind help.

James

[nils_buerckel]

Hi James,

yes, I agree - in this case it does not make sense to set EN as ambiguous.

I guess issue 2) needs to be corrected manually (SUMG can probably not help) ...

Best regards,

Nils

[Former Member]

Thank Nils, Points rewards.

We are performing 2nd round CUUC now.

Other unicode questions will be posted separately.