Hi Magesen,
I just tested this out in a 2009R2 W1 database, new company, all setups to default values, no invoice rounding. I get a different amount (LCY), but the amount is rounded down in this case... whether it's customer or vendor doesn't matter.
Digging deeper, I landed in the T330.ExchangeAmtFCYToLCY() function. Stepping through with the debugger shows that the amount without rounding (and according to the fp-precision used by the runtime) is 698771,674999999999. Using the "nearest" rule this rounds to 698771,67.
When you try the same in Excel, the fp-precision isn't enough to cause this. Also the handy pocket calculator doesn't produce this result... 3 decimals less accuracy than shown in the debugger.
So... the usual fpmath-inaccuracy by being more "accurate" than we usually verify... There is one (technical) catch in it, though: The currency factor is in this case 1 / 3.0695, stored in the fp-format. This will cause the first inaccuracy. Dividing the amount through the currency factor again adds the next one. And so the errors sometimes cancel each other out, sometimes not... leading to less and less usable decimals, the longer the non-rounded calculation gets.
with best regards
Jens