TKS #13 - Equipment Type Based Planning

[Tobias_Berger]

Issue of Multi-Resources

TM road freight orders typically get their capacity information from truck resources. Those truck resources can be defined as single or multi resources. While single resources are usually meant to define physical resources (with a plate number…), multi-resources were meant to represent of a carrier fleet of which I can order an unlimited number of similar trucks.

Both kinds of resources can get assigned to an equipment type in which case the data from the equipment type are copied to the resource but can be changed for the resource in the master data UI.

Over the past years SAP found out that customers struggled with the idea of the multi-resource. They were expecting that with the creation of an equipment type they can use it for sub-contracting scenarios without the need of having an additional multi-resource.

For most of the customers the multi-resource was only an artificial construct which was confusing for the business users as they were used to think in equipment types.

Solution

Therefore, with S4/2021 SAP introduced the so-called equipment type based planning. The major premise is rather simple: each equipment-type defined in the customizing can be used in TM the same as you could use the multi-resource before.

So as soon you created an entry for an equipment-type in the equipment type customizing you will be able to find it in the transportation cockpit in the equipment type area as well as the area for the resource category (e.g., if you create a truck type you will find it in the equipment type as well as in the truck list). In the resource category list for sure the “resource ID” will be empty.

The transportation cockpit selection criteria as well as the selection profiles have dedicated areas to select vehicle and container types.

You can plan with the equipment type as you can plan with normal resources. Entering an equipment type will be treated as entering a resource (leading to manual planning strategy executed – meaning that for example scheduling will get executed in “VSRI_SCH”). As the equipment type now has a unique ID across all equipment groups you will find that the capacity document lists (in the TC) offers only manual input of the equipment type but not of the equipment group. So, the user only needs to enter the one field to change from one equipment type to another.

Equipment Type from Customizing Shows up in Transportation Cockpit

Technical Details

For those of you which are interested in technical details I also want to explain what happened under the hood.

Basically, the equipment type will get an own real multi resource in TM. This multi-resource is “created” by interpreting the equipment type customizing as multi resources. The resource ROOT node already relied on a CDS view and this view is covering not only the old resource master data root but also joins the equipment type table in the meantime.

Equipment Type and Resources are Technically Harmonized to Resources

Each equipment type is therefore also a (multi-) resource with an own resource key and a resource ID which you will find debugging or checking the DB. The ID is always created following the pattern $<equipment group>~<equipment type>.

In enhancements you can use them totally similar to resources as the whole handling is inside of the resource BO and should be transparent for application developers the most time. If you need to differentiate the resources for equipment types (e.g. for raising specific messages) you can use a new root attribute is_equi_type_res to differentiate the equipment types for user interaction.

From standard the concept of re-using the resources shall be transparent to the users – therefore resource ID is only technical information and shall never be shown. Also, messages will usually differentiate between resources and equipment types. Feel free raise an case if you see for example a message which showing such technical ID.

Compatibility

In older releases the equipment type was not a real planning object, was only limited supported from the transportation cockpit, was not a trigger for e.g. scheduling after an assignment and the type ID was only unique inside of the equipment group.

If you need the old behavior, you can set “Restricted Use in Planning” in the equipment type to downgrade to the old behavior. You will need to do it before the first save as an equipment type which was upgraded once cannot be downgraded anymore.

Conclusion

The new equipment type based planning is an usability and understandability improvement against the old multi-resource concept. Therefore, I would recommend using equipment types instead of multi-resources to cover an unlimited amount of resource instances (e.g. for a subcontracting fleet).

Side-remark

If you try to model something like “I have 20 trucks of the same type” I would highly recommend modelling those as single resources. Do not try to model it as a multi-resource with a limited number of instances. The limited number of resources are not fully supported and usually you will run into issues with that.