Stock trades and realized gains/losses

[Derek Atkins]

Ross Boylan <RossBoylan@stanfordalumni.org> writes:

> Actually, I got that.  What I may have missed is that there is no
> representation of a stock at all apart from the transactions.
> 
> My assumption was that the holdings in an account are stored
> somewhere, and that there are cash balances for cash accounts,
> commodity/stock balances for commodity accounts.  I don't know if
> that's true; perhaps it's only calculated from the transaction history
> as needed.

No, gnucash has no specific concept of a 'stock' per se.  A stock is
just a commodity (pretty much just like any other commodity).  For any
Split you have two values, the "amount" and the "value."  The "amount"
is the count of the Split->Account->Commodity; the "value" is the
count of the Split->Txn->Currency.

For a real-world example, let's say we have a transaction denoted in
USD, and this Txn contains a split to Stocks:SUNW which is denoted
in the commodity SUNW.  We can now determine from this split:
        1) the number of shares of SUNW transacted (amount)
        2) the value of those shares (value)
        3) the share-price (value/amount)

> If it is true that the total holdings are stored somewhere, it still
> strikes me that the problem is that a model that is sufficient for
> cash (namely, a number denoting total quantity) is not sufficient for
> stocks.  For those you need a richer model, one including basis and
> acquisition date (slightly more general concepts than cost and
> purchase date).

All accountains maintain a balance in the account commodity.  So,
you always know how many "shares" of a particular type you are
holding.

To follow the previous example, we can determine how many shares of
SUNW we have by looking at the balance of Stocks:SUNW.  That would
tell us we've got N shares in our account.

What we do not have, currently, is a good way to determine how much
we've spent on the stock, and how much profit we've made.

> I understand that the necessary info is available from the
> transactions; it's just that may be awkward as the only way to access
> it.  My thought is not that the problems can't be solved with lots; it
> is, rather, that there may be easier ways to solve them.

Well, there is the storage issue and the presentation issue.  The key
issue is making sure we store enough information such that we can
compute everything we need to.  The issue of presentation is secondary
-- once we have all the necessary information in the system we can
format it however we wish.

-derek

-- 
       Derek Atkins, SB '93 MIT EE, SM '95 MIT Media Laboratory
       Member, MIT Student Information Processing Board  (SIPB)
       URL: http://web.mit.edu/warlord/    PP-ASEL-IA     N1NWH
       warlord@MIT.EDU                        PGP key available