To help you identify the best EDI method for your business, in this article we explore the four main approaches to conducting EDI – namely point-to-point connections, point-to-point connections using Platform-as-a-Service, unmanaged VANs and fully managed VANs.

1) Local point-to-point connections

These connections require a business to have a local EDI middleware on-premise. This software is often referred to as a local EDI converter. It is used to perform business document mappings between the ERP export/import format and the different formats of EDI partners and may also be used to establish individual connections with partners. As every connection is different there is limited scope for reuse of work, making this method highly time intensive. While mapping and connection templates can help to reduce the workload, all work eventually falls to in-house teams, including setup, monitoring, error resolution and updates. Thus, a highly skilled EDI team is a must to operate such a setup.

2) Point-to-point connections using Platform-as-a-Service

In essence the Platform-as-a-Service (or PaaS) method is exactly the same as local point-to-point connections using an EDI converter. The only difference is that this middleware software is now in the cloud. Some service offerings include pre-configured document mappings and connection assets, which must be tailored and configured to one’s needs.  As with local point-to-point connections, every connection requires a great deal of effort, which will either fall to internal teams or require additional services to be purchased.

Common examples of this type of solution include PaaS cloud offerings from EDI converter vendors or the SAP Cloud Platform Integration (CPI) solution.

Other examples of this kind include for instance MuleSoft or Microsoft Azure Logic Apps.

3) The traditional unmanaged VAN

In short, traditional unmanaged VANs offer businesses the opportunity to simplify message exchange processes by moving from the mesh model of point-to-point connections to the star model. Needing just a single connection to your internal system, a VAN acts as a post office, serving to deliver messages to EDI partners who are also connected to this network. However, whilst connection to an unmanaged VAN does simplify message sending, not all EDI partners connected to said VAN will have the same requirements when it comes to formats and document standards. As a result, work is still required to establish document mappings, before messages can be sent via the VAN.

The term “added value” originates from the fact that the network itself may provide additional “value” to its participants. Next to the fact that one may reach any participant in the network easily other added values include validation, message audits, monitoring, etc.

However, as we will explore, the extent of the “value” added differs greatly between different types of VAN.

With unmanaged VANs the value offered usually include only:

• A mailbox
• The ability to send via various protocols (e.g. AS2 and SFTP)
• The ability to trace messages up to the central network node, i.e., you will receive a technical acknowledgement such as an MDN in case of AS2, if the network node has received the message. However, no receipt about the delivery of the message to the final recipient is usually provided.

This is typically the extent of the value offered by these networks. Importantly, there is also a lot that they do not do that customers should be aware of. In particular…

• You have to do everything yourself! – Although less work is needed to send messages via a VAN than point-to-point, the work that remains (e.g. structuring and verifying messages) falls entirely to internal teams.
• There is no proactive support – Once connections are up and running, you and your partner alone are responsible for ensuring the connection is functioning correctly.
• No error alerts/notifications – When errors do occur it is easy for them to go unnoticed if suitable procedures are not put in place internally.

An easy way to think of an unmanaged VAN is like an email provider such as Gmail. Once you have an email mailbox you can send messages to anyone else with an email address. What you put in the email and how you manage your inbox is completely up to you, however. When you do experience problems it is also up to you to find the solutions – you will not be able to get hold of anyone at Google’s headquarters to assist, or even find a number to call. What’s more, unlike email, unfortunately unmanaged VANs are not free!

4) The full service managed EDI network (aka fully managed VAN)

Last, but by no means least, is using a fully managed VAN  – or as we prefer to say, B2B Network in the Cloud. As you would expect, this EDI method offers all the benefits of an unmanaged VAN but with key additional advantages, including…

• All protocols and document formats are supported – Rather than offering transmission via a limited number of protocols, fully managed VANs (such as ecosio) can typically handle transmission via all common protocols and map messages between all formats (e.g. EDIFACT, ANSI ASC X12, XML, etc.).
• Proactive monitoring and support – Rather than leaving the operation of the solution to you, a fully managed VAN should offer round-the-clock message monitoring. In addition, providers may offer (as ecosio does) proactive error resolution, meaning that often nothing is needed from you to fix an error – it may even be fixed without you ever knowing there was an issue!
• Web EDI – A Web EDI solution allows you to benefit from automated message exchange with all partners, no matter their current capabilities. Access to the benefits of Web EDI is only possible with a fully managed VAN.
• Merge/split functionality – As some ERP systems aren’t able to receive multi-document messages, a fully managed VAN will split the message to enable receipt. Similarly, to cater to partners with particular requirements (e.g. those who request only one transmission a day), fully managed VANs can merge messages and send them via a batch message.
• API integration – Whilst not offered by all fully managed VANs, an API connection between your ERP system and VAN can ensure vastly improved data visibility. In addition to allowing for access to real-time data for both you and your partners, such a connection offers full message traceability – right up to the final recipient (rather than just the network, as is the case with unmanaged VANs). This makes it possible to pinpoint where an issue is and what needs to be done to resolve it.
• E-invoicing solution – A fully managed VAN should be able to handle all your e-invoicing needs, no matter how disparate and complex. ecosio, for example, was one of the first certified Peppol access points and can exchange invoices in compliance with all national regulations.
• Cross-VAN communication (VAN interconnect) – In order to simplify users’ EDI landscapes and minimise the number of connections internal teams need to worry about, fully managed VANs offer cross-VAN communication. In many cases (as we shall explore later) this can save clients money.
• Verification – Fully managed VANs are able to verify sent messages to ensure that they are formatted correctly before they are transmitted to the recipient. Ideally this should be done automatically, alerting the sender instantly if something is wrong so that it can be fixed and the amended version resent.

By offering such services, not only do these fully managed VANs grant internal teams much more time to focus on more value-adding tasks, they also ensure the client is less likely to experience issues (as EDI experts are naturally better at EDI matters than non-specialised in-house IT teams). Thus, clients not only save time, but money and stress too.

Unlike ecosio, not all so-called “managed” VANs offer the full range of services and features listed here. Consequently, it is important to examine what services providers using different EDI methods actually offer (see our infographic “How much internal work is required to operate different VAN solutions”).

Want to discover a better solution?

This article is a snippet from our white paper Everything You Need to Know About VANs. In this paper we explore the various issues associated with different types of VANs, the benefits of doing EDI via API and what steps you can take to improve your EDI landscape and minimise VAN costs (among other topics).

Download your copy of our white paper Everything You Need to Know About VANs and find out how you can optimise your processes.

Alternatively, if you have any questions about EDI methods or any related topic, feel free to get in touch. We are always happy to help!

Discover more about our updated product, ecosio.flow.

Der Beitrag An Introduction to the Four Main EDI Methods erschien zuerst auf ecosio.

XRechnung overview

Things are getting serious as of November 27th 2018 – all federal ministries and constitutional bodies In Germany must be able to accept electronic invoices according to the XRechnung standard. All the other federal organisations will follow up a year later, on November 27th 2019, and will also have to accept XRechnung. Suppliers, on the other hand, will still be able to send paper and PDF invoices.

Paper invoices will then completely disappear from November 27th 2020 in this sector – suppliers will henceforth have to generate all their invoices electronically in XRechnung format for the public bodies. Paper invoices will not be accepted anymore after that. Therefore, it is time for any supplier of a federal agency to deal with the topic of XRechnung.

But what exactly is an XRechnung?

The XRechnung was developed in Germany as part of the implementation of the EU directive 2014/55/EU. This EU directive dictates the creation of an individual European standard for the core elements of an electronic invoice. The public bodies of the EU-member states will have to accept electronic invoices which comply with this European standard. The EU directive has already become reality – the EU-member states already developed the standard: today it is known as the EU invoice standard EN 16931.

Since every EU member state will have specific requirements for electronic invoices, the need arose to develop so called Core Invoice Usage Specifications (CIUS). As a matter of fact, the XRechnung is a CIUS for Germany, even though it is not the only CIUS in Germany.

From a technical point of view, an XRechnung is an XML file, which complies with the XML schema according to the European standard EN 16931 and further restrictions dictated by the XRechnung. The European Standard EN 16931 provides two types of XML schemas: Universal Business Language (UBL) and UN/CEFACT Cross Industry Invoice (CII).

For SAP systems this represents the first challenge. SAP systems are unable to populate UBL or CII data on the SD side (Sales and Distribution) out of the box.

Learn how to unlock the potential of EDI with ERP integration

Why Peppol?

Further to define a uniform e-invoicing standard, the protocol to be used to send e-invoices to the authorities must also be determined. In theory one could use the whole spectrum of communication protocols, the same way they are being used for B2B transactions, such as SFTP, AS2, X400 etc. This would result in the authorities having to support all those protocols, including the disadvantages each one may represent.

In order to define a uniform standard, the legislator had to fall back on a rather popular standard in the B2G area within the EU: Peppol. Peppol is the acronym for Pan-European Public Procurement OnLine and was developed by the European Union. Its goal is to simplify the communication between suppliers and public bodies for e-procurement.

Technically, Peppol is the definition of a delivery infrastructure for electronic documents.

Peppol consists of:

• The Peppol e-delivery network
• The Peppol document specifications, which determine the structure of the electronic documents (Peppol Business Interoperability Specifications – BIS)
• A legal framework, which regulates the collaboration within this network (Peppol Transport Infrastructure Agreement)

In order to send and receive via Peppol, one must be equipped with a Peppol Access Point. Since it might prove quite costly from a technical and organisational point of view to create and register an Access Point, most companies will resort to a specialised service provider, through which one can reach the Peppol network.

Do you have any questions?

Do you have further questions about XRechnung or how to connect SAP to Peppol? Feel free to contact us, we would love to help you!

Are you aware of our free XML/Peppol document validator?

To help those in need of a simple and easy way to validate formats and file types, from CII (Cross-Industry Invoice) to UBL, we’ve created a free online validator.

SAP ERP and SAP S/4HANA are the trademarks or registered trademarks of SAP SE or its affiliates in Germany and in several other countries. 

Der Beitrag How to connect SAP to Peppol to allow the exchange of XRechnung erschien zuerst auf ecosio.