ofxdirectconnect in aqbanking3 branch
aquamaniac at gmx.de
Sat Jul 12 01:57:59 EDT 2008
On Freitag, 11. Juli 2008, Andreas Köhler wrote:
> On Do, 2008-07-10 at 00:09 +0200, Martin Preuss wrote:
> > So what I propose is this: You must already have a generic import/export
> > interface which is able to import data from an AB_IMEXPORTER_CONTEXT,
> > since you have an importer for SWIFT MT94x, so why not use this interface
> > to import the data returned? For HBCI it makes no difference, but the
> > other protocols can then also be safely used with GnuCash.
> I suppose this only concerns the fetching of transactions, not balances,
Nope, that also concerns balances (or any request for that matter), since some
protocols do not allow to specifically request the balance (e.g. EBICS) but
rather return the balance with the transaction statements (e.g. in the SWIFT
So when requesting the balance you must also be prepared to import the whole
That's why I propose a single importation point between the application and
AqBanking. It simplifies the design dramatically, and since you already have
the interface for importing an ImExporterContext (->SWIFT MT94x importer) it
would be easiest to use *that*.
Any request send to a bank returns its resulting data in the imexporter
context, so it would be easiest to:
- create the corresponding job
- send it to the bank via AqBanking, passing it the ImExporterContext to use
- check for the status of the job
- import the ImExporterContext
That's how I do it in QBankManager and how it's done in the KMyMoney plugin
and it works rather nicely.
> BTW, I followed
>html , even though you said that was not your recommended solution.
Right, but since GnuCash is setting standards when it comes to financial
applications I don't think it should allow for the user to loose important
"Things are only impossible until they're not"
Martin Preuss - http://www.aquamaniac.de/
AqBanking - http://www.aqbanking.de/
LibChipcard - http://www.libchipcard.de/
More information about the gnucash-devel