Subject | Re: [firebird-support] Re: Generator question |
---|---|
Author | Mark Rotteveel |
Post date | 2009-05-14T17:43:51Z |
Myles Wakeham wrote:
depending on the local law for 1) throwing away numbers without an
audit-trail or 2) recycling numbers out of order.
Do not reuse 'lost' numbers, but mark them as being lost (+ reason).
Also it is better to have gaps in your numbering (and usually
explainable to customers and tax auditors), then it is to have
unforeseen duplicates in your numbering due to synchronisation problems
or seemingly lost invoices that weren't actually lost (double numbering
is usually much harder to explain to your customers and to the tax
auditors...).
error-prone, that also prevents people from already telling an invoice
number, while the final invoice gets a new number due to a data-entry
problem (and the old one is even recycled in your current scheme), with
all kinds of customer service problems as a result.
Mark
--
Mark Rotteveel
> Since a generator is being used to get the next invoice number for theYou (are your clients) could get in trouble with the tax agency
> data entry, and I need to show this to the user at the time of data
> entry, the problem is that if they cancel then go back to enter a new
> one, it is incrementing the invoice numbers so there are holes in the
> sequence. I just want to be able to recycle the invoice numbers that
> have not yet been actually created so that when a user returns to do the
> invoice again, they don't get a number that shows that the out of
> sequence problem.
depending on the local law for 1) throwing away numbers without an
audit-trail or 2) recycling numbers out of order.
Do not reuse 'lost' numbers, but mark them as being lost (+ reason).
Also it is better to have gaps in your numbering (and usually
explainable to customers and tax auditors), then it is to have
unforeseen duplicates in your numbering due to synchronisation problems
or seemingly lost invoices that weren't actually lost (double numbering
is usually much harder to explain to your customers and to the tax
auditors...).
> I'm thinking that using a separate document ID table and justAssigning the invoice number after actual entry might be easier and less
> incrementing that when the document is actually saved might be the best
> (and probably only) option for this. At least I can guarantee that two
> users won't get the same document ID number allocated, and I can reset
> the number back if the user cancels the data entry.
error-prone, that also prevents people from already telling an invoice
number, while the final invoice gets a new number due to a data-entry
problem (and the old one is even recycled in your current scheme), with
all kinds of customer service problems as a result.
Mark
--
Mark Rotteveel