Created attachment 162238 [details] Deposit changes into Payment when changing "Transfer from" SUMMARY When changing the "Transfer from" of a transaction a Deposit is changed into a Payment. STEPS TO REPRODUCE 1. Existing transaction with "Transfer from" has a Deposit 2. Change "Transfer from" to other account or a category 3. Now Deposit is changed to Payment OBSERVED RESULT Now Deposit is changed to Payment EXPECTED RESULT Deposit should stay Deposit SOFTWARE/OS VERSIONS Windows: 10 macOS: Linux/KDE Plasma: (available in About System) KDE Plasma Version: KDE Frameworks Version: Qt Version: ADDITIONAL INFORMATION This bug is causing reconciliation problems. A balance that was initially reconciling now suddenly is out of sync. Initially you think this is human error until you notice that the application changes a Deposit into a Payment.
Created attachment 162239 [details] Transaction has changed into a Payment after changing "Transfer from"
The first thing I would suggest is updating to 5.1.3. There have been changes in the terminology, so there is no longer a "transfer from" or "transfer to" label. The first field is now Payer/Receiver and the second is Category/Account. Changing either the Payee/Payer or the category for me does not change between Payment and Deposit.
Have KMyMoney 5.1.3 running on Ubuntu 22.04 LTS on Windows WSL. See attachments. Same GUI and same behavior. Transaction changed from deposit to payment when changing account.
Created attachment 162253 [details] Ubuntu version 5.1.3 Ubuntu version 5.1.3 running on WSL of Windows 10. Accessing the Windows 10 KMyMoney file via mount.
Created attachment 162254 [details] Ubuntu Transfer from Ubuntu with KMyMoney 5.1.3
Created attachment 162255 [details] Ubuntu version 5.1.3 : deposit change topayment KMyMoney 5.1.3 changes transaction deposit to payment when changing the account.
Dear Bug Submitter, This bug has been in NEEDSINFO status with no change for at least 15 days. Please provide the requested information as soon as possible and set the bug status as REPORTED. Due to regular bug tracker maintenance, if the bug is still in NEEDSINFO status with no change in 30 days the bug will be closed as RESOLVED > WORKSFORME due to lack of needed information. For more information about our bug triaging procedures please read the wiki located here: https://community.kde.org/Guidelines_and_HOWTOs/Bug_triaging If you have already provided the requested information, please mark the bug as REPORTED so that the KDE team knows that the bug is ready to be confirmed. Thank you for helping us make KDE software even better for everyone!
Have repeated the same test on Windows 10 KMyMoney 5.1.3 Same result: transfer from is changed to transfer to after changing transfer from. For example change Computer Equipment to Home Content.
Created attachment 162721 [details] Windows 10 KMyMoney 5.1.3 About dialog
Created attachment 162722 [details] Windows 10 KMyMoney 5.1.3 Transfer From Windows 10 KMyMoney 5.1.3 Transfer From transaction
Created attachment 162723 [details] Windows 10 KMyMoney 5.1.3 Transfer To Windows 10 KMyMoney 5.1.3 Transfer To transaction. After changing the value of Transfer From field from Computer Equipment to Home Contents the transaction type is change to "Transfer To"
Have tested this bug on 3 different computers with KMyMoney 5.1.3. All 3 computers same bug.
This issue is fixed on the master branch and I don't know if we have the resources to tackle this on the 5.1 branch. I am tempted to resolve it either as "LATER" or "FIXED in 5.2" (which we currently use for the next stable branch). Feedback is welcome.
There is one open bug (327890) marked as fixed in 5.2 - it was opened against 4.6.3. If I mark it as a duplicate of 303562, already closed against 5.2, that leaves 14 bugs closed as fixed in 5.2. I'm adding 5.2 for this bug, but leaving open for now, just in case someone wants to try fixing it in the 5.1 branch.
(In reply to Thomas Baumgart from comment #13) > This issue is fixed on the master branch and I don't know if we have the > resources to tackle this on the 5.1 branch. It might be helpful to know the corresponding commit from the master branch where this problem was fixed. Maybe someone can be found to backport this commit.
It's not a single commit or a series since the whole logic changed. It needs to be fixed in different ways in the 5.1 branch.