[account] Rounding regression with invoices even in a basic case (5.0)

in Austria:
for supplier invoices the following has to be achieved
net, vat and total have to conform to the numbers on suppliers invoice.
currently only the total is checked to achieve matching values for - sometimes multiple rates - vat amounts is not self evident.
a more user friendly solution would be desirable

If the vat is not correct on the supplier invoice, how do you calculate periodical legal vat reports?

Hello,

Would you please start the server with price_accuracy option?

Thank you.

Hello,

I've tried with --price_accuracy=2 but still both the purchase order and the supplier invoice have the .39 tax amounts.

Hello,

I have checked your problem and it is solved by start the server with price_accuracy more then 2 (like --price-accuracy=4 ).

Hope this will help you.

Thank you.

I've tried your suggestion but only the purchase order's tax amount has been corrected to .40. The newly generated supplier invoice still has .39. The bug is still present.

Not to speak about the fact that in some places numbers with 4-digit fractional part popped up. 2-digit and 4-digit fractional part numbers mixed. One thing is that this looks very low-end. The other thing is that if I upgrade the database, OpenERP will store 4-digit fractional part numbers and that's not acceptable where the company uses only 2.

Hello Dukai,

We agree that there is no such digit precision specified on dynamic terms, its always a float if you do not define digits to the float field.

However, it has bee corrected by revision 2451 <email address hidden>.

Hope it helps.

Thank you for your patience everyone.

Thank you for all your effort.

I have re-thought the problem and now I consider reporting this bug as a mistake.

Reasoning:
Net total x Tax = .40 result
Sum(Subtotal x Tax) = .39 result

The .39 result (OpenERP's behavior) is the correct one because that is the result that can be achieved by adding up the line subtotals' taxes with a calculator.
The reference system I used in this case had the wrong calculation not OpenERP.

Sorry for the inconvenience.