|JS generated invoice number|
| 10:49 am on Dec 19, 2007 (gmt 0)|
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.
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)|
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)|
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.
| 6:40 pm on Dec 19, 2007 (gmt 0)|
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)|
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)|
|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).
| 6:33 am on Dec 20, 2007 (gmt 0)|
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.
[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)|
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)|
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.
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)|
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)|
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.