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