On Fri, Jan 17, 2003 at 11:35:42PM -0500, Derek Atkins wrote: > Ross Boylan <[EMAIL PROTECTED]> 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 > _______________________________________________ gnucash-devel mailing list [EMAIL PROTECTED] http://www.gnucash.org/cgi-bin/mailman/listinfo/gnucash-devel
