@Michael, you pay VAT on the total invoice, but both items already have the VAT
included on the item line. So the rounding happens at the total level. Else you
get too big rounding errors (especially supermarkets when you have 9%
categories and 21% items (e.g. rounding a 9% tax on a 49ct can of tomatoes is
terrible with a full basket), they have to round on subtotals per tax category.
On 17 Oct 2022, 23:30 +0200, R. Victor Klassen <rvklas...@gmail.com>, wrote:
Misunderstanding.
Look, the problem is NOT a gnucash problem. It is NOT a "rounding"
problem. It is a "politicians are not mathematicians" problem.
The politicians are free to pass legislation saying:
1) VAT will be figured for each item based on the cost of each item.
2) VAT for the total sale will be based on the sum of the cost of each
item. This total is what the customer is expected to pay.
3) The sum of all in "1" will be the same as the total from "2"
The problem is that this legislation is mathematically inconsistent. "3"
is not going to be true. It is untrue not because of a rounding error
but the reality that (rounded A) plus (rounded B) is not necessarily
equal to rounded (A plus B). In other words, you cannot expect to add up
a series of rounded terms and have that sum be equal to the the terms
added without rounding and the sum then rounded. The operation "round"
lacks the property "distributive" with respect to the operation "add".
Example --- the operations addition and multiplication have the property
"distributive" so x(A+B) = xA + xB But the pair of operations "round"
ans "+" do not have this property. Distribution is a property that a
pair of operations may or may not have.
Michael D Novack
_______________________________________________
gnucash-user mailing list
gnucash-user@gnucash.org
To update your subscription preferences or to unsubscribe:
https://lists.gnucash.org/mailman/listinfo/gnucash-user
-----
Please remember to CC this list on all your replies.
You can do this by using Reply-To-List or Reply-All.
