0% found this document useful (0 votes)
2K views258 pages

Practical Guide To SAP Transportation Management

Uploaded by

wafa ben chalbi
Copyright
© © All Rights Reserved
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as PDF, TXT or read online on Scribd
0% found this document useful (0 votes)
2K views258 pages

Practical Guide To SAP Transportation Management

Uploaded by

wafa ben chalbi
Copyright
© © All Rights Reserved
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as PDF, TXT or read online on Scribd
You are on page 1/ 258

Anette Götz

Tobias Götz

Practical Guide to SAP®


Transportation Management (TM)
ISBN: 978-3-9451-7058-8 (ePUB)
Editor: Alice Adams
Proofreading: Tracey Duffy
Cover Design: Philip Esch, Martin Munzel
Cover Photo: Fotolia: #55817054 © Eisenhans
Interior Design: Johann-Christian Hanke

All rights reserved


1st Edition 2015, Gleichen
© 2015 Espresso Tutorials GmbH
URL: www.espresso-tutorials.com
This work is subject to copyright in its entirety. All rights reserved, especially
the rights of translation, recital, reproduction, and duplication. Espresso
Tutorials GmbH, Zum Gelenberg 11, 37130 Gleichen, Germany
Regardless of the care taken in producing texts and illustrations, the
publisher, the authors, and editors accept no legal liability whatsoever for
possible mistakes and their consequences.
Feedback:
We greatly appreciate any kind of feedback you have concerning this book.
Please mail us at info@espresso-tutorials.com.
Table of Contents
Cover
Title
Copyright / Imprint
Preface
1 End-to-end transportation processes enabled by SAP Transportation
Management, including document flow
1.1 Truck transportation
1.2 Ocean shipping
1.3 Air freight
1.4 Intermodal rail freight
1.5 Courier express parcel shipments
1.6 Conclusion
2 SAP TM solution highlights and best practices
2.1 Creating and managing transportation requirements
2.2 Transportation capacity management
2.3 Manual and automated transportation planning
2.4 Subcontracting and tendering
2.5 Transportation execution and real-time track and trace
2.6 International shipping and customs services
2.7 Dangerous goods handling and 1,000 points rule
2.8 Calculation and settlement of transportation charges
2.9 Summary
3 Key innovations with SAP TM 9.2
3.1 Fleet planning with a Gantt chart
3.2 Container management, planning, and optimization
3.3 Load optimization enhancements
3.4 Collaboration portal
3.5 Strategic freight procurement
3.6 Strategic freight selling
3.7 ERP – TM integration enhancements
3.8 SAP Smart Business and SAP Fiori Apps
3.9 Summary
4 Solution architecture and integration with other SAP components
4.1 System landscape
4.2 HANA-enabled SAP TM
4.3 SAP TM collaboration portal
4.4 Summary
5 Summary
A Authors
B Abbreviations
C Disclaimer
D Endnotes
Preface
In a vivid economy where the supply chain network between continents and
countries is increasingly more tightly woven, transportation becomes more
and more important. It is vital to identify cost-efficient and flexible ways to
manage local and global transportation as political and economic boundaries
melt away due to new free trade zones and the expectation of quick and easy
shipments (e.g., same day delivery). Balancing the rising awareness of
environmentally friendly, low carbon footprint shipments and the increasing
pressure to reduce costs and global competition brings another level of
complexity to the resource and carrier selection process and management of
the complete supply chain.
In order to maintain a competitive advantage, companies need to adapt their
organizational structures, as well as use new capabilities in their IT
environments. SAP Transportation Management (SAP TM) provides a new
generation of software that allows users to manage all of their transportation
requirements on one global platform from end to end. Optimized
transportation plans based on minimal costs, real-time tracking, and seamless
integration with transportation cost settlement in ERP are just a few of the
highlights provided by SAP TM.
The supply chain execution platform provides one solution that meets the
needs of shippers as well as transportation service providers. SAP TM
targets all industries where transportation management plays a major role in
order fulfilment. Today’s main customer base covers logistics service
providers, automotive and industrial machinery, life sciences, oil and gas,
high-tech, consumer products, trade and retail, rail carriers, and the chemical
industry.
This book provides a hands-on guide for users working with SAP
Transportation Management for the first time, in addition to users looking for a
comprehensive overview of all of the processes enabled by SAP
Transportation Management. We wrote this book with consultants as well as
management and decision makers in mind. It provides a high-level overview
based on the L1/L2 processes, as well as L3 and tips on system
configuration.
During the course of the book, we describe every aspect of the transportation
processes enabled by SAP TM and the connecting systems. Starting with the
truck transportation process, we highlight the complete list of actions from
planning to execution and tracking. The ocean shipping process is a
completely different industry and is also described in detail. Like the ocean
process, the air freight process works with schedules but inherits some other
specialties such as the house air waybill (HAWB).
Last but not least, we explain the CEP process in detail and in combination
with all modes of transport (intermodal).
Every section describes the transportation process in a straightforward
manner, in addition to process variants, using step-by-step descriptions.
Following the main transportation processes, we explain the solution highlights
and best practices in detail, e.g., what options are available for integrating
transportation requirements from an ERP system, how to best set up capacity
management functionality in TM, and the options available for performing
manual, semi-automatic, or completely automatic planning (to name just a
few).
In the following chapter, we present the key innovations in SAP TM 9.2,
followed by an overview of the solution architecture in order to provide a full
picture of all options for integrating related systems such as SAP GTS, SAP
EH&S, SAP ERP, and SAP BI.

We have added a few icons to highlight important information. These include:

Tip
Tips highlight information concerning more details about the
subject being described and/or additional background
information.

Example
Examples help illustrate a topic better by relating it to real
world scenarios.

Attention
Attention notices draw attention to information that you should
be aware of when you go through the examples from this
book on your own.

Finally, a note concerning the copyright: All screenshots printed in this book
are the copyright of SAP SE. All rights are reserved by SAP SE. Copyright
pertains to all SAP images in this publication. For simplification, we will not
mention this specifically underneath every screenshot.
1 End-to-end transportation
processes enabled by SAP
Transportation Management,
including document flow
In this chapter, we provide an overview of the transportation processes
supported by SAP Transportation Management (SAP TM). We cover all
of the main transportation modes and provide business scenario
samples for both shippers and logistics service providers.

1.1 Truck transportation


In this section, we outline the process of how a company can best leverage
SAP TM to organize and manage its distribution of goods to customers and
other receiving parties via truck transportation. After receiving several sales
orders, the company’s transportation planner uses the SAP TM optimization
engine to create a transportation plan. Taking preferences, costs, and
constraints into account, the optimizer proposes how best to consolidate,
route, and schedule the transports and which carriers to assign. The tendering
process then starts: this sends quotation requests to preferred carriers but
also features broadcast and direct tenders. The logistics execution process is
triggered by SAP TM, as it sends proposals on how to create outbound
deliveries to SAP ERP. The timely loading and physical movements of the
trucks are then tracked in the SAP Event Management (SAP EM) component.
Transportation charges are then calculated and costs are distributed by SAP
TM and sent to SAP ERP for settlement. Invoice verification and release of
cost distribution to accounting conclude this process.
The main process steps are illustrated in Figure 1.1.
Figure 1.1: Outbound truck transportation process

1.1.1 Step-by-step truck transportation process description

Create sales orders


The sales assistant receives customer requests for goods and creates sales
orders in SAP ERP. In this example, four sales orders are posted for four
different customers.
Figure 1.2: Create sales orders with transaction VA01

Create order-based transportation requirements (OTRs)


After the sales orders have been created in SAP ERP, they are automatically
transferred to SAP TM and order-based transportation requirements (OTRs)
are automatically created at the same time. One OTR represents the
transportation demand from one sales order. An OTR document is shown in
Figure 1.3.
Figure 1.3: Display order-based transportation requirement

For details on integrating SAP ERP documents with SAP TM and creating and
managing transportation requirements, please refer to Section 2.1.

Create freight units


After the transportation requirements have been created in SAP TM, freight
unit building is triggered automatically. A freight unit (FU) represents a set of
goods that is transported together through the entire transportation chain. The
freight unit building rule defines whether and how to consolidate or split SAP
ERP sales order items into freight units. In this example process, one freight
unit is created per transportation requirement, as none of the transportation
requirements’ freight exceeds the split quantity of maximum 15,000 lb. or 550
ft³. Details on freight units and freight unit building can be found in Section
2.3.1.

Perform planning
When the cut-off time is reached, the transportation planner enters the
transportation cockpit, which is the central planning user interface of SAP TM
(see Figure 1.4). The unplanned freight units are shown in the top left of the
screenshot.

Figure 1.4: Transportation cockpit with unplanned freight units

The transportation planner starts SAP TM’s optimization engine. During


optimization, the aim is to determine the overall cost-optimal solution for
shipping the freight units while considering all available constraints, such as
requested delivery dates. Furthermore, carrier selection is completed during
the optimization run. Planning results in optimized freight orders with a ranking
list of available carriers. A freight order (FO) is SAP TM’s order document. It
contains the plan for the logistics processing (e.g., what freight units will be
loaded on which vehicle, pick-up and drop-off locations of the tour, and
planned departure times).
In this example, three freight units are consolidated into one freight order for a
full truckload (FTL) tour covering three customer locations. The fourth freight
unit will be shipped in a less than truckload (LTL) freight order. The newly
created freight orders are displayed in the transportation cockpit for the
planner to examine and manually adjust if desired (see Figure 1.5).
Figure 1.5: Newly created freight orders

The mechanism for deciding whether or not and how to consolidate freight
units into freight orders can be configured with the help of comprehensive
planning cost settings that are considered by the optimizer. For details
regarding SAP TM’s planning capabilities, please see Section 2.3.
Figure 1.6 shows the freight order document for the full truckload shipment.
The stop sequence is displayed on the upper part of the screen. The truck
utilization per stage is visualized via a bar chart.

Figure 1.6: Freight order document for FTL

Tender freight and assign carrier


As mentioned, as a result of the optimization run a carrier ranking list is
created for each freight order (see Figure 1.7).
Figure 1.7: Carrier ranking list for FTL freight order

In this case, two carriers have a freight agreement with the shipper that is
relevant for this transportation lane and the carriers are ranked according to
their transportation charges. Very detailed costs can be calculated using SAP
TM’s transportation charge management component by taking numerous
different charge types into consideration, such as charges for distance,
weight, and surcharges for fuel and stop-offs. In addition to costs, the carrier
ranking can be based on further parameters such as allocations, business
shares, and a bonus-malus system.
After all of the available carriers have been assembled and ranked a
tendering process starts. Figure 1.8 shows the multi-step tendering process
for the FTL freight order. In the first step, a peer-to-peer tender is executed,
subsequently contacting two carriers and requiring a response within a
defined time frame if the carrier would like to be subcontracted. In the event
that no carrier is awarded the assignment in the first step, a broadcast tender
is started. In this situation, requests for quotation (RFQs) are sent out to
multiple carriers simultaneously.
Figure 1.8: Tendering plan for FTL freight order

The carrier’s contact person is notified via e-mail and can accept or reject the
request for quotation in SAP TM’s collaboration portal (see Figure 1.9).

Figure 1.9: Freight request for quotation in SAP TM collaboration portal

For the LTL freight order, a direct tendering process is triggered. In this
example, the process is configured in such a way that no response is required
by the carrier. The carrier will automatically be awarded the assignment if
they do not reject it within a defined time frame. Another option would be to
ask the carrier to quote a price before accepting the tender.
The tendering manager uses a set of configurable WORKLISTS to regularly track
and follow up on the open tenders (see Figure 1.10).
Figure 1.10: Worklists for tracking and managing tenders

After the preferred carrier has accepted the request for quotation for the FTL
freight order, the tendering manager awards him the quotation. The carrier is
again informed via e-mail and on the collaboration portal.
Further information on carrier selection, tendering options, and the
collaboration portal are provided in Section 2.4.

Create delivery proposals


As soon as all tendering processes are completed and the freight orders are
ready for execution, SAP TM creates delivery proposals based on its
transportation planning results (see Figure 1.11).

Figure 1.11: Delivery proposals

The delivery proposals are sent to SAP ERP to trigger the automatic creation
of outbound deliveries. In this example, one outbound delivery has been
created for each freight unit (see Figure 1.12). Rules for the relationship
between the freight unit and delivery to be created can be configured via
delivery profiles in SAP TM.

Figure 1.12: Outbound delivery in SAP ERP

Next, SAP ERP deliveries are transferred to SAP TM to communicate


possible discrepancies in actual delivery creation and to use the delivery as
the relevant SAP ERP base document from this point on. For each SAP ERP
delivery a delivery-based transportation requirement (DTR) is created in SAP
TM (see Figure 1.13).
Figure 1.13: Delivery-based transportation requirement

Furthermore, freight units are automatically reassigned from the order-based


transportation requirement to the delivery-based transportation requirement,
as this document now contains the most current information on the
transportation demand. The DOCUMENT FLOW for all relevant business documents
is adjusted accordingly (see Figure 1.14).
Figure 1.14: Document flow after creation of delivery-based transportation requirements

For details on delivery-based transportation requirements and all of the


required follow-up actions, please refer to Section 2.1.1.

Optional: Create SAP ERP shipments


Shippers who have implemented complex business logic in their ERP shipment
document (e.g., for shipping notifications, printing, or packing) can optionally
still create shipments in SAP ERP based on the freight orders in SAP TM.
Freight orders are transferred from SAP TM to SAP ERP, where the
respective shipment documents are created automatically (see Figure 1.15).
This process step is also advisable if you would like to use SAP TM’s planning
or tendering capabilities but would like to retain your existing charge
calculation logic in SAP ERP.
Figure 1.15: Trigger shipment creation in SAP TM

All relevant transportation information for the SAP ERP shipment, such as the
forwarding agent, stages, and deadlines, is taken from the freight order in
SAP TM (see Figure 1.16).
Figure 1.16: SAP ERP shipment

Monitor transport execution


The physical execution of the transports can be tracked and traced in real
time in the SAP Event Management (SAP EM) component of SAP TM. For
every freight order and freight unit a set of events is expected, such as
loading begin and end, or departure and arrival at locations. Actual events can
be sent via EDI, or entered on the collaboration portal or SAP EM web
interface, which can be accessed via several devices, for example, on-board
devices in the truck. Figure 1.17 shows the statuses and events of the FTL
freight order. While the truck was loaded on time and departed on time, there
is a delay due to a traffic jam during its transit to the first customer location. In
the case of delays or other unexpected events, such as damage to a freight
unit, you can notify relevant users or trigger automatic follow-up actions such
as replanning in SAP TM.

Figure 1.17: Expected events and events that have occurred for the FTL freight order

Further information on tracking and tracing is provided in Section 2.5.

Create settlement documents


On completion of the freight orders, freight settlement documents (FSDs) are
created based on the previously calculated charges. A freight settlement
document is used to transmit the results of SAP TM’s charge calculation and
cost distribution to SAP ERP for further settlement. It contains all invoicing-
relevant information and can be considered a draft invoice. Freight settlement
documents can be generated interactively by the user or via scheduled
background reports for mass processing.
Based on existing freight agreements and rate tables, charges have been
calculated for each freight order. Figure 1.18 shows the charges that were
calculated for the FTL freight order, as well as the different charge types that
were included in the calculation.

Figure 1.18: Overview of charges in the freight order document

The total charges for the freight order are distributed to the individual items it
contains. Different apportionment rules can be applied; e.g., based on the
weight of each cargo item. The percentage and total amounts of the
distributed costs, as well as their allocation to SAP ERP items, are displayed
in the freight settlement document (see Figure 1.19).
Figure 1.19: Freight settlement document

Create purchase orders


Once a freight settlement document has been transferred to SAP ERP, the
following documents are created automatically in SAP ERP based on the
charge information transmitted from SAP TM:

A purchase order for the transportation services (see Figure 1.20)


The service entry sheet to enable posting of accruals and invoice
verification (see Figure 1.21)
An agency business document to post the freight cost of a sales order
item to a general ledger expense account
Figure 1.20: Purchase order in SAP ERP

Figure 1.21: Service entry sheet in SAP ERP

Perform invoice verification


After receiving the carrier’s invoice, the accounting clerk posts an invoice for
the transportation service provided in SAP ERP with reference to the
corresponding freight order (see Figure 1.22). Thanks to the reference the
accounting clerk is able to verify the invoiced amount.

Figure 1.22: Post carrier invoice

In SAP TM, the freight order’s invoice status is updated and the invoice is
added to the DOCUMENT FLOW as a successor business document (see Figure
1.23).
Figure 1.23: Updated document flow for a freight order in SAP TM

Release cost distribution


In SAP ERP, the distributed costs are released to accounting and are used
for SAP ERP Controlling and Profitability Analysis (SAP ERP CO-PA) . As
you can include any transport-related charges in your sales order profitability
analysis, this enables better visibility regarding actual profitability.
Figure 1.24 shows the agency business document which includes a reference
to the original sales order, service purchasing order, freight settlement
document, and freight order. The corresponding cost collector is also visible in
the form of the sales order items.
Figure 1.24: Agency business document

When the agency business document is released the following documents are
created:

An accounting document
A controlling document
Profitability analyses

Figure 1.25: Documents in accounting

Further information on cost distribution is provided in Section 2.8.3.


1.1.2 Process variants
This process is described from the perspective of a shipper, but could of
course be adapted to suit a logistics service provider. The process would then
not start in SAP ERP, but directly in SAP TM with the creation of a forwarding
order. Details on this process step are provided in Section 2.1.2.

1.2 Ocean shipping


Using an example this process describes how a company shipping full
containers overseas can leverage SAP TM to plan and manage their
transportation chain from end to end. To reserve cargo space on ocean
vessels, the company’s transportation planner creates a forecast of future
transportation requirements and sends respective bookings to the ocean
carrier. On receipt of sales orders, the transportation planner uses SAP TM’s
transportation proposals functionality to determine the best routing and
scheduling option. The freight units’ main leg is assigned to the previously
created ocean freight booking. Subsequently, cost-optimal freight orders for
pre-carriage and on-carriage are created by SAP TM’s optimization engine,
assuring timely delivery and pick-up at the ports and selection of the best
carrier. When the bookings are ready for execution, delivery creation is
triggered by SAP TM and picking and packing is initiated. Shipping
instructions are sent to the ocean carrier. The containers’ physical movements
are tracked and traced in SAP Event Management until final arrival at the
customer location.
The main process steps are illustrated in Figure 1.26.
Figure 1.26: Outbound ocean freight process

1.2.1 Ocean shipping step-by-step process description

Create capacity forecast


The transportation planner creates a long-term forecast of future
transportation requirements. For this purpose he creates a transportation
allocation and maintains the number of required twenty-foot equivalent units
(TEUs) for the respective trade lane, carrier, and time period (see Figure
1.27). Alternatively, he could leverage SAP TM’s Strategic Freight
Procurement component which we explain in Section 2.2.1.

Figure 1.27: Transportation allocation

When the forecast is complete, the transportation planner downloads it and


sends it to the ocean carrier via e-mail.

Create ocean freight booking


In order to bindingly book container capacity on an ocean vessel, the
transportation planner creates an ocean freight booking for the corresponding
port-to-port connection and a specific sailing date (see Figure 1.28).
Figure 1.28: Locations and dates of the ocean freight booking

The port sequence, respective dates, and utilization are displayed on the
OVERVIEW tab of the ocean freight booking. The requested capacity and
equipment are maintained in the lower screen area. In this example, the
planner reserved two 40 ft. containers (see Figure 1.29).
Figure 1.29: Overview of the ocean freight booking

When all relevant information has been maintained, the planner sends the
booking to the carrier electronically. The carrier’s reply can be received
electronically or updated manually in the booking. The confirmation includes
additional information from the carrier such as exact sailing and cut-off dates,
voyage and vessel information, and the confirmed container count. The
confirmation status is adjusted and the transportation allocation is updated
accordingly, now indicating that 4 of the reserved 100 twenty-equivalent units
(TEUs) have been utilized (see Figure 1.30).
Figure 1.30: Updated transportation allocation

Create sales order


The sales assistant receives a request for goods from a customer in Paris,
France, and creates a sales order in SAP ERP (see Figure 1.31). The cargo
will be collected from the plant in Palo Alto, USA.
Figure 1.31: Sales order in SAP ERP

Create order-based transportation requirement (OTR)


After the sales order has been created in SAP ERP it is automatically
transferred to SAP TM and an order-based transportation requirement (OTR)
is created. One OTR represents the transportation demand from one sales
order. All data that is relevant for the transportation process is transferred
from SAP ERP to SAP TM. Figure 1.32 shows the DOCUMENT FLOW of the new
order-based transportation requirement. Two freight units were created as
successor business documents as we will see in the next process step.
Figure 1.32: Order-based transportation requirement

For details on integrating SAP ERP documents with SAP TM and the creation
and management of transportation requirements, please refer to Section 2.1.

Create freight units


After the transportation requirement has been created freight unit building is
triggered automatically. A freight unit (FU) represents a set of goods that is
transported together through the entire transportation chain. The freight unit
building rule defines whether and how to consolidate or split SAP ERP sales
order items into freight units. In this exemplary process, two freight units were
created as the sales order item’s gross weight of 60,000 lb. exceeds the
defined split quantity of 35,000 lb. Both freight units are automatically packed
into a 40 ft. container (see Figure 1.33).
Figure 1.33: Freight units

Details on freight units and freight unit building can be found in Section 2.3.1.

Determine routing
As we have seen in the previous process steps, the cargo needs to be
shipped from a plant in Palo Alto, USA, to a customer in Paris, France. The
transportation planner now enters the transportation cockpit, SAP TM’s
central planning user interface, in order to determine the best routing and
relevant ports.
In Figure 1.34 you can see the two as yet unplanned freight units in the
transportation cockpit. Each freight unit consists of one stage directly
connecting the Palo Alto location to the one in Paris.
Figure 1.34: Freight units before routing determination

The transportation planner starts the transportation proposals functionality to


let the system generate possible options for routing and scheduling. Taking
the whole transportation network and all relevant planning constraints into
account, SAP TM also incorporates planning costs in order to rate and rank
the proposals. The resulting list of different routing and scheduling options is
displayed in Figure 1.35.

Figure 1.35: Transportation proposals

The transportation planner chooses the first proposal, which routes the cargo
via the ports of Oakland and Rotterdam. Both freight units are updated
accordingly, splitting the direct stage from Palo Alto to Paris into three stages
for pre-carriage, main carriage, and on-carriage (see Figure 1.36).
Figure 1.36: Routing information updated in freight units

For further information on transportation proposals, please refer to Section


2.3.4.

Perform planning
After the planner has decided on the route he looks for an appropriate ocean
freight booking to use for the main leg. In the transportation cockpit he
manually assigns the second stage of the freight units to the booking (see
Figure 1.37).

Figure 1.37: Assign freight units to ocean freight booking

The system automatically allocates the freight units to a container capacity


reservation in the booking. The booking’s current utilization and total container
count are updated accordingly (see Figure 1.38).
Figure 1.38: Updated ocean freight booking after planning

After the main carriage has been planned and hence cut-off times for pick-up
and delivery at the ports have been scheduled, the pre-carriage and on-
carriage can be considered. The transportation planner responsible for truck
transportation in California handles the pre-carriage and a planner for central
Europe’s planning division takes care of the on-carriage respectively. In the
transportation cockpit, they use SAP TM’s optimization engine to create cost-
optimal freight orders that ensure timely delivery and pick-up of the cargo at
the ports and assign the best carrier. A freight order (FO) is SAP TM’s order
document: it contains the plan for the logistics processing (e.g., what freight
units should be loaded on which vehicle, pick-up and drop-off locations of the
tour, and planned departure times). The optimizer also selects and assigns a
carrier. Figure 1.39 shows the new freight orders created by the optimizer.
Figure 1.39: Freight orders for pre- and on-carriage

For further details regarding SAP TM’s planning capabilities, please see
Section 2.3.

Organize container provisioning


To transport goods from the shipper’s plant to the customer, the shipper
needs empty sea containers that have to be transported from a storage
location to the plant by truck. The planner creates a forwarding order to
represent the transportation demand for the container provisioning (see Figure
1.40). A forwarding order (FWO) represents a transportation requirement
that does not originate from an SAP ERP predecessor document.
Figure 1.40: Forwarding order for container pick-up

The system automatically creates a freight order for this container transport in
the background. The freight order is used for tracking and tracing, document
printing, and further activities for transportation execution.
Further information on forwarding orders is provided in Section 2.1.2.

Create delivery proposals


As soon as the freight orders are ready for execution, SAP TM creates
delivery proposals based on its transportation planning results (see Figure
1.41).
Figure 1.41: Delivery proposals

The delivery proposals are sent to SAP ERP to trigger the automatic creation
of outbound deliveries. Subsequently, SAP ERP deliveries are transferred to
SAP TM to communicate possible discrepancies in actual delivery creation
and to use the delivery as the relevant SAP ERP base document from this
point on. For each SAP ERP delivery, a delivery-based transportation
requirement (DTR) is created in SAP TM.
In addition, freight units are automatically reassigned from the order-based to
the delivery-based transportation requirement, as this document now contains
more precise information on the transportation demand. The DOCUMENT FLOW of
all relevant business documents is adjusted accordingly (see Figure 1.42).
Figure 1.42: Updated document flow for the ocean freight booking

For details on delivery-based transportation requirements and all follow-up


actions involved, please refer to Section 2.1.1.

Send shipping instructions


Shipping instructions are sent to the ocean carrier. After receiving the shipping
instructions the ocean carrier sends the bill of lading (BOL) back to the
shipper by e-mail. The bill of lading is added manually as an attachment to the
freight booking (see Figure 1.43).
Figure 1.43: Bill of lading attached to ocean freight booking

Both the shipping instructions’ due date and the receipt of the bill of lading are
tracked and displayed on the booking’s EXECUTION tab (see Figure 1.44).

Figure 1.44: Actual event for bill of lading

Monitor transport execution


The physical execution of the transports can be tracked and traced in real
time in the SAP Event Management (SAP EM) component. For every freight
booking, freight order, and freight unit a set of events is expected, such as
loading begin and end, or departure and arrival at locations. Actual events can
be sent via EDI or entered on the SAP EM web interface which can be
accessed via several devices, for example, on-board devices in the truck.
When the empty container arrives at the shipper’s plant, the containers’ IDs
can be maintained in the freight booking document to enable further tracking
and tracing also based on this number.
Figure 1.45 shows the statuses and events of one freight unit representing a
physical container. The vessel departed from the port of Oakland and is now
on its voyage to Rotterdam. In the case of delays or other unexpected events,
such as damage to a freight unit, you can notify relevant users or trigger
automatic follow-up actions such as replanning in SAP TM.
Figure 1.45: Container tracking

Further information on tracking and tracing is provided in Section 2.5.

1.2.2 Process variants


This process is described from the perspective of a shipper, but could be
adjusted to suit a logistics service provider. Furthermore, the process
described is simplified and does not cover some ocean freight specifics such
as container freight stations. An example for a logistics service provider’s
scenario is given in the next section on air freight forwarding (see Section
1.3).
This process could naturally also be extended to include charge calculation,
charge settlement, and cost distribution. Analogical to the previously
described truck transportation process, charges would be calculated per
freight order and freight booking and costs distributed over cargo items. Via
freight settlement documents, the results of the charge calculation and cost
distribution would be transferred to SAP ERP, creating purchase orders,
service entry sheets, and agency business documents. Lastly, costs would be
released to accounting and used for profitability analyses in SAP ERP
Controlling and Profitability Analysis (SAP ERP CO-PA). For details on these
process steps, please refer to Section 1.1.
If you prefer to outsource the detailed planning, organization, and execution of
your shipments to freight forwarders, you can skip the routing and planning
steps. Instead, you can just send a booking with a door-to-door service level
asking the freight forwarder to organize the entire transport.
In addition to outbound processes you could of course also manage inbound
processes with SAP TM. Instead of a sales order, the transportation
requirement would originate from an SAP ERP purchase order. The receipt of
an advanced shipping notification (ASN) from the vendor would trigger the
creation of an inbound delivery. Finally, the results of the cost distribution
would be used for material valuation in SAP ERP Materials Management
(SAP ERP MM).

1.3 Air freight


As of SAP TM 9.0, comprehensive functionality is provided to meet air freight-
specific requirements such as capacity allocation, master air waybill stocks,
air cargo equipment, and International Air Transport Association (IATA)
settlement.
The process in this section outlines how a freight forwarding company can
leverage SAP TM to plan and manage air freight shipments within a complex
transportation chain from one end to the other. The freight forwarder needs to
organize several shipments from different customers in Japan to a set of
consignees in the United States. After booking cargo space on a suitable
flight, the freight forwarder arranges for pick-up at the shippers’ sites and
consolidated pre-carriage from its forwarding houses to the export gateway
at Narita International Airport. At the gateway the shipments are consolidated
into air cargo equipment, the master air waybill is closed, and the cargo is fed
to the airline’s ground handling station. The airline sends automatic updates
regarding physical departure and arrival of the plane at Los Angeles
International Airport. All relevant data is handed over to the freight forwarder’s
import organization so that they can prepare for the cargo’s arrival,
deconsolidation, import handling, and customs clearance. Subsequently,
shipments are transported to the freight forwarder’s forwarding houses, from
where consolidated tours deliver the goods to their final consignees. Financial
settlement with all carriers and customers involved concludes the process.
The main process steps are illustrated in Figure 1.46.
Figure 1.46: Air freight process

1.3.1 Step-by-step process description

Create master flight plan


Several months in advance the freight forwarder’s capacity manager creates
a master flight plan for its Japan-U.S. connection. It contains specific flights
for a certain period of time, for example one year, planned capacity
allocations, and further details such as corresponding gateways and cut-off
times (see Figure 1.47). The master flight plan is based on an air carrier’s
flight plan, in this example for Japan Airlines connecting Narita International
Airport in Japan and Los Angeles International Airport in the United States.
Schedules can be uploaded automatically so that manual steps are not
required for creating and maintaining the master data.
Figure 1.47: Master flight schedule

Create operational flight plan and bookings


Based on the master flight plan, an operational flight plan is extracted
automatically for a shorter period of time, e.g., four weeks. It consists of air
freight bookings for the scheduled flights which are automatically sent to the
carrier for confirmation. Figure 1.48 shows an air freight booking document
for reserving 20 m³ and 7 t on flight JL 062.
Figure 1.48: Air freight booking document

For further information on schedules and freight bookings, please refer to


Section 2.2.

Create forwarding orders and freight units


Requests for transportation services can be communicated to freight
forwarders in multiple forms, e.g., via EDI, booking services, and portals or
by mail, fax, and phone. The relevant data is stored in the forwarding order
document (FWO). In our example, the customer service agent has received
requests from various shippers in Nagoya and Tokyo, Japan, to ship cargo to
consignees in Phoenix and San Diego, United States, and manually creates
forwarding orders with detailed information regarding service level and cargo
(see Figure 1.49).
Figure 1.49: Air freight forwarding order document

After forwarding orders have been created, freight unit building is triggered
automatically. A freight unit (FU) represents a set of goods that is
transported together through the entire transportation chain. The freight unit
building rule defines whether and how to consolidate or split forwarding order
items into freight units.
Details on creating and managing forwarding orders are provided in Section
2.1. Freight unit and freight unit building related information can be found in
Section 2.3.1.

Determine routing and plan main carriage


The transportation planner starts the transportation proposals functionality to
let the system generate possible options for routing and scheduling. Taking
the whole transportation network and all relevant planning constraints into
account, SAP TM also incorporates planning costs in order to rate and rank
the proposals. The resulting list of different routing and scheduling options is
shown in Figure 1.50.

Figure 1.50: Determine routing via transportation proposals

The transportation planner chooses the first proposal, which routes the cargo
via Narita and Los Angeles airports and their corresponding gateway stations.
The forwarding orders are updated accordingly. The ACTUAL ROUTE is split into
five stages for pick-up, pre-carriage, main carriage, on-carriage, and delivery
(see Figure 1.51).
Figure 1.51: Stages of the forwarding order after route determination

The forwarding orders’ main carriage is assigned to the booking in order to


reserve the necessary capacity on the respective flight. Figure 1.52 shows
the updated capacity and cargo information of the booking after the
assignment of four forwarding orders. The ACTUAL UTILIZATION has gone beyond
100%, causing the capacity manager to extend the reserved capacity with the
airline.
Figure 1.52: Capacity and cargo information after planning main carriage

Afterwards, house air waybill (HAWB) numbers are drawn for the forwarding
orders and HAWB labels are generated for attachment to the cargo later on.

Plan and execute pick-up


Once the gateway has confirmed the main carriage stage, pick-up of the
cargo can be arranged. The forwarding house creates freight orders (see
Figure 1.53), prints necessary documents such as the road waybill, and
sends them to their local truck carrier. The carrier collects the cargo from the
shippers’ sites and transports it to the origin station.
Figure 1.53: Freight order document for pick-up

Plan and execute pre-carriage


On arrival at the forwarding house, the goods are checked, possible
discrepancies resolved, and outbound customs cleared. Afterwards, the pre-
carriage is planned using SAP TM’s transportation cockpit (see Figure 1.54).
The freight units to be planned are displayed in the upper screen area and
can be assigned to road carrier schedules (bottom left screen area) which
operate daily between the origin stations and their corresponding gateways.
The resulting freight orders (bottom right) consolidate the individual freight
units onto long-haul trucks.
Figure 1.54: Transportation cockpit for planning pre-carriage

The physical execution is monitored and repeatedly updated at different


locations along the transportation chain using SAP Event Management (SAP
EM). Status updates can be received automatically from carriers via
electronic data interchange or can be set manually in the SAP EM web user
interface.

Perform load planning


After arriving at the export gateway, the shipments are usually consolidated
into air cargo equipment such as unit load devices (ULDs) or air cargo
pallets. The freight booking is updated with the respective ULD information,
packing hierarchies, and actual weight and volumes.

Close master air waybill and arrange uplift


When loading is completed the master air waybill can be closed and final
booking confirmation, as well as shipping instructions, can be sent. Required
documents such as master air waybill labels (see Figure 1.55) are generated,
printed, and attached to the cargo.
Figure 1.55: Master air waybill label

A freight order is created for the uplift to the airline’s ground handling station
(see Figure 1.56).
Figure 1.56: Items of the freight order for uplift

Execute main carriage


The airline confirms the departure of the plane electronically. Once the goods
have arrived at the gateway in Los Angeles, the execution status of the main
carriage is set to COMPLETED.

Import handover and cargo handling


After closure of the master air waybill, all corresponding data is handed over
to the import organization so that they can prepare for the cargo’s arrival,
deconsolidation, import handling, and customs clearance.

Plan and execute on-carriage


The import gateway reconsolidates the shipments onto long-haul trucks to the
import stations in San Diego or Phoenix. Similarly to the pre-carriage planning,
transport is arranged using a road schedule that connects the gateway to the
respective forwarding house.

Plan and execute delivery


Delivery can be planned via SAP TM’s optimization engine which creates
consolidated tours to deliver the individual shipments to the final consignees.
The freight orders are then subcontracted to and executed by local trucking
companies. Proof of delivery is posted via SAP Event Management and
marks the end of the operational process.

Create settlement documents, carrier settlement, and customer billing


Either during the operational process or when it is complete, the following
financial processes still have to be executed:

Carrier settlement
For settlement with the various carriers involved (local truck carriers for
pick-up, pre-carriage, airline feeding, airline defeeding, on-carriage, and
delivery and the airline for the main carriage), charges are calculated
based on contract rates and freight settlement documents are created in
SAP TM and transferred to SAP ERP for accruals, invoice verification,
and payment. Settlement with the airline is usually processed via the
Cargo Accounts Settlement System (CASS) for the International Air
Transport Association (IATA).
Customer billing
For customer billing, transportation charges are calculated in the
forwarding order; a forwarding settlement document is created and sent
to SAP ERP for billing in the Sales and Distribution (SD) component.
Internal settlement
For internal settlement between the freight forwarder’s different
organizational units, an internal settlement document is created and
costs are allocated respectively.
Profitability calculation
The total profitability of each individual shipment can finally be calculated,
with all relevant costs and revenue information taken into account.

For further information on charge calculation and settlement, please refer to


Section 2.8.

1.4 Intermodal rail freight


This process outlines how a rail freight forwarding company can leverage SAP
TM to plan and manage intermodal rail shipments.
In this scenario, a 20-foot container is handed to a rail freight forwarder at the
container terminal in Halifax, Canada. The container, which contains
dangerous goods, needs to be transported to a container yard in Houston,
USA. As the default route is subject to heavy congestion, the transportation
planner selects an alternative route via Chicago, USA. The planner uses SAP
TM’s transportation cockpit to assign the container to physical railcars and to
select scheduled trains to take the railcar via Toronto, Canada, to Chicago,
USA. Since the connecting trains in Chicago use a different rail terminal, the
planner arranges for cross-town truck transport in Chicago, which he
subcontracts to a local trucking company. The cargo is loaded onto another
scheduled train which delivers it to its final destination in Houston, Texas. The
container’s current location and status is tracked and traced along its multi-leg
journey in SAP Event Management. On receipt of proof of delivery, charges
are calculated and freight settlement documents are sent to SAP ERP. In
SAP ERP an invoice is created for customer billing. Furthermore, service
purchase orders and corresponding service entry sheets are created to
enable invoice verification for the subcontracted carriers.
The main process steps are illustrated in Figure 1.57.

Figure 1.57: Intermodal rail freight process

1.4.1 Intermodal rail freight step-by-step process description


Create forwarding order and freight unit
Requests for transportation services can be communicated to freight
forwarders in multiple forms, e.g., via EDI, booking services, and portals or
by mail, fax, and phone. In our example, the customer service agent has
received a request to transport a 20-foot container from the container terminal
in Halifax, Canada, to Houston, USA. The customer service agent manually
creates a forwarding order with detailed information regarding service level,
movement type, and cargo (see Figure 1.58).

Figure 1.58: Rail forwarding order

When the forwarding order is saved, a freight unit, which represents the
container, is created automatically.

Check default routing


In rail transportation, it is common business practice for contracts between
rail carriers and shippers to contain a default route. This default route is called
the ORDERED ROUTE. Generally, the carrier can take a route that deviates from
the ordered route. The ordered route, however, will be the basis for charge
calculation.
The transportation planner checks the default routing that was automatically
applied to the forwarding order based on the forwarding agreement. The
ordered route contains three stages routing the cargo from Halifax via
Concord and Oklahoma City to its destination in Houston (see Figure 1.59).

Figure 1.59: Forwarding order’s default routing

In SAP TM, a default route is basically a location sequence defining the


default routing between a source location and a destination location. Figure
1.60 shows the default route for connecting the cities of Halifax and Houston.
For the source and destination location of a default route you can also define
a transportation zone in order to minimize the effort required for master data
maintenance. The default route can be assigned to a forwarding agreement
which represents the contract between carrier and shipper.
Figure 1.60: Default route

The transportation planner decides to adjust the initial routing since congestion
on the default route is heavy. Routing the cargo via Chicago seems to make
more sense. The planner inserts another stage which is required for a cross-
town truck transport through Chicago as the connecting trains use different
train terminals. The adjusted routing is displayed as the ACTUAL ROUTE on the
forwarding order’s STAGES tab (see Figure 1.62).
Figure 1.61: Stages after adjusting the route

You can also leverage SAP TM’s map functionality to illustrate the new route
on a geographical map (see Figure 1.62).
Figure 1.62: Map display of the forwarding order’s route

Assign freight unit to railcars


After the routing is adjusted, the planner enters the transportation cockpit and
assigns freight unit stages to a railcar resource. The resulting document is a
railcar unit which represents a physical railcar including a certain set of cargo.
The three objects that are relevant for this first planning step are shown in
Figure 1.63.
Figure 1.63: Assign freight units to railcars

Figure 1.64 depicts the transportation cockpit with a rail-specific layout. In the
top left screen area the freight unit stages to be planned are displayed.
Available railcars are listed on the top right. In SAP TM railcars are
maintained as passive resources with assigned capacities (e.g., 4 TEU, 80
TO, and 82 FT maximum length). Planned railcar units are displayed in the
bottom screen area.

Figure 1.64: Transportation cockpit for building railcar units

When you drag and drop a freight unit stage to a railcar a railcar unit is
created. A railcar unit combines both resource-relevant and cargo-relevant
information. The railcar unit document is shown in Figure 1.65.
Figure 1.65: Railcar unit document

On the CARGO tab, you can find product information as well as data concerning
the equipment and resources used. Our shipment contains 40 canisters of
aluminum phosphide which are packed onto 4 pallets. The pallets are packed
onto a 20-foot container which is again loaded onto the railcar (see Figure
1.66).
Figure 1.66: Cargo information for the railcar unit

If you would like to skip the separate assignment of freight units to railcars,
you can alternatively configure your freight unit building rule in such a way that
the railcar unit is the direct successor document of the forwarding order. This
is especially advisable in transportation scenarios where you use the rail
mode of transport exclusively and where you handle full railcar loads.
If the exact railcar resource is maintained in SAP ERP or SAP EWM and
transferred to SAP TM, this resource is automatically assigned to the railcar
unit.

Assign railcars to scheduled trains


In a second step, the transportation planner has to assign the loaded railcar
unit to a train in order to create a rail freight order. A rail freight order is the
shipment document that can be subcontracted to a carrier.
To create a rail freight order, the planner can assign loaded railcar units to a
locomotive that is maintained as an active resource in SAP TM. Alternatively,
the railcar units can be assigned to a rail carrier schedule. A rail carrier
schedule represents a train that is operated by a rail carrier on a regular
basis. The four relevant objects for this second planning step are illustrated in
Figure 1.67.
Figure 1.67: Assign railcar units to locomotive or scheduled train

In this scenario the planner wants to assign the railcar unit to a scheduled
train. For details on schedules, please refer to Section 2.2.2. The planner
uses the transportation cockpit to search for suitable trains. The railcar units
to be planned are shown in the top left screen area of Figure 1.68. Available
scheduled trains are listed on the top right. The planner drags and drops each
railcar unit to a train schedule, whereupon the system creates corresponding
rail freight orders (see bottom left screen area). If you select a rail freight
order, further details are displayed in the bottom right screen area. In Figure
1.68 the train’s route is displayed on the map.
Figure 1.68: Transportation cockpit for planning rail freight orders

The planned freight orders are displayed in a hierarchy so that you can see
the stop sequence as well as which railcars are to be coupled and uncoupled
at which locations (see Figure 1.69).

Figure 1.69: Rail freight order hierarchy

Figure 1.70 shows a rail freight order document. It contains rail-specific


information such as capacity data for the train, e.g., maximum trailing load or
maximum train length. The INVOICING CARRIER LEVEL states whether only one carrier
will be invoicing and if so which one, or whether there are multiple invoicing
carriers.

Figure 1.70: Rail freight order document

The transportation planner selects scheduled trains for the three stages that
will be transported by rail.
For the cross-town transport through Chicago he creates a road freight order
which he subcontracts to a local trucking company. The resulting four freight
order documents are shown in Figure 1.71.

Figure 1.71: Planning result

Monitor transport execution


The physical execution of the shipment is tracked in SAP Event Management.
Subcontracted carriers can send events electronically during shipment
execution. These events enable real-time visibility of each shipment’s current
location and status (see Figure 1.72).

Figure 1.72: Freight order tracking and tracing

The freight order’s status information is automatically propagated to the


loaded freight unit. The freight unit is tracked from end-to-end, starting with
the cargo handover in Halifax up to delivery to the consignee in Houston and
the customer’s proof of delivery (see Figure 1.73).
Figure 1.73: Freight unit tracking and tracing

Create settlement documents


The availability of rail networks means that multiple carriers can be involved
even though the shipper ordered the transportation from one specific carrier.
Generally, there are three different methods for billing:

The through scenario, where all transportation charges are billed by the
ordered carrier (the bill of lading carrier)
According to Rule 11 of the American Railroad Accounting Rules, which
stipulates that all transportation stages are charged separately by the
executing carrier
A combination of the previous two scenarios (some stages are billed by
the bill of lading carrier and some are billed directly by the executing
carrier)

On receipt of proof of delivery, settlement documents are created based on


the calculated transportation charges in SAP TM. A forwarding settlement
document contains charges for customer billing. Freight settlement
documents are created for settling charges with the subcontracted carriers.
All settlement documents are transferred to SAP ERP. In SAP ERP the
following two independent processes are triggered.

Create invoice
Firstly, an invoice is created based on the customer’s forwarding settlement
document.

Create purchase orders and service entry sheets to perform invoice


verification
Secondly, service purchase orders and corresponding service entry sheets
are created for verification of the incoming carriers’ invoices in SAP ERP.

1.5 Courier express parcel shipments


This process supports a company managing parcel shipments using a courier
express parcel (CEP) service provider. The case that serves as the basis for
the detailed scenario is as follows: the sales assistant receives an urgent
request for goods and enters a sales order. Immediately after the material’s
availability has been checked and the sales order has been saved, an
outbound delivery is created. The process in SAP TM follows the standard
document flow for planning and settlement which is explained in the previous
process section. For details, please refer to Section 1.1.
The specifics for the CEP process with TM are:
High level of automation
The process from delivery creation to ready-planned freight order
document requires no manual user interaction. This enables fast order
fulfilment.
Packing and labeling
The packing information, including handling units and assigned CEP
packaging materials, is taken from SAP ERP. During the packing
process, the label of the CEP provider is printed out via SAP TM (based
on the number range that is allotted by the CEP provider for the freight
order ID).

The main process steps are depicted in Figure 1.74.


Figure 1.74: Courier express parcel shipment process

1.5.1 Courier express parcel shipment step-by-step process


description

Create sales order


The sales assistant receives an urgent customer request for ten cartons of
notebooks and creates a sales order in SAP ERP (see Figure 1.75). He
selects a shipping type which indicates that this sales order has to be
delivered by courier express.
Figure 1.75: Sales order with shipping condition CEP

Create outbound delivery


Immediately after the sales order has been entered and the material’s
availability has been checked an outbound delivery is created (see Figure
1.76).
Figure 1.76: Outbound delivery

Handling units are assigned to the delivery and the notebooks are packed into
two boxes (see Figure 1.77).

Figure 1.77: Handling units

Create delivery-based transportation requirement (DTR)


After picking and packing the delivery in ERP (or related WM systems) and
creating the handling unit, including the required transport equipment, all
information is visible in SAP TM via the DTR. The handling unit information as
well as the packing hierarchy is stored on the DTR’s ITEMS tab (see bottom
screen area of Figure 1.78).
Figure 1.78: Delivery-based transportation requirement

Create freight unit with direct shipment options


Freight unit building is automatically triggered. For each freight unit, SAP TM
immediately searches for options for quick delivery. The system automatically
calculates required transit durations and costs for shipping this freight unit
directly. Direct shipment means that the freight unit is transported straight
from its source to its destination location. Transshipment at hubs or
consolidation with other cargo is not taken into consideration as the
shipment’s urgency is given top priority. The calculation of transit durations
and costs is performed for each combination of relevant carrier and service
level. The most cost-effective option is automatically selected from among the
direct shipment options that meet the required pick-up and delivery date.
All direct shipment options, including transit durations and costs, are displayed
on the DIRECT SHIPMENT OPTIONS tab of the freight unit document. This allows the
user to still check and understand the system’s choice. In this example the
overnight service from FedEx is chosen (see Figure 1.79).

Figure 1.79: Direct shipment options for freight unit

Direct shipment options can be configured in the freight unit type customizing
(SAP Customizing Implementation Guide (IMG) menu path: SAP T RANSPORTATION
MANAGEMENT • T RANSPORTATION MANAGEMENT • PLANNING • FREIGHT UNIT • DEFINE FREIGHT UNIT
T YPES, see Figure 1.80). You can define whether direct shipment options
should be determined automatically when a freight unit is created.
Alternatively, they can still be calculated on demand, e.g., when the user
clicks on the relevant button in the freight unit document. In customizing you
can also specify which follow-up actions should be taken. We will take a
closer look at this in the next process step.
Figure 1.80: Direct shipment options customizing

Automatically assign freight unit to freight order


After selecting the best direct shipment option, SAP TM automatically assigns
the freight units to a freight order that meets the requirements in terms of
source location, carrier, and pick-up date. If the system cannot find a suitable
freight order it creates a new one. The bill of lading number (that is, the
shipment number) is drawn automatically from a predefined number range
that was assigned by the CEP service provider. The resulting freight order
with document type CEP is shown in Figure 1.81.

Figure 1.81: Parcel manifest


Send FO to carrier
Up until this point, all planning process steps have been conducted
automatically in SAP TM to enable fast order fulfilment. The resulting freight
order is now sent to the carrier that was picked during direct shipment
determination. Afterwards, the carrier’s confirmation message is received and
the subcontracting status is updated accordingly.

Create road waybill


The road waybill, labels, and further required documentation are generated
and printed. All documents created are stored on the freight order’s OUTPUT
MANAGEMENT tab (see Figure 1.82).

Figure 1.82: Manifest documentation

Monitor transport execution


The physical execution of the shipment can be tracked and traced in SAP
Event Management (SAP EM). Up until the loading and handover to the CEP
carrier, the process can be tracked by the shipper. During shipment
execution, the carrier must send event messages to allow the shipper and his
customers to access real-time status information about their parcels. For
details on SAP EM’s tracking capabilities, please refer to Section 2.5.3.
Create freight settlement document
On completion of the freight order a freight settlement document is created. It
contains all relevant charges, broken down to indicate the specific charges for
each parcel (see Figure 1.83).

Figure 1.83: Freight settlement document

Create purchase order and service entry sheet


Once the freight settlement document has been transferred to SAP ERP, a
service purchase order with an assigned service entry sheet is created to
enable posting of accruals, invoice verification, or self-billing.

Perform invoice verification


After receiving the carrier’s invoice, the accounting clerk posts an invoice for
the transportation service provided in SAP ERP, with reference to the
corresponding freight order. Thanks to the reference the accounting clerk can
verify the invoiced amount. Further information on charge calculation and
settlement is provided in Section 2.8.

1.6 Conclusion
In this chapter, we discussed the ways in which SAP Transportation
Management supports transport by truck, ocean, air, rail, and CEP. We also
discussed the combinations of these modes. A step-by-step process
description detailed each important step in SAP TM, including views of the
system via screenshots. Now we are well prepared to go one step further and
look at the details of SAP TM configuration.
2 SAP TM solution highlights and
best practices
In this chapter, we cover SAP TM’s key solution highlights for end-to-
end transportation management. We start with transportation
requirements and capacity management and then move on to planning
and tendering capabilities. From there, we outline best practices for
tracking and tracing, international shipping, and handling of dangerous
goods. We conclude the chapter with specific information about charge
calculation and settlement.

2.1 Creating and managing transportation requirements


The starting point of every transportation process is a request for
transportation services. In this section, we take a look at the different options
for creating transportation requirements in SAP TM.
Figure 2.1 depicts a simplified version of the general transportation planning
document flow in SAP TM. Each process starts with a transportation
requirement document which contains all relevant information on the
requested transportation services, such as source and destination location,
requested dates and times, business partners involved, cargo to be shipped,
service level, and further terms and conditions. The transportation requirement
is either created based on ERP documents (e.g., sales orders, purchase
orders, or deliveries) or originates from other external sources. From the
transportation requirement, one or multiple freight units are created that each
represent a set of goods, e.g., a container or a pallet. The freight units are
then planned on a freight order or booking, which is SAP TM’s transportation
execution document.

Figure 2.1: Transportation planning document flow1

However, depending on the business scenario, there are different options for
entering transportation requirements in SAP TM. For shippers, logistics
processes are usually not part of their core business and are supporting
processes only. Usually at these companies there is an ERP system in place
that manages their core processes and already possesses information that is
relevant for the transportation process. In this scenario, ERP transmits the
relevant information from an order or delivery document to SAP TM, where a
corresponding order-based transportation requirement (OTR) or delivery-
based transportation requirement (DTR) is created automatically. As the ERP
system is the leading information system, it is not allowed to make changes to
the ERP-based transportation requirements in SAP TM. Updates are
executed in the ERP system and are then instantly synchronized to SAP TM.
For logistics service providers (LSPs) or carriers, transportation services are
part of their core business. Extensive information on the transportation
demand is required and furthermore, there is no ERP system with
predecessor business documents, such as sales orders, in place. Therefore,
the transportation requirement is created directly in SAP TM. This
transportation requirement type is called a forwarding order (FWO) in SAP
TM.
Figure 2.2 summarizes the different document types used in SAP TM to
represent a transportation requirement.

Figure 2.2: Transportation requirement document types


2.1.1 Integrating SAP ERP documents to create transportation
requirements

Integrating SAP ERP orders


SAP TM can integrate the following SAP ERP order documents:

Sales orders (SOs)


Purchase orders (POs)
Stock transfer orders (STOs)

For each order document that is transferred to SAP TM, one order-based
transportation requirement (OTR) is automatically created in SAP TM. The
ERP order items are listed as OTR items. As you can see in Figure 2.3, the
OTR inherits all information from the ERP order that is relevant for the
transportation process, e.g., source and destination location, business
partners involved (such as the customer), transportation dates, and product
information.
Figure 2.3: Order-based transportation requirement document

In the OTR’s DOCUMENT FLOW, the ERP predecessor sales order document is
displayed with a hyperlink to link it directly to the ERP system (see Figure
2.4).
Figure 2.4: Document flow in OTR document

Technically, the communication to SAP TM is triggered via the output


determination in SAP ERP. To integrate sales orders you have to create the
new output type TRS0. Thereafter, you can activate the transfer of sales
orders via the SAP Customizing Implementation Guide (IMG) menu path in
SAP ERP: INTEGRATION WITH OTHER SAP COMPONENTS • T RANSPORTATION MANAGEMENT •
ORDER INTEGRATION • ACTIVATE T RANSFER OF SALES DOCUMENTS.
Sales order integration

Using the following five attributes you can determine which sales orders
should be transferred to SAP TM (see Figure 2.5):

Sales organization
Distribution channel
Division
Sales order type
Shipping condition

Figure 2.5: Activating the transfer of sales orders


For a combination of the above-named attributes, you have to enter a control
key that defines which documents to transfer to SAP TM and whether the
sales order scheduling functionality should be used. The standard control keys
are shown in Figure 2.6.

Figure 2.6: Control keys for integrating SAP ERP documents with transportation requirement documents
in SAP TM

In the output overview of the sales order in SAP ERP, you can check whether
the SAP TM output message has been processed successfully. You can
access it from the sales order document via the menu EXTRAS • OUTPUT • HEADER •
EDIT.
Figure 2.7: Message output in the sales order document

On the TM STATUS tab of the sales order you can see the current process
statuses in SAP TM (see Figure 2.8).

Figure 2.8: SAP TM status information in the sales order document

Via the DOCUMENT FLOW button in the sales order you can identify the successor
business documents in SAP TM, such as the OTR and freight unit ID (see
Figure 2.9).

Figure 2.9: SAP TM document flow in the sales order document


The SAP TM document can be opened and displayed directly by clicking on
the OTR or freight unit ID in the SAP ERP system.
SAP TM offers 51 web service-based interfaces for communication with
external systems, for instance SAP ERP. 2 SAP recommends setting up the
communication of transactional data between SAP ERP and SAP TM via SAP
Process Integration (SAP PI) due to the associated monitoring capabilities.
However, direct communication is possible as well.
Purchase order and stock transfer order integration

From a technical perspective, the integration of purchase orders and stock


transfer orders is triggered via the SAP ERP workflow technology for output
processing. The transfer of purchase orders and stock transfer orders is
activated via the SAP Customizing Implementation Guide (IMG) menu path in
SAP ERP: INTEGRATION WITH OTHER SAP COMPONENTS • T RANSPORTATION MANAGEMENT •
ORDER INTEGRATION • ACTIVATE T RANSFER OF PURCHASE ORDERS.
Using the following attributes you can define which purchase orders or stock
transfer orders should be transferred to SAP TM (see Figure 2.10):

Purchasing organization
Purchasing group
Order type

Figure 2.10: Activating the transfer of purchase orders and stock transfer orders

Different transportation processes or variants can be set up in SAP TM using


different OTR types. OTR types can be customized via the following SAP
Customizing Implementation Guide (IMG) menu path in SAP TM: SAP
T RANSPORTATION MANAGEMENT • T RANSPORTATION MANAGEMENT • INTEGRATION • ERP LOGISTICS
INTEGRATION • ORDER-BASED T RANSPORTATION REQUIREMENT • DEFINE ORDER-BASED T RANSPORTATION
REQUIREMENT T YPES.
Among other settings, you have to define a freight unit building rule which
determines how freight units are created as successor business documents
(see Figure 2.11). We will cover freight unit building in Section 2.3.1.

Figure 2.11: Customizing for order-based transportation requirement types

The OTR type chosen for a specific ERP order is determined via a condition
of condition type /SCMTMS/OTR_TYPE (see Figure 2.12). In the condition
you can access any data that was transmitted from ERP, and this gives you a
great deal of flexibility for defining the matching OTR type.
Figure 2.12: Condition for OTR type determination

Integrating SAP ERP deliveries


In addition to order documents, SAP TM can also integrate inbound and
outbound deliveries from SAP ERP. You can activate the transfer of deliveries
via the following SAP Customizing Implementation Guide (IMG) menu path in
SAP ERP: INTEGRATION WITH OTHER SAP COMPONENTS • T RANSPORTATION MANAGEMENT •
ORDER INTEGRATION • ACTIVATE T RANSFER OF DELIVERY DOCUMENTS.
Depending on the following attributes you can define which delivery
documents are transmitted to SAP TM:

Shipping point/receiving point


Delivery type
Shipping condition

Figure 2.13: Activating the transfer of inbound and outbound deliveries

For each integrated ERP delivery, a delivery-based transportation


requirement (DTR) is created in SAP TM. A DTR document is shown in Figure
2.14. Additional information that is available in the DTR compared to the OTR
document includes:

Statuses of original delivery in SAP ERP


Shipment planning block
Item information regarding packing (e.g., package type, equipment type,
container)

Figure 2.14: Delivery-based transportation requirement document

In the same way as for order documents, the SAP TM document flow is also
displayed in delivery documents in SAP ERP (see Figure 2.15).
Figure 2.15: SAP TM document flow in the delivery document

Figure 2.16 shows the customizing for DTR types. It is very similar to the
OTR type customizing. The only differences are as follows:

In OTR type customizing you can define whether to plan based on


requested quantities or confirmed quantities.
In DTR type customizing you can enter a delivery split/update type. With
this setting you can configure which planning changes are allowed in SAP
TM at which point in time during the process (e.g., no changes allowed if
the goods movement status in SAP ERP is already “complete”) and
which planning changes should be communicated to SAP ERP. Please
note that the delivery split and update process is only supported for
outbound and not for inbound deliveries.
Figure 2.16: Customizing for delivery-based transportation requirement types

ERP integration scenarios


Now that we have learned how to technically transfer ERP documents to SAP
TM, let us now take a look at a few typical hands-on business scenarios and
the related integration and interaction of SAP ERP and SAP TM.
Scenario 1: Integrating ERP orders and triggering delivery creation from TM
Figure 2.17: ERP integration scenario 1

ERP orders are transferred to SAP TM, where order-based transportation


requirements (OTRs) are created. Freight units (FUs) are built and planned.
Afterwards, delivery proposals are sent from TM to ERP. These transmit SAP
TM’s planning result to SAP ERP, for example, a precise delivery date.
Multiple freight units are consolidated into one delivery proposal (e.g., all
freight units are assigned to the same freight order) if the transportation plan
and order consolidation settings allow for it.
In SAP ERP, deliveries are created which might differ slightly from SAP TM’s
proposals due to additional SAP ERP-specific split criteria. The deliveries are
in turn transferred to TM to create delivery-based transportation requirements
(DTRs) which are used as relevant transportation requirement documents
from this point on as they contain more detailed and up-to-date process
information from ERP than the OTR. Based on the DTR information, the
existing FUs are updated and the planning result is adjusted if required.
Use case for integration scenario 1
You face complex transportation planning scenarios and thus
want to leverage the comprehensive planning capabilities
SAP TM offers (e.g., optimizer, distance, and duration
determination based on a geographical information system,
ocean, and air schedules). ERP orders provide more flexibility and
optimization potential for transportation planning than deliveries do.
Planning constraints, for instance, such as pick-up and delivery time
windows, are not yet tightly fixed. Furthermore, orders can still be
adjusted easily as no successor business documents need to be canceled
for this. Furthermore, you want SAP TM to propose whether and how to
split or consolidate order items.

Scenario 2: Integrating ERP deliveries

Figure 2.18: ERP integration scenario 23

ERP deliveries are transferred to SAP TM, where delivery-based


transportation requirements (DTRs) are created. Freight units (FUs) are built
and planned.

Use case for integration scenario 2


SAP ERP, or a connected warehouse management system,
should be responsible for consolidating and splitting order
items as you might have implemented complex business logic
in SAP ERP which you do not want to rebuild in SAP TM. In
addition, you face complex packing requirements, and packaging
materials allocated by the warehouse have a great impact on
transportation planning. This could be because you need to handle
numerous and diverse packaging materials and equipment with significant
differences in weight or other transportation-relevant attributes.
Please note that planning based on deliveries usually offers less flexibility
and optimization potential for transportation planning as many auxiliary
constraints have been already fixed by that time.

Scenario 3: Integrating ERP orders and triggering delivery creation in ERP

Figure 2.19: ERP integration scenario 3

ERP orders are transferred to SAP TM, where order-based transportation


requirements (OTRs) are created. Freight units (FUs) are built and planned.
Deliveries are created in ERP based on packaging information from the
warehouse management system or ERP. The deliveries are transferred to TM
to create delivery-based transportation requirements (DTRs). Based on the
DTR information, the existing FUs are updated and the planning result is
adjusted if required.

Use case for integration scenario 3


Similar to scenario 1 with the difference that the consolidation
and split of items into deliveries requires detailed packaging
information or custom business logic that is only available in
the warehouse management system or ERP, but not in SAP
TM.
Compared to scenario 2, planning in TM should start before the deliveries
are created in order to have a rough planning complete beforehand and
be able to plan capacities and communicate with carriers early.
Scenario 4: Sales order scheduling

Figure 2.20: ERP integration scenario 4

In this scenario, SAP TM is used during sales order creation to calculate the
material availability date, loading date, and goods issue date based on the
given delivery date requested by the customer.
At runtime, the sales order is transferred to SAP TM, where an OTR is
created and FUs are automatically built. Leveraging the transportation
proposal functionality, the transportation start date and loading date are
calculated by backward scheduling from the given delivery date and are sent
back to SAP ERP. The transportation start date is stored as the goods issue
date in the sales order. The loading date is used as the sales order’s loading
date as well as for calculating the material availability date. Afterwards, an
ATP check is triggered to make sure that the calculated material availability
date can be met. If the ATP check fails, a second scheduling in SAP TM is
started. This time SAP TM performs forward scheduling using the next
possible material availability date determined by the ATP check. In this
process, the SAP TM documents (OTR and FUs) are not saved but used only
to trigger the transportation proposal at processing time.

Use case for integration scenario 4


You want to leverage the better planning capabilities of SAP
TM in order to calculate the sales order dates as precisely as
possible. Compared to the route-based scheduling in SAP
ERP, the sales order scheduling with SAP TM can take
additional planning constraints into account (e.g., availability of resources
or exact voyages of ocean schedules).
Please note that this process is only supported for SAP ERP sales orders.

2.1.2 Creating forwarding orders in SAP TM


The forwarding order is the transportation requirement document used by
logistics service providers (LSPs) and carriers. More detailed information can
be captured in the forwarding order than in the OTR and DTR document to
allow for the greater emphasis which LSPs and carriers place on
transportation processes. The forwarding order is the basis for all subsequent
processes, such as transportation planning and charge calculation.
Forwarding orders can be created via one of the following options:

Automatically using electronic data interchange (EDI) — SAP TM


provides a B2B web service for automatically creating forwarding orders.
This service is leveraged especially by big LSPs and carriers.
Manually — either from scratch, with reference to existing documents
(e.g., as a copy of an existing forwarding order), or via a template.
Often, LSPs’ and carriers’ sales assistants communicate with customers
via e-mail or phone and then manually enter relevant order data into the
system. In many cases, customers regularly order the same
transportation services. Instead of entering the same data every time,
you can set up a template once and then just add specific information to
the individual order going forward.
Based on a forwarding quotation — if there was a preceding quotation
process, you can create the forwarding order as a follow-up action from
the forwarding quotation. This allows all relevant data to be automatically
propagated to the forwarding order.

Figure 2.21 depicts the forwarding order document. It contains many tabs for
specifying detailed information about the requested transportation services.
Figure 2.21: Forwarding order document

In addition to using the extensive full-blown forwarding order document, you


can also leverage a reduced user interface for FAST ORDER ENTRY. As you can
see in Figure 2.22, this user interface contains only those fields that are
usually filled by a sales assistant, such as business partners, sales
organization, general terms, locations, dates, and items.
Figure 2.22: Fast order entry

The HOUSE BILL OF LADING (HBL) number is the number that identifies the shipment.
It can be entered manually on the forwarding order user interface or be
automatically drawn from a predefined waybill stock.
SERVICE LEVEL CODES can be flexibly customized and assigned to a forwarding
order in order to influence planning and charge calculation respectively.

Cargo and service related data


Forwarding order items can specify the cargo to be shipped, including
packaging information, as well as additional services requested. You can
enter multiple items and build item hierarchies to indicate the desired
packaging (see Figure 2.23).
Figure 2.23: Forwarding order items

Via the forwarding order’s SHIPPING TYPE (e.g., full container load, less than
container load, or loose cargo) you can restrict the items that can be shipped
and whether they have to be assigned to special equipment (e.g., to a
container for a sea shipment).

Locations and transportation dates


On the LOCATIONS AND DATES/T IMES tab, you have to enter the pick-up and delivery
location as well as requested dates and times.
The pick-up and delivery dates and times entered represent the dates
requested by the customer. The pick-up date is used as the start date of the
first stage and the delivery date as the end of the last stage respectively.
However, agreements with the customers are usually based on time frames
rather than on a single point in time. During freight unit building, the time
entered in the forwarding order can be automatically converted into a time
window. You can configure the settings for this time window in a condition of
condition type /SCMTMS/TOR_TIMEWIND.

One-time locations
If one of your customers calls and wants you to deliver cargo
to a location you have not used before, you do not
necessarily have to define new master data for this location.
Instead, you can just type in the address directly in the
respective fields on the forwarding order and SAP TM will automatically
create a one-time location in the background.

Transportation stages and routing


After the sales department has taken the customer order and entered basic
data into the forwarding order document, usually another department of the
LSP or carrier that is responsible for transportation planning would typically
take care of further planning and routing. This is supported in SAP TM as you
can save the forwarding order document at any point in time without any
mandatory fields filled out. In this way, you can work on it according to your
responsibility and then hand it over to another department. You can also set
the ORGANIZATION INTERACTION STATUS to indicate which actions should be addressed
by the respective department.
The forwarding order’s routing is determined on the STAGES tab. Here, both the
ORDERED ROUTE and the ACTUAL ROUTE are displayed (see Figure 2.24). The
ordered route represents the routing that is agreed with the customer and is
therefore taken as the basis for charge calculation. The actual route is the
routing the LSP intends to use and is thus used for transportation planning. It
may differ from the ordered route, for example if the LSP wants to
consolidate and optimize several shipments.
Figure 2.24: Forwarding order stages

The actual route can be edited in the forwarding order document in the
following ways:

You can use automatic stage determination to specify permitted stage


types and automatically insert desired stages types into the actual route.
You can configure how the automatic stage determination should via
respective movement types or stage profiles. As you can see in Figure
2.25, you can use the MOVEMENT T YPE to define a stage type sequence
(e.g., pick-up, pre-carriage, main carriage, on-carriage, and delivery) and
whether a stage of a specific type may or must occur. You can define
whether some stages should be created automatically by selecting the
STAGE PROPOSAL checkbox.

Figure 2.25: Defining a stage type sequence

Alternatively, you can leverage the transportation proposal functionality


(which we cover in Section 2.3.4) and let the optimizer propose different
options for routing and scheduling.
Another option is to manually insert stages and add intermediate stops.
Locations and dates can also be edited manually.

Once routing is complete, you can perform planning activities in the forwarding
order directly. Schedules can be assigned to a stage with an input help
automatically proposing valid schedules that run between the two locations of
the stage. When a schedule is selected a corresponding booking is created
automatically. As an alternative to selecting a schedule, you can also assign
an existing freight booking to the stage.
Freight documents can also be created for a specific stage in the forwarding
order document. The dates of the stage are then propagated to the new
freight document automatically.
For more comprehensive planning and also consolidation with other
forwarding orders, you can use the transportation cockpit, which you can
access directly from the forwarding order user interface. For more details on
transportation planning and the transportation cockpit, please refer to Section
2.3.

Profitability analysis
The PROFITABILITY tab offers insight into the profitability of the forwarding order
by comparing the expected revenue as calculated for the forwarding order
and the expected costs resulting from the charge calculation for the freight
documents assigned to the forwarding order (see Figure 2.26). Cost
distribution can be taken into account by only considering those parts of the
freight documents’ charges that have been distributed to the particular
forwarding order. On this basis, the LSP or carrier can decide in advance
whether to accept or reject a forwarding order.
Figure 2.26: Calculated profitability for a forwarding order

In Figure 2.27 you can see the forwarding order type customizing, which you
can access via the following SAP Customizing Implementation Guide (IMG)
menu path: SAP T RANSPORTATION MANAGEMENT • T RANSPORTATION MANAGEMENT • FORWARDING
ORDER MANAGEMENT • FORWARDING ORDER • DEFINE FORWARDING ORDER T YPES. We will not go
into detail for each and every setting here, but would just like to illustrate the
comprehensive configuration possibilities and flexibility in SAP TM’s
forwarding order management.
Figure 2.27: Customizing for forwarding order types
Forwarding quotations
As we mentioned briefly at the beginning of this section, a forwarding order
can be created as result of a forwarding quotation. The forwarding quotation
document is very similar to the forwarding order. The main differences are the
QUOTATION PRICE and VALIDITY, as well as a workflow for negotiation rounds
between the LSP or carrier and their customer (see Figure 2.28).

Figure 2.28: Forwarding quotation

Charge estimation
When customers inquire about the price of a transportation service, you do
not have to create a forwarding order or quotation. Instead, you can use the
charge estimation functionality, which you can access in SAP NWBC via the
following menu path: FORWARDING ORDER MANAGEMENT • CHARGE ESTIMATION • ESTIMATE
FORWARDING CHARGES. After you have entered some basic information on the
transportation service relevant to the inquiry, the system estimates the
relevant charges based on SAP TM’s charge calculation component.

Limitations of the charge estimate


Please note that the charge estimate functionality is only a
rough estimation with no detailed planning or checks, e.g.,
regarding whether the desired route can be applied to this
forwarding order.

2.2 Transportation capacity management


The transportation capacity management module supports you in
professionally managing your own or your carriers’ transportation capacities.
The objectives of capacity management are to:

Provide sufficient transportation capacity and thus avoid capacity


shortage
Reduce transportation costs by avoiding expensive ad hoc orders
Establish trusting long-term relationships with carriers and customers

Figure 2.29 outlines the high level capacity management process and the
business documents involved in SAP TM. Strategic capacity management
deals with negotiating and managing long-term contracts—called agreements
in SAP TM—with carriers (freight procurement) or customers (freight selling).
For tactical capacity planning, different kinds of schedules with embedded
capacity allocations are used. Operational capacity handling is done via
booking documents which can be created automatically based on planned
mid-term capacities.

Figure 2.29: Capacity management process


In the following sections, we take a closer look at each of the three capacity
planning perspectives and how they interact.

2.2.1 Strategic freight management

Strategic freight procurement


The strategic freight procurement module of SAP TM supports shippers and
logistics service providers in planning and securing carriers’ transportation
capacities over a long-term time horizon. The goal is to negotiate long-term
contracts, called freight agreements in SAP TM, with the best suited carriers
for all relevant trade lanes and transportation modes.
The strategic freight procurement process supports you both in managing
your existing freight agreements (via a guided process for renewing expiring
contracts), and negotiating completely new contracts with new carriers or for
new trade lanes, transportation modes, shipping types, or other attributes. In
a complex setup covering international trade lanes in particular, it helps you to
decide which contracts to conclude and whether it is more profitable to
subcontract on a door-to-door level or to separately procure each stage.
Figure 2.30 outlines the general process flow.

Figure 2.30: Strategic freight procurement process

First, you can analyze relevant historical data regarding trade lanes,
capacities, and costs and check on past performance of your carriers. This is
possible in SAP BW based on pre-defined key performance indicators (KPIs)
such as percentage of delayed pick-up and delivery or percentage of invoice
discrepancies (see Figure 2.31).

Figure 2.31: Carrier performance analysis

Based on past data, you can forecast future transportation requirements and
perform what-if analyses.
In the second process step, the request for quotation is prepared and
published to all relevant carriers via B2B, e-mail, or on the collaboration
portal. After receipt of the carriers’ responses, the system helps you to
evaluate and compare them. Two comparison methods are supported.
1. Manual comparison of responses for rate minimization
Responses are compared at charge type level and visualized in several charts
for easier evaluation (see Figure 2.32). You can propose business shares at
the carrier level, perform different kinds of solution spend simulations, and
decide on the best solution.

Figure 2.32: Comparison of carriers’ quotes

2. Automated comparison of responses via the optimizer


Responses are compared at the charge type level for various strategies and
constraints which can be flexibly configured. The optimizer proposes the most
ideal target share distribution to produce the most cost-effective solution. You
can run the optimizer repeatedly with different target share strategies and
strategy versions if desired and finally pick the best solution.
The details of the solution that was chosen in the previous step are
summarized in an award summary for a final check (see Figure 2.33).

Figure 2.33: Award summary

The last process step is now to create a coresponding freight agreement.


Allocations are automatically generated for the business shares awarded
between the subcontracted carriers.
Figure 2.34 shows a freight agreement document with embedded freight
rates. For further information on freight rates, please see Section 2.8.
Figure 2.34: Freight agreement with freight rates

Allocations are used to strategically plan and reserve capacities per trade
lane, carrier, and time period (see Figure 2.35). The capacities to be
reserved can be defined in various dimensions (e.g., weight, volume, TEUs, or
pallets), time periods, time buckets (e.g., yearly, monthly, weekly), and
additional attributes (e.g., shipping type, contract basis, service level, or
handling code).

Figure 2.35: Allocation

Not only can allocations be used to plan capacities, but they can also be used
to track their consumption to date. The amount of capacities already used by
freight documents is displayed directly for each dimension in the allocation.
Business shares define how your total transportation demand should be split
between your carriers for a specific trade lane.
Strategic freight selling
The strategic freight selling module supports carriers and logistics service
providers in managing bids and resulting contracts across complex networks
based on customer requirements, margin, resource, cost, and capacity
constraints. The goal is to market their service offerings, manage customer
relationships, and conclude long-term contracts with customers, called
forwarding agreements in SAP TM.
The strategic freight selling process supports you both in managing your
existing forwarding agreements (via a guided process for renewing expiring
contracts) and negotiating completely new contracts with new customers, or
for new trade lanes, services, or other attributes. In a complex setup covering
international trade lanes in particular, it helps carriers and logistics service
providers to decide on what customer contracts to conclude, which services
to offer, and which rates to assign.
Figure 2.36 outlines the general process flow.

Figure 2.36: Strategic freight selling process

The starting point for strategic freight selling can either be a shipper’s freight
request for quotation, or a shipper’s buying interest in the form of an
opportunity in SAP CRM. Furthermore, the carrier/logistics service provider
can trigger the process themselves in order to renew an expiring contract or
to initiate a marketing campaign.
The carrier’s or logistics service provider’s sales department can use
analyses of historical customer data that are provided in SAP Business
Warehouse (SAP BW) or directly embedded in the relevant context in SAP
TM (see Figure 2.37) in order to identify and design suitable future service
offerings.

Figure 2.37: Analyze historical customer data

To start the quote-to-contract process a forwarding agreement quotation is


created. This document represents the tender quote or bid. The forwarding
agreement quotation can be created automatically based on a shipper’s
freight request for quotation, an opportunity in SAP CRM, an existing
agreement, a service catalog, or a template. From an opportunity in SAP
CRM, a forwarding quotation can be created as a direct follow-up action,
thereby inheriting all relevant data from SAP CRM (see Figure 2.38). The link
to the opportunity is registered in the forwarding quotation’s document flow in
SAP TM.
Figure 2.38: SAP CRM opportunity as the trigger for a bid process

Figure 2.39 shows a forwarding agreement quotation document. It can consist


of multiple items, each with assigned rates in an individual transportation
charge calculation sheet. For details on rates and charge calculations, please
see Section 2.8.

Figure 2.39: Forwarding agreement quotation

Rates can be determined either manually with the help of the rate builder
cockpit, or automatically by the system. In the rate builder cockpit, you can
edit a forwarding agreement quotation while the system is providing relevant
context information from similar agreements, such as suitable services and
matching rates. For automatic rate determination, a context-specific search is
used that proposes best matching rates based on existing agreements or
service product catalogs. You can configure how the system searches for
matching rates in a corresponding selection profile.
Once all relevant information has been included in the quotation, it is sent to
the customer via a B2B interface or e-mail with an Excel attachment. As soon
as the customer has responded, the information is updated automatically in
the freight agreement quotation. If the customer has accepted the quotation,
a forwarding agreement is created which represents the corresponding
contract.

2.2.2 Tactical capacity planning


For tactical capacity planning, different kinds of schedules with embedded
capacity allocations are used.
The regular travels and serviced transportation connections for your carriers
can be uploaded to SAP TM to automatically create carrier schedules.
Based on these, gateway schedules are created which also include
information regarding corresponding gateways, cut-off times, and planned
capacity allocations for each departure. Figure 2.40 depicts a gateway
schedule for air freight.
Figure 2.40: Gateway schedule for air freight

Carriers often make changes to their schedules (e.g., shifting the date and
time of a departure, canceling departures, or adding new departures). The
changed schedule data can be uploaded as carrier schedules, whereupon the
existing carrier schedules are updated automatically.
After adjusting schedule master data we need to take a look at how these
changes affect the related successor business documents. Depending on the
extent of the changes, you may or may not make changes to your gateway
schedules, allocations, and freight documents. The system automatically sets
the statuses of the successor business documents so that you can identify all
business documents for which the carrier schedules have changed. You can
use a POWL query to manually check and, if required, change the
corresponding documents. Alternatively, you can implement your own change
controller strategy to perform automatic follow-up actions according to your
requirements.

2.2.3 Operational capacity management


For operational capacity handling, booking documents are used which
bindingly reserve capacity from a carrier, for example on an ocean vessel or
airplane. Bookings are sent electronically to the carrier for confirmation of the
requested cargo space. As soon as the carrier has confirmed the booking,
freight units can be assigned to it consuming the reserved capacities.
Figure 2.41 shows an ocean freight booking that represents the transport
from a port of loading to a port of discharge and optionally, also includes
container freight stations for consolidating and deconsolidating freight before
and after the main leg. The booking document contains detailed information
about locations, dates, and times, business partners involved, terms and
conditions, such as the incoterm, document flow, cargo to be shipped, and
capacity requirements. Dependencies to other freight documents, such as the
road or rail freight orders for the pre-carriage and on-carriage, are also
displayed and help you to assess the impacts of issues and delays during the
transport.
Figure 2.41: Ocean freight booking

Bookings are subcontracted to carriers. The carrier can be taken from the
underlying schedule, inserted manually into the booking, or determined
automatically via the carrier selection or tendering process (for details on
subcontracting, please see Section 2.4).
In the case of multi-stop voyages, which transport goods along a sequence of
ports, the main leg consists of multiple stages.
Bookings can be created automatically based on the schedules that were set
up during tactical capacity planning via report
/SCMTMS/MP_SCHED_CREATE_TOR. First, you have to specify which
documents should be created (air bookings, ocean bookings, road freight
orders, or rail freight orders). For each document type, you can then fill in the
detailed selection criteria for the schedules and departures to be used. Figure
2.42 shows the selection criteria for creating ocean freight bookings.
Figure 2.42: Automatically creating schedule-based freight documents

In addition to automatically generating bookings via this report, you can also
create bookings manually or via automatic planning.

2.3 Manual and automated transportation planning


Transportation planning is a fundamental part of most transportation
processes. To support your planning process, SAP TM offers extensive
functionality for both manual and automated transportation planning.

2.3.1 Freight units and freight unit building


The starting point of every planning process is the creation of freight units
(FUs) from one or more transportation requirements (TRQs)4. A freight unit
represents a set of goods that is transported together through the entire
transportation chain. It typically represents a box, pallet, or container (or a
group thereof), or a certain amount of a bulk product.
As the freight unit still represents a transportation demand, it holds
transportation-relevant data such as:

Source and destination location, as well as applicable predefined


transshipment locations
Pick-up and delivery dates
Information on the content of the freight unit, e.g., product information,
quantities, and transportation characteristics

All essential freight unit information is inherited from the transportation


requirement.
An example of a freight unit document is shown in Figure 2.43. This freight unit
needs to be transported from a distribution center in Frankfurt, Germany, to a
customer in Karlsruhe, Germany on October 15, 2014 (see the upper screen
area of the GENERAL DATA tab). Information on the content of the freight unit can
be found on the ITEMS tab (see the bottom screen area). This freight unit
represents one pallet of 29-inch mountain bikes. Detailed information—e.g.,
regarding the routing of the freight unit, business partners involved, current
status, or predecessor and successor business documents—can be
accessed on the respective tabs.
Figure 2.43: Freight unit document

What is a freight unit — one mountain bike or a container of them?

A manufacturing company that produces mountain bikes may


model a freight unit as one single mountain bike or a whole
container of bikes depending on their transportation scenario.
If they deliver their mountain bikes directly to the home
address of their end customers, then one freight unit will be the one
mountain bike that the end customer ordered.
However, if they are replenishing their regional distribution center in San
Francisco from their production plant in China, one freight unit might be a
container of 100 mountain bikes, as they are all shipped together from
their source to their destination location.
Building freight units
You have to create freight units in order to start planning in SAP TM because
you cannot plan with transportation requirements (TRQs).5
Freight units can be built automatically immediately after the creation of a
transportation requirement, which makes sense in a lot of use cases. For one
transportation requirement, one or more freight units are created (see Figure
2.44). The reasons for splitting a transportation requirement into multiple
freight units might be that different items of the ERP order (and thus also of
the transportation requirement) have different delivery dates, or must not be
transported together, e.g., due to different temperature requirements.
Another common use case is that one ERP order item has such a large
quantity that it exceeds your resources’ capacity and cannot be transported in
a single shipment.

Figure 2.44: Automatic freight unit building after TRQ creation

Furthermore, it is also possible to consolidate items for multiple transportation


requirements into one freight unit (see Figure 2.45). The consolidation can be
utilized if, for instance, you frequently receive multiple sales orders from one
customer within a specific time frame and the items are processed and
shipped together. At the defined-cut off time, you can trigger freight unit
building either manually or via a batch job.

Figure 2.45: Consolidation of multiple TRQs into one freight unit

You can also use a combination of the two scenarios mentioned above. If you
want SAP TM to consolidate items for multiple transportation requirements
into freight units, but some order items require different cooling, this results in
an n:m relationship (see Figure 2.46).

Figure 2.46: Consolidating and splitting transportation requirements into freight units

In the freight unit building rule (FUBR), you can define how freight units
should be created (see Figure 2.47). The SPLIT QUANTITY of the PLANNING QUANTITIES
determines which maximum physical dimensions one freight unit may reach
before SAP TM will split it. The following planning quantities are available:

Gross weight
Net weight
Gross volume
Quantity
Alternative quantity
Twenty-foot equivalent unit

You can specify whether the system should consolidate multiple


transportation requirement items into one freight unit using the FREIGHT UNIT
BUILDING STRATEGY.
Figure 2.47: Freight unit building rule

How to define the ideal freight unit size

Which freight unit modeling is best suited to you depends on


your business scenario. On the one hand, numerous small
freight units allow for detailed transportation planning and
enable you to best exploit optimization. On the other hand,
this makes planning more complex and may lead to longer runtimes.
Consequently, you should try to model your freight units so that they are
both as small as necessary and as big as possible for your specific
transportation processes.

You can create, edit, or display freight unit building rules via the menu path
APPLICATION ADMINISTRATION • PLANNING • GENERAL SETTINGS • FREIGHT UNIT BUILDING RULE.
2.3.2 The transportation cockpit as the central planning user interface
The transportation cockpit serves as the central entry point and workbench
for the transportation planner. All major planning activities can be accessed
here. You can enter the transportation cockpit via the menu path PLANNING •
PLANNING • T RANSPORTATION COCKPIT.

Selection and planning profiles


To start the transportation cockpit you have to enter a selection profile and a
planning profile.
The selection profile determines what should be planned in this planning
session, e.g., which freight units, freight orders, trailer units, and freight
bookings should be displayed in the transportation cockpit.
Using selection profiles enables quick entry into the transportation cockpit as
you can reuse profiles you have already defined previously. Furthermore, the
options for selecting documents are very comprehensive. In addition to time-
related (see Figure 2.48) and geographical selection criteria, you can access
any information that is provided in the queries for freight units, freight orders,
freight bookings, transportation units, and transportation requirements in the
additional selection attributes.
Figure 2.48: Selection profile: time-related selection attributes

The planning profile defines how to plan. Amongst other things, it specifies
which planning constraints should be taken into account and which resources
and further transportation capacities may be used. In addition, you can
influence the general planning behavior such as how to schedule transports,
how to handle violations of restrictions, or which follow-up activities to trigger
after a manual planning step. We will come back to the details of the planning
profile in Section 2.3.5.

Flexibility via extensive configuration capabilities


The transportation cockpit can be flexibly adapted to suit multiple different
planning scenarios and diverse end-user groups. An operative transportation
planner responsible for planning the container shipping within an international
transportation chain needs to access different information and functions to the
fleet manager of a local trucking company. By defining and using different
layouts, these scenario-specific and user-specific requirements can be taken
into account.
Figure 2.49 shows the transportation cockpit configured for a local less than
truckload distribution scenario. The screen is divided into the following four
screen elements:

1. Freight unit stages, which represent the transportation demands that


need to be planned (top left)
2. Vehicles, which represent the available transportation capacities (bottom
left)
3. Freight orders, which constitute the transportation plan so far (top right)
4. Further details for one selected freight order, such as displaying the
route on a geographical map (bottom right)

Figure 2.49: Transportation cockpit configured for local less than truckload distribution scenario

Figure 2.50 zooms in on the freight unit stages screen element of Figure 2.49.
One line item represents one freight unit stage and provides relevant data for
the transportation planner. In this example, the freight unit stages each
contain one pallet of frozen pizza and need to be transported on July 30, 2014
from a distribution center in Frankfurt to a customer.

Figure 2.50: Transportation cockpit freight unit stages

Figure 2.51 depicts the vehicles screen element. For each vehicle, its capacity
restrictions as well as registration number, means of transport, and short
description are provided.

Figure 2.51: Transportation cockpit vehicle resources

The freight orders that have been already planned are shown in Figure 2.52.
The hierarchical view offers the planner the possibility to drill down to the stop
sequence and loaded freight units per stop. The utilization bar illustrates that
both freight orders are almost charged to capacity, with 93% and 95%.
Figure 2.52: Transportation cockpit freight order hierarchy

Lastly, Figure 2.53 zooms in on the details screen element for one freight
order. In this screenshot, the planner has navigated to the MAP tab. The
yellow line indicates the exact route that the truck will take through the city of
Karlsruhe while delivering to three customer locations symbolized by the icon

Figure 2.53: Transportation cockpit map

In contrast to the local trucking scenario, Figure 2.54 now illustrates


configuration for the transportation cockpit for ocean freight forwarding.
Instead of vehicles, the transportation capacities are now represented by
schedules with their individual departures (see the top right screen element).
The transportation plan is represented by ocean freight bookings and
associated information such as voyage numbers and vessel names (see the
bottom left screen element).

Figure 2.54: Transportation cockpit configured for ocean freight forwarding

In Figure 2.55, the transportation cockpit is again configured for a truck


scenario. However, the focus here is on load planning, e.g., determining the
best possible way to position each freight unit within the truck or trailer. The
decision on which freight units should be transported by which vehicle has
already been made beforehand, meaning that only the resulting freight orders
need to be displayed (see the wide screen element at the top). In addition,
the planner is provided with details on the dimensions of each freight unit and
whether it can be successfully placed within the vehicle (see the bottom left
screen area). A 3D graphic visualizes the load plan (see the bottom right
screen area).
Figure 2.55: Transportation cockpit load planning layout

2.3.3 Manual planning


The transportation cockpit offers numerous functions for manually creating,
extending, or changing a transportation plan. In addition to multiple other
activities the planner can use the transportation cockpit to perform the
following planning steps:

Create new freight orders


Assign unplanned freight unit stages to freight orders
Reassign planned freight unit stages from one freight order to another
Add and remove stops from freight orders or transportation units, or
change the stop sequence
Assign or remove resources from freight orders or transportation units

All major assignment and reassignment activities can be executed via


pushbuttons, hotkeys, or using intuitive drag and drop. The transportation
cockpit offers a dual view for reassigning freight units or stops from one
freight order to another (see Figure 2.56). Here, the current transportation
plan is displayed via two hierarchical views consisting of the planned freight
orders. The planner can use one screen area to drill down to a certain stop,
or a set of freight units he might want to reassign. Thereafter, the second
screen area can be used to scroll through the other freight orders and identify
one that still has open capacity. By dragging and dropping objects from one
side to the other, the planner can easily adjust the transportation plan.

Figure 2.56: Transportation cockpit dual view

The transportation cockpit also offers visual planning based on a geographical


map — the visual transportation cockpit. All planning-relevant objects, such
as freight orders, freight bookings, freight units, locations, vehicles, or
schedules, can be visualized on a map. In Figure 2.57 and Figure 2.58 the
yellow line indicates the routing of two road freight orders within Germany.
Figure 2.57: Transportation cockpit map display

Figure 2.58: Transportation cockpit map display — location information

The user can assign unplanned freight units to vehicle resources or freight
orders, or reassign planned freight units using drag and drop within the map.
Map-based planning is especially useful when you need to identify and plan
multiple freight units for the same route, as you can apply one planning step to
all objects for the same connection.

2.3.4 Semi-automatic planning via transportation proposals


The transportation proposals function combines both automatic and manual
planning elements. For a certain freight unit stage, the system automatically
calculates several options for routing and scheduling taking all planning
constraints and options within the transportation network into account. These
alternatives are then displayed for the planner to examine. You can manually
choose one of the transportation proposals listed and decide whether only the
proposed routing or alternatively the detailed planning result including
scheduling should be saved.

Figure 2.59: Transportation proposals

If none of the options displayed meets your requirements, you can change
planning parameters and preferences directly and let the system calculate a
new set of proposals. Therefore, you can manually prescribe the following
planning decisions:

Shipping via certain transshipment locations


Mode of transport to be used per stage
Carrier to be assigned
Dates and times for start or end of the transport

The following planning parameters can be maintained in the planning profile


and impact the calculation of transportation proposals (see also Figure 2.60):

Variation of route, carrier, and departure date


You can define whether the routes, carriers, and departure dates of the
transportation proposals to be calculated should or should not vary.
Example: If the route and carrier should not vary, but the departure date
should, the system searches for the best route and carrier and proposes
different departure dates.
Time relevance versus cost relevance
You can influence whether the transportation proposals should focus on
timely delivery or on minimizing transportation costs.

Figure 2.60: Planning parameters for transportation proposals

2.3.5 Automated planning via the optimizer


At the heart of SAP TM’s planning component is an extensive optimization
engine called the vehicle scheduling and routing (VSR) optimizer. It
automatically creates transportation plans using a heuristic algorithm to
calculate the best possible solution for a specific transportation problem.
Figure 2.61 outlines the mode of operation of the VSR optimizer. A set of
transportation demands, capacities, master data, and planning settings is
handed over to the optimizer. The optimizer subsequently searches for the
best transportation plan, thereby deciding on how to route, schedule, and
assign freight units to capacities whilst taking the whole transportation
network and all relevant planning constraints into account.

Figure 2.61: Input and output of the VSR optimizer

The VSR optimizer can be started interactively in the transportation cockpit or


triggered in the background via a batch job (see transaction
/SCMTMS/BACKGRD_PLAN or report /SCMTMS/PLN_OPT). As it is a
powerful engine, the optimizer can be used for complex planning problems
with a multitude of objects and intricate planning constraints. With the rising
complexity of global supply chains and regulations, it is becoming increasingly
difficult for a human planner to handle all restrictions and find the best solution
and in many cases it might be quite time-consuming. Therefore, many
customers use the optimizer to calculate an initial transportation plan that can
be checked and manually adapted by the planner if required.

Planning constraints
The following planning constraints are considered by the optimizer:

Capacity constraints on multiple levels (e.g., for mass, volume, and


number of pallets for a truck, trailer, and individual compartments)
Availability of a resource at the requested period of time, i.e., the
optimizer will not double book a certain resource
Acceptable start and end of pick-up and delivery per freight unit stage
Maximum duration of a freight order (e.g., to avoid freight orders that
take longer than the duration of one driver’s shift)
Maximum distance of a freight order
Maximum number of stops for a freight order
Opening times per location
Maximum number of parallel loading/unloading activities at a
location due to a maximum number of ramps
Cut-off times at transshipment locations
Incompatibilities between freight units, vehicles, locations, bookings,
and schedules (e.g., to model that a pallet of frozen pizza will not be
loaded into the same compartment with a pallet of lettuce, or that a
certain truck cannot deliver goods to a certain location because its turning
circle is too big to maneuver in the location’s narrow courtyard)

Planning costs
Individual planning preferences and priorities are incorporated by the optimizer
via a planning cost model. In the planning profile, on the PLANNING COSTS SETTINGS
tab, you can assign virtual costs to a number of variables (e.g., late delivery
or low vehicle utilization). The more important a specific variable is to you, the
higher the costs you should allocate to it, as the optimizer will try to create a
transportation plan with minimized planning costs.
The following freight unit-dependent costs can be defined (see Figure 2.62):

Costs for early and late deliveries per day6


Costs for non-delivery (by default very high because for most business
scenarios this is not acceptable)
Figure 2.62: Freight unit-dependent planning costs

If you want to distinguish planning costs further based on attributes of the


freight unit, you can do so using a condition of condition type
/SCMTMS/FU_PNLT_COST. This means you can, for example, impose
different planning costs for late delivery depending on customer priority and
service level agreements. Another use case might be to assign higher late
fees for freight units with perishable products than for general cargo.
In addition to freight unit costs, you can determine further planning costs
depending on the means of transport (see also Figure 2.63):

Fixed costs to differentiate between means of transport and to reduce


the number of freight orders as these fixed costs are applied once per
freight order.
Penalty costs which are used as multipliers for the freight unit costs for
early and late deliveries. You can use these costs to model different
early and late costs per means of transport, e.g., late delivery on an air
freight leg is more expensive than on a truck transport.
Distance-dependent costs in order to reduce fuel consumption and
costs for depreciation of vehicle resources (costs can be defined on a
destination basis, as is a common practice in North America, or route-
based for Europe).
Duration costs to reduce operating times and idle time.
Costs per additional intermediate stop, which minimizes the number of
stops.
Stepwise linear cost functions to model more sophisticated planning
costs depending on the utilization of the resource.
Figure 2.63: Means of transport-dependent planning costs

How to define planning costs


As we have discussed, the options for defining planning costs
for the VSR optimizer are very comprehensive. Defining an
accurate planning cost model is usually an iterative process.
Start with a simple set of a few cost settings (e.g., fixed
costs, costs for duration and distance) and test them on a realistic set of
data. Work from there by refining your planning costs, adding or adjusting
only one parameter with every planning run.

Optimizer explanation tool


SAP TM offers an explanation tool for the user to better understand why the
optimizer proposed a certain transportation plan. In Figure 2.64 you can see
the explanation tool for one specific optimizer run. You can navigate through
the explanation tool using the folder structure on the left side of the screen. All
of the data that is handed over to the optimizer is listed in the INPUT folder,
including subfolders. The data that is returned by the optimizer after the
optimization run is displayed in the RESULT folder. When you select a folder on
the left, detailed information is displayed on the right side of the screen. In this
example, you can see the freight unit output data. Three freight units were
due to be planned by the optimizer (see the top right side of the screen). Two
freight units were planned by the optimizer (see planning status COMPLETELY
PLANNED) — one freight unit without penalty costs for early or late deliveries
(green traffic light) and one freight unit generating the same (yellow traffic
light). The third freight unit could not be planned (see planning status NOT
PLANNED and red traffic light). If a freight unit could not be planned an
explanation is offered on the bottom right side of the screen. In this case, the
acceptable dates of the third freight unit were outside of the planning horizon
that was defined in the planning profile.
Figure 2.64: Optimizer explanation tool

Before examining the analyses of your optimization runs, you have to activate
the explanation tool by setting the user parameter /SCMTMS/EXP to X.
Thereafter, you can access the explanation tool via the OPTIMIZER EXPLANATION
button in the transportation cockpit or via the menu path APPLICATION ADMINISTRATION
• G ENERAL SETTINGS • REMOTE CONTROL AND COMMUNICATION FRAMEWORK • LOG • LOG DISPLAY

(transaction RCC_LOG).

Optimizer runtime
The VSR optimizer uses a heuristic algorithm. It searches for an initial solution
to the transportation problem and then tries to improve it by searching for
better solutions. The more time you grant for one optimization run, the better
the calculated solution. You can regulate the optimizer runtime on the OPTIMIZER
SETTINGS tab of the planning profile (see Figure 2.65). Start with a rather
generous maximum runtime. As soon as the optimizer creates a reasonable
transportation plan, you can gradually reduce the maximum runtime while
monitoring the quality of the optimizer result. As another option, you can
define a MAXIMUM T IME WITHOUT IMPROVEMENT. If the optimizer fails to improve the
best solution found during the defined maximum time per freight unit, the
planning run is terminated before reaching the maximum runtime. In any case,
make sure you set the AUTOMATIC RUNTIME REGULATION to NOT USED in order to let the
optimizer work deterministically.
Figure 2.65: Optimizer settings

In order to obtain a good optimizer result within a reasonable runtime, you


should consider dividing your planning scenario into parts that can be dealt
with separately. If you own multiple distribution centers whose delivery tours
run independently of each other, you can, for example, set up one optimization
run per distribution center. Also try out the parallel processing functionality in
the planning profile and make sure you schedule performance tests within
your project plan.

2.3.6 Load optimization


The load optimization functionality determines how best to utilize available
cargo space in a truck or trailer. It calculates the best solution for the loading
sequence and item positioning within the truck, while considering numerous
constraints such as the truck’s capacity restrictions, maximum axle load,
weight distribution, and individual items’ weight, width, length, and height.
In the transportation cockpit, as well as in the freight order document, you can
check the optimization’s results in a 3D load plan or a table load plan with the
load planning status of each individual item (see Figure 2.66).
Figure 2.66: Load optimization

You could also add a split deck to the truck and consequently plan two decks
(see Figure 2.67).
Figure 2.67: 3D load plan with split deck

The load plan can be printed and handed to the person responsible for
loading.

2.4 Subcontracting and tendering


In this section, we will look at how shippers and logistics service providers
use SAP TM to outsource the physical execution of their shipments to
carriers.

2.4.1 Carrier selection and subcontracting


In the previous section, we discussed the planning process for SAP TM that
results in freight documents with assigned freight units. The next step in the
process selects a reliable and cost-efficient carrier for each freight document
for those companies that would like to outsource the physical execution of
their transports.
The carrier selection process can be started interactively in the transportation
cockpit. Alternatively, it can be processed automatically in the background via
report /SCMTMS/TSPS_OPT_BGD or during an optimization run. Figure 2.68
outlines the carrier selection process.
Figure 2.68: Carrier selection process

First, all available carriers for a freight order are determined. To do this, the
transportation lane master data is checked for the means of transport that is
used in the freight order for all stages of the freight order.
Second, the list of available carriers is reduced by those carriers that need to
be discarded due to specific incompatibilities. A certain carrier may not be
allowed to deliver to a specific customer, or a carrier may not be able to take
freight orders with dangerous goods because they lack the required
equipment or license. Incompatibilities can be flexibly defined within the carrier
selection settings.
Third, an optimization run is started to build a ranking list of the reduced list of
available carriers. During optimization various constraints and planning costs
can be considered which we will cover in the carrier selection optimizer
section below. The carrier ranking list that has been built by the optimizer is
displayed in the freight order document on the SUBCONTRACTING tab (see Figure
2.69).
Figure 2.69: Carrier ranking in freight order document

The final process step is to select a carrier either by automatically assigning


the first carrier on the ranking list, by manually selecting one carrier on the
ranking list, or by using the ranking list for a subsequent tendering process.

Carrier selection optimizer


The optimization engine used in the carrier selection process considers the
following constraints and costs:

Charges for subcontracting a freight order per carrier. Transportation


charges can either represent the expected actual freight costs calculated
by the transportation charge management component (which we will
cover in Section 2.8), or virtual internal costs defined in the transportation
lane master data or carrier profile.
Transportation allocations which are considered as hard constraints as
they represent capacity restrictions (see Figure 2.70).
Business shares are included as soft constraints. The optimizer
calculates penalty costs for not adhering to intended business shares
(see Figure 2.71).
Discounts for building continuous moves (subcontracting one carrier
for two or more freight orders which can be executed directly after one
another).
Priorities which can complement or entirely replace costs if your
subcontracting preferences are simple.
Figure 2.70: Transportation allocation
Figure 2.71: Business shares

You can configure whether and how the above-mentioned constraints are
taken into account and how transportation charges are calculated in the
CARRIER SELECTION SETTINGS (see Figure 2.72) via the following menu path in SAP
NWBC: APPLICATION ADMINISTRATION • PLANNING • PLANNING PROFILE SETTINGS • CARRIER
SELECTION SETTINGS.

Figure 2.72: Carrier selection settings


2.4.2 Tendering
There are many options for setting up a freight tendering process in SAP TM.
In general, this process is always used to tender a freight order to one or
more carriers. Figure 2.73 outlines the different tendering variants that are
supported in SAP TM.

Figure 2.73: Tendering variants

The carriers that are to be invited to submit a bid for a specific tender can be
taken either from the carrier ranking list that was determined by the optimizer
in the previous carrier selection process, from transportation lane master
data, from the freight order document, or they can be manually assigned.
The tendering type defines the bidding mechanism. The following options are
available:

Peer-to-peer tendering
In the peer-to-peer tendering process one or more carriers are contacted
consecutively. If a response is required and the defined maximum
response duration has passed without a response being received from
the carrier, this is considered a rejection of the tender. If no response is
required, the same would be taken as an acceptance.
Broadcast tendering
In the broadcast tendering process multiple carriers are contacted
simultaneously. The process can be configured to let the first acceptable
offer win in order to receive fast responses and settle the tender quickly.
A bid is regarded as acceptable if it is below the defined price limit.
Alternatively, a broadcast tender can be configured to let the best offer
win. In this case, the carrier offering the cheapest price is assigned after
the defined tender duration has passed.

T h e tendering process can be a direct tender with subsequent direct


awarding. Alternatively, it can be based on a freight request for quotation
where a request for quotation is sent to the carrier. The carrier responds with
a quotation and can be awarded the assignment manually or automatically.
The price can either be fixed or be changeable by the carrier. Alternatively,
you can submit no price at all and use the tendering process to inquire about
the price proposal from each carrier.
The tendering type and process to be used can be configured in the tendering
profile (see Figure 2.74). Different tendering types can also be combined, for
example by starting with a peer-to-peer tender to the carrier who is ranked
first on the carrier ranking list. If the carrier rejects the tender, a broadcast
tender is subsequently published to all available carriers in order to ensure a
quick assignment. In the tendering profile, you can also configure the MAXIMUM
RESPONSE DURATION, PRICE LIMIT, and whether the carrier is allowed to make
changes to the stop dates of the freight order.

Figure 2.74: Tendering profile


You can start the tendering process interactively in the transportation cockpit
or from the freight order document. Alternatively, tendering can be processed
in the background via report /SCMTMS/TOR_TENDERING_BATCH. An
overview of the tendering process and current status is displayed on the
SUBCONTRACTING tab of the freight order document (see Figure 2.75).

Figure 2.75: Tendering process overview in freight order document

For monitoring and keeping track of your ongoing tendering processes you
can access various tendering worklists via the SAP NWBC menu path: FREIGHT
ORDER MANAGEMENT • ROAD • OVERVIEW T ENDERING. There are, for example, worklists
for freight quotations that need to be reviewed, unsuccessful tenders that
should be followed up on, and tenders that were stopped due to freight order
changes.
Figure 2.76: Tendering worklists

Options for communicating tenders to the carrier include electronic data


interchange (EDI), e-mail, SMS, or publication on SAP TM’s collaboration
portal. The collaboration portal is a browser-based portal that enables easy
collaboration with business partners such as carriers. It supports the
tendering process as freight requests for quotation can be published for the
carrier to check, make changes to if required, and respond to by accepting or
rejecting the request for quotation. In Figure 2.77 you can see a list of freight
requests for quotation on the collaboration portal for the carrier to respond to.
Figure 2.77: List of freight requests for quotation in collaboration portal

Figure 2.78 shows the detailed view of one particular freight request for
quotation which includes all relevant data of the shipment, as well as a map
display of the locations and route involved.
Figure 2.78: Freight request for quotation details in the collaboration portal

In addition to supporting the tendering process, the portal offers additional


functionality relevant for collaborating with carriers, such as managing freight
agreements or freight settlement (e.g., self-billing, charge verification, or
dispute resolution processes). For details on the collaboration portal, please
refer to Section 3.4.

2.5 Transportation execution and real-time track and trace


During transportation execution you have to deal with various tasks for
handling and documenting shipments in transit. We look at these tasks in this
section.

2.5.1 Document management and printing


For transportation execution you have to create, print, and carry various
documents that are requested for cargo shipments for compliance and legal
reasons (e.g., waybills, customs declarations, bills of lading, and further
documents). SAP TM supports document management via multiple features
such as:

Flexible configuration of how a specific document should be generated,


e.g., a house bill of lading can be composed either by consolidating all
items containing the same shipper and consignee, or by simply combining
all items on the same forwarding or freight order.
Management of number ranges and automatic drawing of correct
numbers from predefined stocks.
Extensive output management for printing. With SAP TM’s output
management component you can technically connect to printers, manage
queues, and integrate with Adobe Document Server, Adobe Forms
Designer, and interactive PDF forms. Output management is part of SAP
TM’s Post-Processing Framework, which is used to execute program
logic that is considered as a follow-up action to a specific business
process step.

In Figure 2.79 you can see an example of a master air waybill document.
Figure 2.79: Master air waybill

2.5.2 Discrepancy handling and status management


After cargo pick-up and loading, the actual quantities in terms of quantity,
weight, and volume are known and may differ from the planned quantities.
These discrepancies can be documented in SAP TM and then considered in
the following processes, such as a charge calculation. You can also configure
individual discrepancy types and the respective follow-up actions. For
example, in the event of a major discrepancy that exceeds a defined
threshold, the corresponding freight document can be automatically blocked
for further execution until the issue is reported as resolved.
In Figure 2.80 you can see an overview of STATUSES that are tracked to
manage the numerous processes for a freight order or freight booking. In
addition to execution statuses which, for example, indicate whether all items
have been loaded yet or at which location or transportation leg the shipment is
currently in transit, status information is also provided on other processes
such as subcontracting, invoicing, or customs clearance. Handling statuses
are also tracked on the individual cargo and container level.
Figure 2.80: Status overview for an ocean freight booking

2.5.3 Tracking and tracing


SAP Event Management (SAP EM) is a very flexible software tool for
tracking and tracing business processes, managing follow-up actions, and
providing insight into performance data such as the reliability of your business
partners. You can leverage it in supply chain management and beyond to
keep track of order processes, cargo movements, resource lifecycles, and
related financial processes. SAP EM is shipped together with SAP TM
because they are tightly integrated, but it can also be used in a large SAP or
legacy system landscape that communicates with partner systems in a global
network. It can either be deployed directly on SAP TM or on a separate
instance.
With regard to SAP TM processes, SAP EM contains standard content for
tracking the following objects and processes but can also be flexibly enhanced
to support additional business processes:

Tracking cargo movements and containers


Tracking shipping and master bills
Tracking resources and equipment
Tracking standard operating procedures

The basic idea is to monitor processes based on a chain of expected


milestones, called expected events, which typically occur in a specific
business process. A very simple example for a shipment would include
expected events for loading, departure, arrival, and unloading at specific
locations and at a certain point in time.
During process execution real-time data is collected and sent to SAP TM. The
component compares the expected events with actual posted events. This
allows any issues such as overdue events or unexpected events (e.g.,
damage to a container) to be automatically and instantly detected.
Figure 2.81 shows expected and posted events for a container in SAP TM. In
this example, the loading and shipment of the container on the pre-carriage
has already been executed and was on time. However, there is now a delay
in the ocean vessel’s journey from Oakland to Rotterdam, as indicated by the
red status icon.

Figure 2.81: Tracking information for a container

At the heart of SAP EM, there is a comprehensive rule set framework which
enables flexible definition of follow-up actions. In the case of critical
discrepancies, this could involve automatic notifications to the relevant user,
e.g., sending an e-mail that informs the consignee of a delay in the shipment’s
delivery. Furthermore, SAP EM can also trigger automatic follow-up actions
such as replanning in SAP TM if required or posting of a goods receipt in a
distribution system if a customer reports the complete arrival of the cargo at
his premises.

Automatic impact checks as part of SAP EM’s rule set


A large retail company uses SAP EM to holistically monitor
the distribution of goods to their retail stores. If one truck is
delayed, SAP EM automatically calculates the impacts of this
delay for each retail store that still needs to be supplied in
this tour. The retail store is notified only if the newly calculated arrival time
violates the delivery time windows agreed. As part of this notification, the
store is informed of the new arrival time so that they can prepare for the
late receipt of goods accordingly.

As of release 9.0, SAP EM comes with a full map integration which enables
the user to display the current location of a container, resource, or shipment
on a geographical map (see Figure 2.82).

Figure 2.82: Map display of a shipment’s current location

The Web Dynpro user interface will still be supported in the future as the fully
functional SAP EM user interface for power users. As of SAP EM 9.2, there
is an additional user interface targeted at occasional business users such as a
customer service agent, carriers, or customers. It is very simple and easy to
use and also available on mobile devices. In SAP EM 9.2, a SAP FIORI app
for freight order tracking is included that leverages the new user interface.
The home screen is shown in Figure 2.83. In addition to the app for FREIGHT
ORDER T RACKING, you can model key performance indicators (KPI) that are
calculated based on real-time information and displayed on the home screen
(e.g., PERCENTAGE OF ON-TIME ARRIVALS T ODAY). This is part of SAP Smart Business,
which is explained in more detail in Section 3.8. For information regarding
SAP HANA as a prerequisite for SAP Smart Business, please see Section
4.2.

Figure 2.83: SAP EM user interface for occasional users

The SAP FIORI app enables tracking of a freight order shipment’s real-time
status (e.g., by a customer service agent or the customer himself) and
reporting of events (e.g., by a carrier). The freight order details view is
depicted in Figure 2.84.
Figure 2.84: SAP FIORI App for freight order tracking

SAP EM provides flexible interfaces so that actual events can be


communicated in many different ways such as:

Electronically via web services, intermediate documents (IDocs),


business application interfaces (BAPIs), or electronic data interchange
(EDI)
Automatically from onboard devices, e.g., in a truck
Manually from the SAP EM web user interface, via the Android app “SAP
Transport Notification and Status”, or from the SAP TM collaboration
portal (see Section 3.4 for details)
Via barcode and radio-frequency identification (RFID) scanners
Via voice recognition

SAP EM as a basis for process insights and analyses


The comprehensive process information that is gathered by
SAP EM can be used for analyses in a business warehouse
providing insights into the performance of business partners
or process weaknesses. An example would be an evaluation
of the reliability of your subcontracted carriers measured by the number of
delayed deliveries.

2.6 International shipping and customs services


In international logistics and transportation, complying with legal and trade
regulations has become increasingly complex and challenging. An international
shipment can quickly require the provision of numerous documents and
interaction with a multitude of business partners and authorities. Many
different local laws have to be considered depending on the countries of origin
and destination, transit countries, and cargo characteristics.
SAP Global Trade Services (SAP GTS) is the core solution in the SAP
portfolio for managing requirements resulting from international trade and
logistics. In addition to being integrated with SAP TM, it also provides
standard integration with SAP ERP, SAP Extended Warehouse Management,
SAP Event Management, and SAP Customer Relationship Management (SAP
CRM). In this section, we will focus on the functional areas which have a
direct impact on transportation processes in SAP TM.

2.6.1 Trade compliance


In international trade, you are obliged to perform embargo checks and
sanctioned party list screenings for due diligence. After a forwarding order,
freight order, or freight booking is saved in SAP TM, the business partners
and countries involved are transferred to SAP GTS and validated against
embargo lists and sanctioned party lists. SAP GTS subsequently returns the
COMPLIANCE STATUS as either compliant or not compliant. In the latter case, the
SAP TM document is automatically blocked for execution with a
corresponding reason code as depicted in Figure 2.85. You can now either
cancel the SAP TM document or manually release the business partner or
document as compliant in SAP GTS to have the execution block withdrawn in
SAP TM.
Figure 2.85: Non-compliant forwarding order is blocked for execution

2.6.2 Customs management


Forwarding orders, freight orders, and freight bookings are checked by SAP
GTS for customs relevance based on the shipment’s origin and destination
country and the cargo that is to be shipped. If relevant for customs clearance,
the respective SAP TM document is automatically blocked for further
processing until the required declarations are complete.
As soon as forwarding orders, freight orders, or freight bookings have been
identified as relevant for customs, freight units are automatically bundled into
customs groups. This grouping is required because a forwarding order,
freight order, or freight booking can comprise multiple consignees and you
might therefore have to prepare separate customs declarations. For all freight
units assigned to one customs group an export declaration is generated in
SAP GTS and sent to customs authorities. To facilitate this process, SAP
GTS provides numerous standard interfaces for communicating with customs
authorities’ systems. After the declaration has been sent, SAP GTS receives
status messages concerning the further processing of the declaration until it is
finally released by the authorities. On release, the respective reference
number is returned to SAP GTS and SAP TM, where it is stored in the
corresponding forwarding order, freight order, or freight booking. The CUSTOMS
STATUS in SAP TM is set to APPROVED and the document’s execution block is
withdrawn so that further transportation execution can continue. If the
declaration is rejected, the corresponding SAP TM documents stay blocked
and are updated with the appropriate status information.
In Figure 2.86 you can see the CUSTOMS tab in the freight order document
which displays all relevant customs information such as current status,
customs groups, and reference numbers.
Figure 2.86: Customs information in a freight order document

Please note that at present, SAP TM is only integrated with SAP GTS
standard for export customs management. Import customs services and
transit procedures have to be enabled via a Business Add-In (BAdI) which you
can find in the SAP Customizing Implementation Guide (IMG) at: SAP
T RANSPORTATION MANAGEMENT • T RANSPORTATION MANAGEMENT • BUSINESS ADD-INS (BADIS) FOR
T RANSPORTATION MANAGEMENT • BASIC FUNCTIONS • GLOBAL T RADE • DECLARATIONS.

2.7 Dangerous goods handling and 1,000 points rule


Handling and transporting dangerous goods raises a multitude of additional
restrictions and constraints, including specific regulations for documentation,
transportation planning, and logistics execution. Depending on product
characteristics, different hazardous cargo items may not be allowed to be
shipped on the same vehicle or may require special container types and other
dedicated equipment for handling. Furthermore, national capping regulations
may restrict the maximum quantities of certain dangerous goods that can be
imported.
SAP Environment, Health, and Safety Management (SAP EHS) is the core
solution in the SAP portfolio for managing dangerous goods. In addition to
hazardous goods, it also covers further functional areas such as product
safety and stewardship or environmental and product compliance. In this
section, we will take a look at the SAP EHS processes that are integrated
with SAP TM as well as the dangerous goods-related interaction of SAP ERP
and SAP TM.

2.7.1 Integration of SAP TM and SAP EHS


Figure 2.87 outlines the integration of SAP TM and SAP EHS. In shipper
scenarios where an ERP system with detailed dangerous goods-related
master data is in place, this master data can be automatically transferred to
SAP EHS. Logistics service providers, who typically have neither an ERP
system nor product master data at their disposal, can use a dangerous goods
content loader to import regulatory content into the SAP EHS master data
and customizing tables.7 Transactional data regarding dangerous goods is
stored directly in the forwarding order, freight unit, freight order, and freight
booking in SAP TM and can thus be used for further planning, dangerous
goods-related checks, printing, and hazardous goods-specific information on
the user interface. For these functions SAP TM uses the respective
dangerous goods services and frameworks of SAP EHS which are part of
SAP SCM Basis.
Figure 2.87: Integration of SAP TM and SAP EHS for dangerous goods management

2.7.2 Dangerous goods checks and planning constraints


In order to make sure that all dangerous goods-related restrictions and
regulations are taken into account, SAP TM can perform comprehensive
checks of forwarding orders, freight units, freight orders, or freight bookings.
The following standard checks are provided with regards to hazardous goods:

Check whether cargo can be shipped at all (issues can arise due to a
lack of special resources or trained staff, or because some countries
generally prohibit the transportation of certain substances).
Check the product quantity (there are capping regulations that restrict
maximum quantities that can be shipped in one load or imported to a
certain country).
Check the packaging and load plan (dangerous goods usually require
special packaging and are subject to limitations concerning consolidated
shipment with other hazardous goods. There are regulations dictating, for
instance, that certain products cannot be shipped together on a single
pallet, in the same container, or on the same vehicle.).
Check the routing (some substances are banned on certain routes, such
as flammable liquids in certain road tunnels in Switzerland.)
Check the vehicle (for special provisions or equipment that may be
required).
Check any possible exemption for dangerous goods regulations due to
1,000 points rule (European Agreement concerning the International
Carriage of Dangerous Goods by Road (ADR) 1.1.3.6, which we will
cover in the next section)

The checks are technically embedded in the dangerous goods check


framework of SAP EHS. Figure 2.88 shows the respective customizing where
you can define the appropriate check level (document header or item) and
assign a corresponding function module. The SAP EHS framework allows you
to flexibly extend the standard checks with customer checks which might be
required in your business scenario. You can access the customizing for
dangerous goods checks via the following SAP Customizing Implementation
Guide (IMG) menu path in SAP TM: SAP T RANSPORTATION MANAGEMENT • SCM BASIS
• EH&S SERVICES • DANGEROUS G OODS MANAGEMENT • DANGEROUS G OODS CHECKS AND

DANGEROUS GOODS DOCUMENTS • DANGEROUS GOODS CHECKS • SPECIFY DANGEROUS GOODS


CHECK METHODS.

Figure 2.88: Customizing for dangerous goods checks

2.7.3 1,000 points rule


Section 1.1.3.6 of the European Agreement concerning the International
Carriage of Dangerous Goods by Road (ADR), also known as the 1,000
points rule, states that eased transportation requirements can be applied if
the sum of the points of all hazardous cargo items does not exceed 1,000
points. The calculation is based on the cargo item’s quantity (in weight,
volume, or liters) and defined multiplication factors.
In SAP TM, points can be calculated and a possible exemption checked for all
relevant documents. The calculation result and the indicator regarding whether
an exemption can be applied is displayed in the respective SAP TM document
(see Figure 2.89).

Figure 2.89: Dangerous goods information in the freight order document

In addition to document checks, the 1,000 points rule can also be taken into
account in freight unit building. The system will automatically split freight units
as soon as their associated points exceed 1,000 points (or another manually
defined point threshold, see Figure 2.90). Furthermore, SAP TM will not mix
cargo items for transport category 0 with cargo items of another transport
category since an exemption for category 0 is never possible. In this way,
freight unit building will enable the transportation planner to easily build freight
orders with eased regulations and thus reduced costs.
Figure 2.90: 1,000 points rule considered in freight unit building

Lastly, the 1,000 points rule is considered during optimizer planning. The
optimizer will not create freight orders adding up to more than 1,000 points.
Freight units for which an exemption cannot be applied (e.g., as the
respective hazardous substance belongs to transportation category 0) are
automatically planned on separate tours.

2.8 Calculation and settlement of transportation charges


Calculating, managing, and settling transportation charges have become key
functions within logistics for both shippers and logistics service providers. SAP
TM’s charge management component is a very powerful and flexible engine. It
allows you to centrally maintain and manage your logistics contracts and
automatically calculate transportation charges for all modes of transport and a
multitude of business processes. It is fully integrated with other processes
such as strategic freight procurement and operational order management in
SAP TM, or invoicing and billing processes in SAP ERP.

2.8.1 Architecture and master data


Before examining SAP TM’s capabilities for charge calculation and cost
distribution, we will first take a quick glance at the underlying master data.
Figure 2.91 shows the hierarchical structure of the different master data
objects.
Figure 2.91: Master data for charge management

The following master data elements are used for transportation charge
management in SAP TM:

Agreements represent contracts and contain parties involved, payment


terms, validity period, and one or multiple agreement items. You can use
agreement items to divide a contract into sections, e.g., per trade lane,
transportation mode, shipping type, or cargo type. Agreements are used
for documenting customer contracts (called forwarding agreements in
SAP TM), vendor contracts (called freight agreements), and internal
agreements that exist between internal organizational units and that are
used for internal settlement.
Transportation charge calculation sheets have a direct cardinality to
agreement items. They contain one or multiple charge elements (e.g.,
basic charges, fuel surcharge) and determine how charges are calculated
via calculation rules.
Each charge element points to a rate table which stores charge and rate
values. Charge or rate values are defined for a combination of scales,
i.e., parameters which influence the value.
A scale defines one specific dimension for a rate table (e.g., source
location, destination location, distance, or gross weight).
The hierarchical and modular master data architecture allows you to set up
and manage your data efficiently, as many items only need to be created
once and can then be reused in different processes.

Agreements
In Figure 2.92 you can see a freight agreement which is used to document a
contract with suppliers such as carriers. In this example, the contract was
concluded between one specific purchasing organization and one single
carrier. You could also set up an agreement between multiple parties involving
numerous organizational units and vendors. This and further settings can be
configured in the agreement type customizing which you can access via the
following SAP Customizing Implementation Guide (IMG) menu path: SAP
T RANSPORTATION MANAGEMENT • T RANSPORTATION MANAGEMENT • MASTER DATA • AGREEMENTS AND
SERVICE PRODUCTS • DEFINE FREIGHT AGREEMENT T YPES.
At the bottom of Figure 2.92 you can see that this agreement contains two
agreement line items which hold different charge information for full truckload
(FTL) and less than truckload (LTL) shipments. Each agreement item has one
transportation charge calculation sheet assigned.
Figure 2.92: General data of a freight agreement document

When you select one agreement line item additional data is displayed, such as
an overview of the assigned transportation charge calculation sheet (see
Figure 2.93). We will take a closer look at calculation sheets in the next
section.
Figure 2.93: Calculation sheet overview in freight agreement

For each agreement item you can define a precondition, thereby restricting its
usage to certain trade lanes, business partners, or many other attributes
which you can flexibly define in a precondition rule (see Figure 2.94).
Figure 2.94: Preconditions for freight agreement items

If you have negotiated capacities with your carrier, you can maintain them on
the CAPACITIES tab (see Figure 2.95). Via the CREATE ALLOCATIONS button you can
create allocations from the freight agreement document directly. The
prerequisite is that you have assigned an agreement allocation type to your
freight agreement type in customizing.
Figure 2.95: Capacities for freight agreement items

Alternatively, you can create business shares from the freight agreement
document. These shares define how your total transportation demand should
be split between your carriers. For more detailed information on
transportation allocations and business shares, please refer to Section 2.2
and Section 2.4.1.
Freight agreements can be created in SAP NWBC via the menu path FREIGHT
AGREEMENT MANAGEMENT • FREIGHT AGREEMENTS • CREATE FREIGHT AGREEMENT.

Connecting to external agreements


Instead of maintaining agreements yourself in your SAP TM
system, you can also connect to external agreements in third-
party systems via a web service. SAP TM offers a web
service for querying rates from external systems. You can
then control how the external rate information is used for charge
calculation and settlement in SAP TM.

Transportation charge calculation sheets


An agreement must have at least one transportation charge calculation sheet
(TCCS) assigned. A calculation sheet contains charge elements and assigned
rate tables, as well as logic for calculating charges. Calculation sheets are
defined generically and can be used for all agreement types.
You can create a transportation charge calculation sheet either via the ADD
CALCULATION SHEET button in an agreement document, or via the SAP NWBC
menu path MASTER DATA • CHARGE MANAGEMENT AND SERVICE PRODUCT CATALOGS •
CALCULATION SHEETS • CREATE CALCULATION SHEET. Figure 2.96 shows the calculation
sheet’s basic data and items. The CHARGE USAGE determines whether the
calculation sheet can be used for customers, service providers, or internal
agreements.

Figure 2.96: Transportation charge calculation sheet

One calculation sheet item represents one charge element. For each charge
element in your calculation sheet, you have to specify the respective charge
type and assign a rate table. Examples of charges types are basic rates,
documentation fees, fuel surcharges, labelling charges, or a peak season
surcharge (to name just a few). Charge types can be flexibly defined via the
following SAP Customizing Implementation Guide (IMG) menu path: SAP
T RANSPORTATION MANAGEMENT • T RANSPORTATION MANAGEMENT • BASIC FUNCTIONS • CHARGE
CALCULATION • BASIC SETTINGS • DEFINE CHARGE T YPES (see Figure 2.97).

Figure 2.97: Customizing for charge types

Figure 2.98 shows the customizing details per charge type. You can group
charge types by assigning a charge category and subcategory. In addition,
you can specify whether this charge type should be used as a positive or
negative value (e.g., for discounts) and whether it is an absolute or relative
value. Alternatively, you can allow for both options and let the user specify this
later in the charge calculation sheet.
Figure 2.98: Customizing details per charge type

When you select a charge element in the items list, you can maintain
comprehensive information for this charge element. Many of these settings
are optional and are only required if you want to model specific use cases.
The charge element’s BASIC DATA tab contains general information, as well as
settings for the calculation logic (see Figure 2.99).
Figure 2.99: Basic charge element data

If you want the user to manually enter a certain rate value during the charge
calculation process, you can set the MANUAL CHARGE ITEM flag. The charge type is
then determined automatically but the rate value is left blank for the user to
enter the correct charge interactively in the forwarding order, freight order, or
freight booking.
T h e ROUNDING PROFILE defines whether and how the system should round
calculated charges up or down.
As the chargeable weight often has a considerable influence on total charges,
you may define a DIMENSIONAL WEIGHT PROFILE in order to calculate the correct
chargeable amounts.
You also have the option of specifying a CALCULATION METHOD per charge
element. If a rate should only be read from a rate table or an easy calculation
should be executed, no calculation method is required. If you want the system
to perform a complex calculation, you can maintain the calculation method
here. There are some standard methods available, such as calculation logic
for clipping, deficit weight rating, or break-weight rating for air freight. In
addition, you can flexibly implement your own methods to model any custom
logic relevant for your business.
The CALCULATION RESOLUTION BASE defines the level at which a charge is applied
(e.g., per product, package, container, or once per document).
The GROUPING RULE determines whether one charge should be calculated for
multiple items. If, for example, you want to calculate weight charges for a
freight order and define the freight units’ destination as a grouping rule, the
system will take all items with the same destination, add up their weight, and
use the total weight for charge calculation.
Information on actual rate values or rate tables is maintained on the charge
element’s RATE tab (see Figure 2.100). You can use one of the following
options to assign a rate to a charge element:

Assign a rate table (either directly or via a rate table determination rule;
we will take a closer look at rate tables in the next section)
Maintain a fixed rate amount
Assign a percentage value with reference to another charge element
(either in the rate table or directly in the calculation sheet)
Figure 2.100: Reference to rate information in the calculation sheet

Most customers prefer to use rate tables because they allow higher flexibility
and easier rate maintenance. You can define one rate table; alternatively, you
can define a rate table determination rule if you want to use different rate
tables depending on your organizational unit, transportation mode, or other
attributes.
On the PRECONDITION tab you can define prerequisites for when to apply a
charge. You can enter preconditions with regards to trade lanes, service
levels, and business partners involved directly, or alternatively, assign a
precondition rule which offers the highest flexibility.
In order to reduce the manual efforts required for creating calculation sheets,
you can configure charge calculation sheet templates that specify charge
types and basic settings for the calculation sheet. Calculation sheet templates
can be created via the SAP NBWC menu path MASTER DATA • CHARGE MANAGEMENT
AND SERVICE PRODUCT CATALOGS • CALCULATION SHEET T EMPLATES • CREATE CALCULATION SHEET
T EMPLATE.
Since you can maintain your own charge types and flexibly assign rate tables,
or absolute or percentage rates, you can use the SAP TM charge
management structure for all kinds of business scenarios or transportation
modes.

Rate tables
Rate tables contain actual rate values that are required for calculating
transportation charges. One rate table stands for one rate. During charge
calculation, one rate value is read from the rate table dependent on one or
multiple parameters. This value can then be used further for charge
calculation according to calculation rules and other settings as defined in the
charge calculation sheet.
You can create rate tables either manually via the SAP NWBC menu path
MASTER DATA • CHARGE MANAGEMENT AND SERVICE PRODUCT CATALOGS • RATE T ABLES • CREATE
RATE T ABLE DEFINITION, or within a TCCS (transportation charge calculation sheet)
using the ADD RATE T ABLE button. Alternatively, SAP TM provides upload and
download functionalities, as well as a mass update function.
Figure 2.101 shows the rate table’s GENERAL DATA tab, where you can specify
charge type settings, enter organizational data, and assign scales that
represent the rate table’s dimensions (e.g., source location, destination
location, distance, or weight).
Figure 2.101: General rate table data

Rate values are stored on the rate table’s DATES AND VALUES tab. You can enter
one or multiple validity periods and maintain or upload rate values depending
on the previously defined scales, e.g., rate table dimensions (see Figure
2.102).
Figure 2.102: Maintaining validity periods and rate values for a rate table

On the CALCULATION RULES tab, you can specify a calculation rule if the rate value
should be multiplied with a certain data field called CALCULATION BASE (see Figure
2.103). We will take a closer look at calculation rules in the next section.

Figure 2.103: Assigning calculation rules to a rate table

When determining the chargeable weight charge, for example, the rate value
read from the rate table should be multiplied with the actual chargeable
weight of a cargo item. Calculation bases can be flexibly defined in
customizing via the IMG path: SAP T RANSPORTATION MANAGEMENT • T RANSPORTATION
MANAGEMENT • BASIC FUNCTIONS • CHARGE CALCULATION • DATA SOURCE BINDING • DEFINE
CALCULATION BASES (see Figure 2.104).

Figure 2.104: Defining calculation bases

Alternatively, the calculation rule can be defined in the calculation sheet.

Rate table maintenance


As rate tables can consist of a large number of rows,
creating and maintaining them manually would be very time-
consuming and error-prone. In order to reduce the manual
effort, SAP TM offers functionality for downloading and
uploading rate tables from and to Excel (see report
/SCMTMS/TCC_RATE_MASS_CREATE) as well as a mass update
function (see report /SCMTMS/RATE_MASS_UPDATE).

Scales
Scales represent the dimensions in a rate table. Each scale stands for one
parameter that the transportation costs to be calculated depend on (e.g.,
distance, weight, product type, or incoterm to name just a few).
You can create scales in SAP NWBC via the menu path MASTER DATA • CHARGE
MANAGEMENT AND SERVICE PRODUCT CATALOGS • SCALES • CREATE SCALE.
On the scale’s GENERAL DATA tab you have to specify the scale base, type, unit
of measure and optionally a rounding profile (Figure 2.105). The SCALE T YPE
determines how the intervals should be interpreted; options are: to scale (<=),
base scale (>=), or same scale (=). In the example shown in Figure 2.105,
the scale type is defined as T O SCALE (<=). If you now maintain a rate value,
e.g., USD 50, for the interval 100 km in the rate table, the system will use the
rate value USD 50 for all distances less than or equal to 100 km.

Figure 2.105: Scale

On the ITEMS tab you can define the intervals for which you will later maintain
rate values in the rate table (see Figure 2.106).
Figure 2.106: Scale items

2.8.2 Charge calculation


The charge management’s master data allows you to store and manage
supplier and customer contracts. The real benefit, however, is generated
when you leverage it to automatically calculate charges for forwarding orders,
quotations, freight orders, or freight bookings.
Charge calculation can be triggered in the following ways.

Manually via the CALCULATE CHARGES button in a forwarding order, quotation,


freight order, or freight booking
Automatically by selecting the respective flag in the order type, or
freight document type customizing
Automatically via a report for mass charge calculation
Automatically as soon as you generate a settlement document
Automatically when recalculating credit memos

Charge calculation process


The general charge calculation process is shown in Figure 2.107. When
charge calculation is started for a TM document, the system follows a
sequence of process steps in order to determine relevant master data and
then use it in calculating the applicable charges.

Figure 2.107: Charge calculation process

1. Find correct agreement


SAP TM searches for an agreement based on the business partner (e.g.,
carrier) and internal organizational unit (e.g., purchasing organization) that
are maintained in the TM document. In addition, the document’s
calculation date has to be within the agreement’s validity period.
If more than one agreement is found, you have different configuration
options for deciding which agreement should be selected (e.g., based on
the agreement’s priority).
2. Determine valid agreement item
The selected agreement can contain more than one line item. The correct
agreement item is selected based on the attributes that are maintained
both on the line item and in the TM document (e.g., transportation mode,
shipping type, stage category, means of transport, or service level).
3. Find correct calculation sheet
The system searches for a valid calculation sheet for the selected
agreement item. The TM document’s attributes have to meet all
preconditions defined in the agreement item for the calculation sheet. If
more than one valid calculation sheet is found, the system checks each
calculation sheet for valid rates based on the leading charge type. If
more than one calculation sheet has a rate maintained for its leading
charge type, the system will randomly select one of the valid calculation
sheets.
4. Determine valid charge elements
For each charge element in the calculation sheet, SAP TM checks
whether it must be included in the calculation or whether its prerequisites
are not met by the respective TM document. Prerequisites could be, for
example, that a certain charge element should only be applied for a
specific trade lane, business partner, or other attributes.
5. Determine rate value per charge element
For each valid charge element the system determines a rate value.
Depending on your master data setup, the rate value is either taken
directly from the calculation sheet or from the rate table that is assigned
to the charge element.
6. Optional: Use rate value for further calculations
As defined in calculation rules or methods for this charge element, the
rate value is used for further calculations (details on calculations rules
and methods are provided in the following sections).
7. Calculate total charge amount
The total charge amount is calculated based on the amounts determined
per charge element.

If you want to model a more sophisticated logic for selecting the correct
agreement and calculation sheet, you can flexibly maintain and assign BRF+
rules8. Furthermore, SAP TM provides Business Add-Ins (BAdIs) for contract
determination which you can access via the SAP Customizing Implementation
Guide (IMG) menu path: SAP T RANSPORTATION MANAGEMENT • T RANSPORTATION
MANAGEMENT • BUSINESS ADD-INS (BADIS) FOR T RANSPORTATION MANAGEMENT • MASTER DATA •
AGREEMENTS/CALCULATION SHEETS.
You can configure different levels for which the system should determine the
relevant agreement, item, calculation sheet and charge elements:

Header level
The applicable master data is determined once for the TM document.
Exactly one agreement with one calculation sheet is selected.
Item level
The contract determination logic is executed per main item (e.g., a
container) of the TM document.
Stage level
The logic is executed per stage of the TM document. This determination
level is advisable if you want to consider different agreements for
different shipment legs.

You can combine the header and stage levels and SAP TM will then try to
determine one agreement for header charges and another agreement for
each stage. The contract determination level to be applied can be configured
in the calculation profile which you can access in the SAP Customizing
Implementation Guide (IMG) via the following menu path: SAP T RANSPORTATION
MANAGEMENT • T RANSPORTATION MANAGEMENT • BASIC FUNCTIONS • CHARGE CALCULATION • BASIC
SETTINGS • DEFINE CALCULATION PROFILES (see Figure 2.108).

Figure 2.108: Calculation profile

Calculation rules
In step six of the charge calculation process you can perform further
calculations for each charge element. Calculation rules are one option for
maintaining calculation logic.
You can, for example, define a charge element with calculation base gross
weight and a rate of EUR 25 per 100 kg. EUR 25 is the rate value which is,
for example, determined from a rate table. The relation per 100 kg is modeled
as a calculation rule: 100 is the price unit and kilogram is the calculation rule’s
unit of measure (see Figure 2.109).

Figure 2.109: Calculation rule for gross weight

Calculation rule example


When you trigger the charge calculation for a freight order
with a cargo of 2,000 kg the system determines the charge
using the rule of three:
100 kg = EUR 25
2,000 kg = ?
The result is a charge of EUR 500 which is calculated by multiplying 2,000
kg by EUR 25 and then dividing it by 100 kg.

When you use rate tables you can define multiple calculation rules in order to
model more complex business scenarios.

Calculation methods
Calculation methods enable you to perform more sophisticated calculations
compared to calculation rules. You can leverage the standard calculation
methods which are shown in Figure 2.110. Alternatively, you can implement
new methods for modeling any custom logic in charge calculation. If you
assign a calculation method to a charge element in the calculation sheet, the
standard calculation logic is completely replaced by the logic implemented in
the respective calculation method.
Figure 2.110: Standard calculation methods

Calculation results
The charge calculation results are displayed on the CHARGES tab for each
relevant TM document. Figure 2.111 gives a simple example of charges
calculated for a road freight order. The total amount of USD 1,397.50 results
from a basic fee, stop-off costs, and a fuel surcharge. For each charge, its
FINAL AMOUNT is displayed. Furthermore, additional data is displayed to help the
user better understand how this final amount was calculated. The RATE AMOUNT
represents the value that was, for example, determined from a rate table. The
CHARGEABLE QUANTITY is the actual value from the TM document that was used for
the calculation. In this example, for the stop-off costs, the rate value of USD
200 was multiplied by the chargeable quantity of two stops, resulting in the
final amount of USD 400.
Figure 2.111: Charges overview in freight order document

When you select one charge item, further details are displayed, such as
references to the exact agreement, the calculation sheet and rate table that
were used, the calculation rules applied, and a comprehensive CHARGE
CALCULATION LOG (see Figure 2.112).
Figure 2.112: Charge calculation details per charge item

2.8.3 Charge settlement and cost distribution


In this section, we will take a look at SAP TM’s capabilities for charge
settlement and cost distribution. Let us look at three basic scenarios:

Supplier settlement
Both shippers and logistics service providers usually procure
transportation capacities and services from carriers. The resulting costs
can be settled in order to support invoice verification or self-billing
processes. Moreover, shippers can allocate costs to the respective
costing objects for material valuation or profitability analyses.
Customer billing
Billing customers for the transportation services provided is an essential
process for logistics service providers and carriers. Depending on the
incoterms of a shipment, different invoices are sent to the shipper(s) and
consignee(s) involved.
Internal settlement
Logistics service providers are usually organized in profit centers.
Different hubs, gateways, and other departments are responsible for the
optimization of costs and generating a profit. Costs and revenue are
commonly settled among the organizational units involved.

The same general architecture applies for each of these processes. Charges
are calculated and costs are distributed in SAP TM. The settlement, however,
is executed in SAP ERP, leveraging the existing capabilities of SAP ERP
Sales and Distribution (SD) for billing and SAP ERP Materials Management
(MM) for invoicing. Costs are allocated to the respective costing objects in
SAP ERP via its Agency Business component.

Supplier settlement
Figure 2.11 outlines the general process for settling supplier freight services.
For logistics service providers, the process starts with a forwarding order in
SAP TM. In shipper scenarios, an SAP ERP order or delivery is integrated
with SAP TM and creates an order-based transportation requirement (OTR)
or delivery-based transportation requirement (DTR). Freight units are built and
assigned to a freight order or booking which is subcontracted to a supplier.
For this freight order or booking a freight settlement document (FSD) is
generated which contains all of the relevant invoicing information such as the
invoicing parties and calculated charges. It can be considered a draft invoice.
In addition, distributed costs and their assignment to the respective cargo
items are also part of the freight settlement document. The freight settlement
document is transferred to SAP ERP and triggers two subsequent processes:

1. A service purchase order and service entry sheet are created to


enable posting of accruals, invoice verification, or self-billing.
2. In shipper scenarios, an agency business document is created for
posting distributed costs to the respective cost collectors. A shipper can
leverage this in inbound scenarios for product costing and pricing in SAP
ERP MM Material Valuation. For outbound shipments, the freight costs
of a sales order item are posted to a general ledger expense account
and can be used in SAP ERP Controlling and Profitability Analysis (SAP
ERP CO-PA). By this means, any transport-related charges can be
included in the calculation of the profitability of your sales orders.

Both processes follow standard practices in SAP ERP.

Figure 2.113: Supplier settlement process

The creation of freight settlement documents can be triggered either manually


from a freight document or worklist, or automatically by a report for mass
creation (/SCMTMS/SFIR_CREATE_BATCH).
A freight settlement document is shown in Figure 2.114. Basic settlement
information, e.g., invoice date and total amount, organizational data, and
payment terms are defined on the GENERAL DATA tab.
Figure 2.114: Freight settlement document

The results of the cost distribution are shown in Figure 2.115. For each
charge type, the total costs are distributed and allocated to the individual
cargo items that were shipped with the freight order or booking.
Figure 2.115: Cost distribution overview in the freight settlement document

In this example, costs were distributed based on the items’ gross weight.
Other options for cost distribution are:

Net weight
Gross volume
Distance times weight

Rules for cost distribution

If you would like to use a more complex logic for distributing


costs to order items, you can use the Business Add-In
/SCMTMS/TCD_DISTRIB_RULE to flexibly implement your
own custom rules.

The service purchase order and corresponding service entry sheet that are
created for this freight settlement document in SAP ERP are shown in Figure
2.116 and Figure 2.117.

Figure 2.116: Service purchase order in SAP ERP


Figure 2.117: Service entry sheet

When entering an incoming invoice in transaction MIRO in SAP ERP, you can
post it with reference to a specific freight order. This allows the charge
amount which was calculated by SAP TM and transferred to SAP ERP via the
freight settlement document to be automatically pulled into the BALANCE field,
thus enabling invoice verification (see Figure 2.118).
Figure 2.118: Invoice verification and posting in SAP ERP

The SAP ERP documents generated are visible in the freight settlement’s
DOCUMENT FLOW (see Figure 2.119).

Figure 2.119: Document flow in the freight settlement document

Customer billing
The customer billing process is depicted in Figure 2.120. The base document
for invoicing is the forwarding order in SAP TM. Based on the forwarding
order, one or multiple forwarding settlement documents (FWSD) are created
that contain all of the relevant invoicing information, such as the invoicing party
and charges, and can be considered draft invoices. The forwarding settlement
document is transferred to SAP ERP, where a billing document, e.g., an
invoice, is created.

Figure 2.120: Customer billing process

The forwarding order usually covers multiple stages and more than one payer,
such as a shipper and a consignee. The total charges incurred have to be split
and shared among the parties involved based on the incoterm agreed.
Therefore, usually more than one forwarding settlement document has to be
created. A simplified example regarding the splitting of charges is shown in
Figure 2.121. The forwarding order contains three stages routing the cargo
via two ports from shipper to consignee. The incoterm is Free on Board
(FOB). In this example, SAP TM will generate two forwarding settlement
documents: one for billing prepaid charges to the shipper, and another one for
settling collect charges with the consignee.
Figure 2.121: Customer billing based on incoterms

As customers often demand collective invoices, you can also create


collective forwarding settlement documents to consolidate charges from
different forwarding orders. The system will check which forwarding orders
contain the same general settlement data, e.g., bill-to party, payer, or
payment term, and generate a collective freight settlement document. You
can configure whether you would like to use collective freight settlement
documents in the settlement profile. It is also possible to implement and
assign a custom strategy for controlling which attributes should be used as
consolidation criteria. The settlement profile can be maintained in the SAP
Customizing Implementation Guide (IMG) via the menu path: SAP
T RANSPORTATION MANAGEMENT • T RANSPORTATION MANAGEMENT • SETTLEMENT • DEFINE SETTLEMENT
PROFILE.
A forwarding settlement document is shown in Figure 2.122. Its structure is
very similar to a freight settlement document. The GENERAL DATA tab contains
basic settlement information such as invoicing date and total charges,
organizational data, payment terms, and incoterms. In the case of collective
invoicing, all forwarding orders included are listed on the ORDERS tab.
Figure 2.122: Forwarding settlement document

The creation of forwarding settlement documents can be triggered either


manually from a forwarding order or worklist, or automatically by a report for
mass creation (/SCMTMS/CFIR_CREATE_BATCH).

Internal settlement
The internal settlement process is a very common business practice among
logistics service providers. Usually, a booking office takes orders and invoices
the customer, thus eventually generating the revenue. A planning or
purchasing organization, however, will procure capacities from a carrier and
pay the charges incurred. In an internal settlement process, the planning or
purchasing organization will now cross-charge their costs against a forwarding
order from the sales organization. This enables a profit center structure in
which each organizational unit can act independently and optimize its profit.
The general process is outlined in Figure 2.123. The distributed costs, which
have to be settled internally, are stored in an internal settlement document.
Depending on the organizational units involved, intracompany or intercompany
settlement is required. Intracompany settlement shares costs between
branches or divisions of the same company code, whilst intercompany
settlement involves legally independent companies with different company
codes. For an intracompany settlement document, an accounting document is
created in SAP ERP to repost costs from a purchasing organization to a sales
organization’s cost center or internal order. For an intercompany settlement
document, a regular billing document is generated in SAP ERP.

Figure 2.123: Internal settlement process

There are two options for calculating charges for internal settlement. Charge
calculations can be based on:

Internal rates which can be defined in an internal agreement between


the different organizational units. The internal rates represent an average
price of procuring certain transportation services and can optionally
include a profit margin. This encourages purchasing organizations to act
as profit centers and offer best rates for capacities in the organization.
Actual costs which are billed from service providers for freight orders or
freight bookings. The costs from the freight orders or bookings are
distributed and allocated to the items in the forwarding order and can be
used for internal settlement.

2.9 Summary
This chapter outlined the main functional areas of SAP TM and how to best
configure them. Most of these areas, such as tendering, are used by every
mode of transport and merely have to be adapted to the mode being used.
We also explained the surrounding systems, including EHSS, ERP, and Event
Management, in detail.
The following chapter will focus on the latest release of SAP TM 9.2 and its
key innovations.
3 Key innovations with SAP TM 9.2
SAP Transportation Management is one of the strategic solutions for
SAP and is still a major area for investment. As a result, many
developers are working continuously to further improve and extend its
features and usability. This chapter provides a short summary of the
key innovations that are part of the newest release, SAP TM 9.2.

3.1 Fleet planning with a Gantt chart


In SAP TM 9.2, the transportation cockpit includes new functionality that
enables interactive resource-based planning and provides a Gantt chart for
visualizing the usage and availability of your fleet. As you can see in Figure
3.1, the Gantt chart shows each resource’s utilization along the time axis. The
MAXIMUM UTILIZATION bar and a general UTILIZATION STATUS indicate whether the
planner needs to take action to deal with overload, empty movements, or
scheduling conflicts.

Figure 3.1: Gantt chart for fleet planning

Changes can be handled intuitively by assigning or unassigning a resource via


drag and drop. In addition, real-time execution information can be displayed
for each resource, e.g., reported events and the resource’s current status and
location. In the case of delays or other unexpected issues, the planner can
react immediately and adjust the transportation plan if required. To resolve
conflicts, you can, for instance, select a critical resource on the Gantt chart
and display it on the map next to nearby resources, thus integrating the
geographical and time perspectives.

Figure 3.2: Interplay of the Gantt chart and map display

3.2 Container management, planning, and optimization


With SAP TM 9.2 you can manage container resources and plan container
shipment along the transportation chain. Multiple freight units can be
consolidated into a container unit which represents the physical container. In
the case of full container shipments, container units can be built automatically
directly from the transportation requirement. Containers can then be planned
manually or automatically using SAP TM’s optimization engine for determining
the best route and scheduling for the container through the transportation
network. Many of the existing planning functionalities, such as transportation
proposals, default routes, or incompatibilities, are also available for container
planning.
Figure 3.3 shows a list of available container resources in the transportation
cockpit. Freight units can be assigned to it via drag and drop.

Figure 3.3: Container resource list in the transportation cockpit

The location sequence, scheduling, and further planning information of a


container are displayed in the CONTAINER UNIT HIERARCHY — this is a completely
new screen within the transportation cockpit (see Figure 3.4).

Figure 3.4: Container unit hierarchy

In addition to the new planning functionalities, SAP TM 9.2 also provides new
features for managing the provisioning and return of empty containers. The
provisioning and return of empties can be ordered either together with the
request for the cargo transport, or independently of it. In addition to
containers, the empties management function is also available for handling
railcars.
For these new empties movements a triangulation feature is included which
allows the container movements to be optimized in order to minimize empty
movements. If one forwarding order ends with an empty return and another
forwarding order starts with an empty provisioning, the triangulation function
will propose combining these two empty movements to create just one
consolidated empty movement from the first order’s destination location to the
second order’s start. Auxiliary constraints, such as geographical and time
proximity, as well as matching equipment requirements, are taken into
account. An example of this process is shown in Figure 3.5.
Figure 3.5: Triangulation of empty movements

3.3 Load optimization enhancements


In SAP TM 9.1, SAP introduced new functionality for load optimization that
determines how to best utilize available cargo space in a truck or trailer (see
Section 2.3.6).
With SAP TM 9.2, the existing feature, which we explained in Section 2.3.6, is
now enhanced by the following items:

Load planning for a truck and trailer combination


Resource type-dependent load planning rules
Consideration of minimum axle weights for driving and steering axle

3.4 Collaboration portal


T h e collaboration portal is a browser-based portal that enables easy
collaboration with business partners such as carriers. It was introduced in
SAP TM 9.1 in order to support the tendering process between shippers or
logistics service providers and their subcontracted carriers (see Section
2.4.2).
In SAP TM 9.2, the collaboration portal now also supports the following
processes:

Integration of SAP Event Management for tracking and tracing


The carrier can view all relevant execution information for a freight order,
report events (see Figure 3.6), upload attachments, for example a digital
file of the customer’s signature for proof of delivery, and register
discrepancies such as deviating actual quantities that were unloaded at
the customer location. Before SAP TM 9.2, the same functionality was
already available in SAP EM. The integration into the collaboration portal
brings benefits with regards to security, as the collaboration portal’s
architecture includes a demilitarized zone which adds an additional layer
of security to an organization’s LAN: an external attacker has access only
to equipment in the demilitarized zone, rather than any other part of the
network. Details of the collaboration portal’s technical architecture can be
found in Section 4.3.
Figure 3.6: Real-time execution tracking via the collaboration portal

Invoice submission
On the portal, the carrier can access a list of freight orders that were
completed by him but have not yet been invoiced. For one or a set of
freight orders, he can let the system automatically calculate the
corresponding charges based on the agreed rates. If required, he can
manually adjust the calculated charges or add further charge items.
Afterwards, an invoice is created and submitted to the shipper/logistics
service provider. In SAP TM a carrier invoice is created. For validation,
the invoice can be accepted automatically via predefined tolerance rules
or approved manually. Subsequently, it is sent from SAP TM to SAP
ERP, where a corresponding invoice is posted and included in the regular
payment process.
Dispute management
The carrier can create a dispute case on the collaboration portal if he
does not agree with the charges calculated by SAP TM. This can be, for
instance, due to unplanned costs such as demurrage charges because of
delayed cargo availability at the pick-up location, or discrepancies in
planned and actual quantities. The dispute is then handled via a workflow
between shipper/logistics service provider and carrier in order to come to
a quick resolution. The shipper/logistics service provider can accept or
reject the carrier’s proposal, or send a new proposal to the carrier for
approval. Once an agreement is reached, the regular settlement process
is continued based on the charges that were agreed at the end of the
dispute process. In Figure 3.7, you can see how a dispute is raised for
an invoice proposed by the shipper/logistics service provider during the
self-billing process.

Figure 3.7: Dispute management via the collaboration portal

Freight agreement requests for quotation


During the strategic freight procurement process (for details, see Section
2.2.1), shippers or logistics service providers negotiate long-term
contracts with their carriers for all relevant trade lanes and transportation
modes. Corresponding requests for quotations are published to the
relevant carriers either via B2B, e-mail, or on the collaboration portal,
where carriers can respond and submit their quotes directly.

3.5 Strategic freight procurement


In SAP TM 9.1, SAP introduced the strategic freight procurement process to
support shippers and logistics service providers in planning and securing
carriers’ transportation capacities over a long-term time horizon. The goal of
this process is to negotiate long-term contracts, called freight agreements in
SAP TM, with the best suited carriers for all relevant trade lanes and
transportation modes. For details on this process, please refer to Section
2.2.1.
With SAP TM 9.2, the strategic freight procurement process is now enhanced
with the following features:

Target rate
Bonus-malus handling. It is possible to influence the target share
proposed by the system using carrier performance scores received from
SAP Business Warehouse (SAP BW). For example, if a carrier
performed well last year, the shipper would like to give this carrier a
bonus in the current RFQ cycle and influence the optimizer to grant him a
higher target share. If a carrier performed badly, a malus or penalty
should be considered to influence the optimizer to grant this carrier a
smaller target share.
Enhancements in award summary
Master templates from industries
Default route in freight agreement
Download of request for quotation master and carrier responses
Freight agreement consumption enhancements
Alerts on cancellation of requests for quotation

3.6 Strategic freight selling


As of SAP TM 9.1, the strategic freight selling process is available, helping
carriers and logistics service providers to manage bids across complex
networks based on customer requirements, margin, resource, cost, and
capacity constraints. The goal is to market their service offerings, manage
customer relationships, and conclude long-term contracts with customers,
called forwarding agreements in SAP TM.
In SAP TM 9.2, this process was extended by the following functionalities:

Route proposal
Identifying service products based on route
Building end-to-end rates, both manually and automatically
Creating forwarding agreement quotations from an opportunity in SAP
CRM
Creating and updating forwarding agreement quotations from flat format
Excel from customer
Mode of transport-specific forwarding agreement quotation templates
Advanced features in forwarding agreement quotation response, such
as consolidation of charge type before response

3.7 ERP – TM integration enhancements


The existing integration between SAP ERP and SAP TM is enhanced with the
following functionality and processes in SAP TM 9.2:

Delivery proposals based on actual weight and volume in SAP TM


Prior to the release of SAP TM 9.2, delivery proposals were created in
SAP TM based on planned quantities only. In SAP TM 9.2, actual
quantities such as actual weight and volume can now be maintained in
SAP TM and are then used for delivery proposals and subsequent
delivery creation in SAP ERP. This functionality can, for example, be
used for bulk products where deliveries are created on completion of
loading and weighing.
Goods issue triggered from SAP TM
As of SAP TM 9.2, it is now possible to trigger the goods issue posting
directly from SAP TM.
Accept additional handling units from ERP shipment and create new
passive vehicle resources, containers, pallets, or other package
items in the freight order
Before SAP TM 9.2, the integration between the SAP TM freight order
and the SAP ERP shipment already enabled a process in which the
container capacity was planned in SAP TM, but the packing of the
container was determined in SAP ERP/Warehouse Management (WM).
SAP TM sent container items to SAP ERP to create handling units in the
ERP shipment. In the ERP shipment, delivery items were assigned to
these handling units. However, no new handling units could be created
and transmitted back to TM.
In SAP TM 9.2, it is now possible to create new handling units in the ERP
shipment to represent additional passive vehicle resources, containers,
pallets, boxes, or other packaging items and to assign delivery items.
The packaging information is transferred to SAP TM and stored with the
respective packaging hierarchy in the freight order document. Thanks to
the extended integration, it is also now possible to plan in SAP TM based
on products or lower level packages, but both decide on the number and
types of passive vehicle resources and containers and optimize the
loading of the same outside of SAP TM.
Figure 3.8 shows the freight order in SAP TM without packing
information. At this stage, it is transferred to SAP ERP to create an
equivalent shipment. In Figure 3.9, during packing a handling unit is added
in the SAP ERP shipment. The updated packing information is transmitted
to SAP TM and displayed in the freight order.
Figure 3.8: Freight order items before packing
Figure 3.9: Packing in SAP ERP shipment and updated item hierarchy in SAP TM

Synchronization of the transportation planning status for ERP


deliveries based on planning progress in SAP TM
In releases prior to SAP TM 9.2, it was not possible to update the
delivery’s transportation planning status according to the planning
progress in SAP TM. The status could only be updated based on the
ERP shipment.
In SAP TM 9.2, the delivery’s transportation planning status can now
automatically be set to NOT PROCESSED, PARTIALLY PROCESSED, or COMPLETELY
PROCESSED depending on whether none, some, or all of the dependent

freight units have been planned in SAP TM. This functionality is targeted
at customers who control many existing processes, such as billing
activities or document printing, via the transportation planning status and
would now like to substitute the SAP ERP shipment with the freight order
in SAP TM.
Stage building and planning in SAP TM based on handover location
and handover date from purchase order confirmations in ERP
As of SAP TM 9.2, you can now transmit the handover location and
handover date received in the purchase order confirmation from ERP to
TM and use it to decide what stages should be built based on the source,
handover, and destination location. The handover date and confirmed
quantities are taken as the basis for further planning.

3.8 SAP Smart Business and SAP Fiori Apps


As of SAP TM 9.2, there are now sample reports and key performance
indicators (KPIs) available for SAP Smart Business and SAP Fiori apps which
enable easy insight into operational transportation business.
SAP Smart Business is the new user experience for SAP Business Suite
powered by SAP HANA, combining modern working models with consumer-
grade usability. This allows key roles to stay on top of their business, making
better and faster decisions by letting end users touch, analyze, share, and act
in real time.
Available KPIs for SAP TM and SAP EM include:

Delayed deliveries
Average cycle times
Average utilization
Transportation revenue and profit
Transportation orders with discrepancies

Figure 3.10 and Figure 3.11 show examples of an SAP Smart Business
cockpit and an SAP Fiori app based on SAP TM and SAP EM.
Figure 3.10: SAP Smart Business for SAP TM and SAP EM
Figure 3.11: SAP Fiori app for SAP EM

3.9 Summary
The latest release of SAP TM brings the addition of a couple of helpful new
functionalities that make the life of a transportation planner easier. Also, new
technologies such as SAP Fiori make it possible to focus on the most
important information without overloading the user.
The following chapter focuses on the big picture, including the solution
architecture and aspects of integration.
4 Solution architecture and
integration with other SAP
components
This chapter outlines the required system landscape setup for SAP TM,
release dependencies, and options for leveraging SAP HANA for
transportation management.

4.1 System landscape


For a basic transportation scenario, an SAP ERP backend and an SAP TM
installation are required. The other required components are determined by
the business process being implemented.
International shipping and customs checks, for example, require integration
with the SAP GTS module, and an order entry via CRM implies integration
with SAP CRM.
The Adobe Document Server is required for managing the output of printouts.
The process integration engine, including the related content for TM, provides
interface mapping between the SAP components and the outside world.
Aggregated reporting can be established by connecting to SAP BI, including
the related TM content.
In order to enable the direct integration of SAP EWM, the SAP EWM
components have to be directly linked to TM (not via ERP only).
All required releases working with TM 9.1 can be derived from Figure 4.1.
Figure 4.1: System landscape

As an upgrade of all existing components cannot always be performed within


the required deadlines in an implementation project, the functional impacts of
using lower release levels are illustrated in Table 4.1.

SAP TM and SAP ECC release


Table 4.1: Overview of functionalities and required SAP TM releases

4.2 HANA-enabled SAP TM


From SAP TM 9.1 on, there are two options for deploying HANA.

1. Sidecar approach
The TM application operates on any of the recommended DB’s (such as
Oracle and others). The HANA stack is installed in parallel. The
replication from the DB to the HANA stack allows for the use of analytics
capabilities (see below for details).
2. Deploying HANA in TM stack
Instead of the DB, HANA is used. This does not guarantee a higher
application performance, although all analytic-related capabilities are
provided.

Figure 4.2: Technical architecture with SAP HANA

SAP Smart Business provides a preconfigured reporting framework based on


the SAP Fiori technology.
The prerequisites are:

SAP Smart Business Product: SAP Smart Business for Transportation


Management 1.0
Virtual Data Model (VDM): SAP HANA Analytics for TM 1.0
SAP Business Suite Product: SAP Transportation Management 9.0
SPS03

SAP Smart Business for Transportation Management is a collection that


provides an overview of the most important key performance indicators for a
transportation manager. It allows the transportation manager to monitor the
operational transportation business based on the latest reported events,
including forwarding orders created, transportation orders created, average
utilization by transportation orders, transportation requirements created,
dangerous goods, and transportation costs, revenue, and profit. The
transportation manager can use this functionality to monitor the business and
track financial information to get insights into the business. This helps the
transportation manager to identify any issue that might need to be
investigated more closely as early as possible and if necessary, to correct
issues in the operational business before they escalate.
The following reports are provided as of TM 9.1:

Forwarding Orders
Transportation Cost
Transportation Profit
Transportation Revenue
Transportation Orders
Transportation Orders with Discrepancies
Transportation Requirements
Dangerous Goods
Average Delay Time (POD)
Avg. Cycle Time Delayed Deliveries (POD)
Avg. Cycle Time of Deliveries
Delayed Deliveries (POD)
Delayed Deliveries (Total)
Delayed Deliveries (In Transit)
Reporting Completeness
Reporting Compliance

4.3 SAP TM collaboration portal


This section provides details about the products and components that make
up the SAP Transportation Management collaboration portal system
landscape.
4.3.1 SAP Business Suite

SAP TM 9.1
An SAP TM 9.1 system is required to run the underlying transportation
management scenarios. In this guide, it is assumed that you already run this
system in your SAP Business Suite environment, as well as SAP NetWeaver
AS ABAP 7.40.

SAP TM software component SAPTMUI


The SAP TM software component SAPTMUI, deployed on the application
back-end system or Gateway system, provides the user interface and front-
end logic for the SAP TM collaboration portal.
The software component SAPTMUI must have the same support package
(SP) level as that of the underlying SAP TM component.

SAP NetWeaver Component SAP_GWFND


The SAP NetWeaver component SAP_GWFND (SAP Gateway Foundation
7.40), deployed on the application back-end system, establishes the
communication between the Gateway system and the application back end
for the purpose of OData provisioning and push functions.

SAP NetWeaver Component SAP_UI


The SAP NetWeaver component SAP_UI (User Interface Technology 7.40),
deployed on the application back-end system, provides the relevant libraries
to render the user interface for the Web interface.

4.3.2 SAP Gateway


The Gateway system uses OData services to provide back-end data and
functions. It also processes HTTP(S) requests for OData services.

4.3.3 Demilitarized zone (DMZ)


A demilitarized zone (sometimes referred to as a perimeter network) is a
physical or logical subnetwork that contains and exposes an organization’s
external-facing services to a larger untrusted network, usually the Internet.
The purpose of a DMZ is to add an additional layer of security to an
organization’s LAN: an external attacker has access only to equipment in the
DMZ, rather than any other part of the network.

4.3.4 Reverse Proxy/ABAP Web Dispatcher


The ABAP Web Dispatcher is required to translate the traffic from the Internet
to the internal system landscape. As modern browsers check for violations of
the same-origin policy, the Web dispatcher acts as a single point of access
and dispatches the calls to the Gateway services and to the UI sources
respectively. It also acts as a URL filter to only allow those URLs through that
are required for the SAP TM collaboration portal.
Figure 4.3: The collaborations portal’s technical architecture

4.4 Summary
There is not just “one” TM system, rather a series of subsystems and
technical layers that are required to make TM run. Depending on the business
scenario, the system landscape is more or less complex. When you are
connecting systems, the version and release of the solution has to be taken
into account. If it does not comply with the recommended release, there may
be some areas of functionality that do not work and have to be taken into
consideration.
The following chapter provides a preview of what is coming next in the
upcoming releases of SAP TM.
5 Summary
There is one valid principle for every software-related roadmap — it is
subject to change. SAP TM within the SAP Supply Chain Execution
platform is one of SAP’s strategic investment areas and will continue to
increase functionality significantly in the coming years. Specifically,
integration with SAP EWM will be a primary area of focus.
In a global business world, many different goals within transportation
networks have to be taken into account by a transport management solution.
There is no “one size fits all” process for all industries and modes of
transportation. The truck/road-based transportation process is significantly
different depending on the transportation mode, e.g., rail, air, or CEP. SAP
TM has grown significantly in all areas over the past releases to meet the
functional requirements across industries.
Both the role of a shipper, as well as the business role of a transportation
service provider, demands the specifics that have been outlined in detail in the
previous chapters. The SAP TM roadmap looks promising and underlines the
strategic investment SAP has made into the solution suite for the supply chain
execution platform.
Specifically, with SAP EWM deployed on the same release and the same
technical basis, there will be a major integration point between SAP TM and
SAP EWM. New technologies such as SAP HANA and mobile capabilities will
pave the way for new use cases for SAP TM and will ensure that SAP TM will
continue to be a source of strength within the SAP solution suite.
Our Newsletter
Our newsletter will inform you about new publications and
exclusive free downloads.
Subscribe today!
newsletter.espresso-tutorials.com
A Authors

Anette Götz studied business administration at the Cooperative State


University in Mannheim, Germany. After joining SAP in 2006, Anette gained
deep insight into SAP’s supply chain management portfolio while working in
solution management, business development, and the presales teams in
Germany and Singapore. In 2009 she joined SAP Business Transformation
Consulting, specializing in transportation and logistics. Anette has since been
involved in multiple SCM projects, acting as a senior consultant, solution
architect, and team lead for the implementation of SAP Transportation
Management and SAP Event Management.
Aut hor Tobias Götz has a degree in industrial engineering from KIT
(Karlsruhe Institute of Technology). After working in management consulting
early in his career, Tobias joined SAP in 2001 and was responsible for the
first implementations of the transport management solution TP/VS in SAP
APO. Tobias held a number of roles at SAP and was responsible for field
enablement and business development in the SAP logistics and manufacturing
portfolio, including RFID and Event Management. He has been working as a
business transformation consultant since 2009, managing SAP TM
implementations. Since June 2015 Tobias has been a partner at KPS
consulting. Tobias has published multiple books in the SAP Transportation
Management field and is an associate professor at the Cooperative State
University of Mannheim, where he lectures on SAP’s transportation
management solution and SCM.
B Abbreviations
ABAP Advanced Business Application Programming
ABD Agency business document
ALE Application Link Enabling
B2B Business to business
BAdI Business Add-In
BAPI Business application interface
BRIM SAP Billing and Revenue Innovation Management
CASS Cargo Account Settlement System
CO-PA SAP ERP Controlling and Profitability Analysis
CRM SAP Customer Relationship Management
DTR Delivery-based transportation requirement
ECC SAP ERP Core Component
EDI Electronic data interchange
EHS SAP Environment, Health, and Safety Management
ERP SAP Enterprise Resource Planning
EWM SAP Extended Warehouse Management
FA Freight agreement
FB Freight booking
FCL Full container load
FI-CO SAP ERP Finance and Controlling
FO Freight order
FSD Freight settlement document
FTL Full truckload
FU Freight unit
FUBR Freight unit building rule
FWA Forwarding agreement
FWO Forwarding order
FWSD Forwarding settlement document
HAWB House air waybill
HBL House bill of lading
IATA International Air Transport Association
ID Identifier
IDoc Intermediate document
IMG Implementation Guide
LSP Logistics service provider
LTL Less than truckload
MAWB Master air waybill
MM SAP ERP Materials Management
NWBC SAP NetWeaver Business Client
OTR Order-based transportation requirement
PDF Portable document format
PI SAP Process Integration
POWL Personal Object Worklist
RFC Remote function call
RFQ Request for quotation
SCM SAP Supply Chain Management
SD SAP ERP Sales and Distribution
SES Service entry sheet
TCCS Transportation charge calculation sheet
TM SAP Transportation Management
TRQ Transportation requirement
UI User interface
ULD Unit load device
VSR Vehicle scheduling and routing
C Disclaimer
This publication contains references to the products of SAP SE.
SAP, R/3, SAP NetWeaver, Duet, PartnerEdge, ByDe¬sign, SAP
BusinessObjects Explorer, StreamWork, and other SAP products and
services mentioned herein as well as their respective logos are trademarks or
registered trademarks of SAP SE in Germany and other countries.
Business Objects and the Business Objects logo, BusinessObjects, Crystal
Reports, Crystal Decisions, Web Intelli¬gence, Xcelsius, and other Business
Objects products and services mentioned herein as well as their respective
logos are trademarks or registered trademarks of Business Objects Software
Ltd. Business Objects is an SAP company.
Sybase and Adaptive Server, iAnywhere, Sybase 365, SQL Anywhere, and
other Sybase products and services mentioned herein as well as their
respective logos are trademarks or registered trademarks of Sybase, Inc.
Sybase is an SAP company.
SAP SE is neither the author nor the publisher of this publication and is not
responsible for its content. SAP Group shall not be liable for errors or
omissions with respect to the materials. The only warranties for SAP Group
products and services are those that are set forth in the express warranty
statements accompanying such products and services, if any. Nothing herein
should be construed as constituting an additional warranty.
D Endnotes
1 The relationship between transportation requirement, freight unit, and freight
order/booking is not necessarily 1:1:1 but can take any form of x:y:z.
2Prerequisite for the communication via web services between SAP TM and
SAP ERP is that you are using SAP ECC 6.04 SP9 or higher. If you are using
an older SAP ERP release, you have to set up the communication via SAP
NetWeaver PI using IDocs.
3 The relationship between transportation requirement, freight unit, and freight
order/booking is not necessarily 1:1:1 but can take any form of x:y:z.
4 As introduced in Section 2.1, a transportation requirement (TRQ) is the
generic term for the three SAP TM documents: order-based transportation
requirement (OTR), delivery-based transportation requirement (DTR), and
forwarding order (FWO).
5 One exception is a special shortcut planning process where you can
automatically create a freight order (FO) from a transportation requirement
(TRQ). However, this is only possible if all items of the TRQ are to be
transported in one FO (i.e., there is a one-to-one relation between the TRQ
and FO).
6 You can use two different time frames in the freight unit for both pick-up and
delivery: the acceptable time frame, which is a hard constraint for the
optimizer, and the requested time frame. The planning costs for earliness and
lateness are calculated as delta between the planned time of the pick-
up/delivery and the requested time frame.
7 Further information on the dangerous goods content loader can be found in
the software download center of SAP Service Marketplace (go to
service.sap.com/swdc • Installations and Upgrades • A-Z Index • E • EHS
REGCONTDANGER GOODS).
8 BRF+ is a rules framework which allows you to easily and flexibly build
complex business rules by configuring decision tables.
More Espresso Tutorials eBooks
Claudia Jost:
First Steps in the SAP® Purchasing Processes (MM)

Compact manual for the SAP procurement processes


Comprehensive example with numerous illustrations
Master data, purchase requirements and goods receipt in context

Matthew Johnson:
SAP® Material Master—A Practical Guide

Understand SAP Master Concepts


Maximize Your Value Stream Through SAP Materials Management
(MM)
Walk Through Practical Implementation Examples

Björn Weber:
First Steps in the SAP® Production Processes (PP)

Compact manual for discrete production in SAP


Comprehensive example with numerous illustrations
Master data, resource planning and production orders in context
Avijit Dutta, Shreekant Shiralkar:
Demand Planning with SAP® APO — Concepts and Design

Step-by-Step Explanations and Easy to Follow Instructions


Combination of Theory, Business Relevance and ‘How to’
Approach
APO DP Concepts and Design using a Business Scenario
Centralized Process Flow Diagram to Illustrate Integration

Avijit Dutta, Shreekant Shiralkar:


Demand Planning with SAP® APO — Execution

Step-by-Step Explanations and Easy to Follow Instructions


Combination of Theory, Business Relevance and ‘How to’
Approach
APO DP Execution Explained using a Business Scenario
Centralized Process Flow Diagram to Illustrate Integration

Kevin Riddell, Rajen Iyver:


Practical Guide to SAP® GTS

Step-by-Step Explanations and Easy to Follow Instructions


Combination of Theory, Business Relevance and ‘How to’
Approach
APO DP Execution Explained using a Business Scenario
Centralized Process Flow Diagram to Illustrate Integration

You might also like

pFad - Phonifier reborn

Pfad - The Proxy pFad of © 2024 Garber Painting. All rights reserved.

Note: This service is not intended for secure transactions such as banking, social media, email, or purchasing. Use at your own risk. We assume no liability whatsoever for broken pages.


Alternative Proxies:

Alternative Proxy

pFad Proxy

pFad v3 Proxy

pFad v4 Proxy