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]