Palm App FreeCoins data extracted to XML: How to read into GnuCash?

[Derek Atkins]

Kevin Buckley <kevin.m.buckley at gmail.com> writes:

>> 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.

No, OFX does not have the concept of Splits.  If you want/need Splits
then use QIF.

> 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.

Which QIF will do for you if the QIF Accounts are set up correctly.

> 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)

Kinda, yes.

> 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 ?

SMOP.  There is no UI to pre-add an online_id value.  But you could
certainly write code to insert it.

> 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 ?

It would be pretty cool to have a whole-file merge.  There may even
already be some scheme code to implement it, as that's kinda how the QIF
importer works.  It creates a duplicate tree, fills it in with the new
transactions (and accounts), and then merges it back in when you
finish.

Note that this is different than the "generic" importer, which does not
have this clear separation and makes changes to your actual chart of
accounts even before you click "finish".

> 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.

I disagree..  If you're importing GnuCash XML, you should treat GUIDs as
actual, so you don't double-import the same transaction.

> 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

-derek

-- 
       Derek Atkins, SB '93 MIT EE, SM '95 MIT Media Laboratory
       Member, MIT Student Information Processing Board  (SIPB)
       URL: http://web.mit.edu/warlord/    PP-ASEL-IA     N1NWH
       warlord at MIT.EDU                        PGP key available