[Patch] reworked advanced-portfolio.scm

[Andrew Sackville-West]

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

please reply to the list.

> 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 agree with you that there are cases when an automatic price db entry might be a problem. However, it seems to me that the price db just records the price of things from time to time and is not a reflection of any actual gains/losses that may occur. What I'm seeing for the advanced portfolio report is simple. It uses the pricedb to get the most recent price for a commodity and uses that price to calculate the value of a particular holding. It seems people are buying stocks but making no pricedb entry at the time of purchase. This breaks the report and also IMO breaks the books in that the mechanism for recording stock value data is not being used. And I think nothing prevents one from going back and deleteing a price entry after the fact. Perhaps the user should be prompted in the event of a transfer or other ambiguous action? A buy or sell, is certainly not ambiguous as there is a price involved, however removed from real value it may be, but there are certainly other actions where it should be optional.

> 
> 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.

Well, the simple work around to this is simply to place your stocks under different parent accounts: vested and unvested and then just move them when appropriate. Or make pricedb entries as appropriate in the new accounts. I'll be honest in that I don't use the stock accounts. I fell into working on this report randomly and need input into how it should work. However, it appears to me that the pricedb is not much more than a convenience. And in the case of transferring shares from a unvested to vested state would require some bookkeeping no matter what. You could certainly transfer from a vested nonvested accoutn to a vested accoutn and them make a pricedb entry for the original purchase price. That would preserve the record of the the basis in the investment for future use. 
> 
> 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.

As I said above, the lack of a pricedb entry essentially breaks the advanced portfolio report as its currently written. I'm not opposed to making it work right, I'm just trying to make it work within its current basic design. But, using its current design, the user needs to make a pricedb entry to get it to work properly and I was trying to find a graceful way to handle the somewhat-broken state but still get some usable data out of it. your further input is appreciated.

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/46aa822d/attachment.bin