Stock trades and realized gains/losses

[Ross Boylan]

On Fri, Jan 17, 2003 at 11:35:42PM -0500, Derek Atkins wrote:
> Ross Boylan <RossBoylan@stanfordalumni.org> writes:
> 
> > I have a few comments on the discussion.
> > 
> > 1.  Might it be useful to look at the problem as being one of getting
> > the correct model of a stock?  Specifically, shares of stock and other
> > commodities in the current system have only a price and quantity.
> > This is not really sufficient: one needs the purchase date and basis.
> > Basis include price and sometimes transaction costs.
> > 
> > At least in the US, basis is the relevant thing for taxes, and the
> > purchase date affects holding period and thus the tax rate.
> > 
> > If I understand lots, they permit getting this information, but they
> > do not directly add it to the data model for stocks.  If the
> > information were directly available, it seems to me a lot of the
> > problems would get much simpler to solve.
> 
> Unfortunately you are a bit confused.  The purchase transaction
> contains: number of share, value of purchase, date of purchase,
> and if you want you can add other splits for, say, txn fees to
> compute the basis.  So, all this information is already there.

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.

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

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.

> 
> That's not the problem.  The problem is (and always has been)
> tying the purchase transaction to the sale transaction.

Many interesting questions arise before a sale occurs, and there needs
to be a way to answer those.

If the system had a rich representation of a stock, it could naturally
track its sale date and price as well to manage post-sale queries.

> 
> -derek
>