[kmymoney] [Bug 400465] Imported transactions are not matched against reconciled transactions

[Phillip Vuchetich]

https://bugs.kde.org/show_bug.cgi?id=400465

Phillip Vuchetich <phil at vuchetich.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
           Platform|Other                       |Microsoft Windows
                 CC|                            |phil at vuchetich.com
                 OS|Linux                       |Microsoft Windows
            Version|5.0.0                       |5.1.3

--- Comment #4 from Phillip Vuchetich <phil at vuchetich.com> ---
I am not original reporter, but this has frequently affected importing at least
on the MS Windows 10 platform at least in previous versions (The one I was
previously using appears to have been labeled 5.1-bbdd7eb6f).  In previous
versions, imports from bank and credit cards in OFX format would typically
import duplicates that required manual cleanup.  This would typically happen in
the following scenario:
1. Import (OFX) a partial month of current transactions (perhaps the first to
15th of the month).
2. Process these (accept, match, edit categories, etc.)
3. After the month completes, import a new file with the entire month (to match
a billing/statement cycle), including both known duplicates (days 1-15) and
known new transactions (days 16-end of month).
4. The outcome is that duplicates would typically be close to 100% of
transactions that should have been able to match. 

I have just upgraded to the 5.1.3  (stable: file labeled
kmymoney5-mingw64-5.1.3-3.1.12-setup.exe) version and will be importing things
over the next few weeks.  I plan to report back if it looks like imports are
generally clean or if it can be easily reproduced.  I have Windows 10, Ubuntu
20.04 and FreeBSD 13.1 as readily available desktops in case the issue affects
only some platforms.

Suggestion: Leave this open for another month so I can get multiple imports of
valid data in the current version.

I have an financial account that uses QIF, but have few transactions.  Anyone
working on the programming for QIF import functionality knows that the QIF is
very limited in its data fields for deduplication. The QIF I receive has only
Date (D), Amount (T), and Payee (P) fields.

-- 
You are receiving this mail because:
You are the assignee for the bug.