GnuCash for Symbian

[Łukasz Spas]

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 at gnucash.org
> https://lists.gnucash.org/mailman/listinfo/gnucash-devel