It may not wholly be a GNC problem, but a vendor software problem.

Having entered numerous bills from Amazon and Costco recently, there have been 
a few cases where the sales tax did not match. This required an additional line 
item to adjust the sales tax to make the totals match.

Entering bills from some different places with different rates on the same 
bill, I gave up and entered it all with no tax and just added a line item at 
the end (I want able to discern which items were at which rate)

It would be a different problem if you were on the selling side and for 
whatever reason the state disagreed with your sales tax figures and thus what 
you owe them.

Alan

Mar 7, 2024 09:17:18 Michael or Penny Novack <stepbystepf...@comcast.net>:

> On 3/6/2024 12:49 PM, Carl Linkletter via gnucash-user wrote:
>> OK, Found the bug.  The problem is that the tax is totaled up using 
>> sub-penny calculations. That causes a 1.004 + 1.004 to equal 2.008 which is 
>> then rounded to 2.01.  Each line should be rounded to the penny first, then 
>> rounded up.  So if 1.004 is first rounded to 1.00, then that would cause 
>> this calculation to total 2.00, not 2.01.
>> 
>> If that makes any sense :-)  Guess I will enter a bug on this.
> 
> Does NOT solve the problem (rounding to the penny first). It is simply the 
> case that rounded(A) + rounded(B) /= rounded(A+B).
> 
> You have given an example where 1.004 + 1.004 would give 2.00 if rounded 
> first and 2.01 if rounded after adding. But how about 1.004 +  1.004 + 1.004 
> which would give 3.00 if rounded before adding and 3.01 if rounded after.
> 
> The problem is actually because of using "reals" to represent decimal 
> quantities. Now MY working days were spend with machines whose architecture 
> directly supported expressing decimals in BCD (binary coded decimal). But the 
> fact that our current CPUs don't directly support BCD representation and 
> arithmetic does not mean couldn't emulate that in software (in our higher 
> level language). Most of us using c++ are doing that so we don't have to 
> "roll our own" << c++ is actually a "pre-processor" for c >> Somebody like me 
> COULD come up with a BCD arithmetic package and I assume existing developers 
> could also.
> 
> The point is that people like the late Admr. Grace Murray Hopper (WWII 
> cryptologist, designer of COBOL) understood that using reals to express 
> decimals would have this problem and so used BCD for money amounts. That's 
> because intended for business and business implies money amounts. THEN 
> machine were made with architecture to directly support it.
> 
> Michael D Novack
> 
> PS --- BCD is essentially "integer" representation and math with the "display 
> amount" handling the editing to insert the decimal point. Now the only 
> arithmetic operation raising a rounding issue is division.
> 
> 
> _______________________________________________
> 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.

Attachment: smime.p7s
Description: S/MIME cryptographic signature

_______________________________________________
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.

Reply via email to