I got confused while entering a buy. I did not see, the price was in pence and entered the wrong price. Problem 1: The parent accounts got not updated, after I fixed it. The reason seams to be, the database accepts only one price per day and did not update the price. The result is an inconsistent file. Problem 2: While there should only be one Last or NAV, there will often for several reasons (I give several orders or the brokers split them) be some different buy and sell prices on the same day. In the current form I can not correctly enter the statements of my transactions. From a mathematical point one could enter an weighted average price but would fail every audit. Problem 3: the same day the order is executed, I try to get last prices in the evening for my balance sheet, but the result is ignored, because there is already a buy or sell price in the database.
Not a regression, a conscious design decision that was discussed at great length two years ago: https://lists.gnucash.org/pipermail/gnucash-devel/2015-August/038874.html and replies. Lots of replies. You know very well indeed that the pricedb has nothing at all to do with transactions; transactions don't even have prices, they have an amount and a value, and the price is the calculated ratio value/amount. That's what would be audited and the pricedb has nothing at all to do with it. The pricedb is used only for showing the current net value on the Accounts page and optionally for calculating values in some reports. Since the smallest resolution of reports is daily GnuCash can use only one price per day. There's a hierarchy of price sources with the price editor being the highest, followed by Finance::Quote (so that folks who check prices after the close can have the closing price/NAV as the price in the pricedb), then the various transaction-based inputs (which were added so that there's always a price on the day of a transaction, which helps the "nearest in time" price work better in some reports). Lower-priority sources can't overwrite higher priority ones, so if the user hand-enters a price with the price editor nothing else can overwrite it.
Created attachment 359956 [details] CoA after correcting wrong price illustrating problem 1
That illustrates that the latest price in the pricedb is reflected on the Accounts page, as it always has. It has nothing at all to do with (non)problem 1. BTW it looks more like you overwrote a right price with a wrong one (the price given by Conacher in his email was in cents and you've interpreted it as being in Rand).
Yes, I wrote the wrong price at the beginning and it was recorded to the database. Then I edited the transaction, fixing the price and adjusting the related amounts, but the record in the database got no update. I did not edit the database. I looked there only afterwards, what is recorded there: the old much too high price.
Ah, got it. Editing the transaction didn't change the price created with the original transaction, you need to edit in the pricedb as well or perhaps run F::Q. Could it be that you created the transaction in the currency register and then edited it in the stock register? There's an interesting effect from that: The currency register uses the Transfer Dialog to create prices and the Transfer Dialog has a higher precedence than the split register. They should probably be the same; ISTR discussing that 2 years ago, but settled on the present arrangement to manage backward compatibility with existing prices in the database.
(In reply to John Ralls from comment #5) > Ah, got it. Editing the transaction didn't change the price created with the > original transaction, you need to edit in the pricedb as well or perhaps run > F::Q. But then it gets marked as entered by the user instead of ontered by transaction. > Could it be that you created the transaction in the currency register and > then edited it in the stock register? No, in the commodity account. > There's an interesting effect from > that: The currency register uses the Transfer Dialog to create prices and > the Transfer Dialog has a higher precedence than the split register. Because you have all 3 compontents in the commodity account, no dialog pops up. > They > should probably be the same; ISTR discussing that 2 years ago, but settled > on the present arrangement to manage backward compatibility with existing > prices in the database. That was one of the important discussions, where I just was out of town. It was on my todo list but got forgotten. IMHO all conversion transactions should show up in the database - independent from the place where they are stored. It has been a nice place to analyze my trading before the change. Comparing F::Q last/nav quotes with my realized prices. Where else can I see them together? I agree, because we do not have tools to analyze open, hi, lo, volume we can ignore them and replace last by more recent last or close/last of that day. At least if I change - can be thought as remove and add - a transaction, and it has been the one in the database, it should generate an update of the database.
(In reply to Frank H. Ellenberger from comment #6) > IMHO all conversion transactions should show up in the database - > independent from the place where they are stored. It has been a nice place > to analyze my trading before the change. Comparing F::Q last/nav quotes with > my realized prices. Where else can I see them together? > I think that the Advanced Portfolio Report is the best GnuCash has in the way of portfolio analysis, but remember that GnuCash is an accounting package, not a portfolio tracker or a trading program. I don't use it myself; I track my several portfolios (most of which are accounted in separate books) in http://portfolio.morningstar.com/. Also remember that GnuCash transactions all occur at the same time of day so were we to revert the price db to holding multiple prices per day there would be no way to associate any particular price to its transaction. Which of those multiple prices (all having the same timestamp) would GnuCash use for "nearest in time" reports? Another point: I added the transaction creating entries in the pricedb at about the same time as I changed the pricedb to keep only one price per day, so you can't seriously claim that you used to do intra-day tracking of transaction prices in the pricedb.
(In reply to Frank H. Ellenberger from comment #6) > At least if I change - can be thought as remove and add - a transaction, and > it has been the one in the database, it should generate an update of the > database. I agree. That requires at least making the precedence of the Transfer Dialog and register entry of a price equivalent (though that's apparently not the cause of the problem in this case). It may also require figuring out how to detect a change in price in the register. I don't remember offhand if that was an issue at the time that I worked on that code, but from your description it sounds like it might be. Can you try changing the price in the transfer dialog from the currency account? That should replace the price created in the register.
OK, after confirming "Edit Exchange Rate" and already before the save of the transaction the chart of accounts gets updated. The price Database get updated too, but the type "transaction" gets removed. This is also a loss of information. Re "I think that the Advanced Portfolio Report is the best GnuCash has in the way of portfolio analysis...": Before I used the price db to understand, what the report is calculating, find the most reasonable settings, ...
As I don't do multi-currency in gnucash it's a bit hard to follow the discussion. However it does look like the title is no longer reflecting the bug that remains to be solved. Can you propose a more accurate one ? Secondly is this really "major" ?
I think it's now something like "Price change from editing a transaction not reflected in pricedb" and "enhancement". Frank?
*** Bug 797611 has been marked as a duplicate of this bug. ***
I just verified that editing a stock purchase transaction does not update the entry in the price database that was initially created when the transaction was created. My edit was to change the number of shares, price and total value, which was outside the price tolerance, so it asked me which it should update,and I chose price. When I manually edited the price database to correct the price it changed the type from Transaction to Unknown. I am not sure if there had been a last or NAV entry for the same date whether those would have survived or been lost. I personally believe transaction generated entries should not overwrite last or NAV entries, or vice versa, but I am not sure whether that is a consensus. This is in release 3.8 in Ubuntu 20.04 in case there has been a change, tho any change should have required a change to this bug report. Finally, I think this is a bug, not an enhancement.
Somewhere between Build ID 4.2+(2020-09-26) and Build ID 4.5+(2021-03-27) the behavior of automatic creation of entries in pricedb at the same time that a transaction is created changed. In older version, a price entry is created if none exist on the transaction date. In newer version, no price entry is created. Other related info: backend: mysql gnucash-4.2-1.fc32.x86_64 gnucash-4.5-1.fc34.x86_64
Stephen Baker, I can't reproduce that.
David Carlson, I can't reproduce your problem either in current git-maint: I created a transaction and committed it, then edited it so that the price changed. When I committed the edit the price in the pricedb updated to reflect the edit. But note that in order for the price to update you must be editing the only transaction for that commodity pair on that date and you must not have changed the price any other way: Transaction prices are the lowest priority source. IIRC that's at your request because several years ago you were in the habit of updating your prices after the market closed and you wanted reports to use the closing price instead of the transaction price for that day. When you edited the price is changed to Unknown because that's what you had selected in the Edit Price dialog. Note that user edited prices are the highest priority. Once you've manually edited the price on a day the only way it will change is if you edit it again. Also keep in mind that the pricedb is for reports and the current-value balances on the Accounts page. There's absolutely no value to having more than one price per day per commodity pair: The Accounts page uses only the latest one and since minimum report granularity is a day reports can't use more than one price per day. It looks like the only issue here is that the transfer dialog and split-register are different priorities so that once you've created a price with the transfer dialog you can't change it from the register.
I've pushed a change that allows an edit in the register to replace a price created with the transfer dialog.
