global delete of transactions

[Andrew Sackville-West]

Derek Atkins wrote:
> 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!

I'll see what I can do. I know that I entered a bunch of invoices in my 
HEAD version, then later went in to 1.8.11 (where I tend to work most) 
and noticed the issue.

In the datafile, I found that the <gnc:gncinvoice tags (I don't know XML 
terminoogy, so bear with me) the guid for owner was changed to 
"xxxxxx0802000000..." wheres x's are random hex bytes and the whole 
thing was padded with zeros. what i did was pick out the guid for the 
posted txn, "find" it, not the vendor name in the txn, then replace the 
"xxxxxx08020000...." corrupted guid with the proper one for the vendor. 
took many many find-replace iterations and got me thinking about scripts.

I'll report back if I know more.

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

thanks, it was actually neil that sounded offended... and thanks again.


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