in MD04, how to remove element if it's origin and destination has the same MRP area?

[daniel_barnea]

Hello all!

When creating STO, MD04 show 2 element for this STO: goods issue for the date of the STO, and goods receipt for the delivery date at the different receiving storage location. 

now, i have a requirement to hide this STO from MD04 if both the storage locations has the same MRP area.

as far as i can see, i can configure new selection to exclude all STO's - but i need to exclude only STO (or all elements) with the same origin and destination MRP area.

any idea how to solve it without enchantment? 

[DominikTylczyn · Accepted solution]

Hello @daniel_barnea 

MRP data can be manipulated with the MD_CHANGE_MRP_DATA BAdI. However don't use it unless you fixed the root cause of the problem as @Caetano indicated. 

STOs with the same source and destination MRP area don't make any sense. They are a result of an incorrect source determination during MRP run. Fix that first! 

Hiding elements from MD04 is sweeping under the rug. They will still be there, but no one will manage them.

Best regards

Dominik Tylczynski

[daniel_barnea · Accepted solution]

thank you, however:

1. it's different storage location, i edited the question to clarify it.

2. STO is created manually. of course, i don't want to hide them always - i will use selection filter only (i hope that the selection filter is available in the BADI) - and i guess that it's more then reasonable for a planner to see only the objects that effect his total stock, without see the internal process that does not effect his total stock within the MRP area/plant (for exmple, planner for the whole plant does not need to take into considaration cases where the logistic manager move stock between diffrent storage locations - but we need need STO for internal transfer to monitor the transfer process).

[DominikTylczyn · Accepted solution]

You can remove the STOs with the MD_CHANGE_MRP_DATA BAdI. Selection filter is provided in the interface.

[Caetano]

Hello

If I understood correctly, you have two different storage locations that belong to the same storage location MRP Area, and your users are manually creating STOs to move stock between those storage locations. 

If my understanding is correct, than it makes sense to hide those STOs. 

Nevertheless, I would suggest you to use BAdI MD_ADD_ELEMENTS instead of MD_CHANGE_MRP_DATA, because MD_CHANGE_MRP_DATA is no longer called in MD04 in SAP S/4HANA. 

Regards,
Caetano 

[DominikTylczyn]

Hello @Caetano 

Are you sure MD_CHANGE_MRP_DATA is not called in MD04 in S/4? I have not found that in the BAdI documentation. Also the note 2268085 - S4TWL - MRP Live on SAP HANA - MD01N indicates that MD_CHANGE_MRP_DATA is not used in MRP Live and that it is not used in planning transactions. MD04 is not a planning transaction. Would you be able to shed some light on that?

Best regards

Dominik Tylczynski

[Caetano]

Hello Dominik,

You are right, SAP Note 2268085 does not clearly mention that BAdI MD_CHANGE_MRP_DATA will no longer be supported in MD04. 

However, if you set a break-point in function module AUFBAUEN_MDPSX_ANZEIGEN in an S/4HANA system, you will observe that the logic to read the planning elements from the database has been redesigned, and instead of sequentially reading the planning elements in an ABAP code, system now triggers an AMDP stored procedure to bulk read the planning elements in HANA. It basically means that the piece of code where MD_CHANGE_MRP_DATA was called is no longer being executed. 

The easiest alternative is to call the ABAP MD_ADD_ELEMENTS, which is called just after the stored procedure is executed, and this will work if the issue only happens in MD04. 
The BEST alternative is to use the AMDP BAdI that I mentioned in this blog, which is called in MD04, the MRP Fiori Apps, MRP Live and Classic MRP. Note that this BAdI is only available for the latest S/4HANA releases. 

I'll contact the author of note 2268085 and ask him to update the information, adding MD04. 
Regards,
Caetano 

[DominikTylczyn]

Thank @Caetano for detailed explanation. I've checked it and it's spot on.

It's a shame though that the MD_CHANGE_MRP_DATA documentation doesn't say any of it. It should have been updated in S/4HANA.

[Caetano]

Hello

An STO with the same issuing and receiving storage location does not make any sense. What is the business reason behind this STO?

MRP does not determine the issuing storage location of STOs automatically, so if those STOs are being converted from STRs created by MRP, you might have an active implementation of BAdI MD_EXT_SUP, that should be reviewed. 

Regards,
Caetano 

[daniel_barnea]

thank you, of course - it's diffrent storage locations within the same MRP area. i also clarify it now in the question.