I set this up and don't think this is a great option. First of all, it
only works for regular transactions that you can easily schedule. Many
of my bills do not occur on the exact same day each month.
The second problem is that it doesn't work great for the paychecks that
vary by a penny or two every week. Due to how withholding taxes are
calculated for each check, they sometimes vary by $0.01 and since this
can happen for 2 or three line items, the total paycheck amount changes
by $0.01 to $0.03 over many weeks. Before, when this happened, the check
would usually match a previous check that had the same variations. Now,
since the scheduled transactions are fixed based on the one I chose to
base it on, I have to adjust the splits more than half the time (so
far). I'm sure that adjusting the scheduled transaction to match the
most recent two will guarantee the next check will match the original
splits (Murphy's Law).
A scheduled transaction works better for the occasional check that has a
large expense reimbursement but, so far, has been more of a hassle for
weekly checks.
A payee based limit on the time frame for matching would be much better
for my situation.
I will submit a wish list item and hope for the best.
**
*Brendan Coupe*
*3...@coupe7.com*
On 1/23/23 11:53 PM, Thomas Baumgart via KMyMoney-devel wrote:
On Dienstag, 24. Januar 2023 02:32:37 CET Brendan Coupe wrote:
On 1/22/23 11:54 PM, Thomas Baumgart via KMyMoney-devel wrote:
Brendan,
On Sonntag, 22. Januar 2023 20:35:39 CET Brendan Coupe via KMyMoney-devel wrote:
When I import transactions via direct connect or with OFX files, KMM
appears to match the new transaction to the previous transaction with
the same Payee based on the transaction total that is closest to the new
transaction total.
This normally works pretty well but in the case of paychecks, it makes a
complete mess of the splits. My wife has received about 300 paychecks
from her company. When the total changes, sometimes even slightly, the
new transaction can match a paycheck from 5 or 6 years ago. This means
that the splits are all wrong. This happens many times each year due to
changes in some taxes, travel expenses reimbursements and for other
reasons. I usually have to delete the imported transaction, copy the
previous paycheck, change the date and amount, fix the one or two splits
that caused the total to change and then re-import the new transaction
and match it to the one I entered manually. Pretty frustrating. There
are so many transactions from the same payee it's starting to happen
when the difference is less than $1.00.
In the KMM config settings under Ledger, Import you can set the limit to
match transactions within a certain number of days. This has no affect
on this process and probably shouldn't. I think that is meant for a
different purpose.
Unless I'm missing something, I propose that a similar option be added
to each payee. The default should probably stay as it is, but in the
"Matching" tab, it would help to able to limit the time frame used for
selecting which transaction to match. In my case, I would limit the
paychecks to no more than 15 days since I am much more interested in the
splits matching than the totals matching. This would limit the matching
to the 2 previous paychecks. A Payee customizable limit on the percent
difference in the transaction total might also be useful. I would not
set this since I do not care how much the total changes.
Please let me know if I'm missing a setting that would solve this now or
if anyone has a better idea. I will submit this as a wishlist item based
on the feedback.
Do you have a schedule setup for the paycheck transaction?
No I don't.
Take the last pay-check transaction with all the splits and create a schedule
based on it. On next import, KMyMoney will use it as the base for the splits.
Adjust the schedule whenever something changes for good (e.g. total amount).
Adjust the splits that vary after the schedule has been entered.
BEGIN:VCARD
VERSION:4.0
EMAIL;PREF=1:3...@coupe7.com
FN:Brendan Coupe
N:Coupe;Brendan;;;
TEL;VALUE=TEXT:310.626.5380
UID:0c8bfd4a-9d10-40a9-8513-f45eb1fbb169
END:VCARD
