Stocks, gains/losses, do I really have to calculate them by hand?

[David Carlson]

On 4/25/2012 4:13 AM, Fredrik Persson wrote:
> On Mon, Apr 23, 2012 at 4:13 PM, John Ralls <jralls at ceridwen.us> wrote:
>
>> On Apr 23, 2012, at 6:47 AM, Eric Morey wrote:
>>
>>> On Mon, 2012-04-23 at 15:07 +0200, Fredrik Persson wrote:
>>>> Can you explain what you mean when you say "gnucash will do calculations
>>>> for you in numeric fields"?
>>> I'm sure he means that gnucash will, for example, fill the field with 10
>>> if you type 2*5 into the field, thus relieving you of having to do the
>>> calculation yourself (possibly with the aid of a separate calculator)
>>> and entering the result, 10, into the field.
>>>
>> Yup,, that's what I meant.
>>
>> Regards,
>> John Ralls
>
> Well, that brings me back to square one... I'm not sure my question has
> been understood.
>
> Example;
>
> Day 1: I buy 10 shares @ $10
> Day 2: I sell 5 shares @ $15
> Day 3: I buy 15 shares @ $25
> Day 4: I sell 9 shares @ $9
>
> When entering the "sell" transactions, I need to manually calculate how
> much money I've gained. The sell on Day 2 I've gained 5 * (15 - 10) = $25.
> That's easy, but I have to do it by hand. The sell on day 4 it becomes
> complicated. I have 5 shares left that I paid $10/share for, so that's $50.
> Then I have 15 shares that I paid $25/share for, so that's $375. In total,
> I have 20 shares that I paid $425 for, which means 425/20 = $21.25 per
> share. So the loss on the sell on day 4 is 9 * (21.25 - 9) = $110.25.
>
> THAT I need to calculate by hand every time I sell. And if I have a lot of
> transactions on this particular share it adds up to a lot, LOT of work. All
> the numbers are there, so gnucash should somehow be able to help me with
> this.
>
> How? That's the question. Lots seems to be a mechanism that *could* be used
> here, but from what I read about it, it's not very easy or straightforward.
>
> /Fredrik
>

I think that your question was understood but not answered.  I suspect
that you are correct in surmising that there is no easy answer.  A
search of Bugzilla shows serious open bug reports involving the 'lots
druid', as it was called then, going back to June 2006. 

I do not think that we need to have a solution that would work for all
cases.  Day-traders, mutual fund accounts or 401-k accounts may require
external software or spreadsheet solutions.  People who want to use LIFO
or special methods of lot selection and manipulation can find their own
solutions.  In the US, at least, FIFO and average cost are the only
methods to be considered seriously.

I agree with you that if the concern that you expressed so clearly is to
be addressed, it should be done in a revamp to the lots mechanism.  I
also understand that there is context to consider in the development of
a solution or solutions.  A big consideration is how to avoid
complicating the transition to the adoption of a database back end and
to eventually taking advantage of the strengths of that type of back
end.  I can see where a high quality short term solution would probably
involve expending a large block of resources that would be abandoned in
a transition to a high quality database structure.

However, I do not think that it would be satisfactory to wait for an
unspecified amount of time to allow for infrastructure improvements
before addressing any of these issues. 

Judging by John's original answer in this thread, he is fairly well
aware of the shortcomings of the lot mechanism.  I know also that the
lot mechanism does not include commissions in it's calculations.  

Perhaps we could persuade him or another developer to tell us if there
is an interim solution to at least partially address some of these
concerns. For example, it might be possible to combine some manual steps
to restructure transactions to successfully apply the existing code. 
Manual steps could be outlined in the GnuCash Wiki, and I would be glad
to assist with that.

David C
-------------- next part --------------
A non-text attachment was scrubbed...
Name: 0xDC7C8BF3.asc
Type: application/pgp-keys
Size: 1729 bytes
Desc: not available
URL: <http://lists.gnucash.org/pipermail/gnucash-user/attachments/20120425/549a5a4c/attachment.bin>