Issues/Observations with OFX & online banking

Herbert Valerio Riedel hvr at gnu.org
Mon Jun 5 06:32:17 EDT 2006


Hello!

I hope this is the right list for this kind of mail... :-)

I've been playing with gnucash's svn version (compiled on ubuntu
dapper), and even managed to to connect to my bank; what follows are
some problems/issues/observations I encountered:

*) UI HBCI<->OFX;
gnucash refers to HBCI only in its dialogs, although showing data
sources coming from other aqbanking backends as well... this is a bit
confusing imho 

*) OFX encoding ignored?;
Importing from OFX files within gnucash (and also downloading
transactions directly from within gnucash) seems to ignore the OFX
charset encoding; the OFX files (version 1.02) I've encountered had

ENCODING:USASCII
CHARSET:1252

which is also what libofx seems to request; but for some reason this
information isn't passed on to OpenSP (actually I didn't find any
parsing for those headers in libofx), and neither gnucash seems to do
any conversion; and since my bank statements include the following
characters (the 1252 codepage corresponds to latin1) in the MEMO field:

       Oct   Dec   Hex   Char   Description
       304   196   C4     Ä     LATIN CAPITAL LETTER A WITH DIAERESIS
       313   203   CB     Ë     LATIN CAPITAL LETTER E WITH DIAERESIS
       326   214   D6     Ö     LATIN CAPITAL LETTER O WITH DIAERESIS
       344   228   E4     ä     LATIN SMALL LETTER A WITH DIAERESIS
       353   235   EB     ë     LATIN SMALL LETTER E WITH DIAERESIS
       366   246   F6     ö     LATIN SMALL LETTER O WITH DIAERESIS

those get passed on to gnucash unmapped, and cause broken memo fields there...

*) OFX preprocessing?:
is there any way to preprocess the OFX data before it reaches the import
matcher? e.g. my bank has slightly suboptimal OFX data, which I'd like
to preprocess... is this possible somehow? are there any scheme hooks in
gnucash for that?

*) generic OFX/QIF import facility?
is it possible to script the scheme engine in gnucash to provide me a
new menu-item, which executes some program (say I had a python script,
which grabs the statements from my banks web-interface and converts them
to QIF/OFX) which provides  OFX or QIF date, which then would be
directly feed to the import matcher?

*) generic OFX/QIF transaction facility?
...continuing in the line of the previous questions...
say I had a python script, which takes a OFX request,
is able to log into my bank, creates a payment transaction and signs
that... is there an easy way to integrate that with gnucash? :-)

*) online banking w/ OFX direct connect;
after quite some fighting with the OFX protocol and reverse engineering
where the OFX server is actually located at my bank (and what its
preferences are), I was able to connect to my bank, and successfully
download statements directly from within gnucash:

I'm using www.easybank.at (should use similiar OFX server as
www.bawag.at) with the following settings:
(the OFX capatibilities of my bank alas don't include listing accounts,
just downloading statements and issuing payments are supported, but I
haven't tested the latter one yet...)
 
bankId="14200"
bankName="easybank AG"
location="Wien"
street="Quellenstra%C3%9Fe 51%2D55"
zipcode="1100"
city="Wien"
services {
  element {
    type="OFX"
    address="https%3A%2F%2Febanking.easybank.at%2FPebOfx%2Fpebofx"
    pversion="102"
    aux1="EASYBANKFID"
    aux2="easybankORG"
  }
}

my banks OFX server seems to be very stupid, I had to hack libofx not to
send ".000" for datetime elements (although the OFX specification states
clearly, that any OFX server should accept them...):

--- lib/ofx_request.cpp~
+++ lib/ofx_request.cpp
@@ -32,7 +32,7 @@
 {
   static char buffer[51];

-  strftime( buffer, 50, "%Y%m%d%H%M%S.000", localtime(&time) );
+  strftime( buffer, 50, "%Y%m%d%H%M%S", localtime(&time) );
   buffer[50] = 0;

   return string(buffer);

without this hack, the OFX server would return an http error, that my
request was malformed...


regards,
hvr
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 191 bytes
Desc: This is a digitally signed message part
Url : http://lists.gnucash.org/pipermail/gnucash-devel/attachments/20060605/da6847a0/attachment.bin


More information about the gnucash-devel mailing list