Re: At the end of my teather with LSMB

[Luke <..hidden..>]

On Tue, 27 May 2008, Chris Travers wrote:

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

By the way, if I suggested that, it was in error.  The only thing I wanted 
to non-optionally force was the uniqueness of invoice numbers (sales, 
vendor).  Probably couldn't do that with GL entries of other kinds, lest 
recurring transactions become a problem.
Invoices are considered legal documents, so it is reasonable to 
inconvenience sloppy users to keep their numbers unique.

Here is how I would like to see the forced sequence _option_ be 
implemented.

In defaults, we currently can do something like:

<?lsmb YY ?><?lsmb MM ?>0001

You will get:

08050001
08050002
08060003

Some may like that, but in my opinion, most would want:

08050001
08050002
08060001

If you want to cover both cases, then leave the current system as-is, and 
implement a new token.  Something like:

<?lsmb YY ?><?lsmb MM ?><?lsmb lowestnum 4 ?>

Where "lowestnum" specifies that the system must lookup the 
max(PostedInvoiceNumbers) value, and add 1 to it, and "4" specifies a 4 
digit number, left-padded with zeros.

Give me a second, and I can probably think of some cases in which this 
might fail, but it is at least along the lines of what I am thinking.

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

Indeed.  You might make a defaults option to disable the entry of invoice 
numbers for certain user classes.  So only an "admin", for example, can 
manually edit the invoice number on a post in progress.

Certainly wouldn't solve all problems.

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

Agreed.  I see no problem here.

> 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

Yes, but you have those problems now.  In addition, you have the duplicate 
number problem.  That is solvable, and the side effects do not seem 
programatic, but instead seem usage related, which is no different then 
the current situation.

Now, to your actual question: for one thing, you can strip whitespace from 
the right and left hand sides, and maybe even from the entire string.  
Make it a default to trim it from the whole string, and put in a defaults 
option to disable the prevention of mid-string spaces.  There shouldn't 
ever be a good reason to put whitespace at either end of an invoice 
number, although spaces within the number may be needed in some 
circumstances.

You could also block non-alphanumeric characters from appearing at either 
end of an invoice number.  Doesn't solve the problem, but fixes possible 
stupid errors.  Maybe make an exception for matched bracket sets ("()", 
"<>", "[]", "{}").

Other options include setting a permitted characters option in defaults.  
For me, for example, I would limit them to alpha, numeric, and the dash 
character.

As a programmer, I would use a regexp, but that is certainly not going to 
happen.:)

The first thing, however, is making certain of uniqueness.  If you require 
uniqueness, 12345 and 12345R would still work just fine.  Whether someone 
should use them is a local matter of discretion, as it is now 
irrespective of unique numbers.

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

See above.  There probably isn't a reason to allow non-printable 
characters.  That probably gets tricky with character sets other than 
US-ASCII or 8859-1, however, and I'm not sure how you should deal with 
that.

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

Where do you want to have it?

Luke