Welcome to WebmasterWorld Guest from

Forum Moderators: phranque

Message Too Old, No Replies

JS generated invoice number

Consecutive numbering



10:49 am on Dec 19, 2007 (gmt 0)

5+ Year Member

We run a booking reference system that is currently issued manually for running our steam trains for tourists.

We use the date of the month, then an alphanumeric code for the month and a code for the time of departure.

In order to make the booking reference number unique our booking clerk adds a consequtive 3-digit number to this:

23MB001, 23MB002 etc.

Where typically:
23 is the date of the train
M is December
B is the morning train, D would be the afternoon train

That bit is easy with JS, no problems there. Cannot use the time and date as an incremental suffix as if there is a group of people all paying independantly then they have to use the same number and our credit card server will not accept that. Currently I use the time and date as a suffix to get over that problem.

How do I generate the 001 , 002 ,003.... 999 etc. an append it to the "23MB" portion of the reference number?

I have database available (unused) as part of our web server hosting plan but am sure quite where to start.


[edited by: tedster at 8:22 am (utc) on Dec. 20, 2007]


4:32 pm on Dec 19, 2007 (gmt 0)

WebmasterWorld Senior Member g1smd is a WebmasterWorld Top Contributor of All Time 10+ Year Member Top Contributors Of The Month

Firstly, I don't think you should be using JavaScript to let the user generate these numbers within their browser. That is wide open to them crafting their own numbers and sending them to your server.

You should be using PHP/perl/ASP whatever on the server to do these computations. Does each person have a unique user ID or customer number they use to access the site, and does that allow them to only access their own data?

Additionally, any such booking reference should be unique. I should not be able to have the same number on the same day next year. The system also needs to expandable in case in the future there are more trains, or more passengers.

I would use a minimum of 200712190010001 (date/train/booking) as the number, but I would also add a random number (perhaps about 8 to 12 digits long) on the end so that people cannot just guess numbers to type in.


5:59 pm on Dec 19, 2007 (gmt 0)

WebmasterWorld Senior Member jtara is a WebmasterWorld Top Contributor of All Time 5+ Year Member

Yes, booking numbers shouldn't be generated client-side by Javascript! They need to be generated by your server-side software.

You should generate them when you create a booking and add it to your database. The booking number should then be sent back to the browser - either by refreshing the page or via an AJAX in-place update.

You probably generate a confirmation page, so I'd include the booking number on the confirmation page.

As an aside, you should not trust any value generated or checked by Javascript code. Any range-checking you put in Javascript code is for the user's convenience only - NOT as a security or data integrity measure. All values need to be re-checked in your server-side software.


6:40 pm on Dec 19, 2007 (gmt 0)

WebmasterWorld Administrator lifeinasia is a WebmasterWorld Top Contributor of All Time 5+ Year Member Top Contributors Of The Month

Ditto the server side suggestions. (And I would consider them *much* stronger than just "suggestions.")

Besides, what happens when you get visitors with JS turned off- they won't get a booking number.


7:34 pm on Dec 19, 2007 (gmt 0)

WebmasterWorld Senior Member jomaxx is a WebmasterWorld Top Contributor of All Time 10+ Year Member

You need to use the database, or at least some kind of server-side scripting, in order to generate the sequential numbers. And it's a more robust solution, as mentioned previously.

If you're really stuck AND only your own booking agent can enter these transactions, you could use the system time (HHMMSS) instead, in order to create the unique numbers. It's a kluge, but it doesn't sound like you're exactly doing rocket science.


7:41 pm on Dec 19, 2007 (gmt 0)

WebmasterWorld Senior Member jtara is a WebmasterWorld Top Contributor of All Time 5+ Year Member

it doesn't sound like you're exactly doing rocket science

The current manual system will only work if there is only one booking agent (or if the other one is right next to them and can look over their shoulder at the log book).

Part of the problem is not realizing that the current system is not suitable for computerization without modification. Or that it's been modeled incorrectly. The customer is not the booking agent, and in the current system, customers don't make-up their own booking numbers. Put this in Javascript in the browser, though, and that's essentially what you're doing.


6:33 am on Dec 20, 2007 (gmt 0)

5+ Year Member

Thanks for all the great advice.

The problems with the solutions suggested are varied (can't see the responses in this forum when you reply). I will try and elaborate as to how the current system works.

We run our steam trains twice per month, an AM train and a PM train. Total passengers (max.) per train = 350. Ticket reference numbers should be simple and easy to decode visually so that a ticket inspector can see which train it is. Our currently manual system prefix for a train running 23rd December 2007 at 08h30 would be 23MB (23=23rd, M=December, B=AM or D=PM). We run trains to and from other locations when we are not doing our "normal" thing and hence the B and D. Others will include a P and S.

As we are a bunch of volunteers, there is no money in the budget to go out and purchase a "taylor-made" system, besides which, for the number of people that we carry every month (last Sunday and first Sunday) the cost is not warranted (yet). We spend all of our income currently on restoration and preservation (our locos date back to 1912!)

We take telephone and internet bookings. Telephone bookings account for bewteen 20-40% of the booking enquiries from people who have no internet access.

I cannot use the "time and date" stamp, as someone has suggested, as if we have a party of people booking (total reference number say 07AA001) with individuals paying their own fare then they use the same reference number when making credit card payments on-line. When making multiple payments I affix the time and date of the payment to the original reference number, which the payye has to enter, to "trick" the credit card server into thinking it is a different booking number (i.e. 07AA001-ddmmYYYYhhmmss). The current cc server (Nedbank) does not allow for multiple payments on the same reference number for security reasons.

My thinking was, to keep the manual and computerised systems somewhat "alike", to create the prefix of the booking reference number the same as the manual method i.e. 23MDxx where 23=23rd M=December D=afternoon train and xx=manual incrementing suffix. Manual bookings never get up to 99 (per train) as, with a train carrying 350 passengers max., that represents total passengers of 1312! (average booking per reference number is 3.75 people).

Using a random number suffix, as someone suggested, will be far too complicated for the person paying money into the bank across the counter as they will have to remember "23MB-691725" etc. Whilst 23MB001, 23MB002 seems simpler. We are trying to keep the system as simple as possible. We have many pensioners who travel.

Our manual numbering starts from 01 for each next trip i.e. having issued numbers for say the 23rd December the next train numbers start again from 01 - i.e. for January 6th will be 06AB01 for the morning train and 06AD01 for the afternoon train.

If I could use a simple database (we have one available on the server) or an external file that could "store" the last number issued say "023" then the next booking enquiry would be "024" making a new booking reference number of 23MD024.

Thus manual numbers issued would range from 01 thro 99 and computerised numbers would range from 001 thro 999 but would never have to go back to 001 as per the manual method, where the next train starts again from 01.

I trust that I have explained my reasoning for using javascript and look forward to some "brain storming" answers. Credits will be given on the website for any suggestion that is used.


[edited by: tedster at 8:26 am (utc) on Dec. 20, 2007]
[edit reason] no urls please [/edit]


5:16 pm on Dec 20, 2007 (gmt 0)

WebmasterWorld Administrator lifeinasia is a WebmasterWorld Top Contributor of All Time 5+ Year Member Top Contributors Of The Month

Everything suggested so far should fit nicely with your requirements, especially if you have a database available. The database can easily be setup for the numbering requirements you require.

As far as the actual specifics for implementing it depend on the database you have and the programming language(s) available to use. It shouldn't take more than an hour to setup something sufficient for your requirements.


5:41 pm on Dec 20, 2007 (gmt 0)

WebmasterWorld Senior Member jtara is a WebmasterWorld Top Contributor of All Time 5+ Year Member

You weren't planning on using a database?

How are the payments actually made? What is to be the result of the user filling-in the form? Does it just send somebody an email, or is it to do online payment processing?

You have to record the details that are entered by the user SOMEWHERE! One normally assumes it's in a database.

What seems a bit strange to me (but I'm unfamiliar with excursion-booking practices) is the way you have a "booking number" for a group (1 or more) of passengers, with the passengers potentially paying individually.

Is this because you have assigned seating? That would be the only reason I can think of to keep passengers together in a group. Obviously, this complicates things and is one more thing to keep track of.

Anyway, you CANNOT do this in Javascript on the browser side. There's no possible way, so get that thought out of your head. (I see it's still dancing around in there! :) )

You need to keep track of the incrementing number on your server, as you yourself have stated.


7:04 pm on Dec 20, 2007 (gmt 0)

WebmasterWorld Senior Member piatkow is a WebmasterWorld Top Contributor of All Time 5+ Year Member Top Contributors Of The Month

As everybody else has said you do need to go with a database. Dedicated number ranges usually create downstream problems, the ideal solution would be both on-line and phone bookings being maintained on the same database. Anything else leaves you with the risk of double bookings.

If you must go with separate ranges then make manuals 001 to 099 and automated 100 to 999 as having both two bookings number 1 (01 and 001) is going to confuse somebody and messrs Sodde and Murphy will dictate that it will on an occasion that will create maximum embarassment.


1:58 am on Dec 21, 2007 (gmt 0)

WebmasterWorld Senior Member g1smd is a WebmasterWorld Top Contributor of All Time 10+ Year Member Top Contributors Of The Month

You misunderstood me a little.

The eight-digit date group was not the date that the booking was being made, but for the date of the train journey.

You dismiss the eight-digit random number for the booking, and instead replace it with a longer fourteen-digit date/time group.

By the way, if you do anything with date and time, use a Big-endian format so that the numbers sort into date order automatically. That is Year-Month-Day-Hour-Minute-Second.


Featured Threads

Hot Threads This Week

Hot Threads This Month