During the Realization phase of a SAP implementation the project team will configure the SAP environment to meet the requirements defined during Blueprint. Configuration can take many forms and many of them from SAP’s perspective are not considered “modifications” though the line is somewhat gray on occasion. The various types of configuration include:
Types of Configuration
Many of the transactional fields in SAP are populated from drop-down lists, maintenance of these lists is a standard activity on any project and is not considered a modification.
Examples of Table Maintenance:
Payment Terms – Most if not all clients attach payment terms to their Sales Orders. SAP comes loaded with a set of default terms, which can be hidden or others can be added, to fit a particular client’s needs.
Material Groups – In the material master SAP provides Material Groups so that clients can group their materials by product line, product family, etc. The values in this table can be changed as needed. The values themselves are used in things like pricing, but changing the values does not change how SAP works.
No standard code or functionality is affected by adding values to these tables.
Z Conditions and Z Document types
These objects are table entries or views of several tables which are merely containers for sets of instructions SAP uses in its’ standard code to perform tasks.
Example of Z Configuration:
SAP comes with a variety of preloaded “standard” configuration, for example out-of-the-box SAP provides a standard Sales Order called OR in the system, This OR has default settings that trigger certain functions within SAP. The settings take the form of fields populated by drop down lists, check boxes, and free form text fields. All of these settings can be changed without any development time. SAP realizes that the Standard Sales Order may not meet a client’s needs. The standard policy is to use the copy function, make a duplicate of the OR and rename it by putting a “Z” in front of it. So the custom order type would be called ZOR. The character Z lets anyone working on the system know that this is a copy of standard configuration and has been changed for the customers needs. Making a copy of the “OR” rather than changing the “OR” provides a baseline model incase the implementation team needs a point of reference. This does not require development time, though the new configuration does have to be tested. This is not considered a modification by SAP.
Formulas, Requirements and Data Transfer Routines
SAP provides “holes” in its’ code where instruction sets can be “included”. Sample sets are included with SAP but they intend for customers to create their own as required to custom, ”configure” the system to meet business needs. SAP does provide standard formulas, which are listed and defined in a separate document in the ASAP Implementation Assistant. However when new formulas, requirements, or data transfer routines are needed a development resource and time must be set aside, because they are written in ABAP or Java code. These types of code are typically not complex and do not require significant time to produce.
Example of a Formula:
In many cases rounding routinely is an issue during implementations depending on the customers pricing model. Standard SAP rounding will round to two decimal places, however if requirements dictate that rounding should be done to the nearest nickel, dime, dollar etc., a formula could be written to satisfy this requirement.
See Formulas, Requirements, and Data Transfer Routines.
Where Formulas, Requirements and Data transfer Routines are usually no more than a few lines of code, User Exits can be quite complex and perform a variety of functions throughout the SAP system. But since they reside in the “holes” in Standard SAP code that SAP provides they are not considered modifications to CORE SAP.
A SAPScript is a printing program. These programs process the outputs from SAP, Order Acknowledgements, Purchase Orders, Invoices, etc. The SAPScripts contain the layouts for the outputs and hence SAP expects every customer to customize the layouts of their documents. This functionality is being phased out by SAP Smart Forms which are object oriented and easier to maintain.
Changes (Bug Fixes) and/or corrections to SAP code which can be initiated and implemented by SAP and/or SAP customers which are properly documented and identified in such a manner as too easily allow migration to future releases with little or no intervention.
Whenever bugs are reported to SAP, the fixes they put out are call OSS notes. By entering transaction OSS1 in SAP and assuming you have a connection to SAP, you will be linked to their OSS System, which gives you access to all of the notes, which are sorted by release and module. If you are on ECC Release 5.0 none of the notes for prior releases should be important to you since a fix created for 4.6c would have been incorporated as standard in 5.0. So when searching the Database you would look for notes for release ECC 5.0 or higher.
OSS Notes document the problem and the resolution. They require that an ABAP developer apply them, since it more often than not requires inserting and changing lines of Code in SAP.
During Upgrades an evaluation must be done of all the OSS notes that have been applied to see which ones are covered by the upgrade. Any notes not covered by the new release need to be reapplied after SAP has been upgraded.
IPC aka Internet Pricing Configurator
For pricing in SAP CRM, all pricing must be loaded into the IPC a java based application. This requires that any custom pricing requirements or formulas, which were created in SAP’s ABAP programming language must be recreated in Java and loaded onto the IPC in order to do comparable pricing.
To accomplish this a java developer is required as well as extensive testing. Pricing is very complicated in standard SAP, let alone replicating that model in another programming language and setting up communication between the two.
MAS aka Mobile Application Studio
The Mobile Application studio allows you to customize the screens in the SAP CRM Mobile client. This is an object oriented programming tool that can be used to change layouts and remove or add fields to screens in SAP. These screen changes do not carry over into CRM Online or SAP R/3.
Effective use of this tool requires a developer familiar with Visual Basic and object oriented programming methodologies.
MODs aka Modifications
Changes to SAP code which are initiated and developed by SAP customers. When Properly documented and identified these can be readily recognized and retrofitted during migration to future releases.
SAP discourages MODs without their involvement and approval. In all cases MODs are not support under service agreements and SAP will not support any problems they cause with the system.
If a customer works with SAP on the MOD then SAP may incorporate it in future releases at which point it becomes part of standard.
The following OSS note should be considered before any modifications are built.
170183: What to consider when applying modifications
*SAP may support MODs if they are involved in the custom development process and support the change.
** SAP will support work in these areas only so far as it does not impact standard SAP/CRM Functionality.