Re: At the end of my teather with LSMB

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

On Tue, May 27, 2008 at 8:11 PM, Luke <..hidden..> wrote:
> 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.

I agree with your outline but here are a few things to consider:

Invoice is printed but not posted.  Gap in number occurs.
Invoice is posted but not printed.  Can you reprint?  In some
countries (Greece, for example) you cannot.
Suppose there is a printer error, and the invoice jams.  How do you
address this?

Does this affect invoice numbers?  Or do you have to track sequential
numbers in other documents as well?  Are all invoices sequential?  Or
are there multiple sequences for invoices?  (for example, separate
numbering if the invoice is also used as a packing slip)?

To really make this stick, you have to eliminate separate printing and
posting (probably a good idea),

Now, I am going to describe a nightmare to you (why I use Greece as an
example).  I assure you I am not making this up.

In Greece, all invoices must be printed on sequentially numbered
invoice paper which is purchased from the local tax office.  When
audited one must account for every piece of invoice paper issued to
you!  The papers must be used for the following sequentially-labled
documents (each document type has its own sequence!):

* Invoice
* "Transit voucher" (fancy packing slip)
* Combined Invoice/Transit Voucher
* Product Returns
* Voids

Often UPS trucks are searched to ensure that proper documentation (on
proper paper!) accompanies shipments.

So my thinking is that a generic document control number, associated
with a printed document could be the best framework for generic
regulatory compliance modules.  This may also allow some parallel
options for multi-user use since multiple sequences could be used
where useful.

Best Wishes,
Chris Travers

>
>> 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
>
> -------------------------------------------------------------------------
> This SF.net email is sponsored by: Microsoft
> Defy all challenges. Microsoft(R) Visual Studio 2008.
> http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
> _______________________________________________
> Ledger-smb-users mailing list
> ..hidden..
> https://lists.sourceforge.net/lists/listinfo/ledger-smb-users
>