I think I understand and agree with your position.
For you this is business, albeit open source, so clearly your time is
very valuable and also scarce.
I did not write for help from you specifically, but was also thinking of
a possible reply by Erik, _and_ assumed I was confronted with a
non-desirable 'feature' of the Payment forms which led to my unintended
manipulation of many records instead of a few. This it-is-a-bug
assumption was what made me feeling having the 'right' to raise the
issue, instead of just restarting from the latest previous backup.
Not being an accountant, nor being well introduced in business
administration and cases, I didn't realise the extra-ordinary character
of my setup.
So, not restrained by too much knowledge it was not
difficult for me to complain about what happened in the manner as I did.
However, as you explained before, it's not common (although not
'unheared of' :) to have so many unpaid invoices hanging around.
with that and would be perfectly happy if you'd spend your time with
improving the software instead of looking for ways to help this case,
let alone with making changes to lsmb based on this case.
What I mean to say is: don't bother. Really, I mean that. I'd be
perfectly happy in keeping things simple until a thorough description is
written down in the manual, so that pple wouldn't need individual help
anymore to find out how to process things.
If you consider the lax payment requirements an 'agreement', yes, then
one could categorise them as that.
In fact, there is no other agreement with those 'vendors', so it is
> If so set up one vendor account per payment agreement.
already in the 'main account'. Or are you referring to the various
departments in the vendor company?
> Note multiple vendor agreements can be put under the same company,
> but in 1.3 they cannot share billing/shipping address or contact info
> (this is changing in 1.4 btw). Note that payment thresholds and the
> like can be set per vendor agreement.
> >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.
> Ok. There are some other features you can use to track these as well.
> In particular payment threshold and setting invoices to be on hold (if
> they are not to be paid now). With a large number of small
> transactions, particularly if they are automated, I highly recommend
> going with batch workflows. In this way there is basically an extra
> review process between entry and hitting the books. Particularly in
> automated environments this puts a human in control. In non-automated
> environments, it lets you put someone in charge of data entry who
> cannot modify the books directly.
Ok, but I would still divert from the 'specific case' though, and refer
> 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'.
> Actually, these sorts of complex invoicing environments are things we
> try to support. In fact most of 1.3's development was sponsored by a
> company who processes up to 5000 invoices per payment workflow (batch
> payments), and where some vendors split payments in specific ways,
> where fees are charged for issuing payments, and other things. So I
> wouldn't say "unheard of." Without spending some time on the other
> features used for invoice management, I can't tell you what if
> anything needs to be changed in our interfaces to handle your specific
> cases though.
to my original suggestion that in general forms that by default would
manipulate a lot of data without any user input other than hitting
'Post', still might be undesirable.
Yes, thanks for the suggestions. I will let them 'sink in' and see how
> So maybe a reason
> indeed not to invest too much time, if at all, in improving
> software for a case that seldom occurs or maybe even shouldn't
> occur at
> all in a professional accounting environment.
> Here are some features to take a look at carefully:
> 1. Putting invoices "on hold"
> 2. Multiple vendor accounts per company
> 3. Batch workflows (these are batched for review).
> It may be that these three features in some combination may meet your
> needs. If not, then we should figure out what else is needed.
and when to implement them.
Ok, Payment Reversal, I will see whether that works for me.
> However, I'd still be very happy if you could elaborate a bit
> 'recovery' procedure you suggested, but taking into
> consideration my
> remarks (e.g. about using the date as an id for the payments
> to delete,
> Hmmm actually as it occurs to me the better solution would be to go
> through Cash/Vouchers/Payment Reversal (it does create a batch you
> need to review but this is good because if you reverse the wrong
> payment at least you catch it. And this is transparent from an
> accounting viewpoint.
Thanks again for your time, and for your explanations.