Bug 319807

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.

Can a developer review this bug and comment please?

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?

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?

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.

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).

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.

I agree with Cristian. I think a general setting would be better. ie "Copy memos when reusing transactions?" in the Editor settings.

Review request at https://git.reviewboard.kde.org/r/112924/ for a proposed patch.

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