[Patch] reworked advanced-portfolio.scm

[Andrew Sackville-West]

On Fri, 17 Feb 2006 19:58:24 -0700
Mark Johnson <mrj001 at shaw.ca> wrote:

> Andrew Sackville-West wrote:
> 
> >3) a stock account with shares in it but with no pricedb entry. In this case, I made the assumption that the file was broken. There should always be a pricedb entry if there are any shares in an account, IMO. Probably the code should be fixed so that any buy or sell or similar action automatically creates a pricedb entry. Still we have to account for 1.8 files that might be broken in this regard. phew. [...]
> >  
> >
> 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. 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.

A

> 
> 2. I have an employee share purchase plan with several stock 
> sub-accounts.  Two are important here - vested and nonvested shares.  
>  From time to time, shares will vest.  These are to be transferred from 
> the nonvested account to the vested account.  Again, I do not realize 
> capital gains, and so record this based upon the cost of the shares.  
> Otherwise, I would either unbalance the balance sheet, or record capital 
> gains income which is not, in fact, income.  (Recording this using an 
> "unrealized gains" account would make calculating the real capital gains 
> confusing at the actual time of sale.)  Again, an automatic pricedb 
> entry would not be an accurate market price.
> 
> So I disagree with automatically creating pricedb entries.
> 
> I've tried both use cases in g2 a couple of weeks ago, and they worked.  
> Though thanks to things I learned using 1.8.x, I did not try anything I 
> expected to unbalance the balance sheet in g2.  Sadly, due to moving to 
> a new house, I've fallen behind in recording real transactions and have 
> not yet determined if these use cases work in 1.8.12.
> 
> 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/dced7829/attachment.bin