[GNC] rounding of Invoice vs Accounts Receivable

[Michael or Penny Novack]

> @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 <rvklassen at 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