Dear Łukasz, I'm one of the authors of the online banking importer in gnucash (using HBCI online protocol and/or files containing MT940 or OFX data).
I think your idea is great, but difficult. As for the data format for importing transactions: I'd agree with the reservations about QIF as a data format. It has some severe limitations, which are somewhat worked around by the existing gnucash importer, but if you're implementing a new importing scheme anyway, you should better choose an exchange data format that doesn't give your obstacles from start on. Instead, I'd rather suggest OFX as a data format. Hendrik mentioned a "unique transaction identifier" that should be included in the exchange data format for sure, and he is right. OFX has such a unique ID. It is being evaluated in gnucash's OFX importer under the name "online-id". In fact, if the imported file contains this field, duplicate transactions (whose online-id has been observed in earlier imports) will be ignored from the import altogether right now already. Hence, please try to use OFX' data format as your exchange data format for transactions, if possible. Am Freitag, 6. April 2012, 16:54:07 schrieb Ł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? You don't need a "protocol" for the gnucash part. You need a data format for transaction data (and I suggest OFX). You do need a protocol for moving this data from your Symbian device into a PC desktop application such as gnucash. I don't know at all how to hook up the PC application "gnucash" as the listener for specific bluetooth requests. I did some research on vaguely similar areas when I tried to find out how to register gnucash as a handler for particular URI schemes, see http://wiki.gnucash.org/wiki/Custom_URI_Scheme at the bottom. There is surely no one-size-fits-all solution there, but instead each OS and also each desktop system needs its own implementation of those hooks. Good luck! > 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? No, the GSoC students will be completely busy with their own projects. You can surely expect no support from that side. > 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 No, I wouldn't advise broadening your scope from "synchronization from a single mobile device to a single PC instance of gnucash" into some distributed something. Instead, I'd suggest keeping your scope limited to exactly your initial scenario: One mobile device with the data recording, and one PC with a running gnucash. Now you need to solve: - Data recording on the mobile (probably easy) - Exporting data from the mobile into some bluetooth export (exporting is easy if you choose your internal mobile data identical with the export data format; hooking this into bluetooth requires some internal protocol digging in the mobile OS) - Registering gnucash as a bluetooth listener application, probably first limited to one specific OS and one specific desktop environment of your choice - Getting some import process running in gnucash as soon as it receives the data via bluetooth (which is probably easy as the "Import xy file..." already exists in gnucash) Regards, Christian _______________________________________________ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
