Skip to Content
Author's profile photo Former Member

How I learned to stop worrying and love to change the SAP standard

We are tought to never ever change the SAP standard. Ever.

Arguments like voiding SAP support, compromising data integrity or the risk of upgrade issues are meant to scare us and steer us away from the standard delivered source code. These arguments are very much valid and changing the standard is not to be taken lightly. SAP is one of most complex software systems ever created and changing a single line can have a huge impact.

But this does not mean that we should reject the idea outright. It is always a trade-off: if the benefits are high enough from a business point of view, and all alternatives have been depleted, we should be able to set aside our objections to changing the standard.

(And, let’s face it, if SAP didn’t want us to change the source code, they should not have shipped it at design time.)

Because changing the standard is such a taboo, I have never been offered a protocol, or code of conduct if you will to perform the task safely and in such a way that it is transferrable to the support partner. This blog is not to encourage you to go out and change the standard at will, it is to provide such a protocol.

Not surprisingly, documentation is the key. But what should you document? And where? Also, it is not the only topic to keep in mind. Here’s what I’ve come up with.

  • Changing the standard should only be done as a last resort. Always check the alternatives first. Make sure you record which exits and enhancements you have investigated and why they don’t work. You should have considered these four options:
    1. If you are suspecting the standard is not working properly, check the OSS Notes repository or report it to SAP.
    2. Implement a user-exit, badi or explicit enhancement. These technologies give you a clear interface of internal data objects to be used or changed. Unfortunately you are bound to the positioning in the standard logic, and your requirement may be in regard to an area where no such hook-ups exist.
    3. Implement an implicit enhancement linked to the switch framework. A very powerful tool since there are hook-ups at the beginning and end of practically every standard routine, function or method. Unfortunately you are not free from worries during an upgrade, as we will see later.
    4. Build your own logic from scratch and in the customer namespace. Most favorable by ABAP consultants who like to get their hands dirty (and who doesn’t!) but a horror to project managers who see their budgets evaporate. Again, this is a trade-off: if you have to built a custom transaction with thousands of lines to avoid changing a single line of standard logic, I know what the project’s steering comittee will rule.
  • Be very carefull in what you change and how you change it. Make sure the standard process is resumed properly beyond your point of modification. This means taking extra care in issuing messages, screen handling and interferances with the logical unit of work.
  • Use the SAP Modification Assistent to modify source code. This greatly enhances the ease of use of the version management.
  • Document every modification individually. Make sure you record what you have changed to the standard, how you have changed it and most importantly why you have changed it. This last piece of information is vital during working with a SPAU report after an upgrade.
  • Next to that, document your changes centrally so the support partner has an overview of all custom modifications made to the standard. Ofcourse the system registers every modification made but it doesn’t register why a certain object was modified. This central document will serve as the missing link between the SPAU report and the technical documentation for every individual modification. It can be easily pulled when upgrading a system to identify possible points of attention. Information to be documented in a central location should be:
    1. Object name
      Exact and full technical name of the standard SAP obejct to be modified, as stored in table TADIR, containing Program ID, Object type and Object name.
    2. OSS registration key
      Full 20 digit key with which the modification was registered in OSS (provided during first modification)
    3. Installation number
      Netweaver installation number under which the object modification was registered (provided during first modification)
    4. Date
      The date of the modification. This is to distinguish the modifications made before and after a certain upgrade.
    5. Call number
      The registration number under which the modification was registered. The benefit of this is that the project or support systems often contain lots of additional information as to the why a modification was made.
    6. Transport request
      For tracking and tracing.
    7. Documentation
      Link to the individual technical specification
  • There is no need to document OSS Note implementations that are incorporated in support packages. The system should be updated regularly with the latest support packages, so these type of modifications can be considered temporary and will be overwritten with the new SAP standard as soon as possible. Beware that not all OSS Notes are incorporated in support packages – some are considered nice-to-have. These should be documented in the above manner. You can find if and in which package a note is incorporated in the OSS Note under the paragraph “Correction delivered in Support Package”.
  • Use standard tooling to maintain your modifications:
    • SPAU
      Working with the SPAU-list is a largely underrated and sometimes even an ignored task during an upgrade. In my experiende even if it is part of the upgrade plan, the SPAU list is dealt with in an incorrect manner. Most of the times the task is assigned to an ABAP developer who simply resets every red traffic light he/she encounters. In reality going through the SPAU list should be a joint effort of both technical and functional team. The involvement of the functional team is crucial for understanding the reasons of the modification and the business requirement. With this information you can separate the custom made modifications from the OSS Note implementations. On how to use of the SPAU transaction a lot has been said and I will not get into detail here. Suffice it to say that failing to run the SPAU report after an upgrade will make you loose your modifications, causing unhappy faces on the workfloor. This may be fine if the only modifications you made were OSS Note implementations. In that case, running the report is part of good housekeeping.
    • SPDD
      The same but for modifications made to the ABAP Data Dictionary.
    • SPAU_ENH
      The same but for implicit enhancements. Although your enhanced logic will be stored in an object in the customer namespace and will not be overwritten during an upgrade, the reference to your enhancement may have been changed by the standard. How to Get the Most From the Enhancement and Switch Framework as a Customer or Partner – Tips from the Experts describes very beautifully the impact an upgrade has on your enhancements.

Assigned Tags

      You must be Logged on to comment or reply to a post.
      Author's profile photo Kenneth Moore
      Kenneth Moore
      The blog you reference as a good example for SPAU_ENH is invalid.
      Author's profile photo Clinton Jones
      Clinton Jones
      Author's profile photo Former Member
      Former Member
      Blog Post Author
      My bad. Repaired the link.
      Author's profile photo Nathan Genez
      Nathan Genez
      Generally I agree with this. Modifications have their place in developing SAP solutions.  They come with risks but that doesn't mean that they should never be considered either.

      One thing I think you left out is that the customer needs to take a good long look in the mirror and assess their capability to support and administer the modification over the life of the system.  For some companies, it's in their DNA to make changes and have a strong IT emphasis or involvement in their functional processes.  Other customers may not have the in-house talent, department stability, or risk tolerance to deal with this.  I think this is an even bigger factor than the modification itself.

      Author's profile photo Former Member
      Former Member
      Blog Post Author
      You are absolutely right. I wrote the blog from an ABAP developer's point of view, assuming that risk assessment has already taken place. It is ofcourse also the ABAP developer's responsibility to explain the consequences for support to the customer. With these arguments on the table the customer should be able to assess how really important he thinks his requirements are.
      Author's profile photo Chris Paine
      Chris Paine

      I think some reference to the enhancement framework, and also the switch framework would be very useful here. These mean that you can change SAP standard code - in a supportable way!

      However, your thoughts here are interesting.

      Thanks for posting them.

      Author's profile photo Sandra Rossi
      Sandra Rossi
      Thanks Olaf, this is a very clear and informative, and a must-read blog.

      > Implement an implicit enhancement linked to the switch framework.
      Developers, please, don't abuse. I've seen this many many times: when one line needs to be changed inside the procedure, some developers implement the implicit enhancement at the beginning, copy the whole procedure and change it, and terminates it with EXIT to leave the procedure without executing the standard code. Very bad because difficult to see what was changed. Instead, modify the standard.

      > Use the SAP Modification Assistent to modify source code. This greatly enhances the ease of use of the version management
      Just a precision: the assistant is activated by default, developers can switch it off by a menu item. I agree to not switching off because:
      1) it forces the developer to minimize the changes, and think much about the better places to position the custom code. With assistant off, I saw developers changing many things that were not required, making version comparison tool almost unusable.
      2) switching off is not reversible (or very difficult: you'd need to restore the version before the switch off; then you need to reapply the code of following versions again using the assistant...)

      > taking extra care in issuing messages, screen handling and interferances with the logical unit of work
      Yes, that's a very important point. I've seen many developers doing dirty and dangerous changes, because they did not have enough experience about these topics (for example, doing an update synchronously or using BDC synchronous while the standard program used update task to perform the updates!)

      My advise: if you, developer, don't exactly understand the concept of LUW (what is the difference between COMMIT WORK and database COMMIT, what creates a LUW), what triggers implicit database commits (messages, screens, RFC, etc.), what is an update task (set local update task, function modules), then don't change anything in the code called after the SAVE button is pressed.

      I'd like to add two important things IMHO:

      1) A rule that cannot be broken: do modifications of the standard only if you can switching them off at any time: never update tables that could make the standard fail (I have already seen standard fields updated that break standard database integrity)

      2) If you have SAP NW 7.0 or above, do your modifications of the standard by only using ENHANCEMENT-POINT statement, and you implement it inside a Z enhancement implementation that you assign to a Z package (note: you can also group several implementations into a group ("composite") so that to organize related implementations). You can then link these Z packages to the Switch Framework, so that you can switch off all of them in a instant in case you want to make sure some bugs come from the standard and not from your custom code. Be careful, switching off only part of them could lead to inconsistencies if you didn't think to it thoroughly. For more information, read Note 1257033 - Cookbook: Modification/enhancement for standard SAP system.


      Author's profile photo Suresh Datti
      Suresh Datti
      The implicit enhancement feature in ERP6 is a double edged sword and should be handled with care. I have seen many instances where this option is used just because it is readily available. Whereas it should be the last option after exploring/exhausting all the other avenues like user exit/BAdI etc. Either way, it is highly  recommended to make use of the switch framework with the enhancements lest they should go out of control.