| Summary: | wrong memo field after duplicating and editing transaction | ||
|---|---|---|---|
| Product: | [Applications] kmymoney | Reporter: | Stefan Vater <st.vater> |
| Component: | general | Assignee: | KMyMoney Devel Mailing List <kmymoney-devel> |
| Status: | RESOLVED FIXED | ||
| Severity: | normal | CC: | asoliverez, csioulis, mark.blakeney, ostroffjh, ralf.habacker, Vitezslav.Crhonek |
| Priority: | NOR | ||
| Version: | 4.5 | ||
| Target Milestone: | --- | ||
| Platform: | openSUSE | ||
| OS: | Linux | ||
| Latest Commit: | https://commits.kde.org/kmymoney/fbd612529ed896765b82f37c912d761aa582b8c2 | Version Fixed In: | 4.8.1,5.0.0 |
| Sentry Crash Report: | |||
|
Description
Stefan Vater
2010-09-02 10:22:22 UTC
That's by design, AFAICR The memo fields are per split, not per transaction. 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. 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. 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? 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. 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. 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. 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. 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 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 I raised bug 319807 today but just found this bug which is closely related. Adding a linkage between them. Any chance to solve this? 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 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 |