global delete of transactions

[Derek Atkins]

Hmm, you've seen that, too?  That happened to me, once, as well..  I have no
idea how or when, but I agree that it was a nightmare to recover!  If you could
find a reliable way to reproduce the problem where invoices forget their
owners, I'd greatly appreciate it!

-derek

PS: I'm sorry if it sounded like I was offended.  Maybe it's that I'm extremely
terse, even moreso when compared to Neil ;)  I was just pointing out that code
already existed to do what you were proposing, and I was trying to save you
time.

Quoting Andrew Sackville-West <andrew at farwestbilliards.com>:

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


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