Mike Castle wrote:
> What do you do on the following scenario:
> Client 1 is placing an order, gets invoice #1.
> Client 2 is simultaneously placing an order, and gets invoice #2.
> Client 1 changes mind and cancels order. Invoice #1 is not used. Invoice
> #2 is.
> Client 3 comes along. Do they use invoice #1, out of order, or invoice #3?
You must use invoice #3, because #1 was already used for another client and it
remain printed on paper.
I made an billing application (Tcl/Tk + PostgreSQL) and invoice numbers are
generated by a sequence. It works with multiple billing location. When an
operator generate an invoice, he work without a number ... the number is
generated in the moment of saving and printing. In this mode, is posible to
cancel a invoice before the number is generated and is imposible to duplicate
When a numer is generated, operators can not cancel printing. In this case, one
number represent always one printed invoice. If the invoice is canceled, it's
"paper version" is canceled too.
> I suppose of the assignment of the invoice number is set up in such a way
> as it is the very last action performed just before the commit, you should
> be able to ensure that indeed the situation of having to deal with a
> rollback would never occur (outside of a system crash between assignment of
> invoice and commit, and that could be explained to auditors).
I use "begin transaction" ... "commit" (abort) in time to write positions in
invoice because I want to decrease (on increase) stocks on line. In this mode
the other uses get the real stock (I do not use a "stocks" table ... stocks are
calculated "on-line" ... sum(in)-sum(out) on that product for all prices who are
active at that moment) for the products who are in curent invoice. When invoice
is saved positions remain in database and is generated an invoice number or, if
invoice is canceled, all this position are deleted, stocks returns to original
values and no invoice number are generated.
> [What happens in a paper world if a cup of coffee is spilt on some
> invoices, and these precious items are thrown in the trash?]
I cancel all this invoices but I never thrown them to trash because, in ROMANIA,
printed invoces already have a printed number (with safety marks) and when
taxman came to check he want to see all this numbers, valids or canceled.
> Mike Castle Life is like a clock: You can work constantly
> dalgoda(at)ix(dot)netcom(dot)com and be right all the time, or not work at all
> www.netcom.com/~dalgoda/ and be right at least twice a day. -- mrc
> We are all of us living in the shadow of Manhattan. -- Watchmen
I hope this can help ...
Sorry for my poor english.
Data Systems SRL
In response to
pgsql-sql by date
|Next:||From: Volker Paul||Date: 2000-12-22 13:00:43|
|Subject: Re: Create table doesn't work in plpgsql|
|Previous:||From: Tom Lane||Date: 2000-12-22 06:06:27|
|Subject: Re: regcomp failed with error empty (sub)expression? |