SUMMARY Duplicating an entry in an investment account leads to errors in the appropriate account "Verrechnungskonto" (Giro). The errors are hard to describe: On the one hand the entry in the "Verrechnungskonto" has a wrong date. And on the other hand it is additionally automatically connected ("Zuordnung") to wrong entries downloaded via aqbanking. Even with a slightly other amount, e.g. 24,97€ and 25,01€. By the way: A more comfortable way to handle mutual fund investment plans would be appreciated. STEPS TO REPRODUCE 1. Duplicate an investment in an investment account. 2. Edit duplicated entry (date, amount) 3. Go to appropriate account "Verrechnungskonto" (Giro) OBSERVED RESULT 1. Wrong date of duplicated entry. 2. Automatic connections to wrong imported entries (amount, date). EXPECTED RESULT Entry with right date in "Verrechnungskonto" (Giro). No automatic connections which are obviously wrong. SOFTWARE/OS VERSIONS Linux/KDE Plasma: Ubuntu 20.04.1 LTS (available in About System) KDE Plasma Version: KDE Frameworks Version: 5.68.0 Qt Version: 5.12.8 ADDITIONAL INFORMATION
Any news here? Can I provide more information?
Does it matter what type of transaction you are duplicating? Have you checked the other account for the transaction before duplicating? Is the date and amount correct to start? In your step #3, is this the brokerage account? Is the date wrong before you even edit it? Is the date OK for the duplicated transaction in the investment account? (Dates are per transaction, not per split, so the date should be the same on both sides.) Why do you say the transaction is connected to an imported transaction? Can you provide a sample .kmy file you can share which demonstrates the error
I don't know if there is much more we can do without some additional information.
I checked this once more. Maybe there are some errors due to faulty duplication of entries (either due to software or user ;-) ) in my .kmy file. But there is still a behaviour which I do not expect: Step 1 Duplicate entry (e.g. from 2020-10-15) in investment account. Entry is successfully duplicated with today's date (e.g. 2020-11-25). Step 2 Go to checking account Duplicated entry was created with today's date. But it is already matched with the old imported transaction from the entry which was duplicated. Even if it is a lot older (e.g. 2020-10-15). Step 3 Still in checking account Unmatch the new matched entry with today's date (e.g. 2020-11-25). The new entry with today's date is shown. But also the former matched, imported transaction is shown. In this case the imported entry from 2020-10-15 exists now twice. And has to be manually deleted, which is particularly annoying if it is in an already reconciled period. But I'm not sure if it is a bug or a feature. If it is a bug which is unreproducible for you, I will try to generate a sample file.
As I understand things, matching of transaction only happens on import, not when duplicating a transaction, so this does seem very strange. So, before you duplicated the transaction, had you accepted the match of the two transactions in the checking account? (what were the dates of the two matched transactions?) It is possible that the transaction duplication code does not take into account matched but not yet accepted transactions. If this is the case, I should be able to generate a test case.
I've duplicated the issue. 1) create a new investment and brokerage account 2) purchase shares in the investment account (I used a date a month ago) 3) import a csv file to the brokerage account to match the purchase transaction 4) go back to the investment account and duplicate the buy transaction 5) go back to the brokerage account, and the new transaction is also matched to a transaction on the original purchase date. Additional note - both transactions show the memo from the imported transaction in both the imported and original transactions, which also seems wrong. I'll attach the test file - this is after the import, but before the duplication. In the short term, I see two things you can do. First, don't duplicate a transaction if one of the splits has been matched, but the match has not yet been accepted. Second, as you have done - unmatch and delete the incorrectly created transaction.
Created attachment 133717 [details] test kmymoney xml file
Modifying the subject to be more descriptive.
Git commit 1f8cd6b4b3af02f7b5e96ad447a48c9c886a7fde by Thomas Baumgart. Committed on 17/07/2021 at 08:54. Pushed by tbaumgart into branch 'master'. Duplicating a transaction must not copy any match information M +1 -0 kmymoney/kmymoney.cpp https://invent.kde.org/office/kmymoney/commit/1f8cd6b4b3af02f7b5e96ad447a48c9c886a7fde
Git commit 1dcf62ed8e4c7ce2fff9f70ce919e95e4b0092ad by Thomas Baumgart. Committed on 17/07/2021 at 09:00. Pushed by tbaumgart into branch '5.1'. Duplicating a transaction must not copy any match information FIXED-IN: 5.1.3 M +1 -0 kmymoney/views/kgloballedgerview.cpp https://invent.kde.org/office/kmymoney/commit/1dcf62ed8e4c7ce2fff9f70ce919e95e4b0092ad