“In SAP EWM selecting IDocs for communication to ERP instead of qRFCs, is this an option?”.
Thanks,
EB
I was asked recently: “In SAP EWM selecting IDocs for communication to ERP instead of qRFCs, is this an option?”.
So I thought writing a blog about this additional option wouldn’t hurt as there is little to no information available.
In this blog we will:
- find out for which scenarios IDocs can be an option to interface to decentral SAP EWM
- learn how to set it up
- see a possible project approach for connection to 3rd-party ERPs
- draw a conclusion (and get feedback)
Integration scenario
We will look into a 100% IDoc integration scenario as outlined in below picture. But what is it good for? Is it a new SAP recommendation? 
Non-SAP ERP to EWM integration scenario
Clearly SAP to SAP integration is done by using queue communication or qRFCs. It has so many advantages over IDoc communication: Completeness of process coverage, serialization of messages and many more.
However, it can be an option if EWM should integrate with a Non-SAP ERP system. IDoc adapters exist for most common middleware solutions and in the simplest setup it can be just provided as a file. Moreover, IDoc technology is old and mature. There are load distribution techniques inside ALE which can help balancing the message processing. There is even a simple serialization possible by IDoc.
Setting up SAP EWM IDoc integration
First, we need to define the client in which our SAP S/4HANA EWM will run as decentralized EWM. From that point on, SAP EWM is in the dentralized deployment mode and can be attached to SAP and Non-SAP systems.
In the next step we define the distribution model: If you worked with ALE/IDoc integration before transaction SALE is our good companion to achieve this task. We have to set up the logical systems for EWM and partner (Non-SAP) ERP and need to then define the message types. We will need master data and delivery data going into EWM and delivery confirmations (GR, GI) as well as goods movements (inventory difference postings, EWM-triggered postings) going out of EWM.
a) Ｍaster data
There’s a great recent article about S/4HANA EWM master data integration from Prakash Pol, read it to get all the insights for standard setup.
What we need is shown in the table:
We should set up all message types in EWM as reduced messages in SALE since only few fields are needed for warehouse operation. In SALE you would do it here. Reducing message types is a customizing activity.
SALE transaction: master data distribution
It’s usually an iterative approach to find the fields needed when integrating with a Non-SAP ERP. I would like to point again to aforementioned article for more information if you consider using the standard scenarios. When you are done with this exercise it should go into the distribution model.
b) Transaction data
As for delivery and goods movement data you want to use the following setup. Although there are more recent IDoc-types available, the function modules used for IDoc integration are limited to these versions (as of S/4HANA 1909, this can change).
You should be able to find the function modules when searching by /SCWM/IDOC_INPUT* and likewise for /SCWM/IDOC_OUTPUT_*.
At the end of the exercise your scenario should look something like this (maybe without my name in the message type 
):
Scenario in transaction BD64 – Lean setup for EWM
That’s it! Simple to integrate, right? 
In the next paragraph I’ll suggest an approach how Non-SAP ERPs can be integrated.
Accelerating Non-SAP ERP integration projects
We know how to set up S/4HANA EWM decentral deployment option for IDoc integration. What would come in a real project? There are two major areas of activity:
- Setting up SAP EWM to reflect the processes of the warehouse (consider peeking into best-practice processes! That’s a different story but make sure to look here: S/4HANA Best Practice Processes). Your team of SAP EWM consultants wants to play through the processes end-to-end and the business process owners want to see how their future system looks like!
- Going through interface development on Non-SAP ERP side or middleware integration. This involves reading a lot of specs usually and understanding requirements of both sides caused by business processes, industry and legacy definitions. It is often a separate team of experts within a warehousing project.
Problem: The interfaces are not ready when you want to test and demo your processes to the business! Also, giving clear requirements for master data fields and deliveries can be problematic if the EWM processes are just on paper.
In order to demo and test the future processes early in the project – and establish an early verification if I/F requirements towards legacy – we can make use of the fact that the IDocs used for integration have a history in SAP systems as well. They were used in the SAP decentral WMS!
Idea: We set up a separate client in the EWM development system (e.g. best-practice client setup for S/4HANA ERP) and integrate it to our SAP EWM. Later in the project we then retire this client and switch to the Non-SAP ERP test interfaces.
High-level approach outlined for Non-SAP / SAP EWM projects.
You can see from below that the warehouse integration from the test ERP-client is set as “Decentral WMS” that way activating IDoc communication to the decentral EWM client in the same system.
ERP test client: Decentral WMS setting for early test enablement
You can use the standard tools now for SAP WMS to create the distribution model or do it manually in WE20 transaction.
That way running through a complete Procure2Pay cycle is simple and enables your consultants to test the EWM processes as if the Non-SAP ERP would already be interfaced.
“Test-ERP” perspective of an inbound process
EWM decentral perspective from warehouse monitor
PPF action log when posting goods receipt in EWM. Note the IDoc related logging.
Conclusion
There are many ways to integrate with Non-SAP ERPs and above is one option. The approach you choose can look very different. What are your thoughts? I’m looking forward to your comments! Thank you! 
Thanks to Author Gunter Albrecht from SAP Japan Co.
I was asked recently: “In SAP EWM selecting IDocs for communication to ERP instead of qRFCs, is this an option?”.
So I thought writing a blog about this additional option wouldn’t hurt as there is little to no information available.
In this blog we will:
- find out for which scenarios IDocs can be an option to interface to decentral SAP EWM
- learn how to set it up
- see a possible project approach for connection to 3rd-party ERPs
- draw a conclusion (and get feedback)
Integration scenario
We will look into a 100% IDoc integration scenario as outlined in below picture. But what is it good for? Is it a new SAP recommendation?
Non-SAP ERP to EWM integration scenario
Clearly SAP to SAP integration is done by using queue communication or qRFCs. It has so many advantages over IDoc communication: Completeness of process coverage, serialization of messages and many more.
However, it can be an option if EWM should integrate with a Non-SAP ERP system. IDoc adapters exist for most common middleware solutions and in the simplest setup it can be just provided as a file. Moreover, IDoc technology is old and mature. There are load distribution techniques inside ALE which can help balancing the message processing. There is even a simple serialization possible by IDoc.
Setting up SAP EWM IDoc integration
First, we need to define the client in which our SAP S/4HANA EWM will run as decentralized EWM. From that point on, SAP EWM is in the dentralized deployment mode and can be attached to SAP and Non-SAP systems.
In the next step we define the distribution model: If you worked with ALE/IDoc integration before transaction SALE is our good companion to achieve this task. We have to set up the logical systems for EWM and partner (Non-SAP) ERP and need to then define the message types. We will need master data and delivery data going into EWM and delivery confirmations (GR, GI) as well as goods movements (inventory difference postings, EWM-triggered postings) going out of EWM.
a) Ｍaster data
There’s a great recent article about S/4HANA EWM master data integration from Prakash Pol, read it to get all the insights for standard setup.
What we need is shown in the table:
We should set up all message types in EWM as reduced messages in SALE since only few fields are needed for warehouse operation. In SALE you would do it here. Reducing message types is a customizing activity.
SALE transaction: master data distribution
It’s usually an iterative approach to find the fields needed when integrating with a Non-SAP ERP. I would like to point again to aforementioned article for more information if you consider using the standard scenarios. When you are done with this exercise it should go into the distribution model.
b) Transaction data
As for delivery and goods movement data you want to use the following setup. Although there are more recent IDoc-types available, the function modules used for IDoc integration are limited to these versions (as of S/4HANA 1909, this can change).
You should be able to find the function modules when searching by /SCWM/IDOC_INPUT* and likewise for /SCWM/IDOC_OUTPUT_*.
At the end of the exercise your scenario should look something like this (maybe without my name in the message type ):
Scenario in transaction BD64 – Lean setup for EWM
That’s it! Simple to integrate, right? In the next paragraph I’ll suggest an approach how Non-SAP ERPs can be integrated.
Accelerating Non-SAP ERP integration projects
We know how to set up S/4HANA EWM decentral deployment option for IDoc integration. What would come in a real project? There are two major areas of activity:
- Setting up SAP EWM to reflect the processes of the warehouse (consider peeking into best-practice processes! That’s a different story but make sure to look here: S/4HANA Best Practice Processes). Your team of SAP EWM consultants wants to play through the processes end-to-end and the business process owners want to see how their future system looks like!
- Going through interface development on Non-SAP ERP side or middleware integration. This involves reading a lot of specs usually and understanding requirements of both sides caused by business processes, industry and legacy definitions. It is often a separate team of experts within a warehousing project.
Problem: The interfaces are not ready when you want to test and demo your processes to the business! Also, giving clear requirements for master data fields and deliveries can be problematic if the EWM processes are just on paper.
In order to demo and test the future processes early in the project – and establish an early verification if I/F requirements towards legacy – we can make use of the fact that the IDocs used for integration have a history in SAP systems as well. They were used in the SAP decentral WMS!
Idea: We set up a separate client in the EWM development system (e.g. best-practice client setup for S/4HANA ERP) and integrate it to our SAP EWM. Later in the project we then retire this client and switch to the Non-SAP ERP test interfaces.
High-level approach outlined for Non-SAP / SAP EWM projects.
You can see from below that the warehouse integration from the test ERP-client is set as “Decentral WMS” that way activating IDoc communication to the decentral EWM client in the same system.
ERP test client: Decentral WMS setting for early test enablement
You can use the standard tools now for SAP WMS to create the distribution model or do it manually in WE20 transaction.
That way running through a complete Procure2Pay cycle is simple and enables your consultants to test the EWM processes as if the Non-SAP ERP would already be interfaced.
“Test-ERP” perspective of an inbound process
EWM decentral perspective from warehouse monitor
PPF action log when posting goods receipt in EWM. Note the IDoc related logging.
Conclusion
There are many ways to integrate with Non-SAP ERPs and above is one option. The approach you choose can look very different. What are your thoughts? I’m looking forward to your comments! Thank you!
Thanks to Author Gunter Albrecht from SAP Japan Co.
