exporting selected account subtree

Neil Williams linux at codehelp.co.uk
Tue Mar 1 17:43:22 EST 2005


On Tuesday 01 March 2005 9:43 pm, TMaynard wrote:
> After posting on this problem, I did find the thread titled "transaction
> transfer"  around Feb 4
> http://lists.gnucash.org/pipermail/gnucash-user/2005-February/012873.html

Yes, that would be supported. Any selection of transactions could be 
transferred between files, although see the note later about commodities.

> which points to  the  project
> http://code.neil.williamsleesmill.me.uk/guidelines.html

That concentrates on the merge when importing the data, yes. The export stuff 
is later in the same documentation.

> I was under the impression that  the existing  export would export
> transactions

Although it isn't coded to provide an export as such, it's a partitioned book 
that is slightly different and intended for different purposes.

> (I had the gluttons hope for a tool to also export 
> transactions only within specified subtrees).

QSF will do that, maybe not in the first release though. It depends how the 
rest of it progresses.

> It seems like that ability to package entire subtrees for  export (to
> another COA)  would be the basis for also doing prune and graft within a
> COA 

That is true - you would be able to take a whole subtree of accounts and 
transactions between certain dates and merge them into another file.

>  I would welcome a beta testing  tool to do :
>  A:  export (*copy*) subtree from source COA
> B:  graft new (under *empty* placeholder) in destination COA.

The export is an exact copy, yes. The GUID's of the exported accounts 
precisely match the original - they are, in essence, one and the same entity. 
This means that any changes to the exported data would be able to overwrite 
the originals if that data was imported and merged back into the original 
file. 

If merged into a different file, the merge would report the collisions to the 
user and ask how to proceed.

The use of placeholders may be unnecessary.

>  It seems that the task I am describing is partly provided by the QIF
> import that already exists (not being a programmer looking at the code).

The overlaps between QSF, QIF, OFX and the other methods will play out over 
time, each has their distinct capabilities but there will be cases where the 
user will have to decide which is the best choice. Documentation will be 
provided to make that an informed choice.

It is pertinent here to note that QSF cannot support commodities - at least 
for the first and possibly second release(s). New data will be assigned the 
current GnuCash default commodity. This has important repercussions for the 
choice of export/import method for certain users.

> At some point the incoming bank transactions are assigned unique QUID's
> and dummy or one sided  account labels.

That's your basic problem, right there. Without retaining the GUID, it becomes 
hit or miss when you re-import that data - you cannot be absolutely sure that 
the incoming data really does match existing data unless the GUID is retained 
through export AND import.

>  I would even welcome a blow by blow description of how to safely
> identify&copy the pertinent subtree of the source COA and paste *only*
> under/within  the waiting "placeholder" in the destination XML.

I'll look at that. The test case CoA export will provide the XML and it should 
be relatively easy to identify the relevant accounts.

-- 

Neil Williams
=============
http://www.dcglug.org.uk/
http://www.nosoftwarepatents.com/
http://sourceforge.net/projects/isbnsearch/
http://www.neil.williamsleesmill.me.uk/
http://www.biglumber.com/x/web?qs=0x8801094A28BCB3E3

-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
Url : http://lists.gnucash.org/pipermail/gnucash-user/attachments/20050301/09955611/attachment.bin


More information about the gnucash-user mailing list