Quoting Luke <..hidden..>:
That would be good for various reasons. However, making it user immutable, might not be reasonable. What if, for example, you royally screw up an invoice, perhaps by putting the wrong invoice number in on your own. You will want to go back and fix that.
This wouldn't be a problem if you were unable to enter an invoice number at all: you create an invoice, the database gives you a number, and you live with it.
What needs to happen, I think, is that an invoice needs to be utterly unpostable, if the invoice number value is set to something which already exists.
In my scenario above, this wouldn't be an issue.
The default is already to increment them (except that they don't reset at the start of the month, if you use something like <?lsmb YY ?><?lsmb MM ?>-001 as your default). I think they should always seek the lowest possible number, which would cause a reset.
I don't think that this method of invoice numbering is acceptable in the UK, but I'm not a tax accountant. Perhaps one way around it is to have a column in ar which is unique and database-incremented, in addition to what is now called the invoice number. Those of use who need a perpetually incrementing invoice number can simply change our templates to use this instead.