Hello All!!
A detailed explanaton of the problem is below:
We call BAPI_MATERIAL_GET_DETAIL from a non-Unicode program using LibRfc32.
If MATL_DESC (the first field in structure BAPIMATDOA) contains only Western-language characters, everything is fine. LibRfc returns a string built from the correct number of bytes (MATL_DESC: 40 bytes, OLD_MAT_NO: 18 bytes, MATL_TYPE: 4 bytes, IND_SECTOR: 1 byte, and so on).
If MATL_DESC contains Chinese characters, LibRfc return a string with the same structure as in the first case and this is wrong due to the fact that even in non-Unicode programs Chinese characters consist of 2 bytes, one lead byte and one trail byte. In the extreme case for instance that a text consists of 40 chinese characters, MATL_DESC must be 80 byte in size.
LibRfc cuts fields MATL_DESC after exactly 40 byte, so a text containing 40 chinese characters is truncated after the first 20 Chinese characters.
You can see this happening in LibRfc32 trace files if the non-Unicode language is set to Chinese (Taiwan).
This is my analysis of two traces. The first one has an English description only. The second one has a mixed description Chinese + English.
000000 | 05000000 05000503 00000503 05140010 |................|
000010 | 2E7259EC 68555843 AFFA3173 385AFA2E |.rY.hUXC..1s8Z..|
000020 | 05140512 00000512 02010011 4D415445 |............MATE|
000030 | 5249414C 504C414E 54444154 41020102 |RIALPLANTDATA...|
000040 | 03000631 31302020 20020302 0100154D |...110 ......M|
000050 | 41544552 49414C56 414C5541 54494F4E |ATERIALVALUATION|
000060 | 44415441 02010203 00245600 00000000 |DATA.....$V.....|
000070 | 00000002 53800C00 00000000 00000000 |....S...........|
000080 | 00000C01 000C524D 42202043 4E590203 |......RMB CNY..|
000090 | 02010015 4D415445 5249414C 5F47454E |....MATERIAL_GEN|
0000a0 | 4552414C 5F444154 41020102 03019E20 |ERAL_DATA...... |
0000b0 | 43415254 4F4E204C 41422D49 5236392D |CARTON LAB-IR69-|
0000c0 | 30372848 3339392D 302D4330 30303129 |07(H399-0-C0001)|
0000d0 | 31352E32 4B475320 20202020 20202020 |15.2KGS |
0000e0 | 20202020 20202020 20524F48 20453430 | ROH E40|
0000f0 | 31313030 30362020 20202020 20202020 |110006 |
CARTON LAB-IR69-07(H399-0-C0001)15.2KGS
20434152544F4E204C41422D495236392D303728483339392D302D43303030312931352E324B4753 202020202020202020202020202020202020 524F4820453430
C A R T O N L A B - I R 6 9 - 0 7 ( H 3 9 9 - 0 - C 0 0 0 1 ) 1 5 . 2 K G S R O H E 4 0
MATL_DESC : 40 bytes
OLD_MAT_NO: 18 bytes (spaces)
MATL_TYPE: 4 bytes
IND_SECTOR: 1 byte
000000 | 05000000 05000503 00000503 05140010 |................|
000010 | E52D4DE7 5D07BC47 B22D7AFB 4AA3C62E |.-M.]..G.-z.J...|
000020 | 05140512 00000512 02010011 4D415445 |............MATE|
000030 | 5249414C 504C414E 54444154 41020102 |RIALPLANTDATA...|
000040 | 03000637 30352020 20020302 0100154D |...705 ......M|
000050 | 41544552 49414C56 414C5541 54494F4E |ATERIALVALUATION|
000060 | 44415441 02010203 00245300 00000000 |DATA.....$S.....|
000070 | 01084906 00000C00 00000000 00000000 |..I.............|
000080 | 00000C01 000C524D 42202043 4E590203 |......RMB CNY..|
000090 | 02010015 4D415445 5249414C 5F47454E |....MATERIAL_GEN|
0000a0 | 4552414C 5F444154 41020102 03019EA4 |ERAL_DATA.......|
0000b0 | A3F9D7BF FBA4F92D A4ADAAF7 A5F3BCD2 |.......-........|
0000c0 | A8E328A5 5DC3E429 20202020 20202020 |..(.]..) |
0000d0 | 20202020 20202020 20202020 20202020 | |
0000e0 | 20202020 20202020 20464552 54453130 | FERTE10|
0000f0 | 37303530 30312020 20202020 20202020 |705001 |
不銹鋼片-五金件模具(包邊) 䕆呒ㅅ㜰㔰〰‱u2020u2020u2020u2020
A4A3F9D7BFFBA4F9 2D A4ADAAF7A5F3BCD2A8E3 28 A55D C3E4 29202020202020202020202020202020 202020202020202020202020202020202020 46455254453130
不 銹 鋼 片 - 五 金 件 模 具 ( 包 邊 ) F E R T E 1 0
MATL_DESC : 40 bytes (8 + 1 + 10 + 1 + 4 + 1 + 15)
OLD_MAT_NO: 18 bytes (spaces)
MATL_TYPE: 4 bytes
IND_SECTOR: 1 byte
MATL_DESC : 40 bytes (8 + 1 + 10 + 1 + 4 + 1 + 15) this is a problem since
MATL_DESC = 14 characters plus 15 blanks = 29 characters. This means 11 blanks are missing!
LibRfc create BAPIMATDOA structure built from 40 + 18 + 4 + 1 + ... bytes
In case of Windows code pages with 2-byte characters (lead byte + trail byte) like Chinese, all string containing chinese characters must be longer according to the fact that Chinese characters are built from 2 bytes even in non-Unicode.
In this concreate example MATL_DESC must be built like this: 51 + 18 + 4 + 1 + ... bytes
LibRfc cuts MATL_DESC after 40 characters regardless of the language used.
Is there any way to get the entire 80bytes that we require?