This blog will analyze some of the tables behind the SAP user license measurement.
Warning: the list of tables below is not complete. Do not base any assumptions on the content of these tables in your system. In updates and newer versions all content can change. The tables and the text in blog is to give you insight into the process. In any contract SAP will claim the right for inspection of actual usage of your system versus the license rights in your contract.
Questions that will be answered are:
How do I know which objects are measured?
How are objects measured?
How can I find actual measured objects?
The general user measurement principles are explained in the blog on USMM.
The tables behind license measurement
The best table to start with is the TUAPP table: measurement of applications.
Example is given below:
Here you can see that Advanced ATP is measured via call function module. In SE37 you can lookup the function module and see inside the code what exactly is measured:
The other entry in TUAPP we will take as example is Procurement Orders. Its application ID is 5000 and does not measure via function module.
First we get the application to unit and unit name from table TUAPP_UNT (units themselves are defined in table TUUNT):
Now we see procurement is counting Inquiry, Purchase order, Contract, Scheduling Agreement and Others.
The actual values read by the measurement for the application counters are stored in table TUCNT:
The tables behind the AC checks
The AC (anti cheating) modules use bit different tables.
Table TUL_AC_UNIT is to denote the table to count on:
Here you see the main procurement table EKKO has ID number 5018.
In table TUL_ACTTC you can lookup this value:
This data will be used in dynamic SQL statement that will list the user name (ERNAM) who did the create or change and uses AEDAT (last change or creation date) for table EKKO to count for check 5018.
Be careful with the interface users. If an external system posts data into SAP system with a single background user, but it is clear that in the source system multiple real users doing the actions, SAP might want to charge you for 'indirect use'.
For live support of an SAP system you typically will have 2 types of support users:
Users for SAP themselves to logon to your system and provide support to you
Fire-call users with elevated authorizations to solve time critical incidents
Both type of users have no direct business goal, but have only support usage. You can mark them as type 91 Test user, as long as you have a clear naming convention for these users and a general rule that they are locked unless they are needed.
User deletion as regular activity
The user measurement program (both USMM and USMM2) checks for deletion of users in the last three months. To avoid discussions on user deletion it is best practice to delete monthly, or bi-monthly, all persons which have left your company.
End validity date
Users who don’t have a current validity date are not counted in the user measurement program. You might want to schedule program RSUSR_LOCK_USERS in a regular batch job to end the validity of users that did not log on for long time automatically. See this blog for more details.
SAP does measure how many times a user has a double, triple, etc logon. The results are stored in table USR41_MLD. SAP might argue that the same user is used by multiple persons. You can use the contents of table USR41_MLD to prove if this was a mistake only. If the are too many multiple logons you might need to go back to the business to change their behavior.
You can also forbid the multiple logons at system level. SAP system parameter login/disable_multi_gui_login can be set in RZ11 to forbid multiple logons. For some users (like DDIC) you do want to keep multiple logons. These users must be set into system parameter login/multi_login_users=username1,username2,username3,etc.
Use the SLAW or SLAW2 tool to execute a proper consolidation of your measured users. This process will de-duplicate your counted users.
License validation program
Read this dedicated blog to know more about license vailidation program RSUVM080.
LUI License utilization information
The LUI (license utilization information) tool is an online SAP tool that has all the information on your on premise and cloud licenses information combined. For cloud the usage is automatically visible. For on premise systems you can upload the usage via the SLAW files. This can give you insights into under-consumption and over-consumption of licenses. Read more in this blog.
Check for bug fix notes in your advantage
SAP might give you a list of OSS notes to apply in your system before the measurement. These notes normally benefit SAP. You can also check for OSS notes that benefit you.
Attached to this OSS note is the most recent version of the PDF listing which switches are part of the standard license, and which switches require an extra license.
How to read the document?
The document is sorted per business area. Best way is simply use the find button in the PDF and search for your switch.
Example of 2 switches that don’t have license impact:
The pricing comment and License (material number) column are empty. These switches are part of standard license.
Example of switch with license impact:
For this switch your company should be in possession, or acquire the license mentioned in the last column.
EHP switches best practices
Since EHP switch can have license impact the following best practices is suggested:
Restrict SFW5 EHP switch activation access to basis team only (display for all is ok)
Explain basis team the fundamentals of the licenses and EHP switches
Determine in your company who must approve EHP switch on and make clear to basis team only to execute the activation after this approval
If you have switched on a switch with licenses and don’t want to use it, check if it is a reversible switch. Then simply undo this. If it is not reversible, don’t use the corresponding functionality. The latter is much harder since you need to restrict authorizations to that function very carefully.
In the previous blog the new SAP license model for indirect access. The biggest challenge after reading the blog will be: how can I know the impact for my situation and my SAP system?
For this purpose SAP has developed an estimation tool.
Questions that will be answered in this blog are:
Which note do I need to apply to get the estimation tool?
How do I run the estimation tool?
Why is the tool estimation only?
Warning: this tool only gives estimation. The tool cannot take into account specific configurations you have done to standard SAP that influence the outcome. Also the tool cannot take into account potentially company specific agreements you have made with SAP.
Digital access report
Start transaction RSUVM_DAC for the digital access report:
Double click on the line will get you to the details.
Depending on your SAP version and support package the tool is already available, or you need to manually install it. In case of manual installation, first manually create package Digital_Access in SE80. The next OSS note to install is depending on your version (S/4HANA or ECC):
The counting estimation in the ABAP is simply executing a select count for the time frame and user on the respective tables for specific document types.
Example below is the counting of purchase order line items:
Here you can see only lines from EKPO with type lc_bstyp_f (which has value ‘F’) are selected. If you have configured your system differently (for example copied F to Z and are using Z) the count program will not find and report this.
This is the reason why the program is only to give you an estimation.
Regularly check the tool OSS note for new updates of the note version. Other relevant notes and bug fixes: