Personal Insights
Integration: Non-SAP ERP and SAP S/4HANA EWM by IDoc
2nd Blog update — 23rd Jan 2022 — PLEASE NOTE
SAP has released the below described scenario of Non-SAP ERP to SAP S/4HANA EWM for S/4HANA 2021 FP01 onwards.
You can find the details in Note:
3140478 – IDOC Integration for non-SAP ERP systems and decentralized EWM in S/4 HANA.
There is a how-to guide released as well.
This means below blog is valid for (at the moment):
- SAP EWM 9.5 and lower
- SAP S/4HANA 2021 FP01 EWM onwards until further notice.
1st Blog update — 9th Nov 2020 — PLEASE NOTE
I was informed by product management that integration by IDoc is not a supported scenario within S/4HANA EWM. It is supported with SAP EWM 9.5 (and lower), though.
You can find the details in:
2938308 – Release information and restrictions of Decentralized EWM on SAP S/4HANA 2020 or
2806070 – SAP S/4HANA 1909: Release information and restrictions for EWM in SAP S/4HANA
You will find that information in the “deployment differences” document which is an attached PDF within each note.
Introduction
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, read it to get all the insights for standard setup.
What we need is shown in the table:
| Message type | Comments |
|---|---|
| MATMAS | Material master from the leading system. SAP EWM will convert this IDoc by standard processing to a product for immediate usage in warehouse processes. |
| CREMAS | Supplier/ Vendor master data. SAP EWM will convert it by the standard CVI to a business partner with the according role. |
| DEBMAS | Customer master data. SAP EWM will convert it by the standard CVI to a business partner with the according role. |
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).
| ⇧⇩ | Message type/ IDoc type | Comments |
|---|---|---|
| I | SHP_IBDLV_SAVE_REPLICA/ SHP_IBDLV_SAVE_REPLICA02 | Inbound delivery from Non-SAP ERP |
| I | SHP_OBDLV_SAVE_REPLICA/ SHP_OBDLV_SAVE_REPLICA02 | Outbound delivery from Non-SAP ERP |
| O | SHP_IBDLV_CONFIRM_DECENTRAL/ SHP_IBDLV_CONFIRM_DECENTRAL03 | Goods receipt for inbound delivery to Non-SAP ERP |
| O | SHP_IBDLV_CONFIRM_DECENTRAL/ SHP_OBDLV_CONFIRM_DECENTRAL03 | Goods issue for outbound delivery to Non-SAP ERP |
| O | SHP_OBDLV_SPLIT_DECENTRAL/ SHP_OBDLV_SPLIT_DECENTRAL01 | Split information (if EWM needs to split an outbound delivery) |
| O | MBGMCR/ MBGMCR03 | Goods movement posting to Non-SAP ERP |
| O | Cancellation of goods movement. Note: This message seems to be dysfunctional. The EWM module exists but without code. |
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! ?
Great piece of writing!
Excellent information. Great Thanks!
@Gunter Albrecht,
Thanks for sharing a very useful information in this blog post.
Best Regards
RD
Absolutely useful, thanks! We are just setting up IDOC Integration with a decentralized EWM 9.4 with S/41909
Great work Gunter..we missed an article of this kind on this topic.
As an alternative approach, and also to support a future scalability towards a ERP SAP, what about putting a S4 ERP as a “middleware” in the between of EWM and the non-SAP ERP? in this way we can ensure standard integrations EWM-ERP and only integrate MM/SD with the legacy system, by using Idocs ofc!
Hi Simone,
that’s indeed another way
and I have done that in the past with SAP ECC and SAP decentral WMS. We processed the goods receipt in decentral WMS as unplanned and submitted the PO# as part of the MBGMCR IDoc going into ERP from where an interface informed the Non-SAP ERP of the GR. The O2C was done by creating sales orders through ORDERS IDoc from Non-SAP ERP to ECC. From there standard WMS process. We submitted pricing into the SO so billing documents could be printed.
Downside of that approach is the overhead (surplus data volume through SD, customizing for minimal SD/MM, …) and potential license implications which depend on the individual situation.
Certainly it depends on what the Non-SAP ERP can deliver as I/Fs and how they are structured towards SAP S/4HANA EWM. Note: MATMAS, CREMAS, DEBMAS reduced to the minimum possible (basic data only) are sufficient to post a standard process!
So we have to consider the queue on our own.
Hi Gunther, I would like to congratulate you for the initiative in writing this excellent Post, it is very rare to find topics like this.
I would like to request your permission to translate it into Portuguese and Spanish and share it on my Dashboard and placing you as the author, would it be possible?
Thank you very much and again Congratulations.
Alexandre Santos
EWM Solution Architect
Hi Alexandre, good to hear it’s useful and feel free to translate it as you suggested. Happy weekend! ??
Hallo Günther,
With stock room management, the possibility of connecting to an external WMS via WM- IDOCs is no longer there.
Connecting to an external WMS through EWM- IDOC (*SUMO, *CATO etc) in case of a decentralized EWM S/4 seems to be possible.
Can I connect with the same IDOCs to an external WMS having embedded EWM S/4?
Can you please support me on that one?
Thank you,
Rollo
Good day Rollo,
I suppose you refer to the EWM-WCU (warehouse control unit) configuration? Yes this can be done, in both embedded or decentral. I've set up this scenario recently in S/4HANA 1909 embedded, so writing a tiny blog about it might be useful?
Regards,
Gunter
arigato! 🙂
Here's the according article: https://blogs.sap.com/2020/12/28/integration-sap-s-4hana-ewm-to-warehouse-automation-wcu/
Happy new year!
Gunter Albrecht ,
I am trying to connect a non SAP ERP to EWM 9.5, could you please share what standard IDOC types i could use for setting up materials, vendor , plant , shipping points etc?
I do not see MATMAS , CREMAS and DEBMAS in my EWM system. If search for *mat* i only see
AMAT01 (Adopt R/3 Material Data (second))
Thanks
Ritesh
Hi Ritesh,
plant, shipping point are organizational elements which are important in ERP but don't exist in SAP EWM. So you would only need to consider them as far as you need them in the customizing of the ERP/EWM interface (the part from the EWM perspective).
As for CREMAS, DEBMAS, MATMAS you bring up a good point! The CVI interface (Customer/Vendor integration to business partner) and the material to product conversion is only available in S/4HANA. From ECC this is done by the CIF interface.
Now, how would you integrate? For materials you can use the BAPI BAPI_PRDSRVAPS_SAVEMULTI2 which also has an ALE message type and 5 IDoc-type versions. I have set up an integration some years ago with this BAPI - at that time we used a Z-Message type which called the aforementioned BAPI to create or modify the product. If you use the existing message type you should have this running in no time on a prototype basis.
As for customer and vendor you need to do likewise with the BAPI FM BAPI_BUPA_CENTRAL_CHANGE. Here, you have to encapsulate it into your own IDoc FM and need to define your own IDoc type and message type (at least to my knowledge considering EWM9.5).
The standard then covers you completely for the delivery processing and goods movements. Does this help?
Gunter
Hi Gunter Albrecht,
Thank you for the reply , it helped a lot. Could you please also share your thoughts on below.
Thanks
RD
Hi Ritesh Dube,
I hope you enjoy a relaxing year-end! To answer your questions:
WE19 – Test IDoc for product creation from Non-SAP ERP
BD87 – Successful creation and change of product by IDoc
SAP EWM – Product global data view from IDoc creation
WE20 – Partner profile for product inbound EWM
That test setup took me ca. 15mins – so give it a try, I used the latests 06 version, others should work, too.
Cheers,
Gunter
Hi Gunter
Thanks for sharing.
Since IDOC integration is not supported in EWM on S/4HANA do you know which alternative SAP has provided to integrate non-SAP system? I could not find any SAP note about this topic.
Thanks,
Vitor
Vitor Lins Vieira please check the blog update, it took a while but might still be helpful!
@Gunter Albrecht,
Thanks for sharing good insights here.
With this content it appears that before S4HANA 2021 FPS01, the non SAP ERP integration is not available in SAP as standard. We are on S4HANA 2021 initial stack and I can't see these available options in configuration for Non SAP ERP.
if this is true can you share some insights on the best way to integrate please in S4HANA 2021 initial stack.
Regards,
Dinesh
Hi Dinesh Hiran ,
I'm not part of SAP product management for EWM. Since you "just" need to upgrade to FP01 certainly this is the easiest option. There might be no backport to S/4HANA 2021.