Proposal for modifying gnucash to use exact quantities

Gordon Oliver
Thu, 27 Jul 2000 21:48:30 -0700

Hi all.
  One commentary that I would have with exact values is that
in this (and any I imagine) accounting scheme we are representing
one side of the story, i.e. we don't care what the other guy discounts
from the inventory, we care about 2 things
  1) How much (of commodity X) we gave away.
  2) How much (of commodity Y) we recieved.
The price, though interesting, is not relevant to the accounting per se.
It should always be calculated based on the commodity out vs. the
commodity in. In the event that the current value is wanted, it will
always be an approximation (the value of a given commodity is never
known till it is actually sold).

  Can anyone come up with a reasonable condition under which an
account would have arbitrary precision associated with it? Gasoline
is probably not a good one, as the units pumped in and out have
fixed precision (with a built in error), and any differences would be
attributed to loss/gain by evaporation (yeah, gain is actually the
oops we stole from the customers).

  If there are no reasonable conditions for this, then each account would
have a fixed denominator, and the math within the account becomes simpler.
There is however a hiccup, which is in the case of transfering commodities
from one account to another, there may be an arbitrary precision loss. What
gets done with that? (Note that this can only occur in the case of arbitrary
and different denominators for accounts denominating the same commodity,
which seems painful at best)

  The other approach is to provide a single precision for a given commodity/
currency. I.E. you can only transfer dollars from one account to another in
units of 1/100 of a dollar, and you can sell wheat down to 1/64 of a bushel
(as arbitrary examples).

   Before we all lose track. The basic argument I am making is that we do
_not_ need to represent price exactly. It is an intermediate value that has
no real relevence to the accounting...