Application Development Discussions
Join the discussions or start your own on all things application development, including tools and APIs, programming models, and keeping your skills sharp.
cancel
Showing results for 
Search instead for 
Did you mean: 

Example implementation of BAdI ME_PROCESS_REQ_CUST as per note 2618264?

Mithun_Kumar
Active Participant
0 Kudos
2,482

Hi All,

We need to implement the BAdI ME_PROCESS_REQ_CUST as recommended in the SAP note 2618264.

Does anyone have an example code to implement the logic that the note says?

How can we change the message type of a standard message already raised, in the BAdI that's called after the said message is triggered?

Alternatively, how do we detect if this specific message is already in the log? If we can do that, then can remove the same, and raise again using mmpur_message_forced macro with a different message type.

PS. This is a S/4HANA 2020 FPS01 system.

13 REPLIES 13

Mithun_Kumar
Active Participant
0 Kudos
1,660

Also not sure if this logic goes into the PROCESS_ITEM method or into PROCESS_ACCOUNT method?

FredericGirod
Active Contributor
1,660

Go in SE18, display the BADI, go in the Interface TAB and there is a class example

0 Kudos
1,660

Hi Frederic,

It'd be highly appreciated if you read and understand the question before answering. Also, you might want to take a look at the almost empty and useless example class CL_EXM_IM_ME_PROCESS_REQ_CUST, that doesn't serve practically any purpose to help anyone.

0 Kudos
1,660

This is a great answer to someone that take free time to try to help people.

I did not read the oss note for you, and maybe if you take time to explain what is inside this note it could help.

Personaly this example was enough for me to understand & use this BADI.

I hope, as you have a so high requirment level, that you will apply it to your work and research.

Good luck in the ABAP Jungle.

0 Kudos
1,660

Indeed Frederic. Just FYI, I'm already 18yrs in the ABAP Jungle. And have done almost 2 days of research before asking a question here. 😉

All the basics are covered. Even this particular BAdI, I've implemented many times. But never got this type of a requirement, unfortunately.

pataselano
Active Contributor
1,660

You can check the 2666809 - How to identify PO/PR with items created from catalog for identify whether items created from catalog or not.

Base on that criteria, you can create your own logic via BADI ME_PROCESS_REQ_CUST method PROCESS_ITEM when message 06334 should be error or not because you already configured message 06334 as warning in transaction OLME > Environment Data > Define Attributes of System Messages.

Example, if items was not created from catalog then message 06334 should be error.

0 Kudos
1,660

Thanks for the Note, Andy!

As I debugged the process I see that the message 06334 is actually triggered before this BAdI is called, and as per the OLME customizing, it's already in the list. So I'm not sure how can we now 'decide' in the BAdI to make it error or warning, based on any criteria.

As a check, I created an implementation and simply added the message 06334 as 'W' in the PROCESS_ITEM method (without any other logic), using mmpur_message_forced. Then upon running, I see both the messages ('E' and 'W') in the message list.

So it means the decision about the message is already made before the BAdI is called. 😞

0 Kudos
1,660

BTW, just to add to your answer, Andy.

The note you provided is helpful for ECC system, however, in S/4 HANA SAP has already added helpful fields in EBAN to determine if the item is added from a catalog:

So I believe that part is covered. I'm basically stuck on how to make the message from error to warning conditionally.

0 Kudos
1,660

You already configured message 06334 as warning in transaction OLME > Environment Data > Define Attributes of System Messages as per SAP note 2618264.

So, in BAdI ME_PROCESS_REQ_CUST method PROCESS_ITEM, your code will make error for message 06334 in specific condition, eg: if PR is not from catalog.

raymond_giuseppi
Active Contributor
1,660

Don't change the already raised message, that's not easy (or search for mmpur_remove_messages_by_id or threads/questions on 'Handling Errors in Purchase Requisition' but most are removing customer message not standard one) and it's much harder on PR than on PO)

I would rather suggest to use the Customizing option to always ignore the error in the standard and then build your own logic in a BAdI implementation, raise the error with your own business rules.

NB: Look at the data you can get (IM_ITEM->GET_DATA) in PROCESS_ITEM. is the PIR field is available, so you have your second answer.

0 Kudos
1,660

Yes, unfortunately the (easy) customizing option is already ruled out by the note itself (I've updated the question with a screenshot from the note).

For this specific scenario the 'easy' options are out of the window already. mmpur_remove_messages_by_id would remove all the messages, which we don't want to do. mmpur_remove_msg_by_context is a better option to remove individual messages.

Yes, I'm aware that these macros are used only for custom messages, and I've used it for the purpose too. But in this case, that seems to be the only option. I've debugged and found the context number for the standard message. However, cannot figure out the 'ID'.

Moreover, before this, Somehow I'll also need to figure out if the message is even raised by Std in the first place.

0 Kudos
1,660

Try to disable the message in Customizing though, the note can be interpreted in different ways. Perform a test: Does the error message disappear: always, when created from catalog only, when not created from catalog?

0 Kudos
1,597

I know it's "a bit" late, but for yourself and any new readers who come across this like I did when searching for solutions to one of my own problems:
You can use CL_MESSAGE_HANDLER_MM method HAS_SIGNATURE to check if the message has been issued already. See how SAP does it in their own code in include MM06EF0L_LESEN_BELEG form LESEN_BELEG.


Kjetil Kilhavn (Vettug AS) - ABAP developer since Feb 2000, but will probably never be a Rockstar developer