BOP issue

[Former Member]

Backorder processing Un-confirms sales order lines when there is enough allocation qty and sufficient stock. Manual ATP within sales order seems to be okay and this happening only when the item category is changed from 'ZXXX' to 'TAN'.

I am debugging the issue in APO with no success. Can someone provide any pointers to look into and check.

Thanks,

[Former Member]

GV,

I will assume that you have looked and found that nothing else in your BOP Sort Profile would move the changed orders to a lower priority. I will also assume that you have looked and found that nothing related to the SD item category is included in your allocation CVCs (this would be very uncommon).

When you change the item category, SD configuration will redetermine the requirements class in R/3. I don't know which requirements class is invoked for you when ZXXX item category is entered in an order(since it is custom to your company). TAN usually determines "041" but your system may differ.

A change in requirements class can invoke an entirely different ATP in APO. The first thing I would look at would be if the requirements classes of the two item categories were different in R/3. If so, I would then go to APO and look at the configuration for Check Instructions (you will remember that check mode in APO = Requirements class in R/3). You might be invoking an ATP that is either undefined, or does not meet your business requirements.

You can also get detailed info by activating the ATP log in APO, and reviewing the contents after the BOP run. Activate the log in /SAPAPO/ATPLOG. Review the log in /SAPAPO/ATPLOG_DSP.

Best Regards,

DB49

[Former Member]

>

I am a technical consultant & debugging this issue on APO side. I would appreciate if you can help me in 
> GV,
> I will assume that you have looked and found that nothing else in your BOP Sort Profile would move the changed orders to a lower priority.  I will also assume that you have looked and found that nothing related to the SD item category is included in your allocation CVCs (this would be very uncommon). 
-> How to check this one?
> 
> When you change the item category, SD configuration will redetermine the requirements class in R/3.  I don't know which requirements class is invoked for you when  ZXXX item category is entered in an order(since it is custom to your company).  TAN usually determines "041" but your system may differ. 
 -> How to check requirement class invoked in this step.
> 
> A change in requirements class can invoke an entirely different ATP in APO.  The first thing I would look at would be if the requirements classes of the two item categories were different in R/3.  If so, I would then go to APO and look at the configuration for Check Instructions (you will remember that check mode in APO = Requirements class in R/3). You might be invoking an ATP that is either undefined, or does not meet your business requirements.
How do i get this information. 
> 
> You can also get detailed info by activating the ATP log in APO, and reviewing the contents after the BOP run.  Activate the log in /SAPAPO/ATPLOG.  Review the log in  /SAPAPO/ATPLOG_DSP.
> 
> Best Regards,
> DB49

[Former Member]

GV,

You are fighting a battle with one hand tied behind your back if you are facing this alone. It will take forever to debug this if you have inadequate functional expertise to call on. You need to get a functional expert, preferably the one who designed the solution in the first place.

BOP Sorting profile can be reviewed in APO config IMG > APO > GATP > BOP > Define sort profile. If reviewing this configuration does not enlighten you, then you must consult with a GATP functional expert, who can explain how it works and what you should expect.

Allocation Characteristics can be reviewed in APO config IMG > APO > GATP > Product allocation > Maintain product allocation group. Select the Product allocation group that you are using, and look at the characteristics. If any of these are related to order type or item category, then this may be the reason for the de-confirmations. More likely, you will see characteristics that are related to a customer or a product, but not to the order.

Rather that go through the whole spiel about how requirements classes are managed, it is probably easer for me to just have you look at an affected sales order in R/3. Open the order. Review the Item category (lets say it is TAN). Manually do an ATP. You will be taken to an ATP screen in your SCM system. Click on the 'check instructions' button. At the top, you will see the check mode and business event, which are the two keys that SCM will be using to determine the ATP check. Accept the results of the check. Now, manually change the item category to ZXXX. manually perform an ATP again. Open the check instructions window again, see if the check mode and business event is the same. If you have any difficulty executing the above tasks, consult with your local SD or GATP functional expert.

If these two check instructions are the same, you probably want to start thinking about any userexits that may be in either R/3 or SCM.

If I were in your position, I wouldn't debug this until I could get a functional expert to sit next to me. Unless you have a lot of free time.....

Good luck & Best regards,

DB49

[Former Member]

Thanks for your helpful information. I'll take these points and work with my functional counterpart and get update on it.

Thanks again.

[Former Member]

DB49,

We are experiencing this issue only when the item category is changed from ZXXX to TAN for an existing item. However when a new item is inserted with TAN category, BOP is working fine.

GV

[Former Member]

GV,

Ok, change my troubleshooting instructions as follows:

"Rather that go through the whole spiel about how requirements classes are managed, it is probably easer for me to just have you look at an affected sales order in R/3. Open the order. Review the Item category (lets say it is ZXXX). Manually do an ATP. You will be taken to an ATP screen in your SCM system. Click on the 'check instructions' button. At the top, you will see the check mode and business event, which are the two keys that SCM will be using to determine the ATP check. Accept the results of the check. Now, manually change the item category to TAN. manually perform an ATP again. Open the check instructions window again, see if the check mode and business event is the same. If you have any difficulty executing the above tasks, consult with your local SD or GATP functional expert. "

"If these two check instructions are the same, you probably want to start thinking about any userexits that may be in either R/3 or SCM."

The point of this is not to try to troubleshoot everything at once, you already know it is failing. Try instead to isolate the problem to the actual event. Start by doing the change manually, and see what happens. Once it works flawlessly during manual change, then you can start working on BOP, which is an automatic change.

Best Regards,

DB49

[Former Member]

The point of this is not to try to troubleshoot everything at once, you already know it is failing. Try instead to isolate the problem to the actual event. Start by doing the change manually, and see what happens. Once it works flawlessly during manual change, then you can start working on BOP, which is an automatic change.

I didn't quite understood this one. Can you throw some details. Looks like the manual ATP is working correctly... I'll check with my functional guy.