global delete of transactions

Andrew Sackville-West andrew at farwestbilliards.com
Sat May 7 13:55:05 EDT 2005


I did not mean to offend, merely discussing a possibility.

I had just gone through a mildly nightmarish situation where all my 
vendors had been "un-linked" from their bills (using HEAD, and trying to 
reproduce for reporting to you guys) and used the opportunity to figure 
out how the data file works. My new found understanding of the data file 
prompted me to propose a solution. that's all.

The year end closing thing, I know is being worked on, and that's great. 
I was merely proposing a quick, down and dirty solution for year end 
stuff, not meant to be a permanent solution and certainly not supported.

I was not belittling the complexity of the gnucash project, nor its 
development. I was only suggesting that maybe a fairly straightforward 
script could iterate through the datafile, deleting transactions of a 
certain date range, accumulate totals for those accounts, and either add 
in the accumulated transactions, or spit out a list of the transactions 
needed to manually enter for year end totals. I do not think this would 
be a permanent solution, or even necessarily work well at all. Also, I 
don't even know if its really possible in any kind of expedient way.

sorry if I offended.

other responses below


Derek Atkins wrote:
> CVS has code that effectively does "book end" by saving off the transactions
> prior to some date into a new file and then resetting the accounts and balances
> appropriately.  I do not know how well-tested this code is, or even if there's
> a hook in the UI.  But I do know that Linas was working on this a while ago in
> HEAD.
> 
> -derek
> 
> Quoting Neil Williams <linux at codehelp.co.uk>:
> 
> 
>>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.

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

I was not proposing the "answer", see above. I mis-represented here, I 
did not mean mid-range. I meant a range of past dates spanning form 
first transaction to end of a particular year. Though later, if done 
again, you would olny need to do this from the end of the already done 
period to the end of the next year. In that sense it could be mid-range.
>>
>>
>>>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 ???

I don't mean a gap, I mean that, for example, for my numbers from past 
years, I really only need a monthly accumulated total for comparisons sake.
>>
>>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.

I mean collating a set of transactions into large "summary transactions" 
that span a period of time.
>>
>>
>>>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.

Data integrity is definitely important, and nothing like this should be 
done without making note of the fact that one could trash everything.
>>
>>
>>>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.

I merely meant, as I've said above, as a down and dirty workaround while 
the real implementation is being done. Again, I did not mean to offend, 
or cause such a ruckus. just spouting an idea. I'll make a point of 
doing my thinking in my head instead in emails in the future.

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


More information about the gnucash-user mailing list