Key to a good transportation cockpit performance is a good selection. Select as much data needed but as less as possible will basically save response time for every click in the cockpit.
Whenever it makes sense from a business point of view you should split up the scenario.
If you have very special/exceptional cases (like “repairing” freight orders which are already departed in the past by adding freight units) you should think about splitting your selection for a scenario into several profiles (e.g. one “full blown” for the exceptions, which is slower but rarely used and a smaller one for the 80% case).
I’m quite sure that your business will also understand using two profiles for the same scenario as the planers life will also be simplified if he sees only what he needs for the 80% cases.
The planning horizon defines the time for which a planer is creating transportation plans. Technically it controls several planning related functions, e.g.:
– it defines the most outer corners the scheduler can schedule orders
– it defines the corners the optimizer can create/exchange/delete orders
– it defines which (and thereby indirectly how many) schedule departures are loaded into the transportation cockpit
Reason why I tell this is to say that at least manual planning with an “outdated” planning horizon is still possible but with restrictions. If you for example need to repair old freight orders by adding freight units but don’t care about right document dates (as the order is executed anyways) you could optimize the planning horizon for normal cases and plan those special cases without scheduling. Be aware that it is also possible to increase the planning horizon during a planning session using “change planning settings” button. Especially using the optimizer, it doesn’t make much sense for me to begin the planning horizon in the past. I guess you never want a new order to be created in the past only because it would have fit well to have driven the goods yesterday.
But why is a big planning horizon impacting performance of some actions so bad? Well, reason is mostly the context information for some operations. Imagine the optimizer wants to create new orders on a single resource. To not create overlaps we need to read all the freight orders in the planning horizon.
Please be aware that this kind of context determination is absolutely needed for correct results and cannot be deactivated (and has nothing to do with the context determination you activate on the planning profile).
Therefore, always try to keep your planning horizon as short as possible. For sure I cannot give recommendations how long might fit but you should ask your business.
Are they usually planning for the next day? Then it might fit to just have today (for execution planning) and tomorrow.
Are they planning a week ahead? Then you might use an offset of seven days and a seven days horizon. For exceptional cases, you could create another profile for the next 14 days.
Time-Related Selection Attributes
Here the same rules apply than for the planning horizon. Please try to select data which correspond to your planning horizon. It doesn’t make sense to select all upcoming demands in the next 6 month if you just plan for the next two weeks. Sometimes it makes sense to add or remove a few days in one or the other direction for the selection horizon but as always you should try to meet your business requirements with the minimum horizon.
From a performance perspective, there is a very dangerous drop down box in the time-related selection profile: “Use Index Time for Selection”.
But what does it mean and why it’s so dangerous? In TM document selection normally works on a stop level meaning that we select documents based on certain stop attributes. One of them is the time when the stop takes place. But a TM stop doesn’t happen at one point in time but is covering a period of serval times. But there are a lot times at a stop: begin/end of loading, begin/end of coupling, cut-off dates, requested/acceptable times for pick-up/delivery and some more.
If you now search for some document on a certain date the system needs to check all the stops on the database whether one of those times might fit.
This takes a lot of time. Therefore, we invented the index time. It’s one timestamp defining the stop and which is used for selection (and some other decisions, e.g. the sequence on a resource when scheduling several orders).
This time is always the time which should be the most important one for the document in a certain status. For a planned freight unit, it’s always the planned departure/arrival time. If the freight unit is still unplanned, it’s the requested date and if this one is not filled the acceptable date. The logic how standard is defining this most important date is defined in class /SCMTMS/CL_TOR_D_STOP_AM method FILL_SELECTION_TIME_PER_STOP. If you don’t agree with our standard logic for defining the most important date you could add a post enhancement here.
Personally, I would recommend to never use the “Use All Stop Times” value!
Additional Selection Attributes
Inclusion is better than exclusion
Don’t want to go political today but from a selection point of view it’s always better to include instead of exclude. So, in the additional selection attributes if possible try to express your selection by include statements instead of exclude statement. If you for example want to exclude dangerous goods you should express it with “dangerous goods indicator EQ false” instead of “dangerous goods indicator NE true”. For sure sometimes it’s hard or impossible to express selections with a white list.
If you use condition-based filtering first a more documents, then needed are read from the database. Afterwards the filtering (which is not the fastest itself) must filter the data on the application server. Therefore, my recommendation would be to not use it at all but try to cover the requirement by clever selection values.
As I’m often asked “but I need certain non-ROOT fields for my selection” I want to add a short idea how to overcome this issue. For selection (run time) performance it will be much better to determine the attribute you want to filter on in an after modify determination and persist it on ROOT level on a Z-field. For sure this will cost a little bit more memory but the ROOT- based query could now filter for the Z-field on data base level and you don’t need to use condition-based filtering.
Be also aware of the fact that because of the huge potential for performance issues SAP decided to deprecate it in S4 HANA. So you will not be able to use it anymore if you decide to move to S4.
More about performance you can find here.