One of SAP’s main strengths is the level of “out-of-the-box” integration between various SAP solutions. When it comes to SAP Transportation Management (SAP TM), integration capabilities play a crucial role in differentiating it from other TMS products on the market. A relatively common requirement for SAP TM is the ability to integrate with SAP Extended Warehouse Management (SAP EWM) solution.
Customers looking to integrate their SAP TM and EWM systems are faced with several options due to the evolution of the integration over the years. In this article, we explain which options are available and provide recommendations on which option is best suited for which scenario. Keep in mind that, as we’ve mentioned in our SAP S/4HANA Embedded Transportation Management – FAQ blog post, the use of EWM integration options described below requires the purchase of the Advanced TM license (aka Supply Chain for Transportation Management) and cannot be achieved with Basic TM.
Loading Appointment (LDAP) Integration
The initial standard integration between SAP Transportation Management and SAP Extended Warehouse Management was delivered in 2013 as part of SAP Business Suite TM 9.0 release. This integration introduced two new SOAP web services that formed the foundation for SAP TM and EWM integration:
- TransportationOrderLoadingAppointmentRequest
- Web service call from SAP TM to SAP EWM enabling the creation of Transportation Unit (TU) in EWM from a Freight Order (FO) in SAP TM
- TransportationOrderLoadingAppointmentRequest
- TransportationOrderLoadingAppointmentNotification
- Web service call from SAP EWM to SAP TM updating the status of the Freight Order in SAP TM from the status updates in SAP EWM Transportation Unit
- TransportationOrderLoadingAppointmentNotification
The basic premise behind the integration was that SAP TM Freight Order would be replicated into SAP EWM as a Transportation Unit document which would then allow for applicable activities in the warehouse to happen at TU-level rather than individual delivery document level. For example, check-in and loading could be carried out by TU (which would be equivalent to TM Freight Order in this context) and thereby be more efficient. Once those activities have been completed in SAP Extended Warehouse Management, SAP Transportation Management would be notified, and applicable statuses would be updated on the Freight Order.
Although the LDAP integration option has been in place for almost a decade, it still suffers from many gaps and limitations. Here are some key limitations to be aware of:
- Only Road Freight Order is supported. Other TM transportation orders, such as Rail Freight Order, Ocean Booking, Air Booking) are not supported directly. The recommended workaround involves the creation of a pick-up Road Freight Order for the pre-carriage stage of the Booking. While this workaround is technically possible, the impact of introducing an extra document in TM for the pick-up leg should not be underestimated, especially in cases where the entire door-to-door move is contracted to a single freight forwarder.
- Handling of Freight Units with multiple stages is not supported
- Splitting of a single Delivery Transportation Requirement (DTR) into multiple Freight Units is not supported
- Direct creation of Freight Order from DTR (aka “shortcut scenario”) is not supported
- Consolidation of EWM-managed and non-EWM-managed deliveries in a single Freight Order is not supported
- Handling of Container Units from TM is not supported
- Vendor return purchase order process is not supported
From a deployment perspective, LDAP integration option makes sense whenever SAP TM and SAP EWM are deployed on separate SAP instances, since the ASR option discussed below is not available for such deployment.
However, it is important to keep in mind that even though LDAP integration is also technically supported in an environment where SAP Transportation Management and Extended Warehouse Management are co-deployed on the same SAP instance, such integration still relies on the use of SOAP web services to communicate data between TM and EWM. This means that TM and EWM communication will be subject to the same queuing and monitoring overhead as any other SAP SOAP-based integration across separate instances. For many customers, this is rightly viewed as a major downside of LDAP integration option.
Advanced Shipping and Receiving (ASR)
In February 2021 SAP introduced an alternative way of integrating SAP EWM and SAP TM as part of S/4HANA 2020 feature pack stack 1, called Advanced Shipping and Receiving (ASR). While not officially labeled as a replacement for LDAP integration by SAP (but rather an alternative), ASR is generally viewed as the logical successor to LDAP integration that will likely receive the most attention from SAP when it comes to future innovation and functional improvements.
The initial release of ASR in 2020 was only applicable to in-stack (aka embedded) deployment of SAP EWM and SAP TM on top of S/4HANA ERP digital core. However, in 2023 SAP extended ASR capabilities to extra-stack deployment (aka side-car or decentralized deployment) as part of S/4HANA 2023 release.
It is important to note that regardless of which deployment option is chosen for TM with S/4HANA ERP – in-stack vs extra-stack – the use of Advanced Shipping and Receiving requires the co-deployment of SAP EWM and SAP TM on the same “box”. In other words, if SAP Extended Warehouse Management and SAP Transportation Management are deployed on separate SAP systems/servers, then ASR is never available as an option, and integration can only be achieved via LDAP (described above). Therefore, companies should plan for co-deployment of EWM and TM at some point in their SAP roadmap, to take advantage of the innovations delivered as part of the new ASR integration.
One of the main advantages of ASR over the LDAP option is the removal of duplication of TM Freight Order into EWM Transportation Unit. Instead, EWM is able to access and rely on TM Freight Order data directly (since they are both housed in the same logical system). Additionally, ASR option does not require the use of SOAP-based web services to exchange data between EWM and TM, as data is directly available at the source via standard-delivered ABAP logic.
Given the fact that Advanced Shipping and Receiving is a relatively new SAP functionality, in many ways it currently suffers from arguably a larger set of limitations compared to the more mature LDAP integration option. However, in contrast to LDAP, many of ASR limitations are likely to be addressed sooner as part of SAP’s official roadmap. The following is a list of key limitations to be aware of when it comes to ASR capabilities in S/4HANA 2023:
- Only Road Freight Order is supported. Rail Freight Order, Ocean and Air Freight Bookings are not supported. Just like in LDAP, there is a possibility of a workaround via pick-up Road Freight Order, but that comes with its own possible set of challenges.
- Passive TM resources (trailers, container units) are not supported
- Combination of ASR and non-ASR shipping points on a single Freight order is not supported
- Cross-delivery Handling Units are not supported
- Logistics Service Provider scenario is not supported (for example Transit Warehousing)
- Additional limitations with decentralized deployment:
- Only outbound for sales order process is supported
- Inbound process is not supported
- Intra and inter-company Stock Transport Order scenario is not supported
- Subcontracting PO process is not supported
- Vendor returns process is not supported
- Customer return process is not supported
- Order-based planning in TM is not supported
- Freight settlement is not supported
- Additional limitations with decentralized deployment:
It is important to point out that the use of Advanced Shipping and Receiving in a decentralized deployment fundamentally changes the way outbound sales data is shared from SAP ERP to SAP TM. Instead of going through the traditional Transportation Requirement document integration, known as Order-based Transportation Requirement (OTR) and Delivery-based Transportation Requirement (DTR), in case of decentralized ASR the requirement is passed via SAP EWM Outbound Delivery Order (ODO) rather than coming from SAP ERP directly, which means that a) order-based planning is no longer possible, b) TM freight unit building happens from EWM ODO instead of TRQ documents and c) this currently breaks the ability to distribute freight costs for profitability analysis as part of freight settlement (we hope that this gap will be addressed very soon since it is a deal breaker to many SAP customers).
As we’ve noted before, the list of ASR limitations and features is bound to change significantly in the next few releases of S/4HANA. Refer to SAP notes 3243370 and 3018355 for the “latest and greatest” official list from SAP.
Custom Integration between SAP Transportation Management and EWM
There are some instances when standard LDAP and ASR integration options are not viable and a custom integration approach is required. This is typically caused by the following factors:
- Existing SAP EWM implementation is highly customized, and the use of standard LDAP/ASR integration is significantly misaligned with such existing customization
- Some of the items in the limitations mentioned above of LDAP and ASR options are deal breakers that cannot be addressed via a simple workaround or enhancement
- While both SAP EWM and SAP TM are deployed in the same “box”, the business requirements for their integration are relatively simple and can be achieved through a limited number of enhancements primarily dealing with a) releasing a document for further processing after some EWM or TM process step is completed and b) providing the ability for EWM to access TM’s data programmatically. In this scenario, the use of LDAP integration is often “overkill” due to the SOAP web service and queuing mechanism overhead, while ASR might be ruled out due to the large current number of gaps/limitations that we talked about above.
Every effort should be made to utilize standard integration between SAP EWM and SAP TM via the LDAP and ASR options. However, our experience shows that there are some exceptions in which the use of custom integration is warranted and is the “lesser of two evils”. This is especially true in cases where SAP’s standard integration comes with many limitations that are relevant for a particular implementation, and the effort associated with closing those gaps significantly outweighs the effort associated with custom integration.
