On 21 Jun 2000 10:46:42 EST, the world broke into rejoicing as
Bill Gribble <[EMAIL PROTECTED]> said:
> After discussion with some of the other developers, it is becoming
> clear that most if not all of the problems people are having with
> rounding and fractional cents are because, in fact, gnucash does not
> know that there is a minimimum quantum of transactions for certain
> types of accounts. This is an attempt to lay out the problem and a
> possible solution. Please discuss.
>
> Bill Gribble
>
> ======================
>
> PROBLEM: gnucash does not take into consideration the possibility
> that a financial institution may not conduct transactions in fractional
> currency units.
>
> EXAMPLE: purchase 1 share of "foo" at 9 7/8 (9.875) from "bank".
> "bank" balance is displayed as -9.88 (which is correct). purchase 1
> more share of "foo" at 9 7/8 from "bank", in another transaction.
> "bank" balance is displayed as -19.75. This is incorrect, since it
> implies that the intermediate balance was -9.875 rather than (as
> was displayed) -9.88.
>
> In fact, the displayed value "-9.88" is rounded from the actual
> double-precision representation of the amount, -9.875. The transfer
> from the bank should have been, in each separate transaction, an
> integer number of pennies (localized appropriately) meaning that the
> bank balance should be -19.76.
>
> This demonstrates the way in which gnucash currently represents all
> quantities as double-precision floats and rounds these as appropriate
> *for display only*.
>
> PROPOSED SOLUTION: there must be account-type-specific (localized for
> currency) rules describing the minimum unit of transaction for a
> particular type of account and what to do with fractionally-unbalanced
> amounts. For example, it should be possible to restrict bank-account
> transfers to integer pennies but allow for fractional-cent balances in
> brokerage accounts if the brokerage handles the accounting in this
> way. QUESTION: what types of accounts have what types of
> transaction-quanta in the real world?
>
> SIDE EFFECTS: In the case described in the EXAMPLE, 9.88 should be
> transferred from the bank to purchase 1 share at 9.875. The remaining
> 1/2 cent must be accounted for.
>
> Accounting for the fractional amount:
>
> Alternative 1 is to add a split to the transaction which transfers the
> remaining fractional amount into an account designated for such
> things. For security accounts, this could be a "commissions" account,
> since the 1/2 cent is effectively a tiny commission on the
> transaction. This has the drawback of being confusing to naive users.
>
> Alternative 2 is to fractionally adjust the price per share to reflect
> the "true cost" of the shares purchased. In the EXAMPLE,
> price-per-share would be adjusted to 9.88, since the purchaser did
> have to transfer 9.88 to purchase each share, though the market price
> was 9.875. This has the drawback of having possibly surprising
> effects on the total value of holdings in an account. example:
> purchase 10,000 @ 9 7/8. total holdings == $98750. then purchase 1
> more at 9 7/8, price rounded up to 9.88, total holdings == $98809.88,
> an unexpected jump of $50.
Alternative #3.
The price is associated with the _TRANSACTION_, and not with the account.
Different transactions may occur at different prices, and it's _fine_
for them to have different prices.
I may buy stock today at a price of $25, buy more stock tomorrow
at $30, and buy even more stock the day after that at $27.50.
The true cost is not $27.50, nor is it some geometric mean thereof; the
true cost is $25, $30, and $27.50, for the respective purchases.
If we're talking about _VALUE_, as opposed to _COST_, then the purchase
provides us with a new _VALUE_ which may be corrected as needed. For
instance, in the above situation, we have several things happening
at once, that might be described thus:
Yesterday. Purchase #1.
10,000 @ 9 7/8 --> Cost = $98750.
This inserts a new price of $9 7/8, so that we have a
CURRENT VALUE of $98,750, which, not surprisingly, is the same as
the cost.
Today. Purchase #2.
1 @ 9 7/8 --> Cost = $9.88
This inserts a new price of $9 7/8 (_NOT_ $9.88), so that we have
a CURRENT VALUE of $98,759.875, probably rounded to $98,759.88
Valuation computation:
(let*
((units (+ 10000 1))
(latest-value (+ 9 7/8))
(totalvalue (* units latest-value))
(cost (+ 98750 9.88))
(netgain (- totalvalue cost)))
(display "Total Units: ") (display units) (newline)
(display "Total Cost: ") (display cost) (newline)
(display "Total Value: ") (display totalvalue) (newline)
(display "Net Gains: ") (display netgain) (newline))
The fact that the net cost gets rounded indicates that it is not
as suitable for determining the latest price as is a public report
of the actual latest price.
Note that in this computation, the balance is _not_ the result of adding
up values, with all the rounding discrepancies that may be entailed in
computing those individual values; it is the result of adding up UNITS,
and multiplying by their price.
In effect, in this stock account, the running "balance" is really
the number of _UNITS_ (e.g. - shares), and not the dollar value.
And that really is a true statement; if the prices vary, the
dollar value varies, but the number of shares in your portfolio
_DON'T_ vary.
Although that's only half the story; the other half is that you
do have another amount that needs to be tracked, namely the cost.
Which will be, in this case, $98,750.00 as well as $9.88. It is
unambiguous, but is pretty useless on an ongoing basis, when what
you care about is what the stock is WORTH, rather than what it
COST.
This sort of model is true for any account that tracks an asset or
liability...
--
[EMAIL PROTECTED] - <http://www.hex.net/~cbbrowne/>
Rules of the Evil Overlord #137. "Before spending available funds on
giant gargoyles, gothic arches, or other cosmetically intimidating
pieces of architecture, I will see if there are any valid military
expenditures that could use the extra budget."
<http://www.eviloverlord.com/>
--
Gnucash Developer's List
To unsubscribe send empty email to: [EMAIL PROTECTED]
