Enhance OVZ9 Screen with a new element

[babu_kilari4]

Dear Experts,

I know this has been discussed earlier and I had already searched through the forums to see an answer, but I could not find any and hence I am posting this here.

We have the following business requirement in the ECC ATP functionality.

1) We have different types of deliveries ( say QR delivery and normal delivery )

2) We do the ATP check during delivery creation and when we create the normal deliveries ( customer shipments ), we would like to exclude the already created QR deliveries from the ATP situation so that the customer shipments get the confirmation.

To achieve this, we would like to enhance the OVZ9 screen with a new element say "QR delivery" and we would like to keep it unchecked so that when a normal delivery gets created these QR delivery elements are unselected in the Scope of check and the confirmation is given to customer delivery ( normal delivery ).

Is this possible ? If yes - I would highly appreciate your guidance on this.

Thanks & Best Regards,

Babu Kilari

SCM APO Consultant

[former_member223981 · Accepted solution]

I do not think this is possible without some heavy modifications.

Firstly, you have to adjust the OVZ9 screen to include your new flag.

Secondly, you need to adjust the runtime code. For example, the "include deliveries flag" is considered at the following code:

******************************************

* check T441V for VBBE

*-----------------------------------------------------------------------

DEFINE VBBE_T441V_CHECK.

* check T441V

  IF  G_T441V-VBBDP <> XFLAG            " sales requirements

  AND G_T441V-VBBLP <> XFLAG.           " delivery notes

    EXIT.

  ENDIF.

END-OF-DEFINITION.

******************************************

You would need to change this code to take account of your newly created flag in OVZ9.

Then, the system selects the deliveries from table VBBE. At the moment, the standard code does not distinguish between deliveries from STOs and deliveries from sales orders. So you would also need to alter the standard SELECT statements to distinguish between these deliveries (you could use the Sales doc type field to do this).

Therefore, this is not as simple as adding a new flag to OVZ9. This is a huge development effort and you are altering the standard ATP code which is strongly not advised by SAP.

Personally, I would review the business reason for not wanting to include the STO deliveries; what advantage do you gain by not including them? You will just get many overconfirmations when you do not include them.

[babu_kilari4 · Accepted solution]

Hello Noel,

First of all, thank you very much for the reply.

The reason for excluding the STO deliveries is due to the fact these deliveries are always 100% confirmed and we do not want them to hamper the confirmations of normal delivery. System is assuming that "x" amount of quantity has already been given to this STO delivery and hence it is not able to give it to the normal deliveries. In the meanwhile I did some analysis and found that enhancing OVZ9 is not a good option as it was leading to more complexities.

Now, I have different thoughts to implement this. May be you can provide your feedback on this.

What I am actually thinking is to make use of the field PROJN  ( Old: Project number : No longer used --> PS_POSNR ) in the DB table. I see that this field is not being used in our current landscape. I see no entries in the production having this field value filled. So, it is an advantage for me. Also, SAP documentation says it is not being used anymore. So, the idea is while creating this special STO deliveries, we manipulate the XVBBE and put a flag here say "X". and then in the standard SAP enhancement point in the include LATP2FV0, we exclude the VBBE entries that has this flag which meets our requirement.

Only watchout is to see if SAP removes this flag from this table in the next versions of the software which I think is unlike considering this as an important table. What is your opinion on this approach ?
Do you have any other documentation on this field ?

Thanks & Best Regards,

Babu Kilari

[former_member223981 · Accepted solution]

1) I would not take this approach; it is better to create a new Z field than to use an existing field (even if it is unused). If you use an existing field, then you are essentially creating inconsistent data on your system. The field was not designed for this use and therefore should not be used for it. Who knows what could happen in a future SAP release regarding this field....

2) "and then in the standard SAP enhancement point in the include LATP2FV0, we exclude the VBBE entries that has this flag which meets our requirement."

Can you elaborate on how you are going to achieve this? The problem is that this code will be called for other areas in your system; PP, SD etc. where availability checks will be executed. Do you really want these type of STO deliveries to be omitted from every type of ATP check?

[babu_kilari4 · Accepted solution]

Hello Noel,

For point 2 -> The intention is to exclude the entry from Scope of check that has the flag "X" in this field. And, since this flag "X" will be set only for special STO deliveries which is 1% of total deliveries, we intend to do this change in STO delivery creation instead of building a new set of logic in this enhancement to avoid performance issues as this will be hit for every ECC ATP process.

Thanks & Best Regards,

Babu Kilari

[former_member223981 · Accepted solution]

Ok, you set a flag (whether PROJN or a Z flag) to X in the STO delivery.

But you still need to tell the system to not select deliveries with this flag. The select on VBBE is done on view ATP_VBBE in include LATP2FV0. But the standard selects do not consider field PROJN (or a created Z field). You will need a select that states do not select these type of deliveries. So I do not see how you get around having to modify the standard selects? Maybe I am misunderstanding what you are trying to do.....

[babu_kilari4 · Accepted solution]

Hello Noel,

Thanks again for coming back with the questions. I appreciate that.

The intention is to replace the view ATP_VBBE with the DB table VBBE so that I have the flexibility to play with the other fields of VBBE in the enhancment point \PR:SAPLATP2\EX:SAPLATP2_03 provided by SAP. I hope I can do this.

Thanks & Best Regards,

Babu Kilari

[Lakshmipathi · Accepted solution]

Have you tried with the option of Switching Off availability check for your STO delivery item category in 0vlp?

G. Lakshmipathi

[babu_kilari4 · Accepted solution]

Hi Lakshipathi,

We tried and I don't see any benefit with that as per our business requirement.

Babu Kilari

[former_member223981 · Accepted solution]

I would be concerned that you are modifying standard code that is in widespread use across the system. If you proceed down this route, you should ensure that your code is tested thoroughly. Ensure that all your PP / SD processes (any process that executes an ATP check) are tested thoroughly. For example, if the material is used in a component in a production order or planned order, should the STO delivery be considered in that case? Testing just the delivery creation wil not be sufficient.

In theory, your proposal should work but it requires significant development effort and modification. But unfortunately, I cannot think of a better alternative solution.

[babu_kilari4 · Accepted solution]

Hello Noel,

Thank you for your valuable comments throughout the thread. I understand this needs to be tested thoroughly and we also intend to put this flag in the STO deliveries only for very few of them that undergo a specific process as per our business rules. So, the VBBE entries with this flag will be minimal. What I could understand in this include that I mentioned above is why SAP is reading the data from the view ATP_VBBE which in turn is made on the actual DB table VBBE with reduced no. of fields. What are they achieving by doing this ? By replace the select with VBBE am I doing something incorrect from performance point of view ? Would you mind providing some comments on this ?

Looking forward to see your thoughts

Babu Kilari

[Lakshmipathi · Accepted solution]

Can you reconfirm that already you set "X" against "Avail.CkOff" for your delivery item category and created STO delivery but still system is considering ATP?  Ideally it should not be.  Nevertheless, if this option is not working for you, then the best approach what I would recommend is to go for user exit related to ATP rather modifying OVZ9 which is not advicable

G. Lakshmipathi

[Former Member · Accepted solution]

HI,

please take a look on  enchncment ATP00001.

Regards

[former_member223981 · Accepted solution]

To be honest, I do not know why SAP uses these ATP_* views rather than the database table. I doubt it provides any significant value regarding performance. Then again, I am not a performance person so you would be checking with somebody who has performance knowledge.

we also intend to put this flag in the STO deliveries only for very few of them that undergo a specific process as per our business rules. So, the VBBE entries with this flag will be minimal

I know I said it earlier but I think it is worth re-iterating. The modification you are proposing is so big that you should check if it is really necessary, especially if you are talking about so few deliveries on the system. There could be a danger that you are under-estimating just how much the availability check (i.e. the code you are changing) is used throughout the system.

Another approach you could take is to use the EXIT_SAPLATPC_002 exit. This allows you to manipulate the ATP result. In here, you could just select the entries from VBBE that have the flag set (i.e. the flag that identifies them as STO deliveries). and then add this amount to the confirmed available quantity. So lets take this example:

Stock = 100

Issues = 100 [50 are sales order delivery, 50 are STO delivery].

Your scope of check includes deliveries. So at the moment, there is 0 available. You want that there is still 50 available. T_MDVEX-MNG02 will contain the confirmed available amount (so 0). You could implement a select on VBBE in your exit that searchs for deliveries belonging to STO (based on whatever flag you decide to use). Then your code will total the values of these requirements. In this example, there is just one requirement so total would be 50. Then add the total to T_MDVEX-MNG02. This means you have 50 available in the above example, and not 0.

So in summary, use the exit to:

- Select the STO deliveries from VBBE (using the modified select you were going to use in LATP2FV0)

- Total the quantities from the STO deliveries

- Add the total quantity to the confirmed available quantity (T_MDVEX-MNG02)

I think this approach is better as you can control in the exit when the STO deliveries are to be considered and you are not modifying code in include LATP2FV0 (I would be very wary of modifying that code). For example, you can put in conditions like "IF CHECKING RULE = "B" then do this", or "IF Transaction = then do this".

[babu_kilari4 · Accepted solution]

Hello Noel,

I understood what you wrote above and it really makes sense not to modify the standard SAP code. I will go with what you said. Thanks for the suggestion. But, if SAP can really provide an enhancement that can easily add and remove the ATP elements that works for many customers although I understand that customers should think of going to new technologies like gATP sometimes it doesn't work due to age old processes that made people be comfortable with.

Thanks again. I close this thread.

Cheers,
Babu Kilari

[phanikumar_v3]

Dear Babu Kilari

Very Good Informative thread.

We need to thank specially  Mr Noel Connolly who adopted this issue as his own and

given such important precautions.

Thanks to Both of you.

But As suggested by Mr Lakshmipathi,

How are you planning this requirement to get it done(skipping of STO deliveries from Regular Avbl.check at Delivery level)

Requesting you not to forget, on updating us.

Phanikumar

[former_member220617]

Dear Babu ,

Try the below setting to your issue.

Regards,

C.B Reddy

[Former Member]

Hi,

it is not clear to me what you want to do. You mean that you want sales documents ( orders or deliveries )  to have priority regarding ATP against STOs?

If so then maybe you could run you backorder proccesing with the relevant setting.

Regards.

[Lakshmipathi]

we would like to exclude the already created QR deliveries from the ATP situation so that the customer shipments get the confirmation

Do you mean to say, currently, system is considering even already created and saved deliveries but not PGId?  Ideally, this should not happen.

G. Lakshmipathi

[babu_kilari4]

Hello Lakshmipathi,

Thank you for your reply.

From standard SAP point of view, it is working fine as expected. Because, system just knows that there is a delivery since our scope of check says "Include delivery notes", it considers the same during the ATP check and remaining ATP is given to the current delivery document that is being ATP checked.

What we would like to do is as shown below

Stock = 200 Pcs

Delivery created against an STO document = 100 PCs.

Delivery created against Sales order 1        = 75 PCs

So, now the stock of 200 Pcs is already eaten up by the above STO delivery and delivery for Sales order 1.

Now, when I create a new  delivery for Sales order 2 say for 100 Pcs, system behaves in such a way that the new delivery gets only 25 Pieces because ( STO delivery and SO1 delivery together consumed 175 Pieces ). What we need is system should ignore STO deliveries during the ATP check of Sales order deliveries.

Hope the questions is clear now.

Thanks & Best Regards,

Babu Kilari

[Lakshmipathi]

Go to IMG > Materials Management > Purchasing > Purchase Order > Set up Stock Transport Order > Assign Delivery Type and Checking Rule.

There if you have assigned your delivery type for STO, remove that and try.  Also don't maintain the Checking Rule there.  I am not sure whether this will work as long time back, I worked for a similar requirement and I dont remember that settings now.

G. Lakshmipathi