global delete of transactions

Neil Williams linux at codehelp.co.uk
Sat May 7 03:40:20 EDT 2005


On Friday 06 May 2005 6:13 pm, Andrew Sackville-West wrote:
> Josh Sled wrote:
> > On Fri, 2005-05-06 at 17:05 +0200, Arthur Gregson wrote:
> >>is it possible to delete previous years transactions from all accounts
> >>globally.....
> >      NOTE this is NOT recommended or supported!!! Keep data file
> >      backups.
>
> this question keeps popping up on the list every few weeks.

And it still isn't going to be supported as a script hack!

> It should be 
> fairly simple to write a script to do this

If it was that simple, it would be recommended and supported. It is not this 
simple but it is being enabled via the work on partial books, QSF export and 
G2.

> and post it up somewhere. 
> What are some options that could be included?

How to handle references that point to a transaction that has been hacked from 
the file.

How to handle account balances so that you create a usable opening balance for 
the point immediately AFTER the removed transactions.

> I'm thinking:
>
> 1. Delete all transactions from a specified date range

And create a new opening balance.

Transactions cannot be deleted mid-range - you should not have a gap in the 
accounts. All you should be considering is removing the oldest transactions 
from the beginning of the file to a certain date. This is book-closing and 
the code is still being developed. Hacks are not the answer.

> 2. Summarize all transactions from a date range and enter one cumulative
> transaction to allow past year reporting (allowing you to keep past year
> information more compactly. sort of like intuits end-of-year stuff).
> This may be more of a business feature, i suppose to compare sales from
> past years etc.

??? How can you seriously recommend a gap like that ???

There will be support for *exporting* transactions between certain dates and 
this will include creating the relevant opening balance. It cannot be 
sensible to remove an entire set of reconciled transactions leaving a 
horrible gap.

> 3 Make a backup of transactions from a date range in a seperate file.

So what you really want is the export - you retain the data in one file and 
create a new file with a subset of that data.

That is being done but I would not recommend hacking it - data integrity is 
too important.

> any others?
>
> this seems to be something that doesn't need to be done within gnucash
> and for expediency of implementation might ultimately be easier from a
> simple (heh) script

I cannot agree with that assessment. It absolutely needs to be done within 
GnuCash - actually within the QOF engine - because of the need to handle the 
loose ends, balances and references.


-- 

Neil Williams
=============
http://www.data-freedom.org/
http://www.nosoftwarepatents.com/
http://www.linux.codehelp.co.uk/

-------------- 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/20050507/1c96e0f6/attachment.bin


More information about the gnucash-user mailing list