On 7/25/07, David Bandel <..hidden..> wrote:
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.
One of the *serious* difficulties here is that different countries have different rules with regard to numbering of related documents.
For example, in the US, a voiding reversal is not necessarily a separate document. For example, it might be voided before it is sent out (by writing "VOID" across the face), while in Greece is is *required* to be a separate document with a separate incrimenting sequence.
I.e. in Greece you *cannot* legally use the same sequence for basic invoices, voids, and returns (these *all* must use separate incrimenting sequences, as must transit vouchers, invoices, and combined invoice/transit vouchers which is a bigger issue since complying with this means tracking printed documents).
And of course, you seem to require the use of the same sequence for voids as the initial invoices. This is illegal in Greece, according to my understanding.
Obviously one framework for this will not meet everyone's needs everywhere in the world.
So we basically have two options:
1) Don't enforce any rules for anybody
or
2) Let everyone enforce their own rules.
I would opt for the second option but that is not going to be practical until
1.4. We have already built a similar system for handling regional sales tax rules (which can be similarly screwy).
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.
Again, in many countries, numbering rules are different for voids (which must match the original invoice *exactly*) than they are for returns and other sorts of credit invoices. In short, regulation-wise, you have to see two general cases: That of the void, and that of the return. One cannot easily generalize these to a single case without running amok in a surprising number of countries.
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).
I expect 1.4 to have an ability to track returns against invoices per line item. Voids may need to be handled differently, however.
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.
If you read the current inherited code, it takes leading digits.
1.4 (possibly even 1.3 since the code is in) will move this to trailing digits. In other words, in SQL-Ledger, the invoice number 123-456-789 gets incrimented to 124-456-789 instead of 123-456-790. THat seems wrong to me. :-)
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.
I don't think it is enough to satisfy the needs of the majority. If we support a practice which is known to be wrong in a number of countries, that isn't good. I think that we need to look for ways to support local rules so that we can work for universal support in line with our statement of direction.
In short, I am not trying to trivialize your needs or say that we won't support them. Rather I am saying we need to support them in a way which does not deny others the ability to support their own requirements as well.