Stock trades and realized gains/losses

[Matthew Vanecek]

--=-VEnFghdWGEHXXhSkvIcW
Content-Type: text/plain
Content-Transfer-Encoding: quoted-printable

Most of the below concerns were addressed in other posts, but what the
heck...as always, the good conciliatory stuff is at the bottom. ;)

On Fri, 2003-01-10 at 12:39, Linas Vepstas wrote:
> Hi,
>=20
> caution: very long note. that, and I was rather irritated as I wrote it.
>=20
NP

>=20
> > > > Assets
> > > >     Cash
> > > >     COI
> > > >=20
> > > > Income
> > > >     RG(L)
> > > >=20
> > > > Account         Debit   Credit      Bal
> > > > ------------------------------------------
> > > > Cash                    100         (100)
> > > > COI             100                 100    <--- 10 shares @ $10
> > > > ------------------------------------------
> > > > RG(L)                   100         100
> > > > Cash            200                 100    <--- 10 shares @ $20
> > > > COI                     100         0
> > > >=20=20
> The above example misrepresents how gnucash currently works.
>=20
It's not a representation of how Gnucash works.  It's a representation
of how (simplistically) to account for stock purchases/sales.

> > > The problem with this model is that while you can easily track the
> > > gains/losses, you cannot track the "current value" of your holdings.
>=20
> Huh?  the current value of your holdings equals the number of shares
> times the current price.
>=20
> value =3D quantity * price.

That equation is incorrect in accounting terms, unless you're getting
very quick turnaround on the stock (e.g., day traders).  I've explained
that in other mails.

> The quantity of shares that you own is the balance of the account!=20=20
> That's what the words 'current balance' mean!

That is also incorrect in accounting terms.  For longer-term holdings
(months, quarters, years), the balance of the account is the sum of the
purchases + sum of the adjustments.  That's proper accounting, also
addressed in other posts.

> ?? This is off topic.  Gnucash doesn't condon C++ style subclassing=20
> because C++ subclassing is a massive headache for the writers of=20
> the storage backends, never mind for the writers of the scheme reports.
> We provided the key-value pair mechanism precisiely to avoid the=20
> problems of C++ subclassing.
>=20

I disagree, but like you say, off-topic.

> > Or extend the Lot instead of the Split (probably an
> > easier direction, but I haven't looked at it too hard).  Create a
> > StockLot, and InventoryLot, etc.  The Lot has some basic functionality:
> > extend it.  That's one of the key principles in OO A & D.
>=20
> No.  This is one of the key reasons why languages like C++ are broken.
>=20

Again, I disagree.  For development, OO is a great wonderful thing.  Not
necessarily C++, of course, but OO itself.  I prefer Java to C++, as it
avoids mostly the "recompile and reinstall a million clients" problem
you mention (which part I deleted).  Anyhow, different philosophy and
off-topic.  Still interesting, though. :)

> > you do.  The values used in net worth should be based on the recorded
> > purchase cost, plus or minus any adjusting transactions for unrealized
> > gains (loss).=20=20
>=20
> I don't get this.  How do you plan to record a transaction for
> unrealized gain?=20=20
>=20

Simple: Decrease dollar value of stock account, increase dollar value of
unrealized loss account, or vice versa for a gain.  This is where the
adjustment transaction comes in.  Standard accounting practice,
according to gaap.  Of course, this is currently impossible to do in
Gnucash.

> Stock accounts do not have currencies.  This is an old and broken=20
> pradigm left over from gnucash-1.2/1.4 which is supposed to be=20
> eradicated real soon now.
>=20

They *should* have currencies. It's not broken at all.  What's broken is
that I cannot look at my stock account and see how much money I've
invested in that account.  I can look at my bank account and see the
balance, as well as at my House asset account.  Shares * price does NOT
give me an idea about how much I've invested--it only tells me that at
this particular time, if I sold my stock, I could get (shares * price)
money for them.


> > Each transaction should be balanced monetarily.  This is possible if you
> > track the balance in currency instead of shares, and track the purchase
> > cost vs. today's volatile market price.=20
>=20
> Which balance? the account balance or the transaction balance?  the
> account balance is always expressed in shares.  The transaction balance
> is always valued 'monetarily', in the transaction currency.
> The GUI register should show balances in *both* shares, and in some
> arbitrary currency R, the 'reporting currency'.

That would be great, if the register showed both balances.  It doesn't,
though, which is one reason this whole discussion is happening (along
with the lack of a split for gains/losses).

> >  Record the number of shares and
> > price as we do now, and offer a warning if price * share !=3D
> > debit/credit.=20=20
>=20
> ??? why is this a warning??  This is eactly the definition of unrealized
> gain/loss !

Because, as I've said before, the current implementation prevents me
from entering an adjustment transaction and maintaining an unrealized
gains/loss account.  If I have an unrealized loss, it means that the
value of the shares has decreased, not the quantity.  And I cannot show
that currently.

This seems to all be based on differing philosophies about stock
valuation.  You and a some others wish to see a minute-by-minute
valuation of stock, and to always see the most current monetary value in
the reports.  Others (like myself, but I know I'm not alone) wish to see
a more gaap-aware method of maintaining the purchase balance, and making
occasional adjustments when a permanent value change has occurred (for
example, like when Enron bailed).  I don't think it would be too
difficult to do both.  I mean, we already have to implement the
gain/loss split and Lots GUI--going a little further wouldn't hurt.  And
like you mentioned in another post, it's more about presentation than
about the data itself (with the exception of adjustment transactions
that aren't available).

--=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...

--=-VEnFghdWGEHXXhSkvIcW
Content-Type: application/DEFANGED-28204; name="signature_asc.DEFANGED-28204"

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.0.6 (GNU/Linux)
Comment: For info see http://www.gnupg.org

iD8DBQA+HyS5i/CNzDSN0RIRAtSaAJ9o+B4Dukb8lv8zP1OGwJj87XHeLACcCOCp
aw42Qsa3wU17sAC3yWBp7wc=
=lL5/
-----END PGP SIGNATURE-----

--=-VEnFghdWGEHXXhSkvIcW--