SAP Basis Consulting
Shift scheduling
There are several ways to introduce and operate new applications. As a company you have the choice between internal realisation and operation, outsourcing, cloud computing and so-called outtasking. In deciding on one of the above concepts, the SAP basis must be included for the evaluation of various technological and operational aspects, which offers the possibility to develop a sound decision. This decision has a significant impact on the future operation of SAP and the associated operating and maintenance costs. The recommendations listed here are intended to help you decide on other forms of service. Information on the recommendation can be found in the Master's thesis in chapters 7.8 and 9.6.
First you have to create an area menu in the area menu maintenance with the transaction code SE43 or SE43N. Then add the created menu to the SAP standard menu S000.
If you want to get more information about SAP basis, visit the website www.sap-corner.de.
SE38 ABAP Editor
In the area of SAP Basic Administration there are many tasks that occur at long but irregular intervals, such as adjusting the system modifiability. As a result, the know-how is often lacking and it is quickly taken to the next search engine, where long and partially incomplete forum entries make finding the right approach even more difficult. For this reason, I will regularly record recurring tasks from the SAP basis Administration for you in simple tutorials. This blog post will start with the topic system modifiability and client control. If you want to jump directly to a step-by-step guide, just scroll down to the bottom, where I summarised everything once. System Modifiability - What Is It? The system modifiability allows you to set which objects of the repository and the client-independent customisation are modifiable or not. Repository objects can also be customised even further, with respect to the software component and the namespace. You can choose whether an object should be modifiable, restricted, or non-modifiable. In this context, restrictively modifiable means that repository objects can only be created as non-originals (small note: for packages the setting "restricted modifiable" and "modifiable" is identical in the function). Let us now turn to the direct approach to the changeover to system variability. Change system modifiability As a preparation, you should clarify how long the modifiability should take place in your system. I have learned from my clients that it is often desired to set the system to "changeable" for certain tasks from the specialist areas only temporarily. If you have organised this, call the transaction SE06 in the 000 client and click on the button "System Modification". If you do not have permissions for this transaction, you can try either the transaction SE03 —> System Modifiability or the transaction SE09 -> Jump -> Transport Organiser Tools -> System Modifiability (under "Administration"). The following screenshot shows the way across the SE03: Here you can change the desired namespaces and software components depending on your request.
A secure SAP system does not only include a good role concept. It is also necessary to check whether a user should (still) have a specific role. Regular verification of role assignment is called recertification. In this blog post, I'd like to introduce you to the need for recertifications and our own tool, EasyReCert. The need for recertification - scenarios: Example 1: The "apprentice problem" Imagine the following scenario: A new employee (e.g. apprenticeship or trainee) will go through various departments as part of his or her training and will work on various projects. Of course, an SAP User will be made available to your employee right at the beginning, which is equipped with appropriate roles. As each project and department passes, the employee repeatedly needs new permissions to meet the requirements. After the employee has successfully completed his or her induction and is now in a permanent position, he or she still has permissions that are not necessary to perform his or her duties. This violates the principle of "last privilede" and represents a potential security risk for your company. Example 2: The change of department The change of department is one scenario that probably occurs in every company. If a change of department does not automatically involve a complete reallocation of roles and the employee simply takes his old permissions with him, critical combinations of permissions can occur very quickly. For example, an employee who has permissions in accounts payable and accounts receivable violates the SoD ("Segregation of Duties") principle and poses a potential security risk to your company. Recertification as part of a revision: The two examples above show that a regular review of role allocation identifies potential security risks for your business and can be addressed.
Tools such as "Shortcut for SAP Systems" are extremely useful in basic administration.
The mode is blocked while a Support Package is being introduced.
To store all the information on the subject of SAP - and others - in a knowledge database, Scribble Papers is suitable.
STOR and SMSS must be cultivated in the S_ADMI_FCD permission object.