Initial Situation
In TM till TM9.5 loading durations were calculated and stored on a freight unit level based on a condition or per freight unit. The loading activities of those freight units were scheduled each on their own. This modeling had two important disadvantages. First the loading time couldn’t have a fix part which is common in most transports as each location visited will add a few minutes for shunting and so on and second the disjunct loading times scheduling could lead to situations in which loading of two pallets begins on a Friday and gets finished on Monday because they didn’t need to be on block. Even worth for this sequential loading evaluation was that the optimization was done on the time window – not on a LIFO approach which will not have fit most of the transportation businesses.
Solution: Rule-Based Scheduling
The solution SAP invented to revolutionize the loading durations are the so-called rule-based loading durations (or more internally used as project name flexible loading durations). The approach is different in multiple dimensions:
- Scheduling needs to schedule a loading/unloading at one block
- With that there is the restriction that the freight units loaded have an intersection of their acceptable time windows by the way
- Loading times are not longer based on the freight units but there is a fix part per stop plus an additional one for each freight unit based on its quantities
- The loading times are controlled by a rule set
In S4HANA the new rule-based approach is the only loading duration approach which can be used.
For sure all settings described in following are used and respected in both VSS and VSR scheduling.
As scheduling is rather mirroring for loading and unloading, we decided that you have to maintain rules for inbound and outbound independently on own tabs.
Loading Duration Settings in Scheduling Settings
Rule Logic
As said the loading durations are based on a rule-based approach. This means for all the durations you must maintain a rule table which follows some simple evaluation and design rules. Each rule table offers the location as a pattern field (meaning you can use * pattern for e.g. search all Locations starting with C and end with LA [which would result in C*LA]), means of transport, vehicle type and group as decision basis. The importance of a rule is expressed by the position in the table. Basically, when evaluating the rules, the determination logic will go from top to bottom – as soon an entry is hit this line will taken into account (and only this line).
Furthermore, if you want to express that e.g. all your DCs have a certain rule, you can select a location attribute in the scheduling settings general data. This attribute will get added immediately to all the rule tables and can be used to differentiate.
Loading Durations
There is a fix loading duration which gets once applied for each visited stop. This will already fulfill a lot of customer scenarios as I often hear that customers plan with a fix time per stop (e.g. 2 hours loading at the DC and 30 min per customer stop).
Furthermore, each freight unit add variable loading duration to the fix time. This duration will get determined per freight unit going through the rules. In this rule table you will find another column “Unit of Measure”. This column will get evaluated in advance. The first column where the unit of measure mentioned in this column is found in the freight unit root data will get multiplied with the corresponding value.
Example
If you have e.g. two variable loading duration rules:
| Location | Vehicle | UoM | Dur |
| * | * | PAL | 3 |
| * | * | TO | 10 |
A freight unit with 4 TO and no PAL value will add 40 minutes to the full loading duration
A freight unit with 1 TO and 3 Pal will add 9 minutes to the full loading duration
Requirement Document Attribute
There is one more differentiation possibility for this variable parts. As a lot of customers have different assortments which needs different loading times (e.g. it takes more time to get a palled with cooled goods out of a special storage area) you can define a requirement document attribute which gets evaluated in advance. You can choose from any TOR ROOT field and it will immediately get into your rule table.
My recommendation would be to add a Z-field on Root to control about such assortment specific loading times. Anyways – keep in mind that this could have a dependency on how you build your freight units as the attribute will only evaluated on root not on an item level.
More about scheduling settings to come in the next blog.
- SAP Managed Tags:
3 Comments
| User | Count |
|---|---|
| 10 | |
| 8 | |
| 5 | |
| 4 | |
| 3 | |
| 3 | |
| 3 | |
| 3 | |
| 3 | |
| 2 |
