Matching OFX Import - Changes Transaction Date

[Thomas Baumgart]

On Samstag, 25. Mai 2019 06:14:11 CEST Brendan Coupe wrote:

> I think this is a little different. When I download my credit card I accept
> the dates that the bank processes the transaction even though it may be a
> day or two later than the actual transaction date. Same with checks that
> I've written, sometimes they don't hit the bank for a week or two. I accept
> the date the bank shows since that when it actually happens as far as the
> account is concerned. Doing this any other way sounds like way too much
> work.

I have the same situation/problem here, but my bank includes information about when the purchase happened in the memo field.



Here, transaction is April 26th and purchase happened on April 23rd. Also, no matching happens, as there is no transaction on file until I download from the bank.

> With the paycheck it first ends up in my savings account based on the date
> the bank provides when I download the OFX for the savings account. Many
> categories get assigned when this happens, including the transfers to the
> 401(k) account. When it comes time to import and balance the 401(k) account
> I download the OFX file for it and import it. All of the paycheck related
> transactions are already in the account as transfers from the paychecks.
> The problem is that some of the 401(k) transactions don't register until 4
> to 6 days after they paycheck date. If they match when I import the 401(k)
> OFX file it changes the date on the paycheck and every one of the
> categorized transactions that were originally posted on the date of the
> paycheck.

I suspect that the category assignment happens based on a scheduled transaction (I do the same here with my paycheck). One of the design goals in KMyMoney (and probably in other accounting packages as well) is to have a single post date for a transaction. Therefore, you can have only one date. Also, for imported transactions, it makes sense to use the date the bank supplies as this is the date the funds were booked at the institution. Of course, this leaves a little problem, as you have pointed out.

I have a similar situation in the form of a regular money transfer from one account to another. The money is withdrawn from one account and only deposited on the other end the next (working) day. Both of the accounts are mapped online (but importing downloads would work the same way). To accomplish the date management, I created a transfer (asset) account in KMyMoney and have two transactions, one into the transfer account and one out. The amount is the same. For automatic matching and planning I also have two schedules.

An option I could think of is to use such a transfer account automatically if the post date differs during a match operation. This would require changing the first transaction in the back of the user from the 401(k) to the transfer account in your case, though.

> I have no idea how to correct this but it seems to me that something has to
> be controlling when it comes to the date of the transaction. Right now it
> appears to be the last imported transaction wins. Maybe it shouldn't if the
> existing transaction was already an imported transaction. Or maybe there
> should be an option to use the transaction date of existing transactions
> when a newly imported transaction has a different date.
> 
> After next weeks paycheck I will try re-importing the savings account and
> see if that switches the date back. Not a great workaround since I
> frequently only deal with the 401(k) once a quarter.

I am not sure if this will work. Reason: the transaction is imported and possibly matching transactions are searched for the same payee in the same account. If none are found, then the schedules are searched in the same way. In case a schedule is found, the transaction matches this one split. No more activities are performed, so I expect you might end up with a false balance if you do that, now in both your accounts. It could be that you can correct that by manually matching the transaction in the 401(k) account afterwards. Which postdate it takes might depend on the order you select both those transactions before you press the match button.

> I wish this was the only problem with this problem but the OFX file has the
> wrong sign on all of the numbers so I have to save it, run my growing OFX
> correction script on it and then import it. I have some many accounts
> making this mistake I wonder if there is a way to tell the KMM import
> process to swap the signs for some accounts. probably not since there are
> no settings for the import unless the account is mapped.



We could add such a "Swap sign on all amounts" setting to the file selection dialog as well. It uses the same options as the mapped account. It might get tricky, in case an OFX file contains data for multiple accounts and only one should be reverted.



> On Fri, May 24, 2019 at 5:11 PM Jack <ostroffjh at aya.yale.edu> wrote:
> 
> > On 5/24/19 6:12 PM, Brendan Coupe wrote:
> >
> > I'm importing an OFX file for a 401(k) account (retirement account at
> > work). The transactions are not reported on the date of the paycheck,
> > sometimes they are record close to a week later. When I import the
> > transactions and they match with the category in the paycheck entry in my
> > savings account, the date of the paycheck transaction in my savings account
> > is changed. This happens when they match automatically and when I tighten
> > the import date matching criteria and match them manually.
> >
> > Is there any way to prevent this? The paycheck deposit date should not be
> > changed. It's screwing up that account.
> >
> > ----
> > Brendan Coupe
> >
> > This is another one I've also run into, in my case with checking and
> > credit card accounts.  I prefer to keep my KMM accounts using transaction
> > date, but the imported settlement date or post date of the bank always
> > overrides the manually entered date.  I think I put in a wishlist about
> > this, but I'm not sure.  It makes sense if you are trying to have your KMM
> > account exactly match the institution's account, but not everybody does
> > that.
> >
> > Jack
> >
> 

-- 

Regards

Thomas Baumgart

https://www.signal.org/       Signal, the better WhatsApp
-------------------------------------------------------------
Programming is like sex: One mistake and you have to
support it for the rest of your life. (Michael Sinz)
-------------------------------------------------------------

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.kde.org/pipermail/kmymoney-devel/attachments/20190525/68f5bdc2/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image
Type: image/png
Size: 13784 bytes
Desc: not available
URL: <http://mail.kde.org/pipermail/kmymoney-devel/attachments/20190525/68f5bdc2/attachment-0002.png>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image1
Type: image/png
Size: 20967 bytes
Desc: not available
URL: <http://mail.kde.org/pipermail/kmymoney-devel/attachments/20190525/68f5bdc2/attachment-0003.png>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 868 bytes
Desc: This is a digitally signed message part.
URL: <http://mail.kde.org/pipermail/kmymoney-devel/attachments/20190525/68f5bdc2/attachment-0001.sig>