[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Requirements for unique customer invoice numbers
- Subject: Re: Requirements for unique customer invoice numbers
- From: "David Bandel" <..hidden..>
- Date: Wed, 25 Jul 2007 07:36:29 -0500
On 7/25/07, Charley Tiggs <..hidden..> wrote:
Chris Travers wrote:
> Hi all;
>
> One of the serious challenges in this sort of software is how to support
> local regulates when different countries may have different or even
> conflicting requirements, and without burdening everyone with everyone
> else's local requirements. This is not an easy problem.
>
After reading some of the comments, I want to make some suggestions on
how to work with this. These suggestions will work for me, and I
suspect for most others as well, however we need to work out the
details and run up a trial balloon:
1. I know I've had a UNIQUE index and autoincrement on invnumber for
a _long_ time. I absolutely must have sequential, unique numbers for
my invoices, so I modified the database to handle this years ago under
SQL-Ledger.
2. For reversing entries, I sugggest a text box at the end of the
line item line (following the box for serial number) where an invoice
number can be inserted.
What this would do: provide a reference for _that_ return against the
original invoice. So if a customer buys 10 widgets, and next day
returns one as defective, I could include the invoice number against
the one returned item (that shows a negative number purchased). This
is basically how I do it now, but the original invoice number(s) go in
the notes box and I have to manually sort through the items if there's
a return against more than one invoice. This should work no matter
how folks work returns (i.e., a new negative line-item invoice or a
separate AR transaction using a different serial # sequence just for
returns).
3. For those using alphanumeric invoices, most of those that I have
seen have the alpha portion as a prefix to the number (normally
hyphenated). I suggest polling anyone using alphas to see where they
are and just include another field to hold this alpha identifier.
That would still allow a numeric field, and it could be combined with
the alpha to be UNIQUE in case you have I-### invoices and A-###
transactions using the AR table.
I think neither of the above suggestions is radical, and if they will
satisfy the majority, should probably be included in 1.4 if not
sooner.
My thoughts are my own and often disjointed, so feel free to rip this
to shreds (I have a very thick skin).
Copying this to -devel to get widest dissemination (and criticism).
Ciao,
David A. Bandel
--
Focus on the dream, not the competition.
- Nemesis Air Racing Team motto