Bug 243194

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.

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.

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.

(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.

(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?

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.

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

(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.

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.

Created attachment 48540 [details]
Modified version of the anon test file

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.

(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.

> Will try the latest SVN version and post the results here.
 
Just to confirm the same problem with latest SVN version (1145279).

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