Hmm... So maybe it would be better to develop some kind of
synchronization protocol (that meets all specific gnucash requirements)
based on TCP/Bluetooth connection?
It would be a lots of work but there is also no deadlines... :P Maybe
some student form GSoK could also helps in this topic?
This could be also useful when you have few desktop computers and you
want to use GnuCash on all of them and easily keep your data
synchronized...
It would be some kind of GIT for GnuCash. :D
BR,
Lucas Spas
W dniu 2012-04-05 02:50, Hendrik Boom pisze:
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
_______________________________________________
gnucash-devel mailing list
gnucash-devel@gnucash.org
https://lists.gnucash.org/mailman/listinfo/gnucash-devel
