> GnuCash cannot import from its own XML format. > > Your best bet is to convert to QIF or OFX for import. > > -derek
I've had a play with some OFX but it doesn't seem to have the notion of splits ? Not in the examples I have found so far, anyway. It would thus seem that you gain little from having a double-entry app on the Palm/Handheld/Elsewhere ? You end up with, for the simplest case, a pair of un-matched splits per transaction, which you then have to "re-assemble" within the import Druid. So you end up duplicating the info, despite being able to generate a valid GnuCash transaction (OK you could simply add the XML but you can't go much beyond that) The other thing that I may have missed is: does GnuCash allow you to add a slot to an existing account, so that you could "pre-load" the online_id values ? Or do they only get entered when you import "online" stuff ? I even started looking at the "whole file" XML import code in case I could see a way to flesh out the bits needed for a simple transaction import. It that something that those with much deeper knowledge of the code-base, know will fall foul of issues I have not yet encountered when skimming the surface ? I can see that there's a potential to import already existing GUIDs but feel that you could get round that by just ruling out external GUIDs (which would need to be there to satisfy the DTD) and saying that if you import transaction XML, it'd simply be treated as new, whether the GUIDs matched something or not. Now I am sure there are pros and cons to that. I could imagine a "sync with other double entry app" scenario whereby a slot in the GnuCash XML could store a unique ID from the other application and some "store the GnuCash GUID as a text note" mechanism mighty allow some matching. Just airing some random thoughts really, maybe way off beam, Kevin _______________________________________________ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel