If you'll be using MySQL as a way to store the receipt, you can simply define the field for your receipt number as a numeric/integer type (of an appropriate size), and set it to auto-increment. It will do the work for you, generating a new number as soon as you create a record. I'm pretty sure the field has to be keyed (indexed), but not sure if it has to be a primary key. (Mind's getting hazy - that's what I get for using a table editor to do my work) That's how I'd recommend doing it, because you let MySQL handle the overhead.
www.MySQL.com (and several mirror sites) have the manuals online, so you can see how to use the AUTO_INCREMENT attribute in your declaration.
If you're not using MySQL to store the info (or if you need the number long before you create a record for it) you'll have to keep the last used number (written to a text file, kept in a one-record, one-field table, whatever) so you can look it up when you need it, and add 1 to it. You then store that new number in the same place, so if somebody else asks for one afterwards, they'll generate the next number after yours.
Unfortunately with that, you have a concurrency problem when two (or more) people ask for a receipt at the same time. You have to use some sort of traffic control (a semaphore, record locking, whatever) to make sure anybody else that wants to get a number will wait until you've finished the reading, incrementing and writing of your new number. And if you throw the number away without using it, you can only back it out (set it back to the original number) if nobody's come after you. It's a chore, which makes the MySQL option even more appealing (they do all that for you).
My suggestion, if you need the number before you need the record, is to just create the record when you need the number and fill it with the other data when you are ready. If you want to abandon the transaction, you can just delete the record as-is and the number will get reused the next time around.
..KARL...
<SPAN ATTRIB="DORK">KarlGG</SPAN>