Bug 243194 - Investment value is not computed properly
Summary: Investment value is not computed properly
Status: RESOLVED DUPLICATE of bug 245214
Alias: None
Product: kmymoney
Classification: Applications
Component: general (show other bugs)
Version: unspecified
Platform: Gentoo Packages Linux
: NOR normal
Target Milestone: ---
Assignee: KMyMoney Devel Mailing List
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2010-06-29 20:44 UTC by Cristian Oneț
Modified: 2010-07-20 11:59 UTC (History)
2 users (show)

See Also:
Latest Commit:
Version Fixed In:


Attachments
Anon test file to reproduce this (98.56 KB, application/x-compressed-tar)
2010-07-01 19:38 UTC, Cristian Oneț
Details
Modified version of the anon test file (100.32 KB, application/gzip)
2010-07-02 12:16 UTC, Carlos da Silva
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Cristian Oneț 2010-06-29 20:44:38 UTC
Version:           unspecified (using KDE 4.4.4) 
OS:                Linux

When adding shares with the 'Add shares' action the total value of the investments is not computed properly. The price of the share is not used to compute the value of the added shares. If the user edits an 'Add shares' transaction, initially, the editor contains more fields then after selecting the 'Add shares' action.

Reproducible: Always

Steps to Reproduce:
1. 'Add shares'
2. Add a price using the price editor

Actual Results:  
The value of the investment account is incorrect

Expected Results:  
The value of the investment account should be equal to the number of shares multiplied with the price. 

This happens in the current SVN version.
Comment 1 allan 2010-06-30 13:40:34 UTC
When you say "This happens in the current SVN version.", do you mean *only* in the current SVN version?  I'm still on Version 3.98.2-svn1143206, and the way it works for me seems OK.
Comment 2 Cristian Oneț 2010-06-30 13:45:28 UTC
Even when you edit an 'Add shares' transaction there are no extra fields? You must be entering transactions straight into the register I use the transaction form.
Comment 3 allan 2010-06-30 16:12:06 UTC
I've now tried with the form also, and still all works as expected.

If I open an existing add Transaction to edit, I do see all the fields that might be needed, but when I select 'Add' again, I'm just left with Security, Date, and Shares (for the quantity), which is what I expect for an add.

Immediately I accept a changed quantity, the Value is updated with the most recent price.  If I add a new, later price, again the Value gets updated.
Comment 4 Cristian Oneț 2010-06-30 18:02:12 UTC
(In reply to comment #3)
> I've now tried with the form also, and still all works as expected.
> 
> If I open an existing add Transaction to edit, I do see all the fields that
> might be needed, but when I select 'Add' again, I'm just left with Security,

While editing one needs more fields than adding a new transaction?

> Date, and Shares (for the quantity), which is what I expect for an add.
> 
> Immediately I accept a changed quantity, the Value is updated with the most
> recent price.  If I add a new, later price, again the Value gets updated.

That was how it was working for me until my last entry. I'll prepare an anon file.
Comment 5 allan 2010-06-30 18:15:55 UTC
(In reply to comment #4)
> (In reply to comment #3)
> > I've now tried with the form also, and still all works as expected.
> > 
> > If I open an existing add Transaction to edit, I do see all the fields that
> > might be needed, but when I select 'Add' again, I'm just left with Security,
> 
> While editing one needs more fields than adding a new transaction?
> 

I don't think that's exactly it.  If a new transaction is opened, all fields are presented, as it is not yet known which will be needed..  When an existing 'add' is opened for editing, again it is not yet known what the intention is, so again all fields are shown.  It could be the intention is to change the add to a buy, for instance.

That is my rationale for the way it works.  The author's intention might have been different, but to me it seems logical.

> > Date, and Shares (for the quantity), which is what I expect for an add.
> > 
> > Immediately I accept a changed quantity, the Value is updated with the most
> > recent price.  If I add a new, later price, again the Value gets updated.
> 
> That was how it was working for me until my last entry. I'll prepare an anon
> file.

I've been otherwise occupied for a few days so haven't updated.  Has a change been made in the area?
Comment 6 Thomas Baumgart 2010-06-30 21:28:02 UTC
I have to add a few things here: The assumption that a new investment transaction shows more widgets is OK, because the the activity Buy is preset. In case one changes the activity, the respective widgets are shown/hidden depending on the activity selected.

In case an existing transaction is edited, the widgets shown should be the same as when the transaction has been saved. In this respect, the current SVN version has a bug which needs to be fixed. This bug is not present in the 1.0.x series.

We should probably split this issue from the original problem into a new bug entry.
Comment 7 Cristian Oneț 2010-07-01 19:38:06 UTC
Created attachment 48523 [details]
Anon test file to reproduce this

1. Select A000222
2. It has a balance of 26967.0203522
3. The last price of E000004 (ARIPI) is on 12.02.2010 of 13.1277 RON
4. The value is 13.1277x26967.0203522=354014.99 which is correct
5. Add a new price for today of let's say 15 RON
6. The value becomes 152,72 which is totally wrong
Comment 8 allan 2010-07-01 21:30:51 UTC
(In reply to comment #7)
> Created an attachment (id=48523) [details]
> Anon test file to reproduce this
> 
> 1. Select A000222
> 2. It has a balance of 26967.0203522
> 3. The last price of E000004 (ARIPI) is on 12.02.2010 of 13.1277 RON
> 4. The value is 13.1277x26967.0203522=354014.99 which is correct
> 5. Add a new price for today of let's say 15 RON
> 6. The value becomes 152,72 which is totally wrong


Not for me, it doesn't.  It shows a value of 404,505.35.  ( sorry about UK influence).

This agrees with my calculator, of qty. X 15.00 RON.
Comment 9 allan 2010-07-02 01:53:07 UTC
As an aside, I had a couple of crashes with your file.  I wondered if Reports might give your value or mine.  I selected Investments/Graficul prețului investiției (Personalizat) to see if that was relevant, and decided to change the dates.  The crash happened three times on selecting 'As of today'.

Assuming it was displaying prices, I tried with one of my own files, but that didn't crash.

May or may not be relevant, but thought you should know.
Comment 10 Carlos da Silva 2010-07-02 12:16:17 UTC
Created attachment 48540 [details]
Modified version of the anon test file
Comment 11 Carlos da Silva 2010-07-02 12:17:54 UTC
Comment on attachment 48540 [details]
Modified version of the anon test file

Hi,

Just to let you guys know that I confirm the same problem using latest development release (3.98.1) on Slackware 13.1 with one of my files.

I noticed this problem when I changed the price precision in the global options to 9 digits.

I have followed the steps using the attached test file, and have reproduced the error.
The total value of the investment account is informed wrong in all views (home, ledgers, investment, ...), although it is correct in some of the reports (Investment Performance by Account, Investment Performance by Type, Investment Holdings by Account, and Investment Holdings by Type), but incorrect in the pie chart and investment worth graphs.

Will try the latest SVN version and post the results here.

I am also attaching a modified version of the test file after following the steps to reproduce the error and saving it.
Comment 12 Cristian Oneț 2010-07-02 12:44:57 UTC
(In reply to comment #11)
> I noticed this problem when I changed the price precision in the global options
> to 9 digits.

This could be it. I thought it has to do something with the settings since Allan couldn't reproduce it and this only happens on my user account and, as you, I've also increased the price precision since I was getting some rounding errors while transferring between accounts with different currencies.
Comment 13 Carlos da Silva 2010-07-02 18:04:32 UTC
> Will try the latest SVN version and post the results here.
 
Just to confirm the same problem with latest SVN version (1145279).
Comment 14 Cristian Oneț 2010-07-20 11:59:19 UTC

*** This bug has been marked as a duplicate of bug 245214 ***