Handling Investment gain and loss

[Jack]

I'm only going to address one small piece of this now, as I think the  
overall issue is going to take a lengthy discussion.  I personally feel  
the entire investment part of KMM could use some attention and changes,  
I know it won't happen for a while, so we have time to flesh out all  
the issues that will need to be addressed when that is done.

In terms of realized gain/loss, which happens when you sell, as has  
been pointed out earlier in this thread, the user needs to say which  
buy transactions represent the shares that are being sold.  This can  
certainly be done during a manually entered sell transaction.  However,  
if the sell is imported - either the transaction should be flagged as  
incomplete and require manual specification, or it could use a default,  
and the transaction would allow changing that as part of an edit.

One big thing to realize when discussing KMM is that there are a very  
large set of use cases - different people use it in different ways.   
When changes are suggested or made to make support of your use case  
better, some thought should go toward trying to avoid any unintended  
consequences for other users who use it differently.  (Note I don't see  
any such issues here yet, but I know enough not to make that assumption  
too strongly.)

Jack

On 2016.05.26 11:27, Mitch Frazier wrote:
> Unrealized gain/loss is different than what I'm talking about, I'm  
> talking
> about "realized" gain/loss.  Unrealized gain/loss wouldn't be entered  
> into
> a ledger.
> 
> I never import transactions, so we definitely are thinking about it  
> from
> different perspectives.  Even if you import transaction, it seems  
> like the
> time to enter the information for "realized" transactions is then,  
> not when
> you run a report.  Although, the exact procedure for doing it at  
> import
> time is less clear to me.
> 
> On Wed, May 25, 2016 at 6:37 PM, <jeffjl.kde at outlook.com> wrote:
> 
> > Why would I? To have the software do the work instead of the user.  
> And to
> > get the unrealized gain/loss - useful at the end of the year for tax
> > planning, e.g. do I want to take that loss to offset a gain I've
> > already taken.
> >
> > Also, I generally don't enter transactions. I download / import  
> them. That
> > may be another reason I'm looking at it differently.
> >
> > It is definitely more implementation work for the programmer.
> >
> > ------------------------------
> > Date: Wed, 25 May 2016 07:28:57 -0700
> > Subject: Re: Handling Investment gain and loss
> > From: mitch at comwestcr.com
> > To: kmymoney-devel at kde.org
> >
> >
> > Although you could probably do much of this via reports, the main  
> question
> > I have is "why would you?"  Why not enter all the information when  
> you
> > enter the transaction rather than waiting to see it in a report?   
> And doing
> > it via reports strikes me as a much more complex undertaking than  
> adding a
> > couple fields to the transaction entry form.
> >
> > From an accounting point of view, "Sell" transactions are  
> essentially
> > unbalanced transactions.  You get a "debit" to your brokerage  
> account for
> > the money you received, but there's no corresponding "credit"  
> entries for
> > the gain or for reducing the basis of the asset.
> >
> > On Tue, May 24, 2016 at 6:12 PM, <jeffjl.kde at outlook.com> wrote:
> >
> > I'm thinking this could be more of a reports function than a new
> > transaction field. If appropriate "activity" choices are added for
> > transactions, e.g. reinvested long/short term capital gains, return  
> of
> > capital, depreciation if we include assets in general, etc. (there  
> may be
> > quite a few), then it is a matter of collecting the transactions  
> for a
> > given asset and calculating the cost basis (and gain/loss) in a  
> report.
> > Except for the report, those new activities could be treated the  
> same as
> > existing activities, couldn't they? Existing functions could treat
> > a reinvested long term capital gain transaction just like a "buy",  
> for
> > example. No change required to existing code other than recognizing  
> the
> > equivalence.
> >
> > The report could offer selectable specifics like FIFO or average  
> price.
> > I'm not sure the best way to select the assets - maybe choose a  
> date range
> > and display any assets that had "sells" in that range? And the  
> specific lot
> > method probably still needs a new UI.
> >
> > A report could also give you an estimated gain/loss/cost basis on  
> an asset
> > you still owned (unrealized gain/loss).
> >
> > On the taxable / tax-deferred issue - it would be nice if this  
> could be
> > set at the account level.
> >
> > But a report does not provide a way to tag a specific sale with a  
> cost
> > basis method. If you are going to use KMM data to actually do your  
> taxes,
> > that could be important.
> >
> > > Date: Sun, 22 May 2016 18:00:45 -0400
> > > From: ostroffjh at users.sourceforge.net
> > > Subject: Re: Handling Investment gain and loss
> > > To: kmymoney-devel at kde.org
> >
> > >
> > > On 2016.05.22 15:04, Mitch Frazier wrote:
> > > > While entering a number of investment transactions recently I
> > > > realized that
> > > > KMM doesn't actually have a way to record the gain/loss on the  
> sale
> > > > of an
> > > > investment. I was thinking about implementing something to solve
> > > > this but
> > > > wanted to pass the idea past the list first.
> > > >
> > > > As a first step at a solution, I was going to add a couple more  
> rows
> > > > to the
> > > > transaction detail in the investment register:
> > > >
> > > > - A cost basis field. This would be an amount field that is
> > > > used to determine how much the cost of the investment is
> > > > reduced by the sale. Initially this field could be pre-filled
> > > > by the average cost (based on the number of shares being sold).
> > > > If the entire investment is sold, this field would be fixed
> > > > and not editable.
> > > >
> > > > - A gain/loss field. This would be an splitable account field
> > > > for entering the category or categories for the gain/loss.
> > > > Splits are useful for allowing both short-term and long-term
> > > > gain/loss specifications on a transaction.
> > > >
> > > > The current implementation "hides" the gain/loss because the  
> balance
> > > > of an
> > > > investment shows as zero when the share value is zero,  
> regardless of
> > > > the
> > > > amount the investment is sold for. Whereas, since the gain/loss  
> is
> > > > not
> > > > recorded anywhere, the balance ought to be negative if the  
> investment
> > > > was
> > > > sold for a gain and positive if sold for a loss.
> > > >
> > > > Mitch
> > > >
> > >
> > > Unfortunately, I think that may be a bit simplistic. Once you have
> > > sold all off an equity, its value is zero, since you don't have  
> any of
> > > it any more. When you do sell, the amount of the basis is not  
> income -
> > > it just gets back what you paid to acquire it. It is the  
> difference
> > > between that basis and the sale price which becomes the short or  
> long
> > > term capital gain or loss. If you actually buy the shares, that
> > > purchase price is the cost. The only reason you would need to be  
> able
> > > to manually adjust this is if you "add" shares you bought before
> > > tracking with KMM, or if the shares are swapped for a different  
> equity,
> > > in which case you "remove" all the original shares and "add"  
> however,
> > > many shares you get of the new equity. (In that case, hopefully  
> KMM
> > > should be able to do the conversion, so you still shouldn't need  
> to do
> > > it manually.) The cost basis just transfers from the old to the  
> new.
> > > I don't see how you get a cost basis by averaging anything.
> > >
> > > I'm not certain about how to record the gain/loss, but I know I  
> already
> > > have category fields for short and long term gain and loss, and  
> two
> > > sets of each - one for taxable, one for tax deferred. So far, I  
> only
> > > use them where the broker designates a dividend (usually for a
> > > reinvestment transaction) as a capital gain, but I don't see why  
> it
> > > won't also work for a sale, expect for needing a category to  
> represent
> > > the recapture of the original payment (cost basis). I suppose  
> creating
> > > a category of cost basis would make sense. When you buy, that's  
> where
> > > the purchase price goes. When you sell, the cost basis category is
> > > reduced by the same, with the appropriate capital gains category
> > > getting the difference from the actual sale price.
> > >
> > > One complication is that if you acquire an equity through multiple
> > > purchases, at different share prices, then when you sell, you do  
> need
> > > to designate which of those lots you are selling. While it  
> generally
> > > is taken that the oldest gets sold first, you may be allowed to
> > > designate which. That would mean that not only the total value of  
> the
> > > cost basis needs to be tracked, but number and price of shares  
> for each
> > > purchase.
> > >
> > > I do agree it would be great for KMM to be able to track this, as  
> it
> > > would allow tracking unrealized gain/loss instead of just current
> > > value. I'm just not sure how much change would be needed in the  
> core
> > > data structures. However, it's certainly worth discussing, and I  
> don't
> > > think any developer will have time to address it until after the
> > > conversion to KDE Frameworks is complete, and there is not yet any
> > > definite timeline for that.
> > >
> > > Jack
> >
> >
> >
>