Stock trades and realized gains/losses
Matthew Vanecek
mevanecek@yahoo.com
10 Jan 2003 11:43:44 -0600
--=-GMPx139uY/zHJqU0PTEC
Content-Type: text/plain
Content-Transfer-Encoding: quoted-printable
There's a summary at the bottom..
On Fri, 2003-01-10 at 10:18, Linas Vepstas wrote:
> Hi,
>=20
> I think there is some confusion here; the lots system was deisgned to
> avoid both the confusion and the 'complex calculations'.
>=20
> > > > > come to as well. That conclusion is that we should be tracking t=
he
> > > > > dollar amounts of securities, relegating the quantities to an anc=
illary
> > > > > position (e.g., part of a Lot).
>=20
> False. You track the number of securities you own, and you track the
> current price. The value is just the product of these two. The
> underlying system works as before.
>=20
No, it's true. The value is purchase price +/- adjustments (if any).=20
Profit and sell decisions are based on (shares * current price) -
purchase price, with some extra math for adjustments to get the sell
transaction to balance. Net worth is based on balance of a stock
account, which is the accumulation of all the purchase dollar amounts
+/- dollar amounts of any adjusting transactions. The number of
securities I own is relevant when I calculate adjustments, of course,
and when making sell decisions.
To be clear, I'm not saying track one or the other--both share quantity
*and* purchase need to be tracked, but the balance of a stock account
needs to be calculated in terms of dollars, not quantities. That's just
(not-so-basic) accounting. ;)
> > > > gains/losses? The problem is that when you track the dollar-amount=
of
> > > > stock transactions you have to perform a lot of work to determine h=
ow
> > > > many shares you currently own. That means calculating Current Net
> > > > Worth is a lot of work.
>=20
> One must never track the value of the securities, as this is gaurenteed
> to give the wrong answer. One *must* track the quantity of securities
> owned. Net worth =3D=3D quantity * price and is easy to compute.
>=20
Yes you're right, yes, you're right, no, you misunderstand. Net worth
is *not* quantity * price. Net worth uses current balance, in general
accounting. If you *want* quantity * price, I'm certainly not opposed,
and would probably use it. However, both methods should be supported,
with the account balance measured in dollars (sum of purchases +/- sum
of adjusting transactions). As it stands now, there is no way to
logically put in an adjustment transaction, which comes from the
insistence of price * quantity, rather than actual cash expenditure. I
can't record an other than temporary change in the value without
recording a buy/sell, which is just...
> > but I still would like realized gain/loss in income/expense accouts bet=
ter,
>=20
> A realized gain/loss occurs only when a stock is bought/sold. There's
> supposed to be a split that goes into an income/expense account to=20
> record this gain/loss. (The absence of this split is one of the things
> that's broken about the current gnucash).
>=20
Which is why this *whhoooolleeee* thing started! ;)
> You have to have balancing transactions for both the quantity and the
> value. The use of LOTS is the mechanism that allows you to compute
> the correct gain/loss, since it allows you to figure out which shrs
> were sold, at which price (by specifically earmarking a set of shares
> out of a larger sea of them in the account).
>=20
> > > I'm not opposed to having an account per security--mainly because I
> > > don't have enough to make it annoying. That rapidly becomes unscalab=
le,
>=20
> Whoever wrote this misunderstood lots. See above. What we currently
> have is has been failing to scale for years. We need lots to be able
> to close books, and compute things like gain/loss.
>=20
If you extend Lots, then you could have one investment account per
currency you trade in. If you *don't* extend Lots, then you retain the
one-account-per-stock we currently have. In the long run, which way we
go is a trivial matter, and I cannot make a convincing argument to
change (even to myself).
> *Please* review the lots design document.
>=20
It's not that I don't understand them; rather, I was pondering on
different ways of doing things, and extending Lots was one (just one of
many) idea I had.
> However, you can display multiple stocks in one window. This is what
> the general-ledger widnow is supposed to be fore. I can't help noting
> that the general ledger window GUI layout is not ideal; this is a 'bug'
> that needs fixing, and is independent of accounting principles.
>=20
Yeah, 'specially=20
> > > > > Accountants generally are more interested in dollar amounts, not =
number
> > > > > of shares=20
>=20
> This statement couldn't be more wrong. If you don't count shares, and
> count value instead, its called "Fraud". Think "Lawsuit", "Judge", "Pris=
on".
>=20
Perhaps I wasn't clear in this statement. As I said above, I *do* know
you have to track both quantity and purchase value +/- adjustments.
> > I tend to agree. It is not absolutely neccessary that a stock register =
uses
> > the priceDB to show current value. This is only neccessary for the port=
folio
> > report.
>=20
> Huh? How else can you compute the unrelaized gain/loss in your account?
> The unreallized gain/loss is what gives you the "net asset value" or NAV!=
=20
> There is no other way of knowing a value.
An unrealized gain (loss) is calculated when an "other than temporary"
change in value occurs. Enron, for example, had an "other than
temporary" change. In such a case, you calculate shares * current new
price, and create an adjustment transaction to reflect the new value.=20
The balance of the transaction (loss or gain) is placed in the
unrealized gains (loss) account. Again, standard (not-so-basic)
accounting.
My issue is not that we track share quantity, but rather that we insist
the value of a holding is the immediate price * quantity. As you
mentioned (and I'm sure we all agree), we definitely need a split to
record a gain or loss. If we can get that, we're much closer than we
are now. I would *like* to get to a point where I can track my holdings
as I described--which allows for value adjustments, etc, and is much
closer to gaap than just having a gain/loss split. For example, if you
cannot make value adjustments, then how can you possibly record an
UN-realized gain/loss? I could be missing something there, though..
In any case, the most important thing immediately is to get the
gain/loss Split. I contend that becomes easier if we track the stock
account balance based on dollars. The share quantity is still in the
split, the purchase price is still in the split (amount & value).=20
Original share price can be retrieved via (purchase / shares). Current
price is in pricedb. So I don't really think there's a whole lot of
need for changing how the data is *stored*. I just would like to see a
change in the balance calculation and the (price * quantity
calculation)--make it optional for adjustment transactions, (or
something). I'd rather see the balance presented in dollars, as a sum
of all the purchases, instead of as a sum of share quantities.
But most important is the gain/loss split.
To sum up:
1) The current storage format seems OK, esp. since balances are
calculated dynamagically. At most, I think an additional
field in Split would be useful--shareBalance or
purchaseBalance, depending on how this discussion goes.
2) We definitely need a split for realized gains/losses.
3) I would like to see a stock account balance measured in
dollars, not quantities. This does not mean quantities
should be hidden. Perhaps an option to control this
would be acceptable. [if (x) calculateShareQtyBalance;
else calculatePurchaseAmtBalance;
4) I would like to see the register modified a little, to
allow for adjustment transactions which do not have a
share quantity (i.e., shares =3D=3D 0). This is useful
when recording permanent changes in a security's value.
5) re reports--perhaps we could include an option
to use either the current price, or the purchase balance,
depending on what the user wants.
And if you search the IRC logs, which can never be faked =3DP, you'll see
that HAMPTON has graciously volunteered to make all the changes we
decide on!!! (just kidding...).
Hopefully this clarifies my position a little. I really don't
understand how accountants deal with this crap all day every day!! ;)
--=20
Matthew Vanecek
perl -e 'print $i=3Dpack(c5,(41*2),sqrt(7056),(unpack(c,H)-2),oct(115),10);'
***************************************************************************=
*****
For 93 million miles, there is nothing between the sun and my shadow except=
me.
I'm always getting in the way of something...
--=-GMPx139uY/zHJqU0PTEC
Content-Type: application/DEFANGED-77; name="signature_asc.DEFANGED-77"
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.0.6 (GNU/Linux)
Comment: For info see http://www.gnupg.org
iD8DBQA+HwZQi/CNzDSN0RIRAvSNAJ45JncbH+X4Y5XDDmTruMnpvMimXgCgoQn0
X0TOEuT8ghln/ccKqxGkzWo=
=lg3a
-----END PGP SIGNATURE-----
--=-GMPx139uY/zHJqU0PTEC--