A price entered in the price table automatically through the creation of an investment transaction is not changed when the date of the corresponding transaction is changed, causing an incorrect price entry. Reproducible: Always Steps to Reproduce: 1. Enter a transaction in an investment account 2. Check that a new price was added in the price table 3. Change the date of the transaction 4. Verify that the price table was not corrected accordingly. Actual Results: The price table contains a [transaction] price with incorrect date Expected Results: The price table is updated consistently with the corresponding transaction
Thank you for reporting this bug in KDE software. As it has been a while since this issue was reported, can we please ask you to see if you can reproduce the issue with a recent software version? If you can reproduce the issue, please change the status to "CONFIRMED" when replying. Thank you!
Jan, Thanks for the update. Can you please let us know which recent version is still showing the problem? In case you haven't already figured it out, a workaround would be to edit the price entry after editing the transaction, although I know that means you would have to know/remember that the transaction created the price entry. However, I don't imagine it is often necessary to change the date of such a transaction, other then correcting a data entry error. Just as a note, aside from correcting the price entry, it would be necessary to check for any other transactions for the same security on the same date, to ask the user if they also need to have their date changed. If not, then the action would be to create a new price entry, not just to change the date of the existing one.
> Can you please let us know which recent version is still showing the problem? The bug is in 5.08. I would be surprised it was fixed in newer versions. > In case you haven't already figured it out, a workaround would be to edit > the price entry after editing the transaction, although I know that means > you would have to know/remember that the transaction created the price > entry. The price is correct. Only the date is wrong. > However, I don't imagine it is often necessary to change the date of > such a transaction, other then correcting a data entry error. It happens most when I copy a previous transaction and edit it. That's faster than redefining all the fields. > Just as a note, aside from correcting the price entry, it would be necessary > to check for any other transactions for the same security on the same date, > to ask the user if they also need to have their date changed. If not, then > the action would be to create a new price entry, not just to change the date > of the existing one. So the prices stored as a history are not linked to transactions, if that's how they have been defined. I think there should be no confusion possible, as the price for which the date needs to be changed must be exactly the same as in the transaction that is being edited. If there is another transaction for the same security on the same day, either the price will be different, or else it does not matter which one is changed (that is, if both the date and the price are the same). If the edit changes both date and price, the same applies.
A bit of clarification: the update of the price table is an option and there is no link of the price information stored with the transaction to that entry. Imagine you enter two transactions for the same investment on the same date with two different prices and in both cases the price table is updated. In that case, the last entered price information is recorded. Now you change the date of the first entered transaction but changing the price table in that case is simply wrong. Even though this may be rare it is a potential problem. I would rather not change the price table without user intervention/acknowledgement/.... With this said, so far the application behaves as designed. > It happens most when I copy a previous transaction and edit it. That's faster than redefining all the fields. Well, that sounds to me that the price entry in the history already happens when the duplicate is created. In that case, that is the problem and can be fixed (i.e. remove price table entry generation upon duplication).
(In reply to Thomas Baumgart from comment #4) > Well, that sounds to me that the price entry in the history already happens > when the duplicate is created. Not quite. The problem only happens if at first the date is wrong and I need to edit the transaction again to fix it.
I sense some confusion about timing. When you duplicate a transaction, the new duplicate always gets the current date. If a new price entry is created when the transaction is duplicated (I have not yet tested) it seems like it is almost always going to be the wrong date. As Thomas said, once a price entry is created, although it does say the price came from a transaction, there is no further connection between that transaction and the price entry. I can think of some possible approaches to handle this issue, but it's going to take me a while to write them down coherently, at which point I'll post them to this bug, and perhaps change it to a wish list. In the short run, if simply not creating a new price entry when an investment transaction is duplicated, I'll leave this bug as requesting that change, and create a new one for a more complete change.
> When you duplicate a transaction, the new duplicate always gets the current date. Correct, but he mere fact of duplicating a transaction DOES NOT create a new price entry. This is not just an issue with duplicated transactions. A price generated from a transaction will not be adjusted after that transaction has been edited. So, if you manually create a new transaction, as soon as you save it, a price will be generated. If subsequently you edit that transaction, or even delete it, the generated price remains unchanged. You can changed the date, the cost, even the name of the stock, it will not affect the initial price. BTW, if you change the name of the stock of an existing transaction, it will generate another new price in the history. Conclusion: Editing any existing transaction for which a price has been generated does not update that price.
OK - I over focused on the copying to create a new transaction. The underlying issue is as Thomas said - once a price entry is created by creating a new transaction, there is no longer any connection between the price entry and that transaction. Any edit to either one will have no effect on the other. KMM is behaving as designed. As that behavior can lead to incorrecct data, the main question is what to do about it. I don't see any short term simple solution. My proposal would be to switch this to a "wishlist" and change the subject to "Allow editing an investment transaction to appropriately update any associated price entry." I think that will be the best placeholder so the issue is not forgotten. One possible (although admittedly inadequate) solution would simply be to warn the user when a transaction is edited in any way that might invalidate a related price entry.
I understand. Nothing urgent indeed, but it remains undesirable to have obviously incorrect data in the database and do nothing about it. Which is why I would consider it a bug rather than a wish after all. Issuing a warning suggesting the user to fix it manually could be a stopgap solution, but not a fix.