There's a lot of this new lsmb version that I'm still not familiar with,
or even need to use. So I would warn against maken specific changes only
because of my special use case, because that's what it is.
Except for what I mentioned before with respect to protecting users
(like me :) who still don't know exactly what they are doing, against
doing something 'unintended' (to put it mildly).
The case I'm dealing with is a lot of AP and AR transactions between
3... how shall I say it... 'connected'?, 'befriended'?, 'companies',
which are not or partially paid. In each 'company' about 3 departments
are involved, and therefore not all transactions of 1 day can be put in
>From time to time one or some of the invoices are being partially paid,
hence the unusually large amount of unpaid invoices: a daily amount of
small transactions without cash exchange.
Yesterday was the first time I used my new (1.3.29) lsmb to process a
small number of those payments, with the result mentioned.
I don't know what you mean by '600 interfaces'. It's in my world a list
of 600 open invoices between 2 companies. But maybe that's the word you
meant to use: 'invoices'.
Reading your comments and re-thinking the situation I realise now that
this could indeed be categorised as 'unheard of'.
So maybe a reason
indeed not to invest too much time, if at all, in improving your
software for a case that seldom occurs or maybe even shouldn't occur at
all in a professional accounting environment.
However, I'd still be very happy if you could elaborate a bit the
'recovery' procedure you suggested, but taking into consideration my
remarks (e.g. about using the date as an id for the payments to delete,
Otherwise this still could be a good opportunity to install the newest
available debian lsmb package, upgrade it to 1.3.32, and import my
backup from 1 day ago, although I'd prefer to just 'fix' this with some
SQL statements, re-do some 4 or 6 payments, and upgrade just by
unpacking the newest version over the current one.