| Summary: | KMymoney crashes on importing QIF | ||
|---|---|---|---|
| Product: | [Applications] kmymoney | Reporter: | Denis <spaarks> |
| Component: | general | Assignee: | KMyMoney Devel Mailing List <kmymoney-devel> |
| Status: | RESOLVED FIXED | ||
| Severity: | crash | CC: | agander93 |
| Priority: | NOR | ||
| Version: | 4.6.1 | ||
| Target Milestone: | --- | ||
| Platform: | Debian stable | ||
| OS: | Linux | ||
| Latest Commit: | http://commits.kde.org/kmymoney/81d6396a66534f2e95eac89aab19282575554f97 | Version Fixed In: | |
| Sentry Crash Report: | |||
| Attachments: |
attachment-2567-0.html
attachment-2567-1.dat powerni.qif attachment-19562-0.html attachment-19562-1.dat uscurrent.qif attachment-19987-0.html attachment-19987-1.dat uscurrent6.qif |
||
|
Description
Denis
2012-10-11 15:14:41 UTC
Created attachment 74485 [details]
attachment-2567-0.html
Importing of QIF files is very dependant on the actual structure of the file, because the QIF format is very loose. Is MoneyManagerEX able to import the file?
What size is the file?
Is there the possibility that you could provide the file, or a simplified version that still shows the problem, with no personal info included? Or, could you send the file to me, privately.
Thank you, The file size is 669 bytes. MoneyManagerEX is able to import the file OK. Attached is the file. On Thu, Oct 11, 2012 at 9:13 AM, allan <agander93@gmail.com> wrote: > https://bugs.kde.org/show_bug.cgi?id=308247 > > allan <agander93@gmail.com> changed: > > What |Removed |Added > > ---------------------------------------------------------------------------- > CC| |agander93@gmail.com > > --- Comment #1 from allan <agander93@gmail.com> --- > Importing of QIF files is very dependant on the actual structure of the > file, > because the QIF format is very loose. Is MoneyManagerEX able to import the > file? > > What size is the file? > Is there the possibility that you could provide the file, or a simplified > version that still shows the problem, with no personal info included? Or, > could you send the file to me, privately. > > -- > You are receiving this mail because: > You reported the bug. > Created attachment 74486 [details]
attachment-2567-1.dat
Created attachment 74487 [details]
powerni.qif
(In reply to comment #4) > Created attachment 74487 [details] > powerni.qif The problem relates to the '$' items in the file. The '$' signifies the value of a split in the transaction, but these transactions have no split category or memo or percentage, so there seems no need for the '$' symbols. Removing them all allows the file to be imported. Most of them are in transactions with an 'M' item, which sometimes is empty, but there is one transaction with '$' and no 'M'. So, I don't see he rationale here, and, if it's important (ie., you have lots more similar files, you may need to contact MoneyManagerEX. That said, KMM should not crash when handling them, and I'll look into that next. @ Thomas I need your guidance here, I'm afraid. What constitutes a valid split? The problem transactions here have a split amount but no 'S' split category, although they do have a 'L' category item. I have eliminated the cause of the crash, in extractSplits(listqSplits), where the absence of the 'S' bypassed the creation of a listqSplits entry. However, if I create a istqSplits entry on the presence of a '$' split amount, there is no split category so the imported transaction is flagged as having no category, which was present, but with an 'L' entry. If the apparently useless '$' is edited out, these transactions import with the 'L' category assigned, so the user has no need of editing the transaction category. So, to me, the best way would be to ignore (or flag) any split amount entry which isn't accompanied by a 'S' split category. Any other ideas, please? @Allen
I would do the following (line numbers refer to current git master):
a) move the definition of QList<qSplit> listqSplits; right before the if statement on line 1135.
b) change the signature of extractSplits() to return a boolean
c) replace the if statement on line 1135 with the following
if( ! extractSplits(listqSplits)) {
d) change the logic in extractSplits in such a way that it returns true only if KMyMoney finds all the information needed to process them. If one is missing, return false, which will in case process the L entry found. In case no L is present, the importer will create an unbalanced transaction.
Created attachment 74504 [details] attachment-19562-0.html (In reply to comment #7) > @Allen > I would do the following (line numbers refer to current git master): > > a) move the definition of QList<qSplit> listqSplits; right before the if > statement on line 1135. > b) change the signature of extractSplits() to return a boolean > c) replace the if statement on line 1135 with the following > > if( ! extractSplits(listqSplits)) { > > d) change the logic in extractSplits in such a way that it returns true only > if KMyMoney finds all the information needed to process them. If one is > missing, return false, which will in case process the L entry found. In case > no L is present, the importer will create an unbalanced transaction. I wasn't expecting all that, but thanks. It seems to work nicely, but I'll do some more testing, to make sure nothing else complains. I've excluded the split memo from the test for needed items. I am not familiar with the structure of .qif files, but I will copy your comments to MoneyManager (which incidentally cannot import split transactions properly, even from its own qif files). I am attaching a larger qif file which contains many more varied transactions than the previous one. It is a US account but with UK style date dd-mm-yyyy. On Fri, Oct 12, 2012 at 2:53 AM, allan <agander93@gmail.com> wrote: > https://bugs.kde.org/show_bug.cgi?id=308247 > > --- Comment #5 from allan <agander93@gmail.com> --- > (In reply to comment #4) > > Created attachment 74487 [details] > > powerni.qif > > The problem relates to the '$' items in the file. The '$' signifies the > value > of a split in the transaction, but these transactions have no split > category or > memo or percentage, so there seems no need for the '$' symbols. Removing > them > all allows the file to be imported. Most of them are in transactions with > an > 'M' item, which sometimes is empty, but there is one transaction with '$' > and > no 'M'. > > So, I don't see he rationale here, and, if it's important (ie., you have > lots > more similar files, you may need to contact MoneyManagerEX. > > That said, KMM should not crash when handling them, and I'll look into that > next. > > -- > You are receiving this mail because: > You reported the bug. > Created attachment 74505 [details]
attachment-19562-1.dat
Created attachment 74506 [details]
uscurrent.qif
(In reply to comment #9) > I am not familiar with the structure of .qif files, but I will copy your > comments to MoneyManager (which incidentally cannot import split > transactions properly, even from its own qif files). > > I am attaching a larger qif file which contains many more varied > transactions than the previous one. It is a US account but with UK style > date dd-mm-yyyy. Another crash, again because of a split problem. -- D13/08/2012 T-23.97 PPaypal USA N LTransfer MOBDII analyser, Fridge thermometers $-23.97 SHome:Miscellaneous $9.00 EHome:Miscellaneous 9.00 SCar:Maintenance $14.97 ECar:Maintenance 14.97 ^ I believe the $-23.97 split is the problem - it shouldn't be there. The following six lines compose two good transactions, but the presence of the additional $-23.97 split line causes them to get mis-matched, resulting in the crash. Removing that line allows the rest if the file to import without problem, the remaining splits being OK. So far as the crash is concerned, again it shouldn't happen, and I think I've fixed this too. I've needed to do some more tuning of extractSplits() to allow the unedited file to import, with just that one transaction flagged as unbalanced, and in need of user attention. I still have a residual problem, with one of my test files, containing three splits, where the second split, which has no memo, picks up the memo from the preceeding split, but that should be simple, I think/hope, then more testing. Created attachment 74541 [details] attachment-19987-0.html Git commit 81d6396a66534f2e95eac89aab19282575554f97 by Allan Anderson. Committed on 14/10/2012 at 12:35. Pushed by allananderson into branch 'master'. M +31 -17 kmymoney/converter/mymoneyqifreader.cpp M +1 -2 kmymoney/converter/mymoneyqifreader.h http://commits.kde.org/kmymoney/81d6396a66534f2e95eac89aab19282575554f97 You are right the $-23.97 split should not be there, because a transfer should not have a split. My mistake in entering it. I corrected all such incorrect entries but it still crashes. Attached is the corrected file. I wonder if there are some residual files causing this. I removed KMyMoney and associated apps, and as many residual files in the KMyMoney folder (there are some I am unable to delete). Reinstalled and still crashes. I will try importing qif file with no transfers and no splits. On Sat, Oct 13, 2012 at 9:25 AM, allan <agander93@gmail.com> wrote: > https://bugs.kde.org/show_bug.cgi?id=308247 > > --- Comment #12 from allan <agander93@gmail.com> --- > (In reply to comment #9) > > I am not familiar with the structure of .qif files, but I will copy your > > comments to MoneyManager (which incidentally cannot import split > > transactions properly, even from its own qif files). > > > > I am attaching a larger qif file which contains many more varied > > transactions than the previous one. It is a US account but with UK style > > date dd-mm-yyyy. > > Another crash, again because of a split problem. -- > D13/08/2012 > T-23.97 > PPaypal USA > N > LTransfer > MOBDII analyser, Fridge thermometers > $-23.97 > SHome:Miscellaneous > $9.00 > EHome:Miscellaneous 9.00 > SCar:Maintenance > $14.97 > ECar:Maintenance 14.97 > ^ > I believe the $-23.97 split is the problem - it shouldn't be there. The > following six lines compose two good transactions, but the presence of the > additional $-23.97 split line causes them to get mis-matched, resulting in > the > crash. Removing that line allows the rest if the file to import without > problem, the remaining splits being OK. > > So far as the crash is concerned, again it shouldn't happen, and I think > I've > fixed this too. > > I've needed to do some more tuning of extractSplits() to allow the unedited > file to import, with just that one transaction flagged as unbalanced, and > in > need of user attention. > > I still have a residual problem, with one of my test files, containing > three > splits, where the second split, which has no memo, picks up the memo from > the > preceeding split, but that should be simple, I think/hope, then more > testing. > > -- > You are receiving this mail because: > You reported the bug. > Created attachment 74542 [details]
attachment-19987-1.dat
Created attachment 74543 [details]
uscurrent6.qif
(In reply to comment #14) > You are right the $-23.97 split should not be there, because a transfer > should not have a split. My mistake in entering it. I corrected all such > incorrect entries but it still crashes. Attached is the corrected file. > I wonder if there are some residual files causing this. I removed KMyMoney > and associated apps, and as many residual files in the KMyMoney folder > (there are some I am unable to delete). Reinstalled and still crashes. > I will try importing qif file with no transfers and no splits. > This file seems to have the same problem as your original - !Account NUS Key Current 1610 TChecking ^ !Type:Cash D25/01/2012 T0.15 PKey N LIncome:Interest M ^ D27/01/2012 T-1,942.76 PPaypal USA N LTransfer M $-1,942.76 ^ etc The second transaction, and many others, still has an unbalanced split - $-1,942.76, with no split category. As a quick test, I started replacing all '$' with 'M' and the import went much further. Just a clarification. When I said "...and the import went much further.", that was using the unpatched KMM, and it crashed beyond the section I'd edited. Using the patched KMM, the file imported without crashing. |