On Sat, 18 Feb 2006 10:20:24 -0700 Mark Johnson <[EMAIL PROTECTED]> wrote:
> Andrew Sackville-West wrote: > > >On Fri, 17 Feb 2006 19:58:24 -0700 > >Mark Johnson <[EMAIL PROTECTED]> wrote: > > > > > > > >> [...] > >> > >>Automatically, creating entries in the pricedb for any buy, sell or > >>"similar action" strikes me as a rather dicey thing to do. I offer two > >>similar recent use cases I have had to consider: > >>1. One of my mutual fund companies decided (correctly) that it had an > >>excessive number of indistinguishable funds. Therefore, two similar > >>funds were merged, with one surviving. I had units in the non-surviving > >>fund. These were exchanged for a different number of units of the > >>surviving fund (at a different price, of course). Now, this is an > >>exchange and not a buy/sell. I don't realize capital gains. So I wish > >>to record this in such a way that the cost basis of the new (to me) fund > >>is the same as the cost of the old fund. (This keeps the balance sheet > >>balancing, as I don't have capital gains to enter to balance it.) I > >>enter a split to two mutual fund accounts, showing one decreasing by the > >>number of surrendered units and the other increasing by the number of > >>units in the new fund. The dollar amounts shown in the buy and sell > >>columns are the cost basis of the fund. Note that if this were used to > >>create an automatic entry in the pricedb, it would not be the current > >>market price. It would be the (sadly higher) original cost. Thus, such > >>an automatic entry would not be appropriate in this use case. > >> > >> > > > >I have another thought on this particular case. 1) a price db entry at this > >point is exactly what you want as it records your cost basis for the mutual > >fund. That is the number you need later for calculating capital gains, so > >you definitely want a record of that number. > > > I thought that gnucash used the buy transaction in the stock account's > register to calculate the cost basis. And the latest (or whatever > option you select) price in the pricedb to calculate the unrealized > gain. So it should be able to calculate the cost base without a pricedb > entry, but not the unrealized gain. yup. > > >2) you can always come in the next day and record the current price for the > >fund so that the pricedb shows the current value. Make sense? the only thing > >you'll lose will be the price history. Its okay that you don't show the > >current market price at the time of the transfer/exchange. you can always > >provide that number later so that your reports show the current market value. > > > > > True. What about the possibility of reports based upon the pricedb > entries? Eg. a graph of the price history. Such entries would produce > unwelcome blips. I'm just thinking here about possible future features, > and, I suppose, the meaning of pricedb entries. In thinking on this more, as I understand the way the report currently works, that shouldn't necessarily cause a blip. The report takes the txn and converts it from whatever commodity it is currently represented in to the final display commodity(currency). Frankly, I don't understand the currency exchange function well enough yet to know, but it may be that it correctly shows a conversion. so for example if you have 10 units stockA @ $10 and trade it for 5 units stockB @ $20, then the value should line up at $100 either way. What if your trade is not 1:1. hmmm. 10units A @ $10 becomes 7 units B @ $20. well your value jumps from $100 to $140. but this is still accurate as that is what the stock is worth. What am I missing here? > > Your other e-mail indicated that pricedb entries could be automatically > created for buy and sell actions, and the user could be asked for > others. I think this is quite a reasonable solution. However, it still > leaves the possibility of an empty pricedb for some time with a new > mutual fund (created by a transfer from another as in my use case #1). > I believe that the report should be able to deal with this, and the way > in which you suggested is good. well, clearly the report needs to deal with ANY data that comes at it and even more clearly, I don't yet properly understand all the cases and how they should be handled. :( A > > Mark >
pgpI18k6OSUnt.pgp
Description: PGP signature
_______________________________________________ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
