I believe we are missing one UPDATE query as allocations are still available AFTER committing the payment.
The SQL UPDATEs for supptrans do not seem to be correct. Trying to unravel it now...
I had to add "settled=1, " to the SQL statements:
PHP Code:
/* Firstly subtract from the payment the amount of the invoice */
$SQL = "UPDATE supptrans SET settled=1, alloc=alloc-" . $PaidAmount . " WHERE id='" . $PaymentID . "'";
$ErrMsg = _('Cannot update an allocation against the supplier because');
$DbgMsg = _('Cannot update an allocation against the supplier using the SQL');
$Result = DB_query($SQL, $ErrMsg, $DbgMsg, true);
/* Then add the amount of the invoice to the invoice allocation */
$SQL = "UPDATE supptrans SET settled=1, alloc=alloc+" . $PaidAmount . " WHERE id='" . $PaidID . "'";
$ErrMsg = _('Cannot update an allocation against the supplier because');
$DbgMsg = _('Cannot update an allocation against the supplier using the SQL');
$Result = DB_query($SQL, $ErrMsg, $DbgMsg, true);
But then if you click on "Allocate this payment" on the following page it takes you to an allocation page with invalid data because it is passing "?AllocTrans=25" even though the payments are already allocated. I believe this is what caused the AUTO_INCREMENT value to increase by 1 though there are no new records created (i.e., due to failed INSERT)...
While I think the IDEA of integrated allocation is nice I think we need a lot more testing before we release it...
And I say that with the greatest of respect for all work done here...
I think if logic is added around line 693 to remove "?AllocTrans=NNN" when already allocated this can be made to work properly...
For now I have stripped out all the new code on lines 375-387, 549-559, 591-622, and 1329-1369.