homepage Welcome to WebmasterWorld Guest from 54.161.197.188
register, free tools, login, search, pro membership, help, library, announcements, recent posts, open posts,
Pubcon Platinum Sponsor 2014
Home / Forums Index / WebmasterWorld / Webmaster General
Forum Library, Charter, Moderators: phranque & physics

Webmaster General Forum

    
JS generated invoice number
Consecutive numbering
Graham2107




msg:3530991
 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.

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.

Graham

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

 

g1smd




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

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.

jtara




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

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.

LifeinAsia




msg:3531367
 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.

jomaxx




msg:3531406
 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.

jtara




msg:3531407
 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).

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.

Graham2107




msg:3531757
 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.

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.

Graham

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

LifeinAsia




msg:3532112
 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.

jtara




msg:3532137
 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.

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.

piatkow




msg:3532189
 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.

g1smd




msg:3532459
 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.

Global Options:
 top home search open messages active posts  
 

Home / Forums Index / WebmasterWorld / Webmaster General
rss feed

All trademarks and copyrights held by respective owners. Member comments are owned by the poster.
Home ¦ Free Tools ¦ Terms of Service ¦ Privacy Policy ¦ Report Problem ¦ About ¦ Library ¦ Newsletter
WebmasterWorld is a Developer Shed Community owned by Jim Boykin.
© Webmaster World 1996-2014 all rights reserved