Proposal for modifying gnucash to use exact quantities

[Christopher Browne]

On Fri, 04 Aug 2000 11:16:49 EST, the world broke into rejoicing as
Robert Graham Merkel <rgmerk@mira.net>  said:
> Ben Stanley writes:
>  > In Australia, we currently have a curious system. The smallest unit of
>  > currency is 1 cent (AU$ 0.01), which is what bank accounts are kept in.
>  > However, the smallest coin is 5 cents. All cash transactions are rounded
>  > to the nearest 5 cents.
>  > 
>  > Thus, the denominator for your fractionalised representation must be able
>  > to cope with 1/100 for bank accounts, but 1/20 for cash accounts of the
>  > same currency, and be able to convert between them...
> 
> What I'd probably do, if you needed to account for this, is create a 
> "rounding errors" expense account.  If needs be, we can probably
> automate this process (certainly, if/when we add POS capabilities to
> gnucash, we'll need it for Australia).  
> 
> However, I would think that *most* of the time, just putting in the
> amount that you actually pay would be satisfactory.

Interesting situation.

I don't think it necessarily _needs_ anything terribly special to
cope with this.

There are two typical situations with transactions:

a) The transaction is issued using cheque/credit card, and goes through
   the bank.

   In this case, the amount is denominated in terms of "pennies," as
   with $AUS 123.47

b) The transaction is done using cash.

   In which case, it's _still_ done in pennies, just with a minimum
   granularity of $0.05.

Such amounts can coexist nicely; there's no problem with spending
$123.47, paid using a bank card, on groceries, and then with, shortly
thereafter, spending $5.50 in cash on groceries.

For all of this, GnuCash has no need for awareness of the $0.05 
granularity.  You record the amount spent, and if that is denominated
in single "pennies" or in groups of five, the system doesn't have
any need to care about this.

Where it _does_ matter is if there are more complex calculations to be
done, such as adding up an invoice, where, at the end, the amount might
need to be rounded to the nearest 5 cents.

But we don't have an "invoice calculator" yet, so that rounding does
not yet matter.

And I agree that taking the difference between the "exact" calculation
and the actual amount, and adjusting that to some sort of "rounding
revenue/expense" account would be pretty appropriate...
--
cbbrowne@acm.org - <http://www.ntlug.org/~cbbrowne/linux.html>
if (argc > 1 && strcmp(argv[1], "-advice") == 0) {
  printf("Don't Panic!\n");
  exit(42);
}
(Arnold Robbins in the LJ of February '95, describing RCS)