BOP

[former_member561547]

Hi.

We are having some problems when we run the BOP in APO system to update dates and quantities of scheduling agreements. Some documents are being processed ok but others no (creation date <= dec 15, 2015).

This issue began after add a product (in dec 16, 2015) in the master data and all his corresponding configuration so that it would be considered in APO. These are the steps we follow to do this taks

- Add product number in Integration Models (product, Stocks and Trx Data, not in GATP model).

- Generate the corresponding Integration Models (IM).

- Deactivate IM (product, Stocks and Trx Data. Not GATP model).

- Activate the new ones.

- Run Master Data Process Chain.

- Add Characteristic Combinations by flat file in every Master Planning Object Structure.

- Verify and fix inconsistencies due to the new Characteristic Combinations in every planning area.

- Add product characteristics in //mat1 to link it with plants.

- Add product in transportation Lane and link it with a specific means of transport.

- Include all objects to Supply Chain Enginner.

- Copy Characteristic Combination from planning area.

Last week a user realized this problem. While we were analyzing this problem, we found in trx //CC (CIF Cockpit) the following error when executing BOP

Those entries in log correspond to sales documents that cannot be updated and as i said, creation date is less or equal to dec 15, 2015.

Does someone have a similar problem? Can you help me to solve it?

BR,

Julian.

[former_member561547 · Accepted solution]

Hi everybody.

This issue has been solved. There were a problem with material group master data, something not related with the original post.

Talking with the user, he told us material group master data had been updated few month ago. This information is also store in scheduling agreement. BOP probably checks values for material group in scheduling agreements against master data and documents with old material group values were not updated.

After we update those values in VBAP table, the scheduling agreements documents were successfully processed by BOP.

Thanks all of you for your help.

Best regards,

Julian

[Parth_Soneji]

Hi Julian

Try the activation of new IM in the below sequence

- Deactivate IM

- Add product number in Integration Models

- Generate the corresponding Integration Models (IM)

- Activate the new ones

Also you mentioned you are not adding this product in GATP model (ATP check). What is the reason behind this? Why do you want the system not to do ATP check in APO but you still send them to APO and run a BOP on it to re-align the confirmation / dates within APO? This is really strange and defied the purpose of APO GATP.

Hope this helps.

Parth Soneji

[former_member561547]

Hi Parth.

The steps described were made by a coworker. I mentioned them in that way because we think it could be the reason of our problem.

Actually, when we realized that new product was not included in the GATP model, we inserted the product in it. After that, we created a new IM, deactivated the actual model and activated the new.

On the other hand, yesterday we could reproduce the same issue in a QAS environment without adding the product to the IM.

Thanks for your reply. Next time I will try to do the deactivation and activation in the way you suggest.

BR,

Julian

[Parth_Soneji]

Okay.. So are you saying that even after putting this new product in the GATP model, you are facing the issue? To me, it looks like some master data issue with this product. You may have to dig deeper to understand what master data is causing this issue.

Hope this helps.

Parth Soneji

[former_member561547]

Hi Parth.

As I mentioned in previous post, in QAS environment we have the same problem without doing the product configuration, so probably it is not a master data issue with this product.

After run BOP we get a log error en tcode /sapapo/cc with the message of the picture I added in the first post.

Any other idea? Thanks!

BR,

Julian.

[babu_kilari4]

Hello Julian,

From the error message that you posted, it looks to me that there is another user that is processing the document and thus you are seeing the CIF errors. If you're sure that there are no other jobs / users that are processing these scheduling agreements, you may further need to check your user locks in SM12.

Thanks & Best Regards,

Babu Kilari

[former_member561547]

Hello Babu.

We have already checked locks in SM12. Also we checked SM50 for processes and we didn't find records where the objects were locked.

The user that appears locking the objects in the error message is the same used to connect both environments (R3 and SCM). We get this error message immediatly after the BOP execution.

Thanks and Best Regards,

Julián.

[Former Member]

Hi Julian,

Looks like your sales document is open in change mode while BOP result is being published by same BWUSRSP6.

If you have BOP variants defined for background processing, check if the sales documents is picked up by only one of the variant.

Thanks, Nikhil

[Former Member]

Julian,

I will assume that your PO2PROF100 is the RFC name of your ERP system.  Anyhow, this is the system that has the locking problem.  Is this where you reviewed your SM12 locks/SM50 processes?

Best Regards,

DB49

[former_member561547]

Hello Nikhil.

You are right, we have BOP variants defined for background processing. But in this case we are executing the BOP process manually, selecting only one of the variants we have.

Also, when we run the background process, there is a 10 minutes gap between one and another process to avoid this issue.

Thanks and Best Regards.

Julian.

[former_member561547]

Hi DB49.

As you assumed, P02PROF100 is our ERP system. Is there where we have reviewed our SM12 locks / SM50 processes. Everything was correct in this transactions.

Thanks and Best Regards,

Julian.

[Former Member]

Julian,

What are your settings in OVZ1 and OVZ2 with respect to blocking?

Best Regards,

DB49

[Former Member]

Julian,

See if the note 389313 - Backorder processing: E-message in outbound queue helps.

Thanks, Nikhil

[former_member561547]

DB49

I assume that settings in OVZ1 and OVZ2 apply to all documents of the same type with respect to blocking.

If this is the case, then it is not what we are trying to solve because the same process updates newer documents but not older ones.

Thanks again and Best Regards.

Julian

[former_member561547]

Nikhil

Note 389313 is not applicable in our system.

Thanks and Best Regards.

Julian