Mass deletion of transactions

[Ricardo Biloti]

My motivation for such feature is closer to your (b) alternative. I have
the situation where transactions have been registered for more than 4
years. This is not a problem for Gnucash at all (although it takes some --
acceptable -- time to open the file). However, in the last five months
some, but not all, transactions were registered wrongly. After a thorough
inspection, I figured out the source of the problem. Unfortunately, many of
the transaction's original sources are no longer available. Therefore, I
have no hope in fix those transactions.

Finally, my decision was to split the original file in three, one prior the
flaw, one for the compromised period, and one from that moment the problem
was detected.

In the absence of any other alternative, I would have to accept the tedious
process of deleting them manually.

Despite this specific situation, I have had the wish to close a book and
open a new one, after so many years of register, as a way to archive the
remote past (I have been using Gnucash for more than a decade). If that
decision is not taken exactly at the "cut" moment, there is always a boring
process of transfer the last transactions from the old book to the new one.
A feature like my last suggestion in the previous message would be helpful.

> Besides, I would suggest that all accounts have a simple ID that could be
> used to inform both accounts of each transaction in the CSV import. This
> would greatly improve the CSV mass import of transactions. I believe that
> the implementation effort related to such feature is worthy.

As I do not know the code, I can not judge the effort to implement it. I am
just saying that such feature would represent some value to me. Maybe you
could take into account such demands as the code evolves, as a way to make
more feasible the implementation of that sort of functionalities.


On Mon, Apr 7, 2014 at 2:02 PM, Derek Atkins <warlord at mit.edu> wrote:

> Hi,
>
> Ricardo Biloti <biloti at gmail.com> writes:
>
> > I consider two possibilities to overcome such difficulty.
> >
> > 1) apply a simple operation to all entries of a search.
> > After search for all transactions, the user would be allowed to delete,
> > export, switch one of the accounts, etc. This feature however may imply
> in
> > moderate to high efforts in interface design and implementation.
> >
> > 2) native format for exporting/importing of transactions.
> > The user searchs for transactions he/she wants to keep, then export them
> > and reimport them into a new file. This export/import format however must
> > be gnucash native, instead of CSV, to avoid any information loss or
> > necessity of recheck all transactions for consistency and correctness.
> As a
> > developer, I consider this easier to implement, and more valuable as it
> > address other issues, like the possibility to backup just of part of the
> > transactions, not specifically related in time, like it is done in the
> log
> > files.
> >
> > Besides, I would suggest that all accounts have a simple ID that could be
> > used to inform both accounts of each transaction in the CSV import. This
> > would greatly improve the CSV mass import of transactions. I believe that
> > the implementation effort related to such feature is worthy.
> >
> > Are those potencial features valuable to others?
>
> I'm not sure how widely usable these features are.  You are correctin
> that implementing #1 would be very challenging given the current
> architecture.  #2 would likely be possible, but still challenging given
> the way the code works.
>
> Going back to your original question: I'm curious why you feel you need
> to mass-delete a bunch of transactions?  Usually this implies either:
>
> a) you want to go back in time, to which I would say "go to a backup",
> or
> b) you want to split your books up, to which I would say "you don't need
> to -- gnucash will happily continue going"
>
> So... why do you feel you need to mass delete a bunch of transactions?
>
> > R.Biloti
>
> > Please remember to CC this list on all your replies.
> > You can do this by using Reply-To-List or Reply-All.
>
> -derek
>
> --
>        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
>