Re: At the end of my teather with LSMB

[..hidden..]

Quoting Chris Travers <..hidden..>:

> Now for midsize businesses entering lots of invoices, this may not be
> reasonable.  Basically it means you are extremely limited in terms of
> scalability, and after you have a few people in your AR department,
> they end up waiting on eachothers' transactions.  Needless to say, I
> don't see this as a good thing.

ISTR that JD Edwards provided guaranteed consecutive numbering, (but  
it's a long time since worked with JD Edwards). That software was  
designed for high-volume transaction processing.  How did they do it?

> However, some businesses will need this regardless of the performance
> cost so an optional module would not be a bad idea.

I think this would be the best approach.

> Now for unique invoice numbers-- on the surface this looks like a slam
> dunk and I may go ahead and add a UNIQUE index to ar.invnumber.
> However, once you get past that point things can become dependant on
> local requirements.  For example, consider tracking reversed
> transactions.  I see no inherent reason why the invoice number would
> need to be different if I am voiding (fully reversing) an erroneous
> transaction.  However, suppose this is a problem, and that each
> invoice needs to be both guaranteed unique and sequential.  In this
> case, if I have an invoice number of 12345, I can't issue a voiding
> invoice of 12345V, but for those of us who have no such requirements,
> this is very helpful in tracking what happened with a given invoice.

Over here, I believe that the standard way of dealing with erroneous  
invoices is that you do reverse them, getting a new sequential number  
and all, and keep the error and reversal as evidence for when you are  
put to the question.

R