<html>
<head>
<style><!--
.hmmessage P
{
margin:0px;
padding:0px
}
body.hmmessage
{
font-size: 12pt;
font-family:Calibri
}
--></style></head>
<body class='hmmessage'><div dir='ltr'>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.<BR> <BR>Also, I generally don't enter transactions. I download / import them. That may be another reason I'm looking at it differently.<br><BR>It is definitely more implementation work for the programmer. <BR> <BR><div><hr id="stopSpelling">Date: Wed, 25 May 2016 07:28:57 -0700<br>Subject: Re: Handling Investment gain and loss<br>From: mitch@comwestcr.com<br>To: kmymoney-devel@kde.org<br><br><div dir="ltr"><div class="ecxgmail_default" style="font-family: arial,helvetica,sans-serif; font-size: small;">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.</div><div class="ecxgmail_default" style="font-family: arial,helvetica,sans-serif; font-size: small;"><br></div><div class="ecxgmail_default" style="font-family: arial,helvetica,sans-serif; font-size: small;">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.</div></div><div class="ecxgmail_extra"><br><div class="ecxgmail_quote">On Tue, May 24, 2016 at 6:12 PM, <span dir="ltr"><<a href="mailto:jeffjl.kde@outlook.com" target="_blank">jeffjl.kde@outlook.com</a>></span> wrote:<br><blockquote class="ecxgmail_quote" style="padding-left: 1ex; border-left-color: rgb(204, 204, 204); border-left-width: 1px; border-left-style: solid;">
<div><div dir="ltr">
<div dir="ltr">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. <br> <br>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.<br> <br>A report could also give you an estimated gain/loss/cost basis on an asset you still owned (unrealized gain/loss).<br> <br>On the taxable / tax-deferred issue - it would be nice if this could be set at the account level.</div><div dir="ltr"><br>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.</div><div dir="ltr"> </div><div dir="ltr">> Date: Sun, 22 May 2016 18:00:45 -0400<br>> From: <a href="mailto:ostroffjh@users.sourceforge.net" target="_blank">ostroffjh@users.sourceforge.net</a><br>> Subject: Re: Handling Investment gain and loss<br>> To: <a href="mailto:kmymoney-devel@kde.org" target="_blank">kmymoney-devel@kde.org</a><div><div class="h5"><br>> <br>> On 2016.05.22 15:04, Mitch Frazier wrote:<br>> > While entering a number of investment transactions recently I <br>> > realized that<br>> > KMM doesn't actually have a way to record the gain/loss on the sale <br>> > of an<br>> > investment. I was thinking about implementing something to solve <br>> > this but<br>> > wanted to pass the idea past the list first.<br>> > <br>> > As a first step at a solution, I was going to add a couple more rows <br>> > to the<br>> > transaction detail in the investment register:<br>> > <br>> > - A cost basis field. This would be an amount field that is<br>> > used to determine how much the cost of the investment is<br>> > reduced by the sale. Initially this field could be pre-filled<br>> > by the average cost (based on the number of shares being sold).<br>> > If the entire investment is sold, this field would be fixed<br>> > and not editable.<br>> > <br>> > - A gain/loss field. This would be an splitable account field<br>> > for entering the category or categories for the gain/loss.<br>> > Splits are useful for allowing both short-term and long-term<br>> > gain/loss specifications on a transaction.<br>> > <br>> > The current implementation "hides" the gain/loss because the balance <br>> > of an<br>> > investment shows as zero when the share value is zero, regardless of <br>> > the<br>> > amount the investment is sold for. Whereas, since the gain/loss is <br>> > not<br>> > recorded anywhere, the balance ought to be negative if the investment <br>> > was<br>> > sold for a gain and positive if sold for a loss.<br>> > <br>> > Mitch<br>> > <br>> <br>> Unfortunately, I think that may be a bit simplistic. Once you have <br>> sold all off an equity, its value is zero, since you don't have any of <br>> it any more. When you do sell, the amount of the basis is not income - <br>> it just gets back what you paid to acquire it. It is the difference <br>> between that basis and the sale price which becomes the short or long <br>> term capital gain or loss. If you actually buy the shares, that <br>> purchase price is the cost. The only reason you would need to be able <br>> to manually adjust this is if you "add" shares you bought before <br>> tracking with KMM, or if the shares are swapped for a different equity, <br>> in which case you "remove" all the original shares and "add" however, <br>> many shares you get of the new equity. (In that case, hopefully KMM <br>> should be able to do the conversion, so you still shouldn't need to do <br>> it manually.) The cost basis just transfers from the old to the new. <br>> I don't see how you get a cost basis by averaging anything.<br>> <br>> I'm not certain about how to record the gain/loss, but I know I already <br>> have category fields for short and long term gain and loss, and two <br>> sets of each - one for taxable, one for tax deferred. So far, I only <br>> use them where the broker designates a dividend (usually for a <br>> reinvestment transaction) as a capital gain, but I don't see why it <br>> won't also work for a sale, expect for needing a category to represent <br>> the recapture of the original payment (cost basis). I suppose creating <br>> a category of cost basis would make sense. When you buy, that's where <br>> the purchase price goes. When you sell, the cost basis category is <br>> reduced by the same, with the appropriate capital gains category <br>> getting the difference from the actual sale price.<br>> <br>> One complication is that if you acquire an equity through multiple <br>> purchases, at different share prices, then when you sell, you do need <br>> to designate which of those lots you are selling. While it generally <br>> is taken that the oldest gets sold first, you may be allowed to <br>> designate which. That would mean that not only the total value of the <br>> cost basis needs to be tracked, but number and price of shares for each <br>> purchase.<br>> <br>> I do agree it would be great for KMM to be able to track this, as it <br>> would allow tracking unrealized gain/loss instead of just current <br>> value. I'm just not sure how much change would be needed in the core <br>> data structures. However, it's certainly worth discussing, and I don't <br>> think any developer will have time to address it until after the <br>> conversion to KDE Frameworks is complete, and there is not yet any <br>> definite timeline for that.<br>> <br>> Jack<br></div></div></div>
</div></div>
</blockquote></div><br></div></div> </div></body>
</html>