On Wed, 21 Jun 2000, Bill Gribble wrote:
> Richard Wackerbarth <[EMAIL PROTECTED]> writes:
> > As far as I know, EVERY account has a minimum transaction unit.
>
> Actually, that's the question. If every account has a minimum
> transaction unit, we need to enumerate what they are for every type of
> account that gnucash can deal with.
> I'll start: I hypothesize that
> banks don't do transactions in US Dollars with units smaller than
> $0.01.
AFAIK, that is true.
> Now you tell me about the limits on resolution of the number
> of shares in a mutual fund account.
That varies from account to account.
For example, I can buy stock for which I receive certificates only
in increments of 1 share. However, I can buy the same stock in the street
name in fractions of a share. At one brokerage, that fraction is 0.001 shares.
At another brokerage, it is 0.000001 shares for the same stock.
It all depends upon the policy of the brokerage.
Except for a few currencies, we cannot set things up in advance. The user
will need to be able to set the resolution on each account.
> > Alternative 3 is to just accept the transaction. It is an artifact
> > of gnucash that things must balance to floating point accuracy. The
> > reality is that the accountants consider it balanced when the
> > conversion error is within the roundoff error for the transactional
> > units.
>
> Are you kidding? Nobody just lets pennies drop off the face of the
> earth. Those fractional pennies are scrupulously kept track of by the
> bank, so why shouldn't they be kept track of by the user?
You do keep track of the pennies.
> In the example I gave, the brokerage probably a bought a hundred
> shares at 9 7/8 for $987.50, distributed 1 share to each person who
> bought one, charged them $9.88 each, and pocketed the 50 cents
> difference. Everyone's price was 9 7/8 (rounded to the nearest
> relevant unit).
Correct. At the time of purchase, they set their basis on the "lot" at
$987.50. As they sell them, they reduce the basis. They also compute the
average basis cost and report a portion of each sale as capital gains.
If they did this on each individual sale in sequence, the first sale would
show $0.00 gain but would reduce the average cost of the remaining 99 to just
less than 9.875. As a result the next sale would report a gain of $0.01 and
the average cost would again rise to 9.875. Over the course of 100 sales, 50
of them would report a capital gain of $0.01 for a total capital gain of
$0.50.
However, it is more likely that they would perform the calculation for a
group of sales which occurred in the same accounting period. Thus, if they
sold 11 units, they would compute a capital gain of $0.05 on those units and
adjust their basis in the remainder accordingly.
> It's not an "artifact of gnucash", it's an artifact of accounting. If
> what you paid is different from the total price of the items you
> bought, that money will end up in a third party's pocket, and it makes
> sense to record that. In any case, it *has* to be accounted for, even
> if the number that you're counting is smaller than 1.
No, that is not the way that it works. The accountants keep track of a "lot"
and the basis for the lot as a whole. They do not try to divide it out to the
individual units. When they sell a portion of the lot, they approximate the
cost of the portion which they then round to their accounting unit ($0.01)
and assign that exact amount to the portion and the exact remaining basis to
the remaining portion of the lot. Any difference in the assigned basis and
the selling price is reported as a capital gain. (or gross profit on goods
sold)
The key to understanding this is that you have an integral number of items
(100,000 milli-shares) and a basis (98,750 pence). You sell some (1,000
milli-shares) for a price (988 pence) and apportion that sale to cost (988
pence) and profit (0 pence). Eventually, it all averages out.
--
Gnucash Developer's List
To unsubscribe send empty email to: [EMAIL PROTECTED]
