In modern supply chains finding an effective and sustainable method of trading key information with suppliers is essential. As a result it’s no surprise that the demand for flexible and reliable electronic data interchange (EDI) solutions is growing. However, whilst the benefits of being able to trade automated messages with partners may be easy to see, many decision makers are unaware of the key differences between EDI solutions (and in particular the benefits of doing EDI via API), often wrongly assuming that different solutions essentially all do the same job.
In reality, EDI solutions vary wildly – from those that offer EDI via API to local EDI converter software. For example, there are a myriad of differences between on-premise and cloud-based EDI solutions – as we explore in detail in our white paper on this topic. Similarly, the amount of internal work required to set up and operate different solutions differs greatly between suppliers. In this article, however, we will look at perhaps the most important technical factor that separates adequate EDI solutions from excellent ones: API integration.
A brief overview of EDI solution types
When it comes to EDI solution types, there are two main categories: on-premise systems and cloud-based solutions. Those looking for a detailed comparison of the two can download our white paper on this topic, but for the purposes of this article let’s just look briefly at both…
On-premise EDI systems
In on-premise solutions your ERP system is connected to local converter software, which is responsible for mapping, adding signatures, routing and monitoring messages. Typically on-premise systems require a great deal of internal effort to maintain and are unable to connect directly to partners who do not have EDI capability (because local converter software does not offer Web EDI) or external networks such as VANs, Peppol etc. As a result, businesses’ internal EDI landscapes often become increasingly complicated as their partner network grows, with internal teams juggling point-to-point partner connections and connections to other networks and platforms.
Cloud based EDI solutions
If businesses lack either the resources to handle substantial data exchange or the desire/expertise to manage such automation internally, cloud-based EDI offers a simple solution.
By removing the need for organisations to install and operate separate EDI software in-house, cloud-based EDI frees up internal teams. While there is still variation in the amount of assistance offered by cloud-based providers, typically such providers will also oversee much of the connection and operation, with some (such as ecosio) even completely managing partner connections, message monitoring and error handling.
By greatly simplifying internal processes, a cloud-based solution often represents the most cost-effective and sustainable option. Further, with Web EDI it is also possible to connect to smaller “long tail” suppliers who do not have EDI capability.
How cloud-based EDI works
Cloud-based EDI enables you to outsource the routing and mapping of messages to a provider. This provider is then responsible for exchanging messages with your partners – either directly (if the partner is capable of conducting EDI in-house) or via your partner’s provider (as illustrated below).
When it comes to exchanging files with partners, your provider should be able to translate and send/receive virtually all file formats via whichever protocol is required. The choice of exchange method between your provider and partner is largely irrelevant as long as the correct data is sent and received by your provider.
From your perspective, the most important connection is that between your ERP system and your provider – known as the “last mile” – as this will have implications for data visibility and system usability.
In addition to doing EDI via API (which we will discuss in due course), there are several common methods used by EDI providers to connect to their customers. These include (but are not limited to):
- AS2
- OFTP2
- SFTP/FTPS
- Other (e.g. RFC in the case of SAP systems)
Although there are obviously differences between these methods (some of which are expanded on here) they all share key similarities.
- Lack of non-repudiation proof. Some protocols, such as SFTP or FTPS, do not allow for acknowledgements to be sent back from the receiver to the sender (at least not on a per-default basis). Thus, the sender has no proof that the receiver has actually received the sent file. While the transmission will work in most cases, the tracking of a message exchange – in particular in case of failures – is difficult. Modern protocols, such as AS2 or AS4, help to overcome this limitation.
- None of these connection types offers full process traceability. In other words, while the message and its contents are sent, one can only trace the delivery status of a message to the next network, but not beyond. In case of outbound messages this means that in the ERP system I can only see that the message has been received by the EDI service provider. However, I have no trace if the message has been received by the final recipient. Unfortunately, not even modern protocols such as AS2 or AS4 help here.
EDI via API
What is an Application Programming Interface (API)?
In short, an API is a collection of rules and protocols which specifies how the different components of applications should interact by defining exchange formats, exchange protocols, security requirements and so on.
How does it differ from other connection methods?
API connections differ from those mentioned above in that data is accessed directly via a dedicated interface. Because of the nature of the connection, metadata is not lost, meaning that information such as whether an order/invoice has been received by the EDI service provider or even the final message recipient (your partner) can be seen in your ERP’s existing user interface in real time. Needless to say this dramatically improves the efficiency of your supply chain whilst minimising the potential for mix-ups and errors to occur.
Further, if and when errors do occur, the depth of data visibility afforded by API connections allows for the user to ascertain where the problem has occurred and what needs to be done to resolve it quickly.
For example, let’s say you are waiting on a response from a supplier concerning an order you’ve sent. With other connection methods you may only be able to tell that your message was sent correctly and be left to assume that your partner received it. When conducting EDI via API, however, you may see that the order wasn’t received – in which case the order can be checked, corrected as necessary and resent.
Doing EDI via an API connection also affords the potential for full-text message searching within your ERP system (as offered by ecosio’s solution). This makes locating documents much faster, as users are able to use any identifiers such as article number.
As covered in our previous article, all the above benefits also apply to Peppol connections too.
ecosio’s solution
At ecosio we recognise the huge impact that easy access to comprehensive data can have on the efficiency of your supply chain. We are committed to making B2B integration as simple and hassle free as possible for businesses.
Central to ecosio’s solution is our API, which provides unparalleled data visibility and end-to-end monitoring within your existing user interface – meaning no additional systems and no frustrating bottlenecks. With ecosio’s EDI API, staying up-to-date with your company’s data exchange has never been simpler!
In addition to offering EDI via API, we also manage all aspects of EDI, from set-up to go-live, as well as maintenance monitoring, partner onboarding and error resolution – reducing pressure on in-house teams and leaving you to concentrate on whatever it is your business does best.
To find out more, please contact us.
Discover more about our updated product, ecosio.flow.
