Bug 319807 - New transaction from memorised carries old memo
Summary: New transaction from memorised carries old memo
Status: RESOLVED FIXED
Alias: None
Product: kmymoney
Classification: Applications
Component: general (show other bugs)
Version: 4.6.3
Platform: Other Linux
: NOR normal
Target Milestone: ---
Assignee: KMyMoney Devel Mailing List
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2013-05-14 01:16 UTC by Mark Blakeney
Modified: 2013-09-29 07:58 UTC (History)
2 users (show)

See Also:
Latest Commit:
Version Fixed In:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Mark Blakeney 2013-05-14 01:16:00 UTC
I am using automatic VAT/GST splits on my transactions. If I start entering a payee and then select a transaction from the memorised list then enter a new memo on that new transaction then the transaction will always only update the memo on the main transaction. It will keep the first ever entered memo on the split for the main amount.

This is a really unfortunate bug. Means I give a report to my account and the memo descriptions are all wrong (because they are very old and don't correspond to the actual transaction). This bug has existed for a while but I have not got around to reporting it because I assumed it would get fixed eventually. Seems it has not been noticed by many.

Reproducible: Always

Steps to Reproduce:
1. As above
2.
3.
Actual Results:  
Expect new memo on the main split.

Expected Results:  
Old memo still on split.
Comment 1 Mark Blakeney 2013-05-14 01:57:31 UTC
OK, have been hunting in detail through the KDE KMM bug tracker and have found bug 249844 from 2010 which is very closely related. Plenty of discussion there where some developers claim this issue is "by design". Here, that argument is less appropriate because a memorised transaction bears less relationship to the new transaction. Either way, I disagree strongly that this is desirable functionality. The original main split memo was created from the main transaction memo, so it should also be for a new transaction.

My words are not clear from 1st description here, I mean't to say that I give a KMM report to my accountant but it is extremely confusing because she sees all old memo descriptions on the main amount splits, unless I remember to go through an entire year of transactions and manually update them by hand before I produce the report. What a pain.
Comment 2 Mark Blakeney 2013-09-10 13:17:49 UTC
Can a developer review this bug and comment please?
Comment 3 Alvaro Soliverez 2013-09-10 13:51:12 UTC
Copying the memos from old transactions is "by design", as you stated. The memos are per split, actually.

In your case, you'd like that memos are not copied when you reuse a transaction from a payee, right?
Comment 4 Mark Blakeney 2013-09-10 22:51:40 UTC
Oh no, the fact that you say "In your case", and then "you'd like" shows that I have failed to communicate that this problem has nothing to do with anybody's personal preferences and is just a straight out flaw. :(

KMM automatically copies the main transaction memo to the primary split of an auto VAR/GST transaction (and it does the auto splitting well which is one of the reasons I chose KMM over Gnucash 7 years ago when I migrated from Quicken). The problem is that if you add a second or later transaction, based on that original "memorised" transaction, and of course you add a new memo as well, then KMM does not copy that new memo to the new primary split. The bug is that it keeps the memo from the 1st original transaction.

So, e.g., I may buy a Macbook from Apple Store one month, next month I buy an iPad, next month I buy an iPhone. When I produce an expenditure report all those transactions are listed with a memo "Macbook" even though I explicitly wrote "iPad", and then "iPhone" on the memo field of the new Apple Store transactions (note the expenditure report lists per category, i.e. per split). The only way around this is to edit the split of the new transactions and manually rewrite the (hidden) memo field a second time for every entry. Surely you can see this is a bug?
Comment 5 Jack 2013-09-10 23:49:41 UTC
I have to agree it's not a bug, but perhaps the feature doesn't really serve it's purpose as originally designed.  Note that when you select what you call a memorized transaction - it's not "memorized" in any special way, it's just one previous transaction for that payee.  The new transaction is then created as a complete copy of that old transaction.  A transaction has a number of splits, and there isn't a "primary" split, although it is sometimes easy to think of it that way.  I suspect the memo of the transaction itself as well as the memo of each split (they can actually all be different) are copied.  (I have not tested this right now, but I'd be surprised if this isn't what happens.)  When you do create a new transaction by copying an old one this way, I think it should be your responsibility to check the splits before accepting the transaction.  If you need to make changes, then perhaps it would have been better to not copy but just create a new transaction from scratch.  If you want to be able to copy an old transaction with certain parts of it (amounts or memos, for example) blanked out, that would be a reasonable enhancement request.  

Just because it doesn't do what you want or expect doesn't necessarily make it a bug.  There is a bit of perspective involved.  However, if the manual describes this in an incorrect or misleading way, please let me know, and I'll look at rewording the documentation.
Comment 6 Mark Blakeney 2013-09-11 00:02:08 UTC
Of course I understand how splits work, and how "memorised" transactions work. I used the term "primary" split because in this case, where people are using auto tax (gst/var) splits then there are only two splits: the "primary" split, and the tax split created automatically by KMM. This is how 99.9% of my split transactions are (and probably also for anybody else who uses KMM for tracking var/gst business expenses).

I am surprised you would expect the user to hand enter the memo field twice, particularly when the second copy is hidden in the split window so it is hard to see and easy to forget to fix). I don't understand why this can't be changed so that when a user explicitly enters a new memo on a transaction then that memo should be also copied by KMM to the main (i.e. primary) transaction in the split (when the only other split is the one automatically created by KMM specifically for that new transaction).
Comment 7 Cristian Oneț 2013-09-11 07:11:44 UTC
I don't have a strong feeling neither about the current behavior or the one which is requested by Mark that is to automatically copy the memo to all splits when the memo of one split is edited.

So maybe we could accommodate both using a configuration option (I know we already have a lot of them) or by asking the user when needed (the memos differ) using a message box with "Don't ask again" option.

Or yet another option to clear the memos when a previous transaction is used. I would have found this option useful a few times myself because memos usually contains transient per transaction information which is no longer valid when the transaction is reused as a template for another transaction.
Comment 8 Alvaro Soliverez 2013-09-11 11:00:19 UTC
I agree with Cristian. I think a general setting would be better. ie "Copy memos when reusing transactions?" in the Editor settings.
Comment 9 Cristian Oneț 2013-09-25 04:21:31 UTC
Review request at https://git.reviewboard.kde.org/r/112924/ for a proposed patch.
Comment 10 Cristian Oneț 2013-09-29 07:58:08 UTC
Git commit 092f3a79f4ec74d25e0f5a4b9c80dfef64db5da3 by Cristian Oneț.
Committed on 25/09/2013 at 04:08.
Pushed by conet into branch 'master'.

Add a configuration option that allows the user to choose between
reusing or not the memos of a previous transaction when autofilling.
REVIEW: 112924

M  +13   -0    kmymoney/dialogs/settings/ksettingsregisterdecl.ui
M  +2    -1    kmymoney/dialogs/transactioneditor.cpp
M  +4    -0    kmymoney/kmymoney.kcfg

http://commits.kde.org/kmymoney/092f3a79f4ec74d25e0f5a4b9c80dfef64db5da3