Handling Investment gain and loss

Mitch Frazier mitch at comwestcr.com
Mon May 23 13:11:10 UTC 2016


Allan

Actually my reply was written to Jack's email, but I was having email
problems last night and it didn't get sent till after you'd replied.

Mitch

On Mon, May 23, 2016 at 6:08 AM, aga <agander93 at gmail.com> wrote:

> On 23/05/16 13:33, Mitch Frazier wrote:
>
>> ‚ÄčEither I wasn't clear or you're misunderstanding what I'm saying,
>>
> <snip>
>
>> the
>> "cost basis field" is the amount that is used to reduce the remaining
>> basis of the asset.  If you sell the entire investment, the reduction
>> would be the entire cost of the investment (thereby reducing the cost to
>> zero).  The reason that you might need to adjust the cost basis is for
>> exactly the reason that you pointed out: when you sell less than the
>> full asset, there's more than one way to determine the cost of the part
>> that was sold.  You can use "average cost", "FIFO", or "specific lots"
>> (and probably some others) to determine the cost of the part that was
>> sold.  A more sophisticated user interface for entering/determining the
>> cost would be a refinement, this is just meant to be a first step along
>> the way. The difference between the sales price and the cost basis of
>> the part that was sold is the gain/loss on the sale.
>>
>> Creating a  "category" for storing the cost and/or recovering the cost
>> doesn't make any sense, the cost is already stored in the investment
>> account (the stock/bond account).  It contains the original amount
>> (amounts if more than one purchase was done).  The difference between
>> the sales price and the "cost basis" of the sale is the gain/loss on the
>> transaction and that would go to one or more "categories".
>>
>> As far as developers with the time to implement it, when I said "I was
>> thinking about implementing" I meant I was going to work on the
>> implementation.‚Äč
>>
>>
> I made no comment about the proposed functionality.
>
> Neither did I suggest that the developers might have to implement it.
> However, they do have a say it what gets implemented, and it was that to
> which I was referring.
>
> Allan
>
> On Mon, May 23, 2016 at 3:14 AM, aga <agander93 at gmail.com
>> <mailto:agander93 at gmail.com>> wrote:
>>
>>     On 22/05/16 20: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
>>
>>
>>     I think the developers will need to comment on this proposal.  From
>>     my own point of view, it is not a functionality that I need, at
>>     least at present.  What's more important, though, is that it might
>>     be advisable for display of the extra fields to be optional,
>>     certainly from the perspective of a new user.
>>
>>     Allan
>>
>>
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.kde.org/pipermail/kmymoney-devel/attachments/20160523/29e73d2d/attachment-0001.html>


More information about the KMyMoney-devel mailing list