Skip to Content

Electronic data interchange (EDI) is a concept of interchanging business-related documents electronically. As EDI has a history of more than 30 years many de facto standards have established e.g. X12, EDIFACT and ODETTE based on specific industry needs. Due to the fact that miscellaneous companies rely on communication through EDI SAP is glad to offer two different ways for customers to benefit from APIs in SAP S/4HANA Cloud. In dedicated projects customer can implement them to address their specific EDI requirements.

EDI Integration based on SAP S/4HANA Cloud buyer-side integration with SAP Ariba solutions

Right now, SAP S/4HANA Cloud is integrated to the Ariba Network on the buyer side, with procurement functions. The respective integration scenarios can be found on the SAP Best Practices Explorer. The Integration setup and the currently supported X12 and EDIFACT standards including the architecture is visualized in this picture:

 

 

EDI integration based on SAP S/4HANA Cloud SOAP APIs

With SAP S/4HANA Cloud, more modern, extensible and structurally simplified SOAP APIs are being provided and maintained by SAP on the SAP API Business Hub. Furthermore, SAP provides customers with EDI templates for ANSI X12 and EDIFACT. Customers, partners, or VANs could build the mapping between the APIs and EDI standards based on these templates. These templates are available in XSD format on the SAP API Business Hub:

The following illustration explains the described the EDI integration based on SAP S/4HANA Cloud SOAP APIs:

 

Check out the newly released scope items for customers using EDI with SAP S/4HANA Cloud, 2EJ for procurement https://rapid.sap.com/bp/scopeitems/2EJ , and 2EL for sales APIs https://rapid.sap.com/bp/scopeitems/2EL .

To report this post you need to login first.

1 Comment

You must be Logged on to comment or reply to a post.

  1. Mark Nolff

    Are the any plans to offer REST/JSON based equivalents of the SOAP API’s? I only ask because it seems that many organizations are moving away from SOAP to REST for API architectures. If a more structured API with a tighter contract is required in these use cases I could understand why SOAP might be a better fit.

    (0) 

Leave a Reply