SAP TM92 Container Management

The objectives above give an overview on the main topics of this RKT lesson.

This presentation encompasses all aspects of container management, including

enhancements to forwarding order management, freight units and freight orders

as well as planning. As the normal FCL planning process is not changed, this

presentation only deals with the handling of the empty containers.

So far, SAP TM was only concerned with the transport of goods, not the

transport of equipment like containers. The transport itself only started once the

container was loaded and ready for the journey. However, the container already

had to travel before it was loaded at the shippers site.

If the shipper does not have own container an empty container needs to be

hired from either the carrier or the logistics service provider responsible for the

entire transport. The container is then picked up from a container yard where

the empty containers are stored and transported to the point of loading, in this

case the shipper. This process is called empty container provisioning.

Once the FCL (full container load) transport was executed and the container is

unloaded at the consignees site, the empty container needs to be brought to a container yard again (usually not the container yard it was picked up). This

process is called empty container return.

The provisioning and return of the container is usually not considered essential

part of the transportation service of the logistics service provider, however, it

needs to be tied in with the transport of the full container in order to provide the

container at the right time.

6

As shown on the slide above, the source and destination location of the

forwarding order are the loading and unloading points of the container. The

container yards included in the transportation process are not maintained on

tab Locations and Dates/Times.

However, the provisioning or return of empties can be defined in the item

hierarchy. To do this, a container item needs to be maintained in the item

hierarchy. For the container item, the options Empty Provisioning and Empty Return can be set as shown on the slide above.

7

In the details of the container item, two new tabs appear that represent empty

provisioning and empty return. In empty provisioning, the delivery location of

the empty container is already prefilled as well as the delivery date. However,

you can change the delivery date to an earlier date than the pickup date of the

loaded container to allow the shipper time to load the container. You can also

change the delivery location of the container if the shipper wants to receive the

empty container at a different location to where the loaded container is picked

up.

The same applies to the empty return of a container where the pickup date and

the pickup location are prefilled from tab Locations and Dates/Times but can be changed if necessary.

8

Once the pick-up location for the empty container provisioning and the

destination location for the empty container return are defined, they also appear

on the Stages tab as an individual stage. However, since the empty

provisioning/return is not essential part of the transport of the goods, it is not

part of the complete carriage in neither actual nor ordered route.

The dates and locations for empty provisioning/return can also be defined and

amended in the Stages tab directly without having to use the item details of the

container item.

9

When triggering freight unit building from a forwarding order including empty

provisioning/return, freight unit building is triggered separately for the cargo

movement (movement of the loaded container) and for the empty

provisioning/return leg (movement of the empty container). If both, empty

provisioning and return is used in the forwarding order, separate freight units /

transportation units are created as shown in the figure above.

As freight unit building is triggered separately, it can be configured whether the

cargo movement should be represented by a container unit or a freight unit or

should be differentiated from the empty provisioning/return container units by

document type. This can be accomplished by using a condition in the freight

unit building rule that determines the TOR type based on the item category and

movement category.

As illustrated on the screenshot above, the empty provisioning is shown on the

movement category of the transportation unit (empty return is also shown on

movement category).

The container unit created for empty provisioning/return only contains the

container item on the Cargo tab, while the container unit created for the cargo

movement contains the full item hierarchy of the associated forwarding order.

10

In some cases a customer requests the logistic service provider to provide or return more empty containers than only the ones that contained cargo. While the request for empty provisioning/return is only concerned with the containers that also carry cargo, additional empty containers that are not carrying cargo can also be ordered with the same forwarding order. Instead of using the identifier X for empty provisioning or empty return the identifier P (Provisioning Only) can be set for empty provisioning. Likewise R (Return Only) can be defined for empty return. As opposed to the request for empty provisioning of a container that is going to carry cargo, the container items for which Provisioning Only is defined may not contain any cargo item such as a package or a product. The same applies to having defined Return Only for empty return. The container items for Provisioning Only/Return Only can coexist with container items carrying cargo on the same forwarding order. However, it is only possible to define either Provisioning Only or Return Only for a container item. When defining Provisioning Only or Return Only for container items, the number of containers to be provided or returned can be defined in the item details on the corresponding tabs. If empty provisioning/return is requested for cargo carrying containers the number of containers is taken over from the item table and cannot be changed in the item details. Freight unit building will create separate container units for the containers where Provisioning Only was defined. By using the condition to determine TOR types in the freight unit building rule it is possible to differentiate empty container units for provisioning only and empty provisioning for cargo carrying containers.

11

The ordering party may ask the logistic service provider to organize the hire of

a container but picks up the container at the container yard themselves.

If so, the container item in the forwarding order can carry the information that

the pickup or return of the empty container is organized by the ordering party. In

this case the corresponding stage for the empty provisioning/return is set to

Not relevant for planning. The container unit created for the empty provisioning/return is automatically blocked for planning (Block reason: Not

Ready for Planning).

12

Empty provisioning and empty return can also be used in the context of export

and import forwarding orders.

On the export forwarding order both, empty provisioning as well as empty

return are maintained for the container item. However, the export forwarding

order only creates a container unit for the empty provisioning as the export

business unit is responsible for the organization of the empty provisioning.

Once the import forwarding order is created, it automatically creates the

container unit for the empty return as the import business unit is responsible for

the empty return.

Regardless of the responsibility of planning the empty provisioning and empty

return, the charges for empty return could be charged by the export business

unit or the empty provisioning could be charged by the import business unit.

Therefore, the information about empty provisioning and empty return is always

copied to the main cargo item and therefore available on both export and import

forwarding order. Therefore, charge calculation can consider this information

regardless of whether the charging business unit is also responsible for the

planning of the empty container leg.

13

Even though the previous pages have mostly talked about the empty

provisioning/return functionality for container items, all functionality is also

available for railcars.

Please note that the freight unit building rule in this case should be adjusted to

create rail car units.

Empty provisioning/return is currently not supported for trailers and trailer units.

14

When calculating charges for a forwarding order that uses empty

provisioning/return the additional services of the logistic service provider needs

to be charged to the customer. Therefore, in the basic data of a charge line it

can be defined whether this charge line should be used for empty provisioning

and/or empty return.

Furthermore, it can be differentiated between provisioning/return of containers

that are subsequently used for a cargo transport in the same forwarding order

or a provisioning/return only.

16

To demonstrate how charge calculation works with regards to empty

provisioning let us take a look at a forwarding order that contains three

containers of which

One container requests empty provisioning for the loading of goods One container is already available at the shippers site One container should only be provided but not be used for the transport

At the same time, the calculation sheet used for charge calculation contains

four charge types:

One basic handling charge One container charge with no provisioning requested One container charge with provisioning set to X (Provisioning for cargo

movement)

One container charge with provisioning set to P (Provisioning only, without cargo loading)

While this example only deals with empty container provisioning, empty

container return works exactly the same way as in this example.

17

Charge Calculation works differently depending on whether calculation is done on header, item or stage level. In the example above charge calculation is done one header level, while the resolution base for the container charges is set to CONTAINER. For each container item where provisioning is requested, a technical container item with provisioning only (P) is added to the forwarding order in the background. Charge calculation considers this technical item. In the example above it is shown as logistical reference (second last charge line). The container item for which no provisioning was requested is considered for charge calculation only once which is shown on the screenshot with the first charge line marked in red (logistical reference 40). The container item for which provisioning is requested (X) is considered twice, once for the provisioning itself (orange line, logistical reference 10) and for the actual transport (second red line, logistical reference 10). Furthermore, a technical container item with provisioning only was created for this container item which is also considered in charge calculation (first yellow line, logistical reference 90). The container for provisioning only is only considered once, for the provisioning itself (second yellow line, logistical reference 70) but not considered for the basic container charges (DI_CONTAINER) as it is not part of the cargo movement.

18

When calculating charges on item level the entire calculation sheet shown

before is calculated for each item.

However, all basic freight charges are not calculated for items with provisioning

only as they will not be part of the actual cargo transport.

As you can see in the example above, the container item for which provisioning

was requested contains charge lines for basic handling charges, container

handling charges and charges for the requested provisioning (charge type

DI_CONTAINER_X).

While the container for which no provisioning was requested only contains

charges for basic handling charges and container handling charges, the items

for provisioning only (item 70 and the technical background item 90 created for

the container item 10 for which provisioning was requested) contain only the

charges for provisioning only.

19

When calculating charges on stage level charge calculation differentiates

between the stage for container provisioning (X-A) and the individual stages for

the cargo movement. Like in calculation on header level, the resolution base for

all container related charges (DI_CONTAINER, DI_CONTAINER_X,

DI_CONTAINER_P) is set to CONTAINER again.

As shown on the screenshot above the stage for provisioning (A-X) contains

basic handling charges and the charges for the provisioning only. Charge type

DI_CONTAINER_P is calculated twice for this stage, once for the container

item 70, for which provisioning only was defined and once for the technical item

90 which was created for container item 10 for which provisioning was

requested. Container handling charges (DI_CONTAINER) are not calculated as

the corresponding charge type was defined for Empty Provisioning -> Not requested

For the actual cargo movement stages the container handling charges are

calculated per container involved in the transport. On each stage container item

10 is considered twice, once for the container handling charges (as it contains

cargo items) and once for the request for empty provisioning.

20

When looking at the empty provisioning and empty return process discussed on

the previous pages many transports for empty containers are necessary, even

to and from the same container yard.

As shown on the illustration above forwarding order 1 ends with the return of

the empty container to a container yard. In parallel, almost on the same date,

another forwarding order, FWO 2, requests the pickup of an empty container of

the same type from the same container yard.

22

If the situation described on the previous page can be observed, the empty

container could directly be transported from the unloading point to the next

loading point without having to go to the container yard in between. This saves

time and transportation costs.

23

To be able to observe empty container movements that can be consolidated,

the POWL displays the container units that represent the empty container

movement. The POWL column Movement Category shows if the container unit describes an empty container movement. This can also be accomplished

differently if the empty container movement is already represented by a

dedicated container unit type.

In the illustration above we can see that the last two entries of the POWL are

two empty container movements that use the same container yard while one

returns the empty container to the container yard and the other picks up the

container a day later.

24

If two empty container movements have been identified they can be

consolidated by creating a triangulation. The triangulation can be created by

selecting the container units in the POWL and choosing Triangulation -> Create Triangulation. When creating a triangulation one container unit is cancelled while the other

container unit receives the destination location of the cancelled container unit.

The container yard is no longer part of the container unit, the empty container

movement is now direct between the unloading location and the loading

location. The delivery date of the triangulated container unit is the delivery date

of the omitted container unit.

25

As one of the two container units was cancelled the triangulated container unit

now serves as successor document for both forwarding order for which empty

container movement container units were created.

On the Stages tab of the forwarding order the empty return stage (empty

provisioning on the other forwarding order) now shows a note that this stage

was triangulated and also shows the destination location and delivery date

(source location and pickup date on the other forwarding order) that was

derived from the other container unit.

26

When entering the transportation cockpit the profile and layout set screen is now enhanced to accomodate a selection profile for transportation units (TUs). The selection profile can be defined independent of selection profiles for freight units, freight bookings or freight orders. The selection profile for TUs selects all transportation unit stages that should be displayed in the transportation cockpit. In the selection profile you can also define whether only the stage that corresponds with the selection criteria should be displayed or all stages of the container unit if one stage matches the selection criteria. At the same time, transportation units such as container units, railcar units or trailer units can also be selected usind the selection criteria view when entering the transportation cockpit. A new section for transportation units is added to the screen. The selection attributes resemble the selection attributes for freight units. In the selection criteria screen it can also be defined whether all stages of a container unit should be displayed if one stage matches the selection criteria. Furthermore, for transportation units as well as for freight units it can be defined in the selection criteria whether stages that have initial pickup as well as delivery dates should be included in the selection so that they can be planned. When defining selection criteria or selection profiles the transportation unit category can differentiate between trailer units, container units and railcar units. Once the container units are selected they can be displayed in the transportation cockpit in multiple ways. Transportation units are displayed in the transportation units area. Please note that the transportation units area is now independent of the freight units area. The transportation units area in the transportation cockpit differentiates between trailer units, railcar units and container units. For all three categories of transportation units the stages can be displayed with a hierarchy that can be adjusted in Customizing. For all categories, predefined hierarchies are available. Container units however can also be displayed in a list view, with a list of the container units stages or a list of the container units header data.

28

Planning with containers and container units is very similar to the way planning with railcar units works. Container resources can be created as transportation unit resources master data and displayed in the resources area of the transportation cockpit. The capacity selection settings provide a new tab, where container resources can be selected in the same manner as vehicles. Freight units are usually considered as cargo that is not loaded into a container yet, container units are considered containers either empty or with cargo loaded. Freight units can be loaded into containers in the transportation cockpit by dragging & dropping a freight unit (stage) to a container resource. As a result, a container unit is created. This process is very similar to the loading of freight units onto a railcar which as a result creates a railcar unit. However, depending on the configuration freight units can still be containers. In this context we will consider freight units as not loaded into containers though. A container unit can be assigned to a freight order or freight booking by using drag & drop exactly the same way as railcar units can be assigned to freight orders or freight units can be assigned to freight order or freight bookings. Certain prerequisites such as the transportation mode are still checked. Furthermore, container units can create freight documents such as freight orders or freight bookings in the same way as freight units can. This can either be done by using the Create Freight Document button in the container unit area or by planning a container unit stage onto a schedule departure which would create a freight document of a type specified either in the planning profile or in the schedule type. Container units can also be created manually in the transportation cockpit, either from the resources area, where the container unit is created for the resource selected or from the container unit area where equipment group, type or container resource need to be defined in the popup illustrated above.

29

When planning with container units certain incompatibilites also need to be taken into consideration. Therefore, new incompatibility types were introduced to be used in the incompatibility area of complete VSR. All of the container unit specific incompatibilities are similar to already existing freight unit specific incompatibility types such as: Container Unit Container Unit (Vehicle Level)

This incompatibility type defines that two container units with incompatible values may not be loaded onto the same vehicle

Container Unit Vehicle Resource This incompatibility type defines that a container with certain attributes may not be loaded onto a specific vehicle resource

Container Unit Transshipment Location This incompatibility type defines that a container unit with certain values may not be transported via a specific transshipment location

Container Unit Freight Booking This incompatibility type defines that a container unit may not be planned on a certain freight booking that already exists

Container Unit Schedule This incompatibility type defines that a container may not be planned with a certain schedule

To use the new incompatibility types, a new condition type /SCMTMS/INC_TU was introduced which needs to be used in all incompatibility definitions using container units. These incompatibilities are used in both, manual and automatic planning. For trailer units and railcar units no incompatibilities are available.

30

Container units are considered in optimizer planning (transportation proposal and VSR planning) like freight units. This means the optimizer can assign container units to freight bookings, freight orders or vehicle resources, considering possible incompatibilities and capacity requirements. When planning a container unit to a freight booking it is checked whether the equipment type used in the container unit is booked by the freight booking. Furthermore, the physical properties of the container unit is checked against the physical properties of the vehicle resource. The optimizer explanation tool is enhanced and now also shows a separate folder for container units. Furthermore, the optimizer can plan railcar units or container units on schedule departures automatically, creating a freight document in the same way as it is possible for freight units. When scheduling freight documents that were created manually or when scheduling as part of the optimizer planning the container unit is treated in the same way as freight units using pick-up and delivery time windows (PUDL windows) and penalty costs for early or late arrival/departure. If a freight unit was assigned to a container unit the freight units PUDL window is taken over into the container unit. The time required for loading a container into a vehicle resource can be defined using the loading/unloading condition or a fix value in the planning profile as it was already used for loading times for freight units. If loading times occur for loading the container onto a vessel and a freight unit is assigned to the container unit, the loading activities will be propagated and shown on the freight unit. The time required to load the freight unit into a container unit is not considered in SAP TM.

31

The POWL Overview Planning provides an overview of all transactional documents that are created for or by transportation planning. In the query

category Transportation Units individual queries for trailer units, container units and railcar units are available. From these POWL queries business

actions such as triangulation or load planning can be triggered.

32

The summary above recapitulates the main topics discussed in this RKT

lesson.

Documents

SAP TM92 Container Management