This guide aims to give you some information about the first steps a developer will do when checking an TM-PLN* incident. The idea behind that is that as more of those steps are already done upfront as easier it will get for the support or development to analyze the issue. With this you can fasten processing time (You can compare it with issues with your WIFI; if you have already restarted computer and router and maybe even checked for some error messages the support can help you faster as those steps doesn’t need to be taken anymore).
Sometimes I mention “internal tickets”. Those aspects for sure are only of interested if you are a colleague of mine at SAP or if you have somehow access to SAP system landscape (e.g. as you help us in software tests).
1. Transportation Cockpit: Find the smallest data set
Most issues regarding planning are found using the transportation cockpit. Usually in this UI customers process mass data. Therefore, most of the incidents are using selections of hundreds of documents while a simple selection is enough. So, the first thing is to get rid of any data which is not needed. Imagine an issue which happens when assigning 20 FUs to a FO. Try whether the same issue occurs with a subset of the freight units or even with only one. If this is the case only mention the documents which are needed to reproduce the issue.
2. Transportation Cockpit: Save a search for the incident
In the transportation cockpit it’s possible to save searches for the selection criteria screen (which is a much better entry for support than profiles as dedicated documents can be mentioned). In a customer incident normally the support user is fix. Therefore, it makes sense to save a search (e.g. “INC_####”) for an incident which directly fits the smallest possible data set. In internal tickets you can save a “global search” if it’s not one of the main test or development system. If this is not possible for some reasons make sure the information is easy to be found in the incident.
If you did not use the support user to create a saved search also make sure the page layout you used can be accessed from this user. For internal tickets just make it valid for everyone.
3. Try to eliminate bad short descriptions
A lot of incidents have short descriptions like “Error in Transportation Cockpit” or “Wrong Result”. Such short descriptions are bad for identifying the right processor without reading the whole incident. As better you describe the incident in both short description and incident text as faster processing can be done.
Comment to colleagues of mine: if you process an incident and route it to another component, make sure to check the short description matches and describes the incident issue.
4. Try to describe the expected behavior
For incidents mentioning short dumps it’s kind of easy to understand the expected behavior but if you found an issue in the process, wrong calculated data or a wrong display always describe the result you expected. This helps as not all the processors are deep into all our processes. Also avoid only mentioning “as discussed with xyz” as you cannot expect that the person you discussed an issue with will process your ticket (for sure there are exception of this rule but also if a colleague offers to take a look and says “mention forward the incident to me” maybe this colleague wants to forward the incident later – so it’s always worth to spend some minutes to describe the problem).
5. Transportation Cockpit: Try to make the page layout easy (especially if it seems to be a display issue)
Especially if you discovered an issue which looks like a display issue in the transportation cockpit try to eliminate unused areas in the used page layout. E.g. you have an incident which is mentioning that a hierarchy is missing the data it should display. In the used page layout, there are 15 areas shown. Please reduce the number of areas – If e.g. only the hierarchy is needed a perfect layout will only contain this hierarchy.
When using the Gantt chart you can also try to downsize the number of used hierarchies by using another Gantt chart layout.
Make sure the right map/Gantt layout are used in such layouts.
6. Multi-Window Environment
If you are working with the Transportation Cockpit using the multiple window feature, always try whether the same issue also occurs in a single window environment as well (e.g. with a special layout having all your used areas on one screen.
If you work with three windows and saw that the issue will not occur in a single window environment, check whether only two of the three are needed.
If the issue only occurs in multi window environment also check whether it makes a difference whether the additional window was directly opened during cockpit opening or is opened manually during the session.
7. Try to find the correct component
Lot's of incidents are created on major components with a lot of sub-components (e.g. TM-PLN itself) which is ok as you might not know where exactly the issue belongs to. Anyways it worth to think twice about whether you have an idea which direction the ticket belongs.
Was an issue happening during manual planning? Might be TM-PLN-MP
Is there something wrong with times in your document? Might be TM-PLN-SCH or TM-FRM-TIM
Is there an issue in the planning profiles or settings? Might be TM-PLN-PS
Why is that helping yourself? With a better categorization there is a higher chance that the incident reaches the correct processor faster and therefore might fasten the overall processing.
8. Customer enhancements/BadIs
If you are aware of any customer enhancements or BadI implementation which are relevant in the action which lead to the issue it might help to mention this information.
Thanks a lot for reading this blog and creating good documented ticket! This will help processors and processing time.
At the end I want to add some additional information sources of information:
