Need help on BOP run

[Former Member]

Hi Team,

             Need small help on BOP. Whenever a BOP is running, if a sales order is in change mode, will it also be considered in the BOP run?

For example, if a sales order of 20 has a confirmed quantity of 15. This sales order also is included in the BOP run. When this BOP is running, if this sales order has been changed i.e. the requested quantity of this sales order has either been increased to 30 or decreased to 10, how would the BOP result be? Will the BOP be performed on the changed requested quantity or would be performed on the original requested quantity?

Also, during the BOP run of the above sales order, if the confirmed quantity of the sales order has been changed manually, how would the system react?

In my current project, if I try to do a BOP run with a sales order in a change mode, it is allowing and is not giving any error.

Could you please help me how to prevent this situation? Is there any way we can prevent a sales order(that is included in BOP run) from being changed during the BOP run?

Thanks in advance for the help and for your time.

Thanks & Regards,

Srikanth.

[Former Member]

Hi Team,

        Could any one please help me regarding this? This is an issue happenning quite frequently.

      The below is the scenario:

I created 5 sales orders ---- 3 low priority sales orders(LPS1,LPS2,andLPS3 ---- all of equal priority) and 2 high priority sales orders(HPS1,HPS2 ---- all of equal priority). The available stock was consumed fully by LPS1, LPS2, and LPS3. As a result of this, HPS1 and HPS2 have been unconfirmed.Since there is no additional stock available, I want to confirm the HPS1 and HPS2 using BOP. Before running BOP, I have put LPS2 and LPS3 orders again in change mode and am doing the GATP check. I haven't yet saved the sales orders. As a result of this, TQAs have been generated corresponding to these 2 sales orders. Since TQAs have been generated, the confirmed quantities of these sales orders should be "protected" and should not be utilized for confirming any other high priority sales order or any other order. With this setup, I have executed the BOP run.

Contrary to what I expected, the already confirmed quantities of LPS2 and LPS3 have been used to confirm the previously unconfirmed HPS1 and HPS2.

After the BOP run, in the /SAPAPO/RRP3 view, the LPS2 and LPS3 orders have their previoulsy requested and confirmed quantities displayed. The BOP results' screen however shows that the confirmed quantities of LPS2 and LPS3 have been changed to 0 as these have been used to confirm HPS1 and HPS2.

Now, when I save the LPS2 and LPS3 orders, the confirmed quantities remain the same as that of their previous values. When I check the /SAPAPO/AC03, it shows overconfirmation as that of the below data for example:

Receipts: 50  Requirements: 100  Confirmed Requirements: 60

This is an undesirable situation. Could you please let me know if there is a way to avoid this situation?

Thanks in advance for the help and for your time.

Thanks & Regards,

Srikanth.

[babu_kilari4]

Hi Srikanth,

This is a very generic case and is a topic for the discussion in length.

First of all, the very thumb rule that you should bear in mind is that, for BOP - the data from Live cache is considered as source. So, the initial sales document content that is available in APO is being considered and accordingly BOP does rescheduling and changes the confirmation. During the BOP run, if the sales order is in the change mode and if the sales order is saved by the time the BOP finished the run and triggered the queues, always the BOP updated quantity will be sent to ECC. It is because, CIF queue doesn't find the sales document in change mode and updates whatever the quantity that has come from BOP ( APO ). After updating the sales document the BOP updated confirmed quantity will again be transferred back to APO with an acknowledgement queue to keep both ECC and BOP in synch.

Sometimes, due to mishandling of the documents between ECC and APO, inconsistency arises and that is the actual reason SAP suggests us to schedule /SAPAPO/SDRQCR21 and /SAPAPO/CCR reports regularly on a daily basis to keep the systems in synch.

There is also a scenario where in the sales document is in change mode, but it was not saved yet and BOP updated CIF queue tries to update the sales document in ECC. In such a scenario, the queue fails in SYSFAIL error and it will always wait for the user to come out of the sales document and it updates the BOP updated quantity.

So, as far as I know since it is a fact that two systems are talking to each other controlling BOP when the sales document is in change mode is not an easy task. Though you can implement a solution in BOP exit to see if the sales document is in change mode or not by doing an RFC call to a custom developed RFC function module, it is not a suggestible as we do not know how long BOP runs. What would you if the BOP moves on to ATP Checking process after sorting and filtering and during ATP checking process, someone opened the sales document in ECC in the change mode ? Can we control ? I wonder...

I think in SCM 7.0 Ehp3, SAP is thinking in the direction of having APO within ECC to avoid such situations. We need to wait till SAP provides an official stand on it.

Thanks & Best Regards,

Babu Kilari

[Former Member]

Hi Babu Kilari,

              Thanks for the help. Can you please tell me the name of the CIF queue that updates the BOP updated quantity to ERP?

             For simulation, in my present scenario, I have 10 sales orders on which I have performed the BOP run. The BOP run has completed in less than a second. Is there any way we can know the process that has happened between ERP and APO systems during this BOP run? I ran the SQL trace. But, couldn't understand it.

             As an example, I have total available receipts of 1000. I created 7 Low Priority customer orders. At the end of these 7 sales orders, the available receipts was 300. Now, I created 3 high priority customer orders of quantities 200, 150, and 250. All these high priority customer orders have the same priority. Now, using BOP, I want to confirm the partially and the unconfirmed high priority customer orders by cancelling the confirmation of the low priority customer orders. I was able to fully confirm the previously partially confirmed and unconfirmed high priority customer orders.

               Now, if a low priority customer order is in change mode, a TQA would be generated which prevents this order's quantity from getting consumed by other sales orders. But, when I run the BOP, this quantity is not being protected and is being given to the high priority customer orders. I am unable to figure out the error in the process of BOP. Could you please help?

               Could you please let me know if we can prevent a sales order(that is included in a BOP) from being changed(through Standard SAP or through a user-exit) whenever a BOP run is being executed on it?  Because, if a BOP run is being performed on a particular sales order and one wants to change(increase/decrease) manually the requested quantity, since one doesn't have control over the BOP run, one doesn't know whether the BOP run has been performed on it or not before the change of that sales order has happened manually. Could this be a limitation of BOP?

                Thanks in advance for the help and for your time.

Thanks & Regards,

Srikanth.

[babu_kilari4]

Hello Srikanth,

Usually the Sales order CIF queues that were generated by BOP are of the name "CFCO...XXXXXXX". XXXXXX could be the sales document number. You can see these queues in SMQ2 in ECC Inbound after the BOP run. You can also stop the queues using //C4 transaction and see the content of it and how it is updating it in ECC.

If you want to trace what happened between ECC and BOP during the BOP run, trace might not help. I tell you, BOP by design invokes the CIF queue dispatcher to push out the updates from APO ( if it was run in update mode ) and the queues get generated which have the naming convention as explained above. These queues flow back to ECC and uses the standard SD change function module "SALES*DOCU*MAINTAIN ( Don't remember the exact name that is why I mentioned * in between. You can press F4 in SE37, you will get the exact name ).

Now, coming to your example, for the example; that you have provided I guess you can use the ROC application of GATP module and very well manage the confirmations to ensure that always high priority documents are confirmed by taking away the stock from low priority orders that were confirmed earlier. You need to have an ODL built that stores all the documents which are partially or fully confirmed and read to give away the confirmations. There will be a background BOP that gets triggered by the system automatically and it manages to de-confirm the low priority documents and assign the confirmations to the high priority documents Again, Please note that if the low priority order is in change mode, system will not respond as you expect. That is how BOP has been designed.

Usuallu, BOP is recommended to run as a batch process during night when the sales order changes are not being done ( after business hours ). This is the practice that industry has also been following. If you want the real time confirmations to happen between low and high priority documents use the ROC application as explained above.

Please find the below documentation of how ROC works. Please let me know if this explanation helped you.

http://help.sap.com/saphelp_apo700_ehp03_on_erp/helpdata/en/49/980a0231633eeee10000000a421937/conten...

http://help.sap.com/saphelp_sm40/helpdata/en/ee/05fd401800f123e10000000a155106/content.htm

Thanks & Best Regards,

Babu Kilari

[Former Member]

Hi Babu Kilari,

               In my current scenario, BOP was already implemented. BOP is being run 3 times a day ---- 2 times in the morning and 1 time in the night. But during BOP run, sales orders are being changed manually and this is leading to a mismatch in the data that is getting updated in the /SAPAPO/RRP3 and /SAPAPO/AC03.

              In order to prevent this, they are looking for ways in order to prevent the sales orders from being changed.

           Also, as per the standard SAP behaviour, whenever a sales order is in change mode i.e. whenever an GATP check is being performed on a sales order, a TQA would be generated and prevents this quantity from being consumed by other sales orders. So, even if we run BOP on this sales order, this sales order will not be considered and also this quantity will not be assigned to another sales order. This can be achieved by selecting the flag "Temporary Quantity Assignments" in the Global settings of GATP settings. Please correct me if I am wrong.

          In my current scenario, they are looking more in terms of improving the BOP capabilities. I am not sure if they would be willing to go for ROC. Will check with them anyway.

Thanks & Regards,

Srikanth.