When I try to replace a field with a decimal value, I receive a Reject message with this text: "invalid integral value: 0.8", with SessionRejectReason=INCORRECT_DATA_FORMAT_FOR_VALUE.
In the fix dictionary the field type is PERCENTAGE, which should accept decimal values.
I tested with other fields that also are of type PERCENTAGE and there was no problem.
When i send a NewOrderSingle with a decimal value in that field, there is no problem, only when I try to send a replace.
That text is found in the IntConverter class in the convert method, but i don't know why is it being called only when i send a Order Cancel/Replace Request.
I'm setting the field like this: "replace.setString(30022, textValue);", I tried using setDouble and setDecimal and had the same problem.
What can I do to prevent that field form being converted to an integer?
Replace message: 8=FIX.4.49=31735=G34=349=SILICONBOVDEVEL0152=20240812-14:22:30.82856=SILICONBOVDEV1=32111=30022552721=438=100040=241=140438870644=1054=155=MBOTFBOV159=060=20240812-14:22:30.819111=1000847=10130022=0.830023=14:05:0130024=20:50:0030025=1030026=100030036=1030038=Y30057=0453=2448=935452=7448=TZINI452=3610=166
Reject message: 8=FIX.4.49=13135=334=349=SILICONBOVDEV52=20240812-14:22:30.93356=SILICONBOVDEVEL0145=358=invalid integral value: 0.8371=30022372=G373=610=181
Thank you.
The code on your side is not causing this... at least, not directly.
Based on the info you've provided, it looks like your code is creating valid FIX messages and sending them. It's the receiver that is trying to parse your 0.8 into an int; when that fails, it creates this reject message and sends it back to you.
So, I think there are two possibilities:
You have made a mistake, and 30022 should really be int. Double-check your docs.
Your counterparty has a bug where they're trying to erroneously parse tag 30022 as an int (but only in Order Cancel/Replace situations, per your description). Contact their support and be ready to supply this log snippet.