Rounding off problem.

[Geoffrey]

Mike or Penny Novack wrote:
> Abhinav wrote:
> 
>> Hi Everyone!
>>
>> We've been using Gnucash for all accounting purposes in our organisation 
>> for about two years now. And things have been going just fine!  :)
>>
>> Our accountant now wants us to round off figures. Basically if, the 
>> value entered is 20,000.33, he wants us to round this off to 20,000.00 
>> and if the value entered is 20,000.73 he wants us to round this off to 
>> 20,001.00. We need to do this on each entry in the journal - not just 
>> for the totals.
>>
>> Is there any way to configure something like this with gnucash? We're 
>> using gnucash version 2.0.5 on Debian (Etch).
>>
> Oddly enough, pretty difficult to implement. Since it seems that it 
> would be easy, I will explain the issue (back when I did this for a 
> living, often had to compute or correct a less experienced programmer's 
> "fuzz" value).
> 
> The problem is that when SEVERAL numbers are rounded off individually 
> the result of a mathematical operation involving them might not give the 
> same result as when you first perform the operation with unrounded 
> values and then round off the answer. The most obvious place this would 
> come into play is with "splits" where GnuCash would be deciding that 
> there was a (small) discrepancy. When I earlier referred to calculating 
> a "fuzz value that's what I meant -- for some PARTICULAR computation the 
> "difference error" which is to be ignored when deciding whether two 
> values are or are not equal (it can't be a universal value or actual 
> errors will be missed).
> 
> Here's an example. Suppose you have the following split:
>           account-a            1000.98
>               account-b                        500.49
>               account-c                        500.49
>     the transaction is in balance
> 
>           account-a            1001.00
>              account-b                        500.00
>              account-c                        500.00
>              imbalance                            1.00
>     the transaction is out of balance

I simply do not understand a situation where you would have 1001.00 
split to 500.00 and 500.00.  This is not a rounding issue.  I would 
expect to see 500.50 and 500.50 or some such.  I wouldn't expect to see 
rounding come into play unless we're talking percentages such as taxes 
or some such.  In that case you might have a split that generates 
500.499 and therefore rounding comes into play.

Bear in mind, I'm not an accountant, but your second example simply does 
not make logical sense in discussing a rounding issue.

> 
> Essentially you will have to do what your accountant wants by adjusting 
> the figures when entered. In the above example, either the account-b or 
> the account-c entry will have to be for 501.00 instead of 500.00 to keep 
> the split transaction in balance and which to adjust can't easily be an 
> automated decision. The computer has no way of "knowing" whether the 
> numbers you enter are the correct ones and so can't determine (when it 
> sees an imbalance) whether to "adjust" (randomly would prevent 
> systematic error) or report the imbalance as an imbalance error.
> 
> Understandable that your accountant might want the final reports "whole 
> dollar" but not so understandable at the "books" level as the whole 
> basis of error finding in "double entry accounting" is that the books if 
> correct are always in EXACT balance.
> 
> Michael
>         
> _______________________________________________
> gnucash-user mailing list
> gnucash-user at gnucash.org
> 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.
> 


-- 
Until later, Geoffrey

Those who would give up essential Liberty, to purchase a little
temporary Safety, deserve neither Liberty nor Safety.
  - Benjamin Franklin