Bug 426161 - Duplicating an investment transaction also duplicates a matched but not accepted transaction in the brokerage account with original not the new date on the matched transaction
Summary: Duplicating an investment transaction also duplicates a matched but not accep...
Alias: None
Product: kmymoney
Classification: Applications
Component: general (show other bugs)
Version: 5.1.0
Platform: Compiled Sources Linux
: NOR major (vote)
Target Milestone: ---
Assignee: KMyMoney Devel Mailing List
Depends on:
Reported: 2020-09-03 19:14 UTC by TobIs
Modified: 2021-07-17 09:01 UTC (History)
1 user (show)

See Also:
Latest Commit:
Version Fixed In: 5.1.3

test kmymoney xml file (18.27 KB, text/xml)
2020-11-28 23:00 UTC, Jack

Note You need to log in before you can comment on or make changes to this bug.
Description TobIs 2020-09-03 19:14:23 UTC
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.

1. Duplicate an investment in an investment account.
2. Edit duplicated entry (date, amount)
3. Go to appropriate account "Verrechnungskonto" (Giro)

1. Wrong date of duplicated entry.
2. Automatic connections to wrong imported entries (amount, date).

Entry with right date in "Verrechnungskonto" (Giro). No automatic connections which are obviously wrong.

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

Comment 1 TobIs 2020-11-18 19:34:32 UTC
Any news here? Can I provide more information?
Comment 2 Jack 2020-11-18 19:55:54 UTC
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
Comment 3 Jack 2020-11-25 01:09:30 UTC
I don't know if there is much more we can do without some additional information.
Comment 4 TobIs 2020-11-25 20:52:24 UTC
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.
Comment 5 Jack 2020-11-28 22:09:02 UTC
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.
Comment 6 Jack 2020-11-28 22:59:30 UTC
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.
Comment 7 Jack 2020-11-28 23:00:23 UTC
Created attachment 133717 [details]
test kmymoney xml file
Comment 8 Jack 2020-11-29 22:30:52 UTC
Modifying the subject to be more descriptive.
Comment 9 Thomas Baumgart 2021-07-17 08:54:39 UTC
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

Comment 10 Thomas Baumgart 2021-07-17 09:01:45 UTC
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