PartAlloc QTY Transitions

I am trying to create an In-Tran Data Directive that will put a hard stop on users over Fulfilling orders. I’m trying to prevent an over shipment further upstream (we had several and it’s an issue with firearms). I created a BAQ that is being called VIA Custom Code (DD/In-Tran/SYNC/Terminate on Error) that basically provides summed totals of what was already shipped, currently “Reserved/Allocated/Picking/Packed” and what the Order/Line requires. My issue appears to be the way Epicor Updates the PartAlloc table. In short, I am summing up what they are doing in the current transaction and adding that to what was already shipped as well as what is in (Reserved/Allocated/Picking/Picked) and comparing quantities to Order Line total. If the quantity exceeds the line total it stops the transaction.
For starters if the current transaction is an Update I stop it if there is more than 1 row in PartAlloc for the order/line( a saw a few in there). If the transaction if Adding a Row I just sum Shipped/PartAlloc/ttPartAlloc. One of the questions I have is if there is an existing row for same order/line/rel shouldn’t any new PartAlloc against that be an Update? In other words I shouldn’t see 100/1/1 Reserved:20 and then be able to use Fulfilment Workbench to Create another reservation for 15 (totaling 35 between 2 PartAlloc Records)? It should update the 20 to 15 and not create a new row? I ask because I see 4 duplicate records in there. This leads to the next question. If we can/should only have 1 row per Order/Line/Rel then what is the Process the PartAlloc update follows? I assumed you would normally start with Reserved ->Allocated->Picking->Picked->Packed (PartAlloc records gets deleted when you set ReadyToInvoice in the Shipment). If that is the case can you have a given PartAlloc record that has quantities in more than one stage? 20 In Reserved and 20 in Picking same row? What I have seen is the ttPartAlloc appears to “move” the quantities during an update by writing 0 in the old state and updating the new state with quantity. If this is the case (for updates) where only 1 row will exists and only 1 qty per “state” then I should be able to just ignore what is currently in the database and just assume that the quantity in the ttPartAlloc will “win”? My false positives maybe from over complicated IFF statements to compensate/anticipate transaction that are not possible.