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:
If you are suspecting the standard is not working properly, check the OSS Notes repository or report it to SAP.
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.
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.
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:
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.
OSS registration key
Full 20 digit key with which the modification was registered in OSS (provided during first modification)
Installation number
Netweaver installation number under which the object modification was registered (provided during first modification)
Date
The date of the modification. This is to distinguish the modifications made before and after a certain upgrade.
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.
Transport request
For tracking and tracing.
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.
