Suppose if the Next Available Reference for Journal Entry is JE222 in Transaction References. Change it to JE220. Now if you will make the Journal Entry you will get the message "Reference already in use".

Now place the above code in core and test now. You will see that the message will not appear and the system will itself increment the values and record the transaction with Reference JE222.

I hope now someone can test it and give feedback to @joe.

Joe

Modified the below function in includes/references.inc

at Line 228

function is_new_reference(&$ref, $type, $trans_no=0) //modified by faisal
    {
        $old_ref = $ref;
        while ($this->_get($type,$trans_no,$ref))
        {
            $ref = $this->_increment($ref);
        }

        if ($old_ref!=$ref)
            $this->reflines->save_next($type,$ref);

        return !$this->_get($type, $trans_no, $ref);
    }

At Line 428

function is_new_reference(&$ref, $type, $trans_no=0)//Modified by faisal
{
    global $Refs;

    $old_ref = $ref;
    while (!$Refs->is_new_reference($ref,$type,$trans_no))
    {
        $ref = $Refs->_increment($ref);
    }

    if ($old_ref!=$ref)
        $Refs->reflines->save_next($type,$ref);
    
    return $Refs->is_new_reference($ref, $type, $trans_no);
}

includes/data_checks.inc at Line 666

function check_reference(&$reference, $trans_type, $trans_no=0, $context=null, $line=null)

the code for it has been placed in the forum and possibly in the wiki adn the end user can make a choice.

@apmuthu can you refer the wiki or post where this code is available for this solution.

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.

Any Transaction form picks the value of next reference from Transaction References table and Upon new record creation it sets the next reference in Transaction References table.

This process is very natural but sometimes, not always but rarely the value doesn't increment in Transaction References. The User see the message "The reference is already in use " . Then the user has to manually increment the value in Transaction References.

I could not find the reason why the increment stucks but it is not always like this.

What could be the fix for this problem?