https://bugs.kde.org/show_bug.cgi?id=345259
Glenn <k...@g.zazu.com> changed:
What |Removed |Added
----------------------------------------------------------------------------
CC| |k...@g.zazu.com
--- Comment #7 from Glenn <k...@g.zazu.com> ---
I noticed this bug report because I observed the impact of this fix which was
released just a few days ago. The new behavior seems incorrect to me. I agree
completely with Jack: the purpose of the transactions match setting should be
for automated/system matching, not to prevent manual matching. I want to keep
that setting short (4 days seems reasonable) to prevent unintended matching
when downloading transactions. However, when managing paper checks, it is
quite common that a check isn't deposited or cleared for many days or weeks --
certainly beyond that setting window. In such cases, I should be able to
manually match the downloaded transaction to the transaction that I entered
weeks earlier.
Allan wrote: "a suitably wide setting for the match-window should allow you to
match such transactions, shouldn't it?" Absolutely not. What's suitable for
manual matching is completely unsuitable for automatic matching and vice versa.
It would be fine for the program to prompt for confirmation when attempting to
manually match two transactions whose dates differ by a greater amount than the
configured match setting, but a user should be able to manually match without
needing to go back to the original transaction and change its date or needing
to change the setting to a value so high as to become useless for protecting
against improper automated matching.
--
You are receiving this mail because:
You are the assignee for the bug.
_______________________________________________
KMyMoney-devel mailing list
KMyMoney-devel@kde.org
https://mail.kde.org/mailman/listinfo/kmymoney-devel
