Application Development Discussions
Join the discussions or start your own on all things application development, including tools and APIs, programming models, and keeping your skills sharp.
cancel
Showing results for 
Search instead for 
Did you mean: 

bcd_baddata during interfacing...

Former Member
0 Kudos

Hi,

I am receiving a value NETWR in my RFC in 4.6 from VBRP table from ECC 6.0 via PI.

The value is perfectly passed from PI response as 17866.80 to RFC in 4.6.

But in 4.6 I receive it as 1786680<3.03.

Same is the issue with other currency fields NTGEW and BRGEW.

where as other currency field values are passed properly such as KZWI1 to KZWI6. (CURR 13, 2)

The currency NETWR field is 15, 2 and that is having some issue !!! Bcos of this my calculation fails and I get a dump BCD_BADDATA.

What cud be the problem ?

Hope i am clear.

thanks

Edited by: Vijay Babu Dudla on Jan 1, 2009 12:38 AM

13 REPLIES 13

Former Member
0 Kudos

Hey,

To add , I am facing this issue with QUAN field also which has size 15, 3...Looks the size matters here. Any tips ?

thanks

0 Kudos

I dont see any SAP ABAP issue in here.. the PI is sending the correct value but by the time it reaches SAP the value gets spoiled..

1. check if both the PI and SAP 4.6 data element or the field are same type Quant, Curr etc..

2. How are u pulling data from PI.. flat file, Idoc, Xml...there could be something here..during the transformation there might be some hexa decimal values which might be hidden, which we cannot see..carriage return or line feed etc..

3. Check the RFC destination etc...

0 Kudos

Thanks for your response.

Yes, both PI and SAP 4.6 have fields of exactly the same type. The RFC was imported into PI from 4.6 as it is and no changes have been done to the data type.

RFC adapter is used to interface between 4.6 and PI.

Also I noticed one thing. If a QUAN 13, 3 value received from PI into 4.6 is a smaller number say 21.99 then it is received as Packed decimal size 7 in 4.6 and the value is perfectly fine. But if the value is a bigger one say 12345.675 then it is received as Packed 8 and here is where the number is containing undesired symbol, i.e. '<'. i.e. this number changes to 12345675<3.03.

Any more suggestions ?

thanks

0 Kudos

Hi there.. there is sum limitation in using type p.. before in SCN there was one post I remember where type P variable cannot accept length more than 16 characters/bytes...

The maximum number of decimal places for a packed number is 14. To use the decimal places, the program attribute Fixed point arithmetic must be set, otherwise, the variables will be treated like integers. When you assign a value to a packed number, non-significant figures are rounded.

It is not currently possible to refer to generic data types in the DATA statement other than to generic standard tables without a defined key.

Example

DATA: text1,

text2(2),

text3(3) TYPE c,

pack TYPE P DECIMALS 2 VALUE '1.225'.

This example creates three character variables with lengths one, two, and three bytes respectively, and a packed number variable with length 8 bytes and two decimal places. If the attribute Fixed point arithmetic is set, the value of PACK is 1.23.

[....Info from SAP Help|http://help.sap.com/saphelp_nw04/Helpdata/EN/fc/eb3034358411d1829f0000e829fbfe/content.htm]

The valid length for packed numbers is between 1 and 16

bytes; two decimal places are packed into one byte, whereby

the last byte only contains one place and the plus/minus

sign; after the decimal separator, up to 14 decimal places

are permitted. Depending on the field length len and the

number of decimal places dec, the following applies for the

value area: (-10(2len -1) +1) / (10(dec)) to (10^(2len -

1) -1) /(10(+dec)) in steps of 10(-dec). Values in

between this range are rounded off.

0 Kudos

Thanks for the info...

Yes , Fixed point arithmetic checkbox is selected in 4.6 program !!

and the value I am dealing with is for e.g. 11265.12 which if I am right is less than 16 bytes of integer and 14 decimal places... Still when I receive it from PI in 4.6 RFC, I get this as 1126512.0<0

I appreciate ur endevour in suggesting all possible solutions.

Unfortunatly still my issue is unresolved !! Pl do let me know if u have any other suggestions.

thanks

0 Kudos

>

> The valid length for packed numbers is between 1 and 16

> bytes; two decimal places are packed into one byte, whereby

> the last byte only contains one place and the plus/minus

> sign; after the decimal separator, up to 14 decimal places

> are permitted. Depending on the field length len and the

> number of decimal places dec, the following applies for the

> value area: (-10(2len -1) +1) / (10(dec)) to (10^(2len -

> 1) -1) /(10(+dec)) in steps of 10(-dec). Values in

> between this range are rounded off.

Hi There,

And this Info from [Here|http://help.sap.com/abapdocu/en/ABENBUILT_IN_TYPES_VALUES.htm]

0 Kudos

Hi Amit how many points will you want to leave me on my own.. every post I did have ur comment..

is it some sort of tail gateing... US gov. don't allow tail gateing... so does SCN

Former Member
0 Kudos

If this is a batch input question, then you should know that you cannot pass currency or quantity fields. You have to use character fields instead.

Rob

0 Kudos

Hey Rob,

I am not invoking any BDC with this data...It is a simple Remote function call and I receive back the needed data from ECC 6.0 via PI. Leave the manipulation part, but in debugging mode when I see my internal table, I see only such weird values.

Find below my code snippet..

TYPES: BEGIN OF i_vbrp,

vbeln LIKE vbrp-vbeln,

posnr LIKE vbrp-posnr,

fkimg LIKE vbrp-fkimg,

ntgew LIKE vbrp-ntgew,

brgew LIKE vbrp-brgew,

netwr LIKE vbrp-netwr,

kzwi1 LIKE vbrp-kzwi1,

kzwi2 LIKE vbrp-kzwi2,

kzwi3 LIKE vbrp-kzwi3,

END OF i_vbrp.

DATA: vbrp_itab TYPE TABLE OF i_vbrp WITH HEADER LINE.

...

CALL FUNCTION 'ZRFC_FM' DESTINATION 'ZRFC_DEST'

TABLES

INPUT = XX_ITAB

VBRP = vbrp_itab

EXCEPTIONS

SYSTEM_FAILURE = 1 MESSAGE l_msg

COMMUNICATION_FAILURE = 2 MESSAGE l_msg.

COMMIT WORK.

INPUT passes some value to ECC and based on that I get back data in vbrp_itab.

So here is where I put a breakpoint and check and I see these weird values. I also checked the XML response from PI to 4.6 RFC and the values are perfect as shown below..

<vbrp>

- <item>

<VBELN>0910000203</VBELN>

<POSNR>000001</POSNR>

<FKIMG>4.0</FKIMG>

<NTGEW>11265.12</NTGEW>

<BRGEW>11265.12</BRGEW>

<NETWR>4224.42</NETWR>

<KZWI1>4224.42</KZWI1>

<KZWI2>4224.42</KZWI2>

<KZWI3>4192.56</KZWI3>

</item>

</VBRP>

But what I get is

FKIMG = 4.000 (this is fine, rest below are jumbled !! )

NTGEW = 1126512.0<0

BRGEW = 11265120<.4<4

NETWR = 422442<3.03

I have given all the info I have. Hope this helps you to analyze better.

thanks

0 Kudos

>

> I am not invoking any BDC with this data...It is a simple Remote function call

Then why the subject "bdc_baddata during interfacing..."?

Rob

0 Kudos

I guess it is BCD_BADDATA.

0 Kudos

Sincere apologies...It was a typo error...The title must be BCD_BADDATA....

thanks

0 Kudos

Converted all the currency and quantity data to string when sending from ECC to PI. And PI's receiver communication channel setting had to be set to Unicode. This issue is resolved. thanks .