[Patch] reworked advanced-portfolio.scm

[Derek Atkins]

Andrew...

Any chance you could add 80-character line breaks to your messages?

Andrew Sackville-West <andrew at farwestbilliards.com> writes:

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

This is unfortunately an incorrect assumption.  It's perfectly
legal to have stock transactions without pricedb entries.  The
reason:  you can ALWAYS determine the purchase price or sale price
of a stock based on the actual transaction information.  So if you
only want to compute realized gains and don't care about current
value or unrealized gains, then you don't NEED any pricedb entries.

So, you cannot assume that stock transactions without pricedb is an
error condition.

>         There
> should always be a pricedb entry if there are any shares in an
> account, IMO. 

Sorry, I do not agree..

>    Probably the code should be fixed so that any buy or
> sell or similar action automatically creates a pricedb entry. 

Arguably..  But that's a different not

>    Still
> we have to account for 1.8 files that might be broken in this
> regard. phew.

yep.  we definitely do.

>    What it does: flags the particular stock as being
> "dirty" and tries to make a reasonable guess at what the current
> value and gain is based on data pulled from the actual
> transactions. I am not convinced however that this data is properly
> exchanged across multiple currencies. So the report spews what it
> can on this stock, but sticks a * in the price column and places a
> warning at the bottom of the report explaining the situation. Also,
> any stocks that don't have a pricedb entry are EXCLUDED from the
> totals at the bottom of the report as the information is not
> reliable.

a) you shouldn't compute realized gain from pricedb -- it should be
   computed from the actual transaction data.
b) you CAN compute unrealized gain from pricedb OR txn data.
c) I do not believe you should exclude stocks without pricedb entries
   from the totals.  It gives a false lower amount.
d) I think marking prices computed from txns vs. prices computed from
   pricedb is a good thing
e) you might want to also display the date of the pricedb entry, so you
   know "this value is computed as of ...".

> please give me feedback on this monster and my assumptions. I would
> like to make it behave appropriately and I don't know if my
> assumptions are correct.

I think I did above.

> thanks
>
> A

-derek

-- 
       Derek Atkins, SB '93 MIT EE, SM '95 MIT Media Laboratory
       Member, MIT Student Information Processing Board  (SIPB)
       URL: http://web.mit.edu/warlord/    PP-ASEL-IA     N1NWH
       warlord at MIT.EDU                        PGP key available