Generic importer:QIF

Christian Stimming stimming at
Sun Jun 24 16:12:22 EDT 2007

Am Sonntag, 24. Juni 2007 20:22 schrieb Chintan Agarwal:
> Thanks for that information. I could not find the declaration of
> Transaction structure(or its un-typedefed form) per say but from the
> functions in the file, could gather the variable types present.

That is intentional. We don't use direct access to the structure anywhere in 
gnucash, and you shouldn't use that, too. Instead, all access is done solely 
by the accessor functions in Transaction.h -- that's the whole point of that 
file. Do you have doxygen installed? Run "make doc" and a HTML documentation 
will be created in src/doc/html/index.html; in that documentation, browse 
to "Files" and go to "Transaction.h". This should give a usable overview of 
what can be done with a Transaction*. 

Having said that, there is also the header file src/engine/TransactionP.h 
where you can observe the actual data fields of the Transaction structure. 
But as I already mentioned, the structure must not be accessed directly from 
anywhere else in gnucash.

> I think that for QIF importer, we could have a simpler structure, akin OFX
> importer wherein the function void gnc_file_ofx_import (void) (in
> /src/import-export/ofx/gnc-ofx-import.c)is the top-level function. 

Sounds okay. 

> In such 
> a top-level function there are basically three steps:-
> 1) Creating a context for the input data(done by QIF context)
> 2) Parsing the data(done by QIF parser written in /src/import-export/qif)
> 3) Integrating the parsed data into the Gnucash accounts, actions like
> matching, mapping etc.(as pointed out earlier, this is done simply by using
> functions in import-main-matcher.h, specifically the function
> gnc_gen_trans_list_add_trans(...)).
> As for the frontend, it would be there only in step 1 as after that the
> parsing process( in the backend) starts and completes.

As a high-level description this is fine. However, I think problems will arise 
in the details, especially for the QIF format. But I would suggest you should 
commit the first code parts to your branch so that Josh and others can 
comment on that directly.

> Some questions:-
> 1) Do the above three steps miss out something vital for QIF import?

Yes - the QIF file format has a whole bunch of nasty ambiguities. For that 
reason, there are multiple places throughout the importing process where the 
user might have to be asked to resolve some ambiguities (e.g. date format 
Year/month/day vs. Month/day/Year vs. whatever). The existing OFX importer is 
an example for you to start with, but QIF needs much more interaction with 
the user due to these ambiguities compared to the more modern OFX format. 
Your proposal above might still be sufficient, but please keep in mind you 
will have to add more user interaction along the way.

> 2) The top-level function that would be made should be by what name? In
> other words, which function call results in the QIF import process being
> trigerred?

If you're adding your code in the qif-import directory, just start by 
modifying the content of the gnc_plugin_qif_import_cmd_new_qif_import() 
function and have it create your new dialogs instead.

> 3) Does GNUCash use the standard GNU indentation format?

Currently probably yes, but it's up to the individual developer. There are 
efforts to unify the indentation. Once these are put in place, clear 
guidelines about the indentation will be given. As long as you haven't been 
told anything more specifically, just pick your favorite indentation and 
stick to it. GNU format is just fine.



More information about the gnucash-devel mailing list