Not displaying the reference number in such forms and then automatically generating it and populating the appropriate tables with it was discussed but that detracted from the freedom to make any non standard transaction reference by the end user and hence given up.
This happens when two or more transactions of the same type are being created and submitted (by different users or the same user from different browser tabs/windows) either simultaneously or one after the other after all had opened the entry form for creation.
When each instance opens an entry form for record creation, the current accepted dispensation makes the next available reference number as the default value in the form. This will be the same in all such form instances across users / browser instances as long as the last record for the transaction type reference has not changed. When the first one submits the record it is taken without any error. When the second one is submitted, it is bearing the old "next reference" still and hence is rejected as it had been allotted to the one which was submitted first. Whilst it is possible to allot the real next reference that obtains at the time of submission, it was thought to be best presented to teh end user for choice of reference number instead - it may be implemented in private FA dispensations by allotted the next reference directly though and the code for it has been placed in the forum and possibly in the wiki adn the end user can make a choice.
The best way forward to have made a sys_prefs flag for prompting the enduser for choice of new reference or automatically take on the next available one. Although this affects a plethora of forms, it can be implemented directly in the add method of the relevant class definition.
@joe: If taken into the core with the appropriate default, it will save a few heart stops.