Advanced portfolio report

Sat Dec 1 12:01:24 EST 2007

On Fri, Nov 30, 2007 at 10:51:32PM -0500, Mike Alexander wrote:
> --On November 30, 2007 12:20:14 PM -0800 Andrew Sackville-West 
> <ajswest at mindspring.com> wrote:
>>
>> I warned that it was still ugly like that ;) There's actually useful
>> information in there!
>
> Yes, but nevertheless I would urge you to use gnc:debug for debugging 
> output.  That's what it is for and it lets you (and others) control the 
> amount output at run time.

yeah yeah yeah. I'll figure it out.

>
>>> In the case of Apple, I've got a number of purchases and sales over
>>> several years, along with a few stock splits.  However the net
>>> result  is fairly simple.  All the lots are closed except for the
>>> most recent  purchase and there have been no splits since then.  It
>>> almost handles  this correctly except for some shares I donated to
>>> charities.  For some  reason it considers the value of these shares
>>> to be brokerage fees.
>>
>> That's because you've "Expensed" those shares, right? There is no way,
>> at this time, to distinguish between different types of expenses. To
>> the stock account, they all look the same. We would have to actually
>> create more ACCT_TYPE_FOO entries to make this distinguishable. The
>> better bet is to change how user's enter this data so that any
>> "Expense" that is *not* a brokerage fee should pass through a suspense
>> account of some kind. That would move the expense out one level so
>> that the report doesn't see it. Same with employer contributions that
>> go directly to some kind of stock or fund...
>
> If by "Expensed" you mean the other split is an expense account, then yes, 
> that's what I did.  It seems like if the number of shares is non-zero and 
> the only other account in the transaction is an expense account then it 
> should be treated as a sale.  A corresponding rule could be used for income 
> accounts and purchases.  You can use xaccSplitGetOtherSplit to get the 
> other split.  This will return a null pointer (or the equivalent Scheme 
> construct whatever that is) if the transaction has more (or less) than two 
> splits, and return the other split if it has exactly two.

hmmm... I can see this being pretty useful. There is still the problem
that we don't know what that money is being used for. So, if we call
any two-split txn, with an expense on one split and the stock itself on
the other, a sale, it can be used to adjust the basis and also
money-out.

That doesn't work on the income side though because there is still no
way to distinguish between the different sources of income. BUt again,
expecting the user to jump through certain hoops for that particular
case is not unreasonable, IMO.

>>> A more complicated example is Altria Group.  I purchased two lots in
>>> 2004 and 2005.  In 2007 they spun off Kraft. 
...
>> How do you enter a spin-off like this? What txn structure shows the
>> reduction in Altria basis? Is there an actual reduction in the
>> number of shares or some other method?

> The spinoff transaction has two splits.  The one in the Altria account has 
> zero shares and a non-zero value.  The one in the Kraft account has a 
> non-zero number of shares and the same value (sign reversed, of course).  
> The number of shares I own of Altria was not changed by this transaction 
> (that's the normal case in a spinoff), but the basis of those shares 
> changed by the value of the Kraft shares I obtained (which is also the 
> basis of the new Kraft shares).  The sum of the Altria and Kraft bases was 
> the same after the transaction as before.

okay, another pretty easy case to test for in the basis
functions. Sort of the opposite of the splits/mergers code where
instead of non-zero shares and zero value we test for zero shares nd
non-zero value. 

thanks for your input on both of these Mike. It helps a *lot*! I see
no reason I can't get this into the current version.

On to lots:

>>> If there are lots assigned to the splits for a stock or other asset,
>>> the report should use them.  In this last case, the sale was part of
>>> the second of three acquisitions.  This is correctly recorded in the
>>> splits (which I realize is hard to do now, but someday it might be
>>> easier) and the report should really use this information to
>>> determine  the basis for the shares sold like the lot scrubber does.
>>
>> I honestly don't have a clue about lots and how they work. Its very
>> possible that I've duplicated code that the lots system already
>> handles. However, it's not immediately clear to me that lots will be
>> used and so we have to build for the case we know we have, which is
>> the txn data. At this point, I'm not sure I'm really willing to go
>> that deep into it, as my main goal is to get something usable out of
>> the mess that curerntly exists. But maybe there's something obvious
>> and simple that I'm missing.  Again, a test file would be great.
>
> Use of lots simply assigns a lot to each split that represents a purchase 
> or sale of shares.  For the purposes of your report all I'm asking is that 
> you ask each split what lot it is in and if you find a purchase and a sale 
> in the same lot, you use that purchase to compute the basis for the sale.  
> If the sale is not in a lot (or if you can't find the corresponding 
> purchase in the lot, which indicates a bug) then use the FIFO, LIFO, or 
> whatever rule to find the corresponding purchase.  It's pretty simple and 
> wouldn't complicate things much at all.  You can use xaccSplitGetLot to get 
> the lot a split is in.  Then, if this is not null, you can use 
> gnc-lot-get-split-list to get a list of splits in the lot.

Okay, I understand how that works. Basically I have to track the lots
along with the price and number of shares in the basis list. The
problem is how to deal with the "Average" basis. Currently, with the
average-method, instead of tracking separate cells for each txn, it
just collapses each txn into a single cell that gets adjusted
along. So first I'd have to *not* collapse it into a single cell, but
keep track of each txn. no biggie. The problem is how to adjust the
average when you yank a lot out of the middle while also performing
"non-lot" sales. I don't understand lots in the real world application
and whether its a case of "once you use lots you must always use lots"
or some other case. Here is an example of the situation, maybe you
have some insight.

using average-method basis

1/1/01 purchase 10 shares @ 50
1/2/01 purchase 10 shares @ 60 assigned to lot 1
1/3/01 purchase 10 shares @ 70

at this point basis is 30 shares at 60=1800 (regardless of method)

1/4/01 sell 5 shares with no lot assignment

because its average basis, the new basis is 25 shares at 60 = 1500
but, if we're trying to track lots, how do we apply that? which 5
shares do we remove? If the sale is a lot sale, it gets easier,
because you can recalculate the average with those specific shares
removed. Does it work if we track the average separately all along and
recalculate it when we get a lot sale? I just don't see how it would
work if you hit a non-lot sale.

I'm not arguing against using lots here, BTW. Just trying to figure
out this corner case. 

hmmm... having just re-read all this, it may be as simple as
*ignoring* lots for the average-method, as it just doesn't apply.

>
>>
>> I think that probably the long term solution is to take the stock
>> register away from the user and get all these transactions built in
>> some wizard (this was mentioned previously on one of the lists) so
>> that the reporting can build reports based on a systematic
>> structure. This may involve hackery such as a predetermined, immutable
>> set of accounts or actions for these things*. The interim solution is
>> to get reasonably stable and predictable performance out of the report
>> (which I think we're really close to) and then adjust the docs to
>> reflect that performance.
>
> Having used Quicken for many years before switching to Gnucash, I would be 
> less than enthusiastic about this approach.  Coming up with a wizard that 
> handled all the various complex transactions people make would probably be 
> extremely difficult.

I won't argue that point, because you're right. I'm only suggesting
that this might be the approach to ensure that the transactions all
conform to a structure that can be reported on within the limitations
of the information we have access to. But I also don't doubt for one
second my lack of knowledge about what is doable in gnucash. :)

Thanks a lot for your help with this Mike.

A

----- End forwarded message -----

-- 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: Digital signature
Url : http://lists.gnucash.org/pipermail/gnucash-devel/attachments/20071201/1e2416f8/attachment.bin 