Bug 249844 - wrong memo field after duplicating and editing transaction
Summary: wrong memo field after duplicating and editing transaction
Status: RESOLVED FIXED
Alias: None
Product: kmymoney
Classification: Applications
Component: general (show other bugs)
Version: 4.5
Platform: openSUSE Linux
: NOR normal
Target Milestone: ---
Assignee: KMyMoney Devel Mailing List
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2010-09-02 10:22 UTC by Stefan Vater
Modified: 2019-08-29 00:22 UTC (History)
6 users (show)

See Also:
Latest Commit:
Version Fixed In: 4.8.1,5.0.0


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Stefan Vater 2010-09-02 10:22:22 UTC
Version:           4.5 (using KDE 4.5.0) 
OS:                Linux

When I duplicate a transaction (with no splits) in the ledger view and then edit the memo field, the memo field in the splits view and in the other account (from/to where the money is transfered) is still the old one. I have either to edit the splits (delete all - hit OK - leave total amount as originally specified), or to clear the other account - leave the transaction - reenter other account.

Reproducible: Always

Steps to Reproduce:
see Details


Expected Results:  
edited memo field appears also in other account/splits view (if transaction is not splitted)
Comment 1 Alvaro Soliverez 2010-09-02 11:43:04 UTC
That's by design, AFAICR

The memo fields are per split, not per transaction.
Comment 2 Stefan Vater 2010-09-02 12:04:36 UTC
But it is highly nonintuitive, since it is not visible to the user at once. When I have duplicated an old transaction (WITHOUT splits) and edited the memo field, I expect that this is also done for the other account. You only get the error, when you look at the transaction list of the other account.

In my experience, you often have very similar transactions, which only differ by the memo field. Then, the "obvious" solution is to duplicate the old transaction and adjust the memo field a bit.
Comment 3 Alvaro Soliverez 2010-09-02 12:22:45 UTC
What may seem obvious to you, it's not to someone else.

I agree that a better solution may be found, but there is no obvious one.
Comment 4 Stefan Vater 2010-09-02 16:20:55 UTC
OK, I agree. It might depend on the point of view.

But think of the simple scenario: You entered a new transaction between two accounts and you made a typo in the memo field. In the current bahaviour, you have go to both accounts (or to the splits dialog) to change it everywhere. Otherwise the data are some kind of incosistent. 

Would it be reasonale/make sense to introduce a test or search for such cases?
Comment 5 Jack 2010-09-02 16:29:26 UTC
Would it be possible (and reasonable) to create some sort of flag or popup that tells the user when saving a transaction that would leave the memo different from the other split?  It could offer choices such as: OK, OK and don't tell me again, make the other one the same as this one, save this one and then display the other one.
Comment 6 Alvaro Soliverez 2010-09-02 16:31:10 UTC
How can we discern whether you intended to modify both, or you only wanted to change one of the memos?

By design, each split has its own memo.

I'm all for adding some UI help when modifying the memos, to remind or help on modifying all memos.

But, the memos are per split and not per transaction, and modifying the memo for only one split is a very valid use case. That has to be taken into account when modifying that area.
Comment 7 Jack 2010-09-02 16:45:44 UTC
I did not suggest making any change automatically - only to inform the user when the save is creating a split with a memo different from the split on the other side of the transaction.  The user can then decide whether to take any action or not.  Maybe that means it would be too dangerous to include the "make the other one like this one" since there may be more than one other split in the transaction.  Clearly there is some possible enhancement here - but I'll continue the discussion of splits on the mailing list, since it's not specific to this bug/wishlist.
Comment 8 Stefan Vater 2010-09-06 10:07:24 UTC
Hi, I just realized that the same is happening for the payee: Enter a new transaction between two accounts, save it, reenter it and change the payee name. When going to the other account, there is still the old name. The payee should be definitely per transaction, not per split. 

Maybe this is worth another bug report. However, since the problem is very similar, I wrote it into this bug.
Comment 9 csioulis 2010-09-06 21:25:39 UTC
Dear Stefan,
I totally disagree with the expression "The payee should be definitely per transaction, not per split", especially when the transaction is a "transfer" (as it is in your report) where two -or more- accounts (=not one account and some categories, like in deposits and at withdraws) are involved.
Both Memo, Payee (and 'No') fields SHOULD BE 'per split' in this occasion, and it SHOULD BE easy to entry, see and edit any of them per split.  

From my point of view, there are much more situations where you would like to be able to assign different Payee, Memo and No values at the two (or more) splits of a transfer transactions to avoid some inconsistencies in KMyMoney! For example, if you credit your supplier when you receive goods and, then, in a next day, you pay him, you need to assign in "Payee" field: a) his name in your asset account (cash or checking) from where you pay him, and b) your name (or even your partner's name -if you are a company) as a "payer" to his (liability) account (where you debit the amount of the transfer), to have the right balance in his payee view. (see the 'WONTFIX" Bug No 141364 for details).
My way to overcome this is to change/modify the payee at the "half-part" of the transfer transaction  (in supplier liability ledger) for the first time and then, for every next payment to this supplier I duplicate this "half-corrected" (with the different Payees in each split) transaction editing only the date and the amount (and maybe the memo) fields!    

So, the problem that you describes exists, but IMHO it is problem of the data-entry GUI especially in transfer transactions, not of the data structure.
If only you had in front of you both of "Pay From" and "Pay to" payees fields to fill in in the data entry form, you should resolve a lot of issues - such as this in the current bug report.
 
It is more than 1 year that I insist that there are a lot of problems about transfers in KMyMoney -see post http://forum.kde.org/viewtopic.php?f=69&t=29110 "Transfer need DUAL Payee, Memo and No fields in form to entry" for some argues on it.

Another useful thread on this issue (with many links to similar discussions) you can see at:    
http://sourceforge.net/mailarchive/forum.php?thread_name=w2p64e15f8f1004281745xfa74a637m912461f8d45e3b4d%40mail.gmail.com&forum_name=kmymoney2-developer (started at 25/4/10 by Charles Merriam)

I hope that I will find soon the time to write analytic bug reports and proposes about the "transfer issue".
S. Chris
Comment 10 Stefan Vater 2010-09-07 10:18:46 UTC
Dear Chris,
thanks for your clarification. I did not know, that these issues have been already discussed multiple times. I am not a an expert in financial book keeping; so these cases were not obvious to me. I agree now, that a redesign of the transaction editing would be probably the solution to my problems. But if you do not know of these subtleties, then you could get very confused, when editing transactions at the moment.

However, I see a problem in the complexity of these issues. Up to now one thing which was always mentioned about kmymoney, was its simplicity. But, if you change the transaction editing as you suggested in your post, things might get complicated for the inexperienced user. I am not sure if it is possible to have an expert mode (for experienced users) and a simple mode (for unexperienced ones), the latter fixing these issues by simply keeping track that the payee etc. is always the same on both sides.

If I got it correctly, Alvaro suggest a disscussion about the redesign of the ledgers view anyway, some time ago. I hope that these issues will be incorporated into this.

Thanks for the instructive discussion!
Stefan
Comment 11 Mark Blakeney 2013-05-14 01:58:40 UTC
I raised bug 319807 today but just found this bug which is closely related. Adding a linkage between them.
Comment 12 Vitezslav.Crhonek 2016-06-15 13:01:16 UTC
Any chance to solve this?
Comment 13 NSLW 2017-05-14 04:42:08 UTC
Git commit 398304bcf331a322a0fe7e475775aea887c4b565 by Łukasz Wojniłowicz.
Committed on 14/05/2017 at 04:40.
Pushed by wojnilowicz into branch 'master'.

Update memo in the other split if requested
FIXED-IN:5.0

M  +7    -3    kmymoney/dialogs/transactioneditor.cpp

https://commits.kde.org/kmymoney/398304bcf331a322a0fe7e475775aea887c4b565
Comment 14 Thomas Baumgart 2017-05-14 13:17:27 UTC
Git commit fbd612529ed896765b82f37c912d761aa582b8c2 by Thomas Baumgart.
Committed on 14/05/2017 at 13:16.
Pushed by tbaumgart into branch '4.8'.

Update memo in the other split if requested
FIXED-IN:5.0
(cherry picked from commit 398304bcf331a322a0fe7e475775aea887c4b565)

and adapted to work on Qt4.8

Signed-off-by: Thomas Baumgart <thb@net-bembel.de>

M  +7    -3    kmymoney/dialogs/transactioneditor.cpp

https://commits.kde.org/kmymoney/fbd612529ed896765b82f37c912d761aa582b8c2