Integration of SAP EWM with a third-party ERP system is technically possible. It will, however, require a feasibility analysis for your unique situation and should be structured as a subproject of its own within the EWM implementation project.
You should not underestimate the required effort. In this blog post, we will discuss some aspects that you should consider as part of the integration of a third-party ERP system with EWM. First, you will need to decide on an integration approach. There are two main approaches that appear feasible, the first of which represents the usual way, with the connection of the third-party ERP system with EWM via a middleware solution that takes care of mapping and routing the various messages. The figure below shows a potential system landscape for this approach. The second approach is a direct connection of the third-party ERP system with EWM (without middleware); however, this is not a sensible option in our view.
Integration with a Third-Party ERP System via Middleware: When integrating EWM with a third-party ERP system via a middleware solution, you must be aware that the middleware solution will probably require access to the metadata of all the interfaces used. Because EWM calls function modules from ERP in the outbound message processing, you must find a way to make the metadata of the respective ERP function modules available. One possible approach to this would be to retrieve the metadata from another ERP system, if available in your system landscape. Otherwise, you could define the ERP function modules at least in their structure in EWM or another repository system to make the necessary metadata available.
In addition, there is the possibility of putting an ERP system between the middleware and EWM. This approach is especially useful if you are already planning to introduce ERP sometime in the future. One possible advantage of this solution is that you can use the full functionality of the delivery interface and may have less customization and mapping effort with the interfaces between order management and inventory management in your ERP system. The additional integration of an SAP ERP or SAP S/4HANA system appears less disadvantageous if you plan to use it more extensively in the future anyway. In this setup, you would need to plan for additional configuration, testing, and migration effort.
See the figure below for a schematic diagram of this integration approach. You should accurately identify and weigh the advantages and disadvantages against your own situation, especially in the light of available integration possibilities and interfaces of the ERP system.
The next decision you have to make will concern the integration technology you will use: qRFC or IDoc. Integration with IDocs is intended to be a technically simpler solution, but it will also bring limited functionality of the delivery interface. The functional restrictions on IDocs are shown in the three tables below. If you will require functionality that is not possible to implement with IDocs, you may prefer the usage of the qRFC technology.
How-To Guide for IDoc-Based Non-SAP ERP Integration: SAP Note 3140478 provides information about connecting decentralized EWM to non-SAP ERP systems via IDoc-based interfaces as of SAP S/4HANA 2021 FPS 1. A how-to guide is available that shows how a basic scenario using inbound and/or outbound deliveries can be set up using ALE IDocs. You can find the guide named How to Integrate a Non-SAP ERP System with a Decentralized EWM on SAP S/4HANA via ALE IDoc in the SAP Community wiki at https://wiki.scn.sap.com/wiki/display/SCM/How-To+Guides+for+SAP+EWM.
The SAP ERP or SAP S/4HANA version control settings, mentioned at the beginning of this section, will enable you to configure the integration independently of the chosen integration technology (IDoc/qRFC) so that it will meet your functional requirements. The settings certainly do not support all of your integration requirements out of the box, though. You might, for example, want to prevent the possibility of cancelling goods receipt postings because your legacy ERP system will not support this. You can make such settings via the SAP ERP or SAP S/4HANA version control.
Preventing the Use of Outbound Delivery Splits: SAP Note 1600871 provides information about how to prevent the creation of split deliveries in EWM. Because your non-SAP ERP system will likely not support this SAP ERP/SAP S/4HANA feature, you should consider the information contained in this SAP Note.
In addition to these rather technical issues, you should not forget some key points of the functional system integration. Analyze the application architectures of your ERP system and of EWM in order to understand whether the systems’ logistical execution processing logics fit each other at all. The decisive factor here is the question of whether the necessary interfaces in the ERP system are already present, or at least conceptually feasible.
Furthermore, it is important to decide which of the two systems has to adapt to the prevailing conditions and the interface situation of the other. This question is not easily answered. It is good to argue that the EWM standard should not be changed, specifically to allow for a future connection to SAP ERP or SAP S/4HANA. On the other hand, changes to the existing ERP system might be difficult because it may be technically obsolete, poorly supported, or inadequately documented.
After clarification of the integration architecture, you should analyze the nature of the required interfaces and address the mapping of fields for each message. Stopping message processing by queue deregistration, as described earlier, will be essential to an understanding of which data is expected to be received and sent out by EWM. For this purpose, it is useful to have an SAP S/4HANA installation available that is integrated with EWM in order to understand how ERP communicates with EWM in various process scenarios with regard to messages and data.
Integration with a Third-Party ERP System via the Delivery Interface: SAP Note 1465477 provides five possible solutions for creating custom outbound messages or interfaces based on EWM deliveries. Should you plan for custom interfaces within your EWM implementation project, consider the information contained in the SAP Note for the technical solution design.
The final aspect that you need to consider when integrating with the third-party ERP system is the mapping of the stock models. EWM provides its own stock mapping in the inbound and outbound message processing in its integration with ERP. Particular importance is attached to the EWM stock type that is ultimately mapped to the ERP storage location and stock type via the availability group and the location-independent stock type and the stock type role. When integrating with a third-party ERP system, you will have to map the stock model of the third-party ERP system, not only to the EWM stock model, but also to the ERP stock model.
The interfaces only know the fields of the ERP stock model, which can prove to be a bottleneck in your integration project. Therefore, you either have to enhance the relevant interfaces with custom fields for stock data or map the stock model of the third-party ERP system to a “virtual” ERP stock model before it is again mapped to the EWM stock model in the EWM system itself. In the latter case, you would communicate stock data to EWM as if EWM was connected to ERP, which makes this aspect of the integration, at least from the EWM side, appear easy to handle. This approach is especially useful if you are planning to introduce ERP in the near future and might have already defined the setup of the ERP stock.
Editor’s note: This post has been adapted from a section of the book EWM with SAP S/4HANA: Architecture and Programming by Peter Zoellner, Robert Halm, Daniela Schapler, and Karen Schulze.
Comments