Re: At the end of my teather with LSMB

["Chris Travers" <..hidden..>]

On Wed, May 28, 2008 at 12:03 AM,  <..hidden..> wrote:
> 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?

The only way you can guarantee consecutive invoice numbers is to lock
and serialize your transactions.  Now, the later you lock, the less
contention there is, but you still have locking issues.  Also, the
less you lock, the better concurrent performance will be.  However,
you still have to lock an wait.

The basic reason is:  if a transaction rolls back for whatever reason
you don't want that to create gaps.

Now, in a web-based program, this is a lot harder :-).

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

My point is that different regions may have different requirements in
this area.   The suffix in my case is so that, in any report I run,
the voiding transaction will show up next to the original
transatction.  This makes is much easier to see which transactions
were reversed.  However, it may not be valid everywhere.

Best Wishes,
Chris Travers