OFX import from aqbanking (was: Fresh build of jhbuild and gnucash on OSX)

[Christian Stimming]

Am Freitag, 20. Mai 2011 schrieb Brad Grupczynski:
> I didn't touch libofx. Only made aqbanking import match libofx file import
> more closely.
> 
> libofx uses a callback to split the fields where they need to go. What I
> should do is figure out a way for them both to use the same callback. Or
> figure out a way for libofx to do the whole job. I'm sure there are ideas
> out there. And I am ready for them.
> 
> In the mean time, I have submitted a patch to aqbanking that was applied to
> the trunk and available in aqbanking 5.0.6. And I submit the attached
> patch for GC. Neither depends on each other but when they are both used
> together, the results from file import and aqbanking import match (from my
> test data set).

aqbanking 5.0.6 is now released. Feel free to continue submitting patches to 
any of the involved projects :-)

However, your proposed gnucash patch needs some more discussion:

> GC changes:
> - gnc_ab_description_to_gnc cleaned up and returns different result. Not
> currently used.
> - gnc_ab_trans_to_gnc made to match libofx file import
> callback more closely. Placing tag values into different fields and
> building up a different memo for the split.

Your proposal has some issues, both in structure and in actual field texts. As 
for structure, I intentionally introduced the function 
gnc_ab_description_to_gnc()  which should encapsulate the conversion of the 
AB_Transaction information to gnucash's "description" field. Your patch would 
throw away this encapsulation again by implementing the setting of the 
xaccTransSetDescription directly in gnc_ab_trans_to_gnc(). That function is 
already quite large, so I want to continue to have specific tasks such as the 
buildilng of the xaccTransSetDescription refactored into separate functions.

As for the field text, esp. the memo: You introduce several user-visible new 
strings that should encode the specific OFX information in the 
xaccTransSetNotes field. This needs further work to let it work in other 
languages and in other (non-OFX) import data as well. In the current state, it 
would work only in English and only if people happen to import OFX. For you, 
the downside in this code here is that the very same code is used with data 
from MT940 or DTAUS or HBCI or whatever further format is supported by 
libaqbanking. Hence, any text rules here must be general enough for all this 
data, and this isn't the case with your current patch which means we won't 
apply this to our SVN in this state. Sorry for that.

Maybe what you need instead here is a framework to use specific configurable 
conversion rules. If you have any good solution how this can be implemented in 
a user-configurable way (maybe just by gconf  keys, not yet with full GUI in 
gnucash), I'd be very interested to hear about those.

> Also -
> Christian wrote:
> "
> By the way, you can add a "Import OFX file" using the aqbanking module
> (instead of the hand-written OFX importer) by calling the function
> gnc_file_aqbanking_import() with (I think) importername="ofx",
> formatname="default", called from gnc-plugin-aqbanking.c. Just follow the
> examples for e.g. mt940, all in the above directory.
> "
> But there is already an OFX import menu item so I didn't do anything here.

Yes, of course there is. I was just pointing out in case you wanted to see the 
OFX import from file through libaqbanking in gnucash directly, so that you can 
compare the OFX-from-file-by-libofx vs. OFX-from-file-by-aqbanking in gnucash 
directly.  Subsequently, you could use that as a starting point to decide 
whether you continue your work on one or the other. In that case, it could be 
imagined to let gnucash switch from the one method to the other iff the new 
method implements as many features as the previous ones, plus your new 
additions.

Regards,

Christian