[Patch] reworked advanced-portfolio.scm

[Andrew Sackville-West]

On Sat, 18 Feb 2006 10:20:24 -0700
Mark Johnson <mrj001 at shaw.ca> wrote:

> Andrew Sackville-West wrote:
> 
> >On Fri, 17 Feb 2006 19:58:24 -0700
> >Mark Johnson <mrj001 at shaw.ca> 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
> 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
Url : http://lists.gnucash.org/pipermail/gnucash-devel/attachments/20060218/4ccb40c9/attachment.bin