Create an own (Z*) Function-Module within an SAP-Owned Function-Group

[master1980]

Hello,

I want to create an own (Z*) Function-Module within an SAP-Owned Function-Group, Pros/Cons are not part of the Discussion.
The Function Group is M61Q.
I Created ZMD_BEARBEITEN_KOMPONENTEN as Copy of MD_BEARBEITEN_KOMPONENTEN
Within the INCLUDE LM61QUXX SAP add's automatically LM61QU20 as the ZMD_BEARBEITEN_KOMPONENTEN is the 20st Function-Module within the Function-Group.

Questions:
I was not asked for the access-key, so i think this is not a Modifikation? In the coding of ZMD_BEARBEITEN_KOMPONENTEN there's an "{ INSERT ...." Tag.
What is about changes by SAP within M61Q in the Future? Will ZMD_BEARBEITEN_KOMPONENTEN still be there after an Update? If SAP adds a new include LM61QU20 into the Group, will ZMD_BEARBEITEN_KOMPONENTEN then be in LM61QU21?

Many thanks

[Sandra_Rossi]

NEVER copy a standard function module, do a modification of the standard because you'll be informed by the upgrade process (SPAU). It has been discussed a lot in the forum in the past years, and the old way (copying standard) is now considered completely wrong.

NB: S/4HANA doesn't request access keys anymore, but anyway modifying anything standard is a modification of standard.

[master1980]

Thank you very much, I have also an R/3 System here and testwise I tryed to copy the FM there, I was asked for an Access-Key. I will set up a meeting with the customer and will gofor the modifikation withing the SAP-FM.

Actually I have been set on the wrong track when I copied the FM in S/4 and not beeing asked for the access key by falsely thinking copying is not not a modification.

According to the Mandalorian: This is the way!

[RaymondGiuseppi]

If SAP were to introduce a new function module to this function group in a future release, and it were to use the include LM61QU20, this could create compatibility issues during subsequent system updates. Such modifications to standard SAP components are generally discouraged as they may:

1. Be overwritten during standard SAP upgrades
2. Cause technical conflicts with future SAP enhancements
3. Require extensive regression testing after each SAP update

As a best practice, I recommend:

1. Creating a Z-namespace function group for custom developments
2. Using enhancement points or BAdIs where possible
3. Documenting any necessary modifications to standard components