GNOME Bugzilla – Bug 350286
Missing QIF import of categories and noted bookings
Last modified: 2018-06-29 21:11:00 UTC
with release v2.0.1 it is possible for the first time to (real) import the bookings via qif Import. Great! But there are two other kinds of entries in a qif file, that need to be supported. Its - categories [more important] and - 'noted bookings' (bookings, that can be used as templates for bookings) [less important] In order to migrate from quicken without a lot of working, import should be done completely.
maybe there is not to much work left over for categories, since all of the categories, that come within a booking are imported already in the right way, even as sub categories.
The importer should pull in all categories that are actually used. It's possible that it ignores unused categories. And yes, memorized transactions are not imported; that's because the importer was written prior to GnuCash's SX support and has not been revised. Finally, I don't see why 2.0.1 would be significnatly different than 1.8.12.. There were very few fixes made to the importer.
My experience is like this, using opensuse 10.0 and later 10.1: - 1.8.12 until 2.0.0: cannot import my exported data from quicken via qif. - dividing my qif in separate parts (bookings, categories, memorized transactions) and importing those qifs, shows the problem among the bookings part. - 2.0.1 is the first release to be successful. I think you are right about the fact, that only used categories are imported now. My actual cause for the enhancement is, that i want to import a lot of accounts from quicken, where they all should have the same set of categories, used or not.
Huh, I wonder which bugs you were hitting in 1.8.12 that failed the import? Oh, I bet it was an unknown !Option tag... Does 2.0.1 import the data as a single file? Or do you still separate it out into separate account files?
1.8.12: Don't know the reason anymore, but think it was not stated. maybe gnucash crashed or hung. Stopped working with it then until V2.0.0 2.0.1: Did a try to answer your question, result is, that the import works fine with the single file, including all infos. remarks to separate files in V2.0.0/V2.0.1: - they can be imported without crash, but nothing gets imported, the listboxes remain empty. - forgot to mention another type of qif content, that also was ignored: sorry, must say in german, my english words might confuse it: Konto, would call it (logical) accounts within a gnucash file.
The listboxes are only filled with transactions.. So perhaps there are no transactions to be imported from the "separate files" section. Also, do you load all the files in a single QIF Import session? Or do you process them individually? I'm glad to hear the single-file import works. I have no idea what "Konto" means, I'm afraid. Do you have a QIF file you could upload to this bug that I could use for testing? Otherwise, I just don't know what to do with this bug right now, as you said that the full-file import works. So I'm lost as to the actual problem now.
Konto names examples from gnucash in german: Aktiva, Passiva and the sub sections Of course I will add files, first for categories and Konten. If useful, I will try to export some example transactions from the file for you, but this will take a little time Session file: Usually, you will save all informations of a quicken file (accounts, categoroies, transactions, memorized transactions) into one qif file. That's what i did and what worked now. Just for finding out, where the problems are, I did 4 different exports from quicken, to get a glimpse, where the trouble is in gnucash (1.8.12) All my descriptions have the condition, that i only used ONE file with the gnucash import.
Created attachment 70418 [details] file of categories
Created attachment 70419 [details] file of "konten"
Explanation for konten: It is the kind of an account By the way, while importing the transactions I recognized, that some names of categories got shrinked due to german 'umlaute' like "ä" and "Ö", more exact: the strings end at the first occurrence of such a char. And may be, that was the problem since 1.8.12. And V2.0.1 is the first version, where the sw continues to import. Env: LANG=de_DE@Euro Should there be created an extra bug for this?
The missing Umlauts are bug#344841 and that's a larger task ahead. But do the strings really *end* at the umlauts? We fixed this some time ago but our solution was to *remove* the umlauts, but keep the rest of the string intact. If the string *ends* at the umlaut then we've done something wrong. Does one of your example file above also contain umlauts? But again, this is bug#344841. As for the German words: Konto == account (singular), Konten == accounts (plural). If you need the english words, look into http://svn.gnucash.org/repo/gnucash/trunk/po/glossary/de.po As for what to do with this bug: IIRC basically this is an enhancement request that memorized transactions should be imported as well...
sorry, have been offline for a few days. I created an example file, that holds umlaute at different places. As can be seen in the screenshots afterwards, it is the importer that cuts the string, exactly as I described it. For better understanding: - account "B" was "Büro" - account "Bankgeb" was "Bankgebühren" - account "Depotgeb" was "Depotgebühren" - Description "Kontof" was "Kontoführung" and more In order to inform other developers, i will add a comment at bug#344841
Created attachment 70736 [details] QIF with transactions, that hold umlaute
Created attachment 70737 [details] screenshot of "cut" account names while importing
Created attachment 70738 [details] screenshot of "cut" descriptions while importing
What encoding does this QIF file use? QIF doesn't talk about charset encodings, so right now it really only works if the QIF is in your local charset encoding. Is it? It's also possible that guile doesn't like UTF8.
you're right derek, there is no encoding info available. What can i tell you about my env: - original qif files were created under win2000, german - my extract now was done, adjusted and saved under OpenSuSe 10.1, LANG=de_DE@Euro But you will need this information, I guess. Then there is only one way to handle it: one must ask the user, he will know the language resp. encoding...
So the QIF file is ISO-8859? What LANG setting do you run gnucash? I assume de_DE.UTF-8, right?
right, the QIF file is ISO-8859, perhaps ISO-8859-15 As described before, I'm using the LANG setting de_DE@Euro with my OpenSuSE. In order to get a glimpse of de_DE.UTF-8 encoding, i changed to root and did an "export LANG=de_DE.UTF-8", prior to starting GC in the console. Importing now shows a dlg, that tells: An error happened, while loading the import file. So, this behaviour is completely different. Did i misunderstand you? Have some sorrow, whether we talk of the same things rightaway ;-)
I don't see this problem running GnuCash with LANG set to either en_US.UTF-8 or de_DE@Euro. The invalid utf8 characters are correctly stripped with either setting, and the rest of the string is passed to gnucash. I see no truncation of strings. I used the attachment from comment 13 to perform my testing. Looking at the code I don't see how it would be possible for this truncation to ever occur. When a string fails to validate as utf8, gnucash removes the offending byte from the string and then revalidates the entire string. Any chance you're somehow running gnucash with 16 bit wide characters? That's the only way I can postulate that you're somehow shifting in a NUL character and truncating the string.
I recently committed a fix for which should allow the QIF importer to import QIF files encoded according to the locale. This would probably work for the German characters discussed above. See bug 396665 for more information. As for categories, as stated earlier, only those categories actually used in transactions will be imported. As for memorized transactions, I suspect that the GnuCash application itself doesn't support memorized transactions. The register does offer auto-fills, but I believe these are based on existing transactions only. The QIF importer cannot import memorized transactions unless GnuCash can support them.
A little background: Quicken maintains a list of "memorized transactions". When manually entering a new transaction in an account register, if the user enters a payee that has one memorized transaction associated with it, then Quicken copies the information from the memorized transaction into the register. If instead there are multiple memorized transactions associated with that payee, then Quicken presents a drop-down list of them to the user, who then picks one of them to copy the information from. I received confirmation earlier today from Derek Atkins that the GnuCash register's auto-fill feature works only by copying information from the most recent transaction that uses the same value for "Description". There is no separately maintained set of transactions to be used for auto-filling, and therefore no way to import memorized transactions from Quicken. To do so, the design of GnuCash would have to change. So to recap the three issues raised: 1. German character encoding: This is a duplicate of bug 396665. 2. Category importing: By design, the only categories actually used in transactions are imported. So this is not a bug in the QIF importer. If we want to make importing ALL categories an option, then I would suggest creating a new enhancement request specifically for it, as this one is rather crowded. 3. Memorized transactions: GnuCash does not support these, so they cannot be imported. So this is not a bug in the QIF importer. So unless anyone objects, I would recommend closing this bug as NOTABUG.
GnuCash bug tracking has moved to a new Bugzilla host. This bug has been copied to https://bugs.gnucash.org/show_bug.cgi?id=350286. Please update any external references or bookmarks.