In which case inserting a record becomes a two stage process. first off write as record, I;d suggest the barest minimum of information, retain that ID, accept user input, validate then update the record.

However this can leads to problems by nature of your design. Unless your system allows order numbers to non contiguous (and I'd check with the user or the users auditors) then coercing an autonumber value to be someghtign like an ordernumber is a bad idea.

Why? you never ever know what may happen to your data, a system generated autonumber ID may skip a few records (as rows get deleted, inserts are made but fail for whatever reason, some servers allow the gap to be altered, most allow the number to be reset. In short its not a good idea to use autonumber for things like receipt no, order no, where the number has a significance outside the system itself. Autonumber columns are there purely for the db engine to have a quick simple method of making a row unique, nothing more, they should not be used for any other purpose outside the system itself.

If you want on order number then there are several alternative methods
either retrieve the current highest order number in the system, requires a table lock, write your record, release the table lock

OR the better solution in my books, store the last used order number in a config table somewhere, theres often a grubby little config tabel in a system containing the data that couldn't be normalised, or is disparate settings and the like.. store the order number there, get a record lock, get the order number, add one, write the new order number and update the last used order number and finally release the record lock.

Another less elegant solution could be to create a skeleton order record, with no data in it, query the db for the first available skeleton record and update that record, writing another skeleton record to replace the one just used. a nasty nasty solution but it may work, again you will need to be carefull with record locks to make sure you don't have problems with mulitple users trying to grab the same skeleton record at the same time

Assuming you are using PHP then I'm pretty certain you need to be using INNODB tables rather than MyISAM, as MyISAM tables do not support transaction.