Delivery Status Notification (Failure)

[Mitch Frazier]

Either I wasn't clear or you're misreading what I said, 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 being developers with time to implement it, when I said "I was
thinking about implementing" I meant I was going to work on the
implementation.

On Sun, May 22, 2016 at 8:11 PM, Mitch Frazier <comwestcr at gmail.com> wrote:

> Either I wasn't clear or you're misreading what I said, 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 being developers with time to implement it, when I said "I was
> thinking about implementing" I meant I was going to work on the
> implementation.
>
> On Sun, May 22, 2016 at 8:07 PM, Mail Delivery Subsystem <
> mailer-daemon at googlemail.com> wrote:
>
>> Delivery to the following recipient failed permanently:
>>
>>      kmymoney-devel at kde.org
>>
>> Technical details of permanent failure:
>> Google tried to deliver your message, but it was rejected by the relay
>> smtp.comwestcr.com [162.222.225.59].
>>
>> The error that the other server returned was:
>> 550 5.4.6 <kmymoney-devel at kde.org>: Recipient address rejected: Email
>> Sending Quota Exceeded
>>
>>
>> ----- Original message -----
>>
>> X-Gm-Message-State:
>> AOPr4FVu0oEez5K2wjcZeaQMyodBvafuf2fz4j5bV0C7VmiXhz2cxMzm60aI4LpneddE8kWmxL18cRZ/PcvJlw==
>> MIME-Version: 1.0
>> X-Received: by 10.112.10.71 with SMTP id g7mr5051605lbb.116.1463972835043;
>>  Sun, 22 May 2016 20:07:15 -0700 (PDT)
>> Received: by 10.25.149.203 with HTTP; Sun, 22 May 2016 20:07:14 -0700
>> (PDT)
>> In-Reply-To: <XfUpxxvj1AG910etgdjBWc at 42S8b2qDD03hCrzav0bcE>
>> References: <CALA8Od96nRvZWNAEZuauW5hzn6O+_0T8R2W=
>> Mnm-TS5b6sGsjA at mail.gmail.com>
>>         <XfUpxxvj1AG910etgdjBWc at 42S8b2qDD03hCrzav0bcE>
>> Date: Sun, 22 May 2016 20:07:14 -0700
>> X-Gmail-Original-Message-ID: <CALA8Od-bHFaVb=
>> Mu6FNBR-j8qK7xFMhVGXnm3QfFGkGdM8vVcg at mail.gmail.com>
>> Message-ID: <CALA8Od-bHFaVb=
>> Mu6FNBR-j8qK7xFMhVGXnm3QfFGkGdM8vVcg at mail.gmail.com>
>> Subject: Re: Handling Investment gain and loss
>> From: Mitch Frazier <mitch at comwestcr.com>
>> To: For KMyMoney development <kmymoney-devel at kde.org>
>> Content-Type: multipart/alternative; boundary=001a1137f422cb3890053379bca2
>>
>> Either I wasn't clear or you're misreading what I said, 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 being developers with time to implement it, when I said "I was
>> thinking about implementing" I meant I was going to work on the
>> implementation.
>>
>> On Sun, May 22, 2016 at 3:00 PM, Jack <ostroffjh at users.sourceforge.net>
>> wrote:
>>
>> > 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:
>> >>
>>
>> ----- Message truncated -----
>>
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.kde.org/pipermail/kmymoney-devel/attachments/20160522/9c867591/attachment-0001.html>