- When a SOP sales order is fulfilled, a record of the bin allocation to the sales order line is made in SOP10203.
- When the sales order is subsequently converted to a sales invoice, the bin allocation changed to the SOPNUMBE of the newly created invoice. The Bin allocation is then against the invoice because the invoice, when posted will ultimately take the stock from inventory.
- The sales order at goes to history tables.
- When the invoice is posted the bin allocation record in SOP10203 is marked as posted by setting the POSTED field =1, effectively marking the bin allocation as historical.
JOIN SOP30300 ON sop30200.SOPTYPE = SOP30300.SOPTYPE
AND SOP30200.SOPNUMBE = SOP30300.SOPNUMBE
JOIN SOP10203 ON SOP30300.SOPTYPE = SOP10203.SOPTYPE
AND SOP30300.SOPNUMBE = SOP10203.SOPNUMBE
AND SOP30300.LNITMSEQ = SOP10203.LNITMSEQ
AND SOP30300.CMPNTSEQ = SOP10203.CMPNTSEQ
WHERE POSTED = 0
AND SOP30200.SOPTYPE = 2
Running the above query looks for live allocations to sales order lines for sales orders that are now in history, something that should not occur. The issues is that I’m seeing tens of records returned for this query.
On checking, the records for these allocations to sales orders in history are duplicated. They are also existing, marked as POSTED for the associated invoice that derived from the order that is now in also in history.
From this evidence, it seems sometimes when an order is invoiced and moves to history, the bin allocation is correctly being made against the resulting invoice, but the original bin allocation against the sales order is not being deleted.
This causes me problems as our custom pick list routine sees that there is not enough available stock in the bin to fulfil the next order that comes along for those items due to this phantom bin allocation.
Please comment if you too get this issue or have tracked its root cause down. I have introduced some monitoring to see if I can identify the circumstances under which this occurs and will update this post if I find a solution myself.