API has been a hot term in recent years and will definitely be one of the buzz words in 2022. In this blog I will present a use case in transportation management (TM) combined with extended warehouse management (eWM) on how we use application programming interfaces for our carrier integration.

The days of sending files asynchronously to notify your parcel carrier of truckloads are over. All major carriers (UPS, FedEx, DHL, Shunfeng, …) now offer integration via APIs. In my last implementation we have made an integration with all these carriers via APIs.

Request and receive quotations from carriers

When a parcel rolls off the packing belt and is completed in eWM, an API call is automatically launched to one or more carriers. Based on the destination and the size of the parcel they return their best quotes within seconds. All incoming quotes are displayed on a small RF scanner screen. The info is limited but it contains enough detail for you to make the right choices and scan the handling units or pallets on the shop floor.

Quote reply example

Shipment

When all the quotes are in and shown on the RF screen, you select the carrier and the service you want to go for. That immediately triggers a new API to book the carrier and the service.

You can also specify who will pay for the transport and the duties, if applicable. This is a very nice feature if you ship a lot EXW or FCA. Often your customer has better rates with a particular carrier. At order intake, you can capture his preferred carrier and account number, and take that into account when booking his parcels. When shipping dangerous goods, you can also include the data of SAP EHS – the Environment, Health, and Safety Management module – in your shipment call.

When the shipment is booked, you will receive a tracking number. You can use it to follow the further process.

Documents

We all know how exciting it is to develop a shipping label of UPS, for example, in SAP Smart Forms or PDF Builder. Bar codes, QR codes … lines everywhere. With the API this is no longer necessary. When the shipment is booked, you receive the shipping labels from the carriers. You only need to convert them to PDF and print them on the form. This works very quickly and you are independent of the carrier. If UPS decides to change their labels tomorrow, that’s fine. They will continue to send you the latest labels.

Next to shipping labels, the carrier will often provide you with pro forma invoices, dangerous goods labels, dangerous goods declarations, … This assuming, of course, that you pass on the data in the shipment API. Which brings us to the next point: how do you organize all those different calls to different carriers? We assume that all carriers need the same kind of information, such as the ship-to address, the dimensions of the handling units, … That is why in S/4HANA we created one structure per message with as much information as possible. All the data is aggregated into one big CDS view. S/4HANA always passes the same information to SAP Process Orchestration. SAP PO does the detailed mapping based on the carrier. For a new carrier, we just need to do the mapping in SAP PO without changing anything in the CDS in S/4HANA.

How is this linked to SAP Transportation Management?

After a successful shipment call the handling units are automatically linked to the transportation units in eWM and TM.

After the truck leaves, the freight order in TM is updated with all parcels assigned to the truck (via LDAP xml). We do not calculate the charges using rate tables, but we use the results from the quote that we have stored in our internal tables. This enables us to create a correct FSD (Freight settlement document) and, as result, a freight PO against the carrier. Thanks to this, we have almost no discrepancies whatsoever on incoming invoices. Of course, deviations still occur, for example if the package is larger than what the user has entered in eWM or when the driver has corrected an address when delivering the package.

Conclusions

Benefits

• No more label development
• Mobile solution: user can walk around while scanning packages
• Online choice of the cheapest carrier: on every call, we can compare rates of different carriers resulting in a lower freight invoice

Points of attention

• When the connection to a carrier is down, you cannot ship anymore. Although the big players have redundancy procedures, the local smaller partners might still run into stability issues.
• Time is important. You cannot create a bottleneck at your packing station because the API calls are slow. You cannot ask your user to wait 10 seconds for every parcel he scans. In developing the solution, we made it as lean and fast as possible.