Bug 451828

Summary:	When importing Online transactions using OFX, transactions may be skipped if occurred on the day of the last update
Product:	[Applications] kmymoney	Reporter:	Dawid Wróbel <me>
Component:	onlinebanking	Assignee:	KMyMoney Devel Mailing List <kmymoney-devel>
Status:	RESOLVED WORKSFORME
Severity:	normal
Priority:	NOR
Version:	5.1.2
Target Milestone:	---
Platform:	Other
OS:	Other
Latest Commit:		Version Fixed In:
Sentry Crash Report:
Attachments:	OFX import options attachment-7347-0.html

Description Dawid Wróbel 2022-03-23 16:09:09 UTC

SUMMARY
I had it happened a few times that when importing transactions, that one or more transaction were not imported due to their posting date — either on the same day (although cannot confirm it) or a day before the date of the previous import. This can reasonably happen since some transactions may simply be cleared by the bank/merchant with a delay and, as such, posted retroactively with a backdate. 

A potential solution would be to always assume a backdated margin of -X days from the last update when executing an import. The X would match the "Match transactions within days" number, specified on Import tab in Ledger settings, thus guaranteeing no duplicates were created upon import.

Comment 1 Thomas Baumgart 2022-03-23 17:29:09 UTC

Created attachment 147685 [details]
OFX import options

Please see attached screenshot. Such an option is already available. If it is not working, then please state that here or close it as not a bug.

Comment 2 Dawid Wróbel 2022-03-23 22:49:26 UTC

Created attachment 147690 [details]
attachment-7347-0.html

This actually isn’t an alternative, as it sets the period of time to a
fixed T minus X. If the last time I downloaded transactions was anywhere
earlier than in the last X days, some transactions will be ignored. What I
want is for KMM to remember when I last downloaded (which it does in
default setup), but also assume extra margin of a few days, so that any
backdated transactions are also included.

On Wed, Mar 23, 2022 at 6:29 PM Thomas Baumgart <bugzilla_noreply@kde.org>
wrote:

> https://bugs.kde.org/show_bug.cgi?id=451828
>
> --- Comment #1 from Thomas Baumgart <tbaumgart@kde.org> ---
> Created attachment 147685 [details]
>   --> https://bugs.kde.org/attachment.cgi?id=147685&action=edit
> OFX import options
>
> Please see attached screenshot. Such an option is already available. If it
> is
> not working, then please state that here or close it as not a bug.
>
> --
> You are receiving this mail because:
> You reported the bug.

Comment 3 Jack 2022-03-23 23:07:46 UTC

Thomas would know better than I, but I thought when you selected date of last update, it actually did use a date three days earlier.   However, making that extra window configurable could be useful in cases like this.

Comment 4 Thomas Baumgart 2022-03-25 07:57:18 UTC

Jack is right: in case you select "Last update" the start date in the request sent to the OFX server will be adjusted by 3 days prior to that. This never caused any problems so far. In case we think 3 days is not enough, we can simply enlarge that to 5 or even 7 or 10 days. Duplicates btw. are detected by the current logic without problems. There is no additional logic needed. The constant subtraction for OFX is performed in MyMoneyOfxConnector::statementStartDate().

The screenshot may have caused some confusion. The selected option was by accident. I did not pay attention when I created it. I just wanted to show that we have options, and obviously the "Last update" is the one you want to use. KBanking for the HBCI protocol does exactly the same and I never missed a single transaction in the last 10+ years or so.

Comment 5 Dawid Wróbel 2022-03-25 15:10:54 UTC

OK, so in that case I don't know what actually happened, as the transaction which went missing was dated one day ahead of the previous update performed. Given that we take -3 days, per your explanations, it should have been downloaded just fine. Weird!

Comment 6 Jack 2024-07-06 18:42:25 UTC

I tend to blame such things on the phase of the moon.   I'm not suer why this wasn't closed but doing so now.  Obviously this can be reopened if the problem recurs.