HBCI data structures and Gnucash

[Benoit Grégoire]

> Apart from those details, online banking deals with just a few different
> data types, and I'm going to describe which ones they are and where they
> should belong to inside Gnucash, IMHO. This is meant to kick off a
> discussion for both the HBCI developers as well as other Gnucash developers
> (especially if they are working on yet more online banking standards) on
> whether this seems to be the "right way" of implementing online banking in
> Gnucash.

I dont know if I have the "right way" anymore than you do, but I am currently 
working on OFX support, so here are my thoughts.

> 4. HBCI support in Gnucash
>
> I think the HBCI concept of an Account *directly* maps to the Gnucash
> concept of an account. But the HBCI concept of Banks and Customers do not
> have any direct counterpart in Gnucash -- a user can have accounts
> belonging to different banks inside the same gnucash book, and the accounts
> inside one gnucash book don't need to belong to the same person or HBCI
> Customer.

Actually, I would go further and say that the concept of Customers and Banks 
are not even relevent to the normal operation of gnucash, and that Accounts 
MUST be made to map exactly to the Gnucahs equivalent.  Accounts are real 
life objects, with properties of their own.  The most important of wich is 
that they are worlwide unique in real life, and they can be uniquely 
identified in a reasonnably standard way.

For standard bank accounts, we have:
1-A FI (Financial institution, not necessarly a bank) identifier 
2-A FI branch identifier
3-A FI specific account identifier
The first and second are not used in all countrys.

For credit cards we have a single identifier (the card's number) wich is 
unique (Actually, more information can be deduced from this number 
http://www.merriampark.com/anatomycc.htm).  This identifier could be seen as 
the equivalent of the third one above.

What I did in libofx is concatenate identifiers 1 to 3, to make a globally 
unique identifier that will be stored in the gnucash data structures.  Note 
that it is not too late for me to change the format of these identifiers, but 
we should agree on a common format, so that it will be possible to:
-Associate unambiguously an account with downloaded transaction, independently 
of the protocol
-Change the online protocol.
-Associate a new or an existing account to to an online one, simply by adding 
the unique identifier.

So we should add a new string in AccountP.h named accountID, and the 
appropriate access functions in Account.h and agree an document the format.  
All other Customer and Bank information should be considered implementation 
specific.  You could store it in whatever kvp_frame that is convenient to 
you, but i think they should not be stored in a publicaly accessible static 
structure.

I don't currently intend to store any OFX specific data.    And I dont see 
what data would be usefull to share between OFX and HBCI, so we should use 
identifiers like hbci_something and ofx_something, otherwise it is quite 
likely we will end up with name collisions.

I'll post some more when I have given it some more tought.

Benoit Grégoire