Stock de-allocating from the sales order when multiple moves have been put into stock (25R2)

@FHubsch check your build first. There's a known 25R2 defect where the final Move on a production order linked to an SO line doesn't allocate the receipt to that line. It comes with the new manufacturing release process, and it's reported fixed in build 25.201.0213. Thread with the support case numbers is here:

https://community.acumatica.com/manufacturing-89/manufacturing-new-release-process-glitches-33765

If you're below that build, the update is the real fix. Anything else is cleanup you'll keep repeating. If you're already on it or later and still see this with multiple moves, log a case and reference that thread, because that would be a different defect.

For orders that are already stuck, you don't need to clear the production. The cleanup people have used is on the sales order line: clear Mark for Production, remove the line details, retype the quantity, then check the allocations. It does drop the link between the SO line and the production order, so try it on one order in a test tenant first.

https://community.acumatica.com/manufacturing-89/item-not-allocating-after-both-production-order-and-move-transaction-completed-25143

I'd stay out of SQL for this one. The allocation isn't a flag on the SO line. It's a chain of inventory plan records tying the SO demand to the production supply and then to the receipt, and the availability quantities are built from those plans. A script that patches one table leaves the rest disagreeing, and that's harder to unwind than the original problem.