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. Managing Your Money and, I assume, Quicken record holdings with the original price and purchase date as far as I can tell from the user interface. 2. From the user's point of view, every sale may not be associated with a particular purchase. This is so if they use average cost accounting. I believe there are two permitted variants in the US depending on whether you average everything or just within long and short term holdings. Of course, other users may wish to associate every sale with a specific purchase. Ideally, the program could cater to both groups. I mention the first because they may find the model underlying lots unnatural. By the way, the one function I have missed in Managing Your Money is "sell so as to maximize or minimize capital gains." 3. If you sell shares and buy them back it is a "wash sale" and does not count for tax purposes in the US. As I recall, there is a 30 day window on either side of the sale in which purchases can wash (i.e., a sale can not count because of a previous purchase). (I just wanted to correct some earlier misinformation--it's not directly relevant to program design unless we want to think about tracking this as well!) By the way, forcing people to perform phantom sales for purposes of the program is not friendly (I'm not sure that was proposed, but some comments seemed to hint at it). 4. My mutual funds indicate a dollar value of a transaction, a price and a quantity. But sometimes value <> price * quantity because of a small rounding error. It is definitely the number of shares, not their value, that is "real" as far as the mutual fund is concerned (though, of course, the money they take for the purchase is quite real too!). I bring this up first because it may have some relevance to the debate over whether accounts should be in currency value or share quantities (it's an argument for quantities) and second to alert you to an unpleasant possibility the program should be able to handle. 5. There might be hiding in here some more general question of tracking things. For example, retirement accounts may have a mix of pre and post tax contributions; Roth retirement accounts have different aging buckets; (see also points 2 and 3) ..... It seems unlikely that the program could or should incorporate all such possibilities, but it would be nice if it had an architecture that made adding them possible. _______________________________________________ gnucash-devel mailing list [EMAIL PROTECTED] http://www.gnucash.org/cgi-bin/mailman/listinfo/gnucash-devel
