Hello guys,
Problems related to the lack of data in ST03 due time zone incorrect settings are highly recurrent. I mean HIGHLY. The root cause for those wrong settings are, in the majority of the times, related to two scenarios:
---> Wrong time zone settings at SAP level (transactions STZBC, STZAC, etc...)
---> Mismatch between the timezone used by the OS level and SAP system.
There is a procedure that I often use to "navigate" through the possibilities and find out whether a time zone issue exists and, in case it does, where it's located. It is fairly simple and has helped for in several occasions while working with related scenarios.
The flow of the troubleshooting / decision making follow these steps, starting with the symptoms see at ST03:
ST03 does not report data / does not report current data (last two days) / ST03 seems odd...
In order to confirm or rule out a time zone issue as the root cause for the above topic, the first thig to do is go to STAD transaction and run it with the default settings. Just get into it and execute:
In case STAD does not report any data whatsoever, then we most likely have a winner. In case workload data is returned, then the issue should be approached thorugh different ways. We follow assuming that nothing returned to the query.
The very next thing to do is to check OS level time zone settings and cross it with R/3 level (client 000). The procedure vary depending on the operating system but on unix platforms, the command "date" will bring the desired information. For windows, "systeminfo":
| UNIX: | WINDOWS: |
 |  |
Then you cross that information with R/3 level (client 000), transaction STZAC. The same timezone name must be seen there. The SAP system used for this analysis is hosted at a linux server (above) so the OFFSETs are matching.
That was the easiest check to do. Now comes the tricky part, which we approach in case the outputs present correct settings but even so ST03 and STAD are presenting issues.
First we need to understand the the system has its own timezone but users have it as well. User timezone can be the same as the system's (for cases in which both are located at the same region) or different (like seen above) where server is located at one place and users in another. We are using that feature in our advantage in this analysis.
For the above STZAC situation, the would be the expected output for SYSTEM > STATUS menu:
The "System time" field will present the time zone from the system itself and the "Time Zone" issue will report the timezone *ONLY IN CASE* the user have a different than the system. If both have the same timezone set, the field Time Zone will not appear at all.
Now here starts the "trick"... Whenever facing time zone issues on your system, you'll notice that the extra "Time zone" field will be there, and we'll use it in our advantage in this analysis.
As soon as you know what is the default time zone being used by the system (transaction STZAC, client 000) you go to:enu
> Menu system > User profile > Own data. Then, you change to tab "Defaults";
Inside of the Defaults tab, we'll look for the section "Personal Time Zone", where the current user time zone settings can be changed. First thing to check is whether the same is being used. In case its not set at all (assuming the system time zone) or set to another value, please set it to the same value:
After that, you have to save the changes, log out and in again. As soon as you log in again, you need to check menu "System > Status" one more time. Most likely you'll see something like this:
Above we can see that even using the very same time zone as the system, the output still shows one hour difference. Now what we have to do its change the user time zone settings again and, instead of CET (which should be equivalent for UTC+0100) use the OFFSET directly in the field. We already know that the OFFSET is not properly equivalent to UTC+0100 as it should, because if it were, the extra field "Time zone" would not appear at "System > status" menu.
Finally you just have to try another UTC OFFSET, lets SAY "UTC+0200" in the field, log out and log in again until the "Time zone" filed ceases to appear at "System > status" menu. Then you can finally access STZBC transaction and check why the time zone set for the system (in this case CET) is not behaving correctly as UTC+0100 but as UTC+0200 insted.
This procedure might appear complicated for first timers but, in time, you'll get the hang of it. I can assure :wink:
Cheers,
Ian Segóbio.
- SAP Managed Tags:
1 Comment
