Work around for long running BOP Jobs

[Former Member]

Dear APO-GATP/BOP gurus,

We are encountering locks and errors in our BOP results every day.

Errors can be seen below, they both pertain to same material:

Item Product/Item has not been updated, as the purchase order was locked

Changes not adopted due to different change statuses

What we did is that we split our materials into 8 ranges, just to prevent the long running. unfortunately, there are thousands of POs that has multiple items (mostly more than 50 items) and that is our constraint.

Please help how are we going to have it solved. Any work-around you might want to suggest?

We cannot restore the single variant job due to the fact that it will run long (more than 12 hours) and eventually fails due to connection/interface/etc error...

Thanks in advance!

Zeke

[babu_kilari4 · Accepted solution]

Hello Ezekiel,

If the no. of updates are more in number, these things tend to happen.

Why don't you implement EDQA functionality in your system so that system processes the GRs done by the reciept elements to assign the quantities in synch as per the business expectation ? By doing this, the no. of items that posts the updates back to ECC would be less in number.

Also, choose the right timings for running the BOPs in your system. You said that you had splitted the materials in 8 groups ? Why don't you run BOP at plant level instead of choosing materials ?

Hope this gives some insights.

Babu Kilari

[Former Member · Accepted solution]

Hi Ezekiel,

Ususally we use batch jobs to minimize user locks. But when BOP is updating the Orders users are changing the orders or by system update, then definately locks will occur. I will also accept Babu on running BOP only when users are off line/ in night times or early mornings...there will be minimum locking..

No need to run BOP based on Procducts because there might be number of orders across plants for same material.But if you run at plant level BOP will choose all products ATP for a min. plants. which can reduce locking issues and you can identify when to run BOP for those plants.

If this also not help then split plant wise and product range.

Hope it helps...

Thanks,

Bala.

[Former Member · Accepted solution]

Dear Babu,

thank you for your response. EDQA is something business would probably consider in the latter part as we have just got some implementation that got live recently and they are the ones causing this constraints are having.

as with regard to the variants, no. We are using Prod-Loc as filterin BOP. Let me explain in details how we did the split of materials.

Plant is 2050

Material is 1-1000 (just an example, but we do have plenty of products)

Since we are having BOP cancellation when its run for 1-1000 under plant 2050, we split the materials into ranges and run them in parallel.

jobs:

1: 1-100

2: 101-200

...

3: 901-1000

Also mentioned in my previous message, POs ordering from 2050 has more than 50 items.

For example:

PO 123456789 has items

1, 200, 300, 400, 500, 600, 700, 800, 900

These are our constraints.

Thanks and regards

Zeke

[Former Member · Accepted solution]

Dear Bala, thanks for your response.

Yes we are running the BOP jobs at night, where there are no user activities. and we do not get those locks from users, rather we got them from the same BOP running under 2050, which has different materials in the variant. Yes, we did split the product range... Please refer to the repy i sent to Babu.

It is quite difficult to recover rejected items because it reaches the daytime of users, hence the reprocessing of rejected items will no longer be successful.

Thanks and regards!

Zeke

[babu_kilari4 · Accepted solution]

Hello Zeke,

Since you're running them in parallel; the chances are very much high that the same PO document has two or more updates and all the CIF queues are trying to update the same PO document. The way CIF has been designed for POs is completely different as compared against CIF queues that gets triggered for SOs. For, SOs always an acknowledgement into APO is expected back and hence you see the less locking issues for SO documents.

Did you try internal parallelization for the large BOP without splitting them into smaller variants, You may also seek help from SAP to see what they suggest for these issues.

Thanks & Best Regards,

Babu Kilari

[Former Member · Accepted solution]

Thanks Babu!

I'll further check on that one.

Warm regard!

Zeke