Skip to Content
Personal Insights

Integration: Non-SAP ERP and SAP S/4HANA EWM by IDoc

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:

  1. find out for which scenarios IDocs can be an option to interface to decentral SAP EWM
  2. learn how to set it up
  3. see a possible project approach for connection to 3rd-party ERPs
  4. 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%20ERP%20to%20EWM%20integration%20scenario

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) Master 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%20transaction%3A%20master%20data%20distribution

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 MBGMCA/ MBGMCA01 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:

  1. 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!
  2. 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%20approach%20outlined%20for%20Non-SAP%20/%20SAP%20EWM%20projects.

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%20test%20client%3A%20Decentral%20WMS%20setting%20for%20early%20test%20enablement

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

“Test-ERP” perspective of an inbound process

EWM%20decentral%20perspective%20from%20warehouse%20monitor

EWM decentral perspective from warehouse monitor

PPF%20action%20log%20when%20posting%20goods%20receipt%20in%20EWM.%20Note%20the%20IDoc%20related%20logging.

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! 😊

9 Comments
You must be Logged on to comment or reply to a post.
  • 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!

      /
      👍
  • 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