Re: At the end of my teather with LSMB

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

First a note on consecutive invoice numbering and why forcing this is
not reasonable for all users:

The only way you can ensure that all invoices are consecutive is that
they run sequentialy from the point of getting an invoice number.
Otherwise, you allocate invoice numbers, some transactions roll back,
and you get gaps.

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.

However, some businesses will need this regardless of the performance
cost so an optional module would not be a bad idea.  I wrote this once
for Greece and might look at rewriting the logic if there was demand
(or handing my previous work for SL to someone else to rewrite if
someone wants to do this).  My approach there was not to restrict
invoice numbers proper because that is incompatible with other Greek
requirements.  Instead each document had an (internal) invoice number,
and any number of printed document numbers (Greece requires
sequentially-numbered packing slips too!).  There was a certain amount
of logic relating to numbers of appropriate document types (can't
issue a return on a voided invoice, can't issue a "combined"
packing-slip/invoice if either has already been issued, etc).

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.

Similarly, if I have 12345 as my last invoice?, can I add another
invoice with 123451?  How about 12345-?  How about 12345.?  How about
"12345 "? Properly handling the regulatory compliance rules will
probaby require national packages specifically for this purpose
(though there may be some generally useful things that can be packaged
as well).  For those with sequential numbering requirements, none of
those work, but if the only requirement is that they not be unique, I
could add non-printable, invisible characters after an invoice number
which would not display (for example, a tab or a space) and thus
defeat the system.  Hence I am somewhat retiscent to make the change
without a fair bit of dialog on what is actually required for the
lowest-common denominator, and what really should be pushed to local
compliance modules.

Best Wishes,
Chris Travers