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: 

Can I change standard SAP V1 FM?

former_member202077
Participant
0 Kudos

Hello Experts,

Requirement: Determine PO item's (EBELP) associated Reservation item # (RSPOS)

Pl. let us know is it allowed to implement an Implicit Enhancement in an UPDATE function module (MB_CHANGE_RESERVATION), is it safe to do so? or its not suggestible to create an Implicit enhancement in an UPDATE kind of FM?

Thank you

13 REPLIES 13

matt
Active Contributor
0 Kudos

So long as you understand how update FMs work, it's not more dangerous than enhancing any standard SAP object.

raymond_giuseppi
Active Contributor
0 Kudos

"is it safe to do so?" depends on what you intend to do in the enhancement, usually such update FM should only update some database table, so you could update a customer table, but don't call a BAPI for example.

In your example (trigger something when reservations are changed?) I would have implemented the four BTE (type 'Z') related to reservation and APO : 01000501 to 506. (Alas BAdI MB_RESERVATION_UPCHD is restricted to SAP...)

0 Kudos

Thank you, I have implemented the said BTE and my purpose is solved, so no need of impl. ENH, appreciated your help

In the implemented BTE's Z FM, I'm buffering the newly created reservation item # by using custom class's SET/GET methods and I'm using to update my custom table

SET - BTE's Z FM

GET - My custom report, wherein ''m calling the BAPI reservation change wherein I'm updating a Z table with GET method returned item #

DominikTylczyn
Active Contributor

I'd advice against implementing implicit enhancements and using direct repairs / changes to standard SAP code. In my opinion the latter are easier to maintain in case of an upgrade or patching. Consider implicit enhancement implementation of function MB_CHANGE_RESERVATION. Then assume that SAP introduces in a note or a patch a change to the function that is incompatible with your enhancement. The note or a patch is going to be implemented and you'll never see a conflict in SPAU transaction. Therefore you'll have no chance to check enhancement implementation against new version of the function.

Whereas if you do a repair with modification assistant SPAU will show a conflict and will prompt for resolution. Here you can check if your change is still needed and if it is compatible with the correction introduced by SAP.

I am aware that the above goes against common rule of not changing standard SAP code. However I hope my reseaoning is clear.

matt
Active Contributor
0 Kudos

Wouldn't transaction SPAU_ENH catch such situations?

It would if SAP delivered enhancement implementation conflicted with your implementation that you did built beforehand. Otherwise there is no conflict of ABAP object version and SPAU_ENH would catch that.

The scenario I'm referring is when you have an enhancement implementation and then SAP delivers a fix or change to an object e.g. a function that was enhanced by implicit enhancement. Then there is no conflict, technically at least. However SAP change might render enhancement implementation obsolete (SAP delivered functionality in standard that previously required enhancement) or the logic of SAP code could make the logic enhancement inconsistent.

The message I'm trying to convey here is that when you use old fashioned repairs each time SAP delivers new version of the changed code, SPAU transaction makes you rethink your change logic and business rationale.

In my mind implicit enhancement are very dangerous. They are a way of changing standard SAP code in a hidden way. Thus they should be avoided if not down right forbidden.

Hope my point is clear.

Thank you Dominic.

Not in this case, but our recent SPU caused some issues in QA system on our enhancements in Web DynPro area hence we reapplied by copying from production

You could've used SPAU_ENH transaction to resolved conflicts in enhancements implementation. Coping implementations from production might work but it's not the right way to go.

matt
Active Contributor
0 Kudos

All clear. I prefer modifications anyway.

What do you mean by "modifications" here:

  1. repair/change to SAP code
  2. enhancement implementation?

matt
Active Contributor
  1. repair/change to SAP code

Which is always preferable to cloning...

0 Kudos

Couldn't agree more.

Sure, thank you, this time we already done with our SPU, next on wards I will consider your suggestion