Use of Standard SAP function modules in custom development
I work on SAP Product Support. There are several incidents opened by customers related to the use of Standard SAP function modules (FM) in custom development. Basically they use a standard FM in their custom code and it does not work as they expected, then they open an OSS message asking why it does not work as they wish. My goal with this post is to share some information about FM not released for customer’s use, since there are several customers that are not aware of this restriction.
When considering to use standard SAP FM in custom development, firstly it is advisable to check if it is released (or not) for customer’ use. It is possible to check check it in tab “Attributes” when displaying the function module in transaction SE37, as shown below:
In the sample above, function module RS_VARIANT_DISPLAY is not released for customer use, hence not supported. When a function module is flagged as “Not released“, SAP recommends that customers avoid using this object in their custom code. However, it is not forbidden. You can use this function as it is a global function. However, it will not be supported by SAP if it does not work as you expected. Besides, SAP might change, remove or rename this object at anytime by an upgrade or support package.
So it is kind of useless to open an OSS message in such cases. However, there are some alternatives:
- Look for a standard functionality that can be used instead;
- Develop the desired functionality on your own by a custom development;
- Create a copy of standard function and use it. Then you can adjust it as you need.
Further information can be found on the following notes:
SAP Note 109533 – Use of SAP function modules
SAP KBA 1909989 – Standard SAP function modules do not work as expected in custom development
I think a "not released" does not explain why it does not work as expected. Maybe there is a wrong expectation or a poor documentation.
But beside of that, I wonder why a function module is classified as "not released" but at the same time featured already for many many years in help.sap.com >>>You can use function modules and customer exits (enhancements) to replace many existing batch input processes that are used in WM.<<<
as you can read here: Function Modules and Customer Exits in WMS (SAP Library - Warehouse Management Guide)
By the way, your KBA link is a SAP internal link, people here cannot follow this link, you have to replace the URL
https://css.wdf.sap.corp/sap/support/notes/1909989 by http://service.sap.com/sap/support/notes/1909989
Thanks! I have adjust the KBA link 😉
😆 Seems the links in you original post are marked "Not released".
Good piece of info. Thanks.
Unfotunately I would say this is a weak criterion to make a dicision on using one or another FM. Just to illustrate:
All three are NOT RELEASED...
I have used MATERIAL_UNIT_CONVERSION in many situations and never realized that it is not released.. 😯
Very good information. 🙂
I believe that many of us are fully aware of the implications of using Function Modules that are not released - however I think that it is not acceptable for the standard answer from an OSS message to be that we should we should use something else because the Function Module is not released.
There are 137,050 non custom Function Modules in our APO system - and less than 3% of them are released (3,173 to be precise). Even with BAPIs - only 54% of them are actually released (751 released out of 1382). Our ERP system is even worse at 1.6% (6,921 our of 431,191) and 61% of BAPIs (2658 our of 4354).
I think that the expectation is that when you spend thousands, and in some cases millions, of dollars in to get support for a system - that support is provided for more than 3% of the system.
We use CML and in that module there is 1 released BAPI and 0 released FMs as far as I can remember. It doesn't make any sense for us to re-write absolutely everything when we want to do some custom programming.
We take a more pragmatic approach and treat SAP's FMs as if they were 3rd party libraries. We wrap them in our own classes so they aren't called in a zillion places if/when they change or get deleted. Any bugs or deficiencies we find we create unit tests to document so that if they ever get fixed we will know about it...