Applying a Discount with more than 2 decimals ends up in wrong calculation

[pannagger]

Hi folks,

We encountered an issue when applying a discount on a ZFItem with more than 2 decimal places, for example, "12.20040000" Euros. This number results from a discount on the document level divided by an odd quantity.

The problem occurs in:

mustangproject/library/src/main/java/org/mustangproject/ZUGFeRD/LineCalculator.java at Line 59.

Here, the setScale(..) method uses 2 as the new scale, which causes the total net amount (with other similar positions) to be 211.10 instead of 211.094000. After applying the VAT of 19% and rounding the result to 2 decimal places, the total becomes 251.21 instead of 251.20.

I recommend to adapt the mentioned line to use a scale of 18 like in Line 58.

Kind regards
Philip

[pannagger]

Update: we faced this Problem in many other places to, because the calculation uses setScale(2... all the time. It would be nice to have a possibility to set an option for this. To enable exact calculation results.

[jstaerk]

Hello,

1. the setScale should only happen on line level, where EN16931-1 explicitly requires a maximum of 2 digits
2. please include detailled steps to reproduce, such as a complete java source code listing, ideally with a complete XML
   thanks!

[djmj]

Hello,

first thanks for this library as i am testing it to replace the konic library i was using before.

This unnecessary rounding results in a common problem if the item price in databases are saved as gross (2 decimal digits) and setting the Item.price with the calculated net value (with more decimal digits) may result in multiple cent difference in the final invoice LineTotalAmount of <ram:SpecifiedTradeSettlementHeaderMonetarySummation> depending on the rounding error per item.

I also found this topic at this discussion: https://groups.google.com/g/zugferd/c/PEC77bEnWKQ

[jstaerk]

I'll close this issue unless someone gives me steps to reproduce. In terms of gross price calculation methods please note that it's not yet in the norm, and kosit suggests a workaround.