On Wed, 04 Apr 2012 15:24:47 +0200, Łukasz Spas wrote: > Hello. > > I've developed small application for Symbian (tested on S60) which > allows users to manage their finances using their Symbian phone. (Here > is the repo: https://gitorious.org/gnucash-s60/gnucash-s60) > It is still incomplete because I would like to add functionality which > allows to synchronize list of transactions with desktop' GnuCash via > Bluetooth using QIF file format. > And here goes the question - is it hard to add "reciving QIF file via > Bluetooth & importing it to GnuCash's database" functionality? I have > never look inside GnuCash's code and I don't know where I could start. > (Maybe someone could help?) Moreover, is it even possible to add such > Bluetooth import functionality to main GnuCash repo? I think it might be > useful for many of smart-phones owners and gives a possibility to write > many of mobile ports/clients of GnuCash easily.
Doing bluetooth is probably the easy part. It's just a comm protocol, after all. The trouble lies with QIF. At least the last time I looked, it just doesn't have all the information you need. It doesn't identify the account the QIF file is about, and it doesn't clearly identify the accounts that are at the other end of transactions. The result is that the QIF reader in gnucash contains *lots* of code about guessing what accounts are to be used for different transactions and recording user feedback about the guesses to make better ones in the future. Not to mention that if you get another QIF from the bank a week later, it has to identify which transactions are *already* in the gnucash file and which are new. QIF provides no transaction serial numbers to make this reliable. Such serial numbers are de rigeur in any professionally designed protocol. In any case, if the user has edited the transaction using gnucash, you *don't* want that change to make the importer fail to recognize it and import it anew. So, to do the job *right* (whether it's worth the effort or not), gnucash would have to have unique transaction IDs for each transaction in its database. (Does it already do this? I don't know.) Then you could perhaps look at the code for qif import (or maybe there's another importer you could look at which might be better) and adapt it to whatever intermediate file format you'd *like* to use with your application. That file format should explicitly identify the accounts at both ends of each transaction. Gnucash accounts, at least in the XML file, have some king of binary hash ID to identify them uniquely. That might be useful here. I don't know if those hashes are in the actual data base, though, or just part of the XML file format. You app would of course have to know the names of the accounts so that the user with the mobile phone could select them unambiguously. It might even be possible that gnucash's XML format for transactions might have the right information for your intermediate files. Or not. All in all, it's a big job, and *I* didn't volunteer to do anything like it a few years ago when I thought it might be useful. -- hendrik _______________________________________________ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
