wm.b2b.edi.util. formatServices:formatN2

Hi,

I am attempting to send out a tradacoms invoice. The values mapped to the document are acurate up until I use the service …

[SIZE=2]WmTRADACOMS.wm.b2b.tradacoms.Util:convertToString with the schema : WmTRADACOMS.wm.b2b.tradacoms.TRADACOMSSchema.TRADACOMS:INVOIC.
Some of the values that are returned as a string are then incorrect. It needs to run this service to format the transmission file correctly for sending, and up until now it has worked fine.
For example, in the second MHD.STL14, STL15 and TLR11 and TLR12 in this file go into the service as 1159.34 and come out as 115933. They should be 115934.
Also the same happens in the third MHD.VRS07 and VRS08, and in the fourth MHD.TOT04 and TOT05
I have looked at the schema and on these fields (and on quite a few of the others) it uses the formatting service : wm.b2b.edi.util.formatServices:formatN2.
I have tried running this service and just giving it random numbers to see if they come out correctly and as long they are already rounded to 2dp (anything more just gets truncated), most of those I tried are fine, but I have also received some ‘strange’ results.
115.34 is correct 11534
1159.30 is correct 115930
1159.31 is correct 115931
1159.32 is correct 115932
1159.33 is correct 115933
1159.34 is incorrect 115933
1159.35 is incorrect 115934
1159.36 is incorrect 115935
1159.37 is incorrect 115936
1159.38 is correct 115938
1159.39 is correct 115939
1159.40 is correct 115940
1159.41 is correct 115941

Has anyone else come across this ? If so any ideas how to resolve it ?

Thanks,
Janet
[/size]

That service uses java.text.DecimalFormat. That class converts strings to doubles. Then the formatN2 converts that to the implied decimal string.

IMO, the problem here is the use of double by DecimalFormat. As mentioned in other threads, using floating point representations can lead to inaccuracies such as the one you’ve encountered.

I’m not sure what work-around you could use to correct this. The real solution is for the formatting services to not use classes that use floats/doubles. Dunno if wM is ready to do that or not.

Thought of an approach to work around the issue: Disable the formatting that the EDI module provides (edit format.xml following the info in the EDI docs); format each of the fields you need within your transformation services (avoiding the use of float/double of course).

the problem is now resolved. we applied cumulative fix pack 28 for WmEDI and all appears to be ok so far. thanks.

Janet,

Thanks for update.and good to know about that a fix exists for this problem,certainly will help others in need.

–RMG.