Block the ATP Stock for non-ATP checked items in BOP

Question

Hello GATP Experts,
We have a strange and interesting scenario here with STOs. Let me explain step by step
1) We don't do ATP check for STOs and hence a Z-check mode has been designed and it will be considered for STO documents
2) Now, let us consider a situation where I have a stock of 100 CS for Material M1 at Plant P1.
3) Let's say, a STO document gets created at 09:00AM in the morning with requested quantity 50 and as it doesn't do ATP check this will be fully confirmed
   and consumes 50CS of the stock.
4) So, the net cumulative quantity that is available is 50CS.
5) At 11:00AM,let us say; there is a sales order that was created for a quantity of 100 CS. As the sales document does the ATP check it consumes the only available 50 CS and gets saved with partial confirmaiton situation.
Now, at 12:00 PM - We are running the BOP. When we run the BOP ; what standard SAP does is STO document (as per our business scenario, STOs has higheest priority and they fall on top of the list) gets skipped due to non-ATP check mode and full stock is allocated to the sales order which makes no sense to us which leads to over confirmation situation.
We thought of exluding the STOs from BOP ; however - we end up in not re-scheduling the STO documents which would result in requiring a separate BOP to be run for the STO documents.
FYI - We have contacted SAP and they have confirmed that the above mentioned behavior of the BOP is as designed and it cannot be changed.
Is there any alternative solution for this ? Appreciate your valuable ideas.
Thanks
Babu Kilari

Answer 1

You might have already considered this. pardon if this sounds dumb.
see if you can pass STO's as a receipt in the scope of check for STO's. I presume it is requirement element in your case for ATP checking rule for STO's. Don't include these STO's in sales order checking rules.
This may result in inconsistent ATP logic though. Alternately try creating a Z category for STO and call it a receipt. include this also in the scope of check for STO's. 
Try running BOP and see what happens. BOP on its own is not a gurantee that a requirement is always confirmed over another, whatever be the sorting criteria. If there isnt enough stuff, the system has its own internal logic of sorting too which probably treats priority by time of creation of the requirement.
Publish if you meet any success. These ideas are just based on my fancies
Guru