Before we answer these questions, let’s first explore how EDI and APIs work and the pros and cons of each.

How EDI works

EDI itself isn’t really a technology; it’s more like a method of B2B communication. In a nutshell, EDI is the means by which business partners exchange structured information such as orders, invoices and delivery notes with one another.

Sending an EDI message involves condensing the relevant data that one wishes to send into a specific computer-readable file format. This simple file is then transmitted to the recipient via an agreed transfer protocol, after which the recipient’s system then automatically reads, extracts and stores the data.

For a more detailed breakdown of how EDI works, please see our “What is EDI?” article.

The benefits of EDI

• Security. EDI is conduced using closed networks such as X.400 or VANs or by using dedicated point to point connections – e.g. based on AS2, SFTP or OFTP2. The security credential exchange with the business partner is usually done via a secure channel – e.g. in case of ecosio using the ecosio.monitor. Plain APIs are often secured with HTTP Basic Authentication or Bearer Tokens, whereby the exchange of the security credentials is not clearly defined. More modern approaches such as OAuth2, however, are successfully trying to overcome this limitation, by introducing a central identity provider.
• Popularity. As it has been around for decades, EDI is used by businesses worldwide and across all industries. Today it is by far the most popular method of exchanging business-critical information with partners and is thus the logical choice for those debating EDI vs API. 
• Time-saving. By vastly reducing the number of manual tasks involved in sending/receiving B2B documentation, EDI allows internal teams to focus on more value-adding tasks while simultaneously reducing the potential for human errors.
• Low message size. Compared to other methods of exchanging data, such as via email or JSON, sending messages via EDI standards (with the exception of XML) requires much less bandwidth..

The limitations of EDI

• Batch processing. In most EDI scenarios messages are sent and received in batches (e.g. once a day) rather than one at a time. While this may not be a big issue for some, it does prevent real-time data visibility. This in turn impacts the ability of businesses to respond quickly to new information – e.g. by updating inventory levels.
• Partner-specific communication channels. Though EDI can be used by companies to connect them with thousands of partners, each partner connection must be set up individually. For customers, this typically involves providing suppliers with a message implementation guide (MIG) which specifies the desired file format and transfer protocol. The supplier then needs to conduct technical mapping to ensure information can be correctly converted from their inhouse format to the required EDI format. Once this is done, they must then send test messages via the agreed protocol before the connection is made live.
• Limited traceability. In traditional EDI exchanges, it generally isn’t possible to see whether or not a message has been received by the final recipient. Even when modern protocols such as AS4 are used, the sender can typically only see when a message reaches the EDI service provider (a bit like seeing just one grey tick on WhatsApp and not two blue ticks).

What is REST API?

REST stands for Representational State Transfer. REST itself isn’t a protocol. It’s a widely employed method of writing APIs. APIs inherently lack a standardised composition. Instead, their structure is dependent on messaging formats such as JSON, with REST relying on HTTP(S).

The benefits of APIs

• Speed. With APIs there’s no need to wait for the other side to send information; instead relevant data can be pulled automatically as soon as it becomes available. In fast moving supply chains this can be extremely useful.
• Flexibility. APIs are by their nature flexible, as there are few rules and standards concerning how data must be used. This makes APIs a fantastic tool for software developers as they can be integrated into existing and emerging solutions to boost performance, whether this involves pulling relevant data periodically or receiving data instantly via POST.

• Simplicity. Unlike with EDI, with APIs there’s no need for data to be transformed to and from different encrypted formats. Instead, the API connects systems (e.g. ERP systems) directly, meaning data is automatically updated in the relevant place.
• Less specialised. As APIs are used in a myriad of different scenarios, knowledge of how to use APIs is not limited to individuals with experience in certain industries – something that cannot be said for EDI expertise. All web developers should have at least a basic understanding of how to use APIs.

The limitations of APIs

• Scalability. As every business’s data is structured and stored differently, no two APIs are the same. As a result, unlike with EDI, where mappings between common EDI file formats and your inhouse format can be reused as the semantics of the data being exchanged is standardised, every API-based connection requires a bespoke technical setup. Similarly, there is also no standardised way of designing APIs, meaning there is no agreed process choreography. For example, whereas one partner might request a purchase order response, another may simply take a successful order placement as confirmation – a situation that can easily lead to issues.

• Popularity. When it comes to the EDI vs API debate concerning B2B interactions, this is a key issue. Thanks largely to the lack of scalability offered by APIs, the vast majority of supply chain organisations prefer to exchange information via EDI, with many larger customers simply refusing to work with suppliers who cannot conduct EDI.

• Security. While an API may be extremely useful in some cases – e.g. allowing all potential partners to see your full product catalogue master data – it isn’t suitable for exchanging sensitive information.
• Missing information. APIs typically don’t include information such as logical sender address, receiver address or document type definitions. Although these aren’t required in point-to-point scenarios, they are extremely important when communicating with the third-party-networks used by large businesses.
• Internet-dependent. As APIs depend on a stable internet connection, if and when you experience internet connectivity issues, it will not be possible to retrieve information via API.

Why APIs won’t replace EDI

Having examined the benefits of APIs, one could be forgiven for concluding that APIs will replace EDI as the main method by which B2B partners exchange information. Undoubtedly, APIs do offer considerable advantages when it comes to streamlining B2B interactions. In particular, EDI cannot compete with the speed with which APIs allow information to be fetched, the depth of integration API’s offer into existing systems, or the data visibility APIs provide.

However, there is one key reason why APIs will never ultimately win the EDI vs API battle… the need for bespoke processes.

Until such a time as universally acknowledged rules are created for APIs and their usage in supply chains, all API integrations will involve unique technical requirements and must therefore be handled individually. Although APIs may be great for a single point-to-point connection between two partners, it is simply not possible to use the same approach for a wide partner landscape. Imagine a supplier with hundreds of customers, for example. If APIs were used for each connection, potentially every customer could demand that the supplier follows a different process. This would involve a huge amount of time and effort.

By contrast, EDI usage has continued to grow over the decades as its insistence on the use of accepted file formats and standardised processes enables connections to be established much faster and for previous mapping work to be reused. Similarly, EDI’s methodology and focus on standardisation also ensures the right data is exchanged and makes it easy to test multiple different business scenarios, in turn helping to avoid issues further down the line.

Why the future is EDI + API, not EDI vs API

While APIs will never replace EDI for the reasons explained above, this doesn’t mean that APIs can’t help to boost the efficiency of B2B communication. In fact, used properly, APIs can transform EDI solutions by providing functionalities previously out of reach to EDI users.

For example, two of EDIs major limitations – namely its limited data visibility and reliance on batch processing – can be essentially eliminated by incorporating APIs. While converting internal data into agreed formats and transmitting this data to partners via secure protocols still offers the most efficient solution for exchanging critical B2B information, APIs can streamline the process at either end by allowing relevant systems to talk to one another. By incorporating APIs into EDI processes, users can experience end-to-end message visibility, allowing them to see whether or not partners have received or acknowledged a message in real time. Meanwhile, by integrating an EDI solution into your ERP system via API, EDI data can be made accessible to any and all relevant individuals within your existing user interface, ensuring that EDI doesn’t become a black box.

Similarly, the rapid rise of country-specific e-invoicing requirements presents another arena where APIs can improve the efficiency of EDI solutions, with API usage even mandated by public administrations in some countries. 

In conclusion, although there is certainly some overlap in what API and EDI do, they each have their own separate domains. It’s therefore pointless to picture the situation as EDI vs API. They aren’t enemies, but rather tools that can be combined intelligently to create flexible yet secure B2B integration solutions.

How ecosio EDI solution works

At ecosio we’re acutely aware of the benefits of combining EDI expertise with a powerful API and have developed a unique solution incorporating API to help our clients achieve maximum automation with minimum effort.

As illustrated below, the technical hub of ecosio EDI solution is called the Integration Hub. This is located in the cloud, and is where all the technical mapping and routing work is done by ecosio’s EDI experts to connect you to your partners. Crucially, rather than requiring clients to send data to the Integration Hub manually, ecosio EDI solution is integrated directly into clients’ ERP systems. 

This deep integration enables you to benefit from unmatched data visibility and real-time monitoring within your existing user interface. The result? No need for additional systems, no more frustrating bottlenecks, and no more silent message failures.

What’s more, thanks to ecosio’s ongoing message monitoring, when errors do occur, they are identified and resolved proactively by our EDI experts, leaving your team free to focus on more value-adding activities.

Discover more about our updated product, ecosio.flow.

Der Beitrag EDI vs API: A Battle of Brothers erschien zuerst auf ecosio.

E-invoicing in Romania: the story so far

The gradual implementation of B2B and B2G electronic invoicing in Romania first started to take shape back in September 2021, when the country’s Ministry of Public Finance published a draft on the enablement of B2G e-invoicing via an existing national system called RO e-Factura. RO e-Factura is an IT system for reporting, storing and downloading invoices through the ANAF (The National Agency for Fiscal Administration) server. 

The implementation of e-invoicing via RO e-Factura took place during a pilot programme, created to test B2G e-invoicing within the system. E-invoicing became operational from 1 October that same year under Ordinance no. 120/2021, which regulated the e-Factura system. 

By December 2021, the country was taking its first steps towards a nationwide e-invoicing mandate, with Order no. 1366/2021 from 5 November 2021 approving the technical specifications and basic elements of the e-invoicing format RO_CIUS nationwide. At this stage, B2G e-invoicing was optional for taxpayers, as was B2B e-invoicing, but solely under the condition that both senders and recipients of the e-invoice were registered in the e-Factura registry. 

In January 2022 Romania announced a move away from the voluntary use of e-invoicing, stating that B2B taxpayers supplying high tax risk products – products which bring about a high risk of tax fraud and evasion – would be obliged to use electronic invoices using the RO e-Factura system from 1 July 2022.

Products which fall under the category “high tax risk” (i.e. susceptible to tax evasion) include: 

• Fruit and vegetables
• Alcohol
• Construction materials
• Mineral products
• Clothing and footwear

In January 2022, Romania applied to the EU commission for a derogation in order to bring about obligatory e-invoicing via the country’s e-Factura invoicing system for all transactions carried out between taxpayers in the Romanian territory. In order to enforce mandatory e-invoicing, the country’s government requested authorisation from the European Commission to apply an exception to Articles 178, 218, and 232 of Directive 2006/112/EC on VAT.

On 1 July 2022 Romania announced that:

• Romanian taxpayers were obligated to issue e-invoices for B2G transactions via RO e-Factura
• Taxpayers supplying or receiving high tax risk products as part of a B2B arrangement would be obliged to use e-invoices via RO e-Factura

In June 2023, it was announced that the European Commission had published a draft authorising the implementation of mandatory B2B electronic invoicing in Romania from 1 January 2024. This authorisation will remain in place for three years (from January 2024 until December 2026) or until the ViDA (VAT in the Digital Age) proposal is adopted by the EU. 

What is ViDA? 

ViDA (VAT in the Digital Age) is a strategy put together by the EU Commission to ensure fair and straightforward taxation for businesses. It outlines how tax authorities can utilise technology to combat tax evasion and fraud, help organisations and ensure that current VAT legislation is appropriate and necessary for businesses operating in the digital age.

On 19 September 2023 a draft decree was published which stated that the shift to a clearance model in Romania will be pushed back to 1 July 2024. Between 1 January 2024 and 1 July 2024 Romanian taxpayers will need to send their invoice to the e-Factura platform within five days of issue.

Current Romanian e-invoicing requirements

At the time of writing, all Romanian companies supplying high tax risk products are mandated to issue e-invoices using the RO e-Factura system

As we’ve seen, since July 2022 there has been a mandate in Romania for all companies that supply high tax risk products to other businesses to use the national e-Factura infrastructure for the issuing of e-invoices. 

Additionally, regulation changes are expected that will see obligatory e-invoicing for all Romanian businesses from 2024.

Upcoming changes

From 1 July 2024, there will be mandatory e-invoicing for all B2B transactions across Romania using the RO e-Factura system, in addition to the existing requirement for B2G e-invoicing and B2B e-invoicing for high tax risk products.

From the start of 2024 until this deadline, taxpayers will need to send invoices to the e-Factura platform within five days of issue.

How to prepare for the changes

Here’s a short list of what your business can do now in preparation for the changes to Romanian e-invoicing regulations…

1) Review your current resources 

Before making any decisions as to your preferred e-invoicing solution, it’s important to conduct a thorough audit of your internal resources – both technical and human. When performing an internal inventory, ask yourself the following questions: 

• On average, how many invoices is the company sending and receiving every month? 
• Does our current e-invoicing solution depend on a few individuals with specific knowledge? 
• How easily could our current e-invoicing solution be adapted to work with the RO e-Factura system? 
• How informed are the relevant individuals on the upcoming regulatory changes regarding invoicing in Romania?

2) Avoid short term thinking 

While it’s important to prepare your company and employees for the upcoming regulatory changes, it would be foolhardy to assume that these are the last e-invoicing regulatory changes your company will need to adapt to. In fact, e-invoicing requirements are only likely to become more complex as your partner network expands and governments introduce increasingly specific regulations. 

To ensure you’re fully prepared for whatever changes might affect your business in the future, it’s worth selecting a flexible e-invoicing tool that is able to adapt to your specific needs. For those businesses without extensive in-house e-invoicing expertise, this almost certainly means outsourcing effort and responsibility to an external e-invoicing solutions provider such as ecosio.

3) Don’t leave it to the last minute 

The implementation of a new e-invoicing solution can seem like an inconvenience that some businesses may be tempted to postpone. However, doing so only causes bigger issues later on. You’ll need to update your e-invoicing system at some point, and leaving it to the last minute means you have less time to fully evaluate the available options, and a much greater chance of choosing an ill-fitting solution.

For these reasons, we strongly recommend taking the time to investigate the best e-invoicing solutions for you as early as possible. As well as avoiding the unwanted disruption caused by leaving it too late, we’ve also found that companies who prioritise choosing their new e-invoicing tool in a timely manner reap many benefits from doing so – from saving time and money to reducing risk and boosting competitive advantage. Try to see the implementation of a new e-invoicing solution as an opportunity to enhance your current business strategy and boost efficiency moving forward.

4) Stay abreast of e-invoicing developments 

E-invoicing regulations are constantly being updated the world over. As a result, staying ahead of the changes can seem like rather a daunting task. But don’t worry! With ecosio’s e-invoicing newsletter you can get global e-invoicing updates straight to your inbox. Simply enter your details and you’ll be among the first to hear of all the latest developments in the field as and when they happen. 

Three things to consider when selecting an e-invoicing provider

When evaluating different e-invoicing solution providers, asking the following questions should help you determine which one is a good fit for your company:

1) Can they streamline the entire e-invoicing process? 

While some e-invoicing solution providers, like ecosio, offer a fully managed service, others require companies to take on some of the internal tasks required to achieve a streamlined e-invoicing process themselves. Before committing to a solution, be sure to get a full rundown of exactly what the e-invoicing service is prepared to offer and how much additional internal work will be required from your team.  

2) Do they provide an API connection? 

By connecting to your EDI provider via API, it’s possible for invoicing data to be seamlessly and automatically sent to and from your internal accounting system or ERP. This significantly improves data visibility and accessibility for internal teams, in turn reducing the likelihood of errors occurring.

For more information on the benefits of such an approach, see our detailed article on the benefits of conducting EDI via API. 

3) Are they a certified Peppol Access Point? 

As compliance with Peppol is already a mandatory requirement in many countries, selecting an e-invoicing solution provider that is also a certified Peppol Access Point (as ecosio is) is important. 

Without access to the Peppol network, you will be unable to meet e-invoicing requirements in many countries and will therefore need to enlist the help of another e-invoicing solution provider should you wish to do business in those areas in the future.

Conclusion 

Hopefully this breakdown of e-invoicing in Romania has provided you with the information you need to prepare your team for the upcoming regulation changes. 

To ensure you don’t miss any further updates, register now for the ecosio e-invoicing newsletter. You’ll get the latest e-invoicing news straight to your inbox! 

Der Beitrag E-invoicing in Romania erschien zuerst auf ecosio.

With the end of each year comes an inevitable desire to look back over the last few years to assess what has happened, and wonder what the years ahead are likely to bring. Unfortunately, however, when it comes to predictions regarding the future of EDI and B2B integration, industry commentators have a poor track record. Many of those who have peered into the tea leaves in an attempt to discern what the future holds for EDI have forecasted its swift demise. In spite of these predictions, however, EDI is still here and still going strong.

Yet the question of whether EDI will still be essential to supply chains in the future is still a valid one. Thanks to the emergence and continued development of potentially game-changing technologies such as AI, APIs and blockchain in recent years, fresh questions are being asked of EDI. Perhaps the most prevalent of these is ‘will EDI be able to incorporate these new developments or be superseded by them?’

By considering the views of industry commentators and addressing each of these new technologies and their potential relationship with EDI moving forward, in this article we aim to answer this question and provide clarity on a topic historically clouded by complexity and conjecture.

EDI’s History

In order to predict what the future holds for EDI it is first necessary to consider its history.

Although computer systems couldn’t exchange data until the 1960s, EDI’s roots date back to a system developed by US Army Master Sergeant Ed Guilbert for managing cargo information during the Berlin airlift of 1948-9.

By 1965 Guilbert’s original paper-based system had evolved into an electronic one, and the first EDI messages were sent in the form of trans-Atlantic cargo documents via telex.  Inevitably, as technology improved, faster and more efficient methods of data exchange were developed. However, universally recognised standards were needed to avoid confusion. Consequently, the Transportation Data Coordinating Committee (TDCC) was formed in 1968 by US automotive transport organisations, and released the first EDI standards in 1975. Six years later the American National Standards Institute published the first multi-industry national standard, X12, which was followed by the creation by the United Nations of a global standard, UN/EDIFACT, in 1985.

Significantly, the 90s brought the need for new protocols governing the transmission of EDI over the public Internet (EDIINT). This led to the creation of protocols AS1, AS2, AS3 and AS4, based on Simple Mail Transfer Protocol (SMTP), Hypertext Transfer Protocol (HTTP), File Transfer Protocol (FTP) and Web Services respectively.

Why EDI is still standing

Since its inception, EDI has been constantly evolving alongside technological developments as businesses demand faster and more efficient document exchange processes. Such has been the hype surrounding some of these developments (like the introduction of XML and SOAP), that many have even forecasted they would replace EDI entirely. As yet, however, all such predictions have failed to come true. As Founder and CEO of Celigo, Jan Arendtsz, identifies, predicting EDI’s imminent demise is now almost “an annual ritual”:

“Competing standards, web services and modern APIs — all have been forecast to end EDI at one time or another. But EDI is here to stay for now as it still works well for many users.”

Likewise, Program Vice President of Supply Chain Strategies at IDC, Simon Ellis, notes:

“There have been many contenders to overthrow EDI over the years, and none of them have succeeded because EDI does what it does pretty well”.

Consider the development of the telephone over the past 50 years, for example. Phones today are almost completely unrecognisable from the rotary dial landline telephones of the 60s and 70s, both in appearance and how we use them. Yet whilst the technology has hugely improved, the key challenge – to connect people far from one another – remains the same. The evolution of B2B data exchange is remarkably similar. Whilst modern message formats may be far removed from the telex messages of the first EDI exchanges, the key business challenge – i.e. exchanging business information in as efficient a fashion as possible – remains as important as ever.

Meanwhile a similarity can also be drawn between the predicted decline of EDI and that of oil over the past 20 years. Indeed, despite repeated stating of the importance of moving away from fossil fuels, yearly global oil consumption today is over 25% higher than in 2000. Likewise, in direct contrast to the predictions of its detractors, EDI usage is rising, with a recent report by Forrester Wave placing yearly global EDI transactions at over 20 billion and growing. And the good news – in contrast to oil, the supply of EDI will not deplete.

But what about recent IT developments? Do they have the potential to replace EDI? Will they supplement EDI? Or will they have little impact on B2B integration moving forward? In order to answer these questions we need to look at each technology in turn.

API

Perhaps more than any of the other technologies in this article, APIs are widely viewed as posing the biggest ‘threat’ to traditional EDI over the short to medium term. Although few predict an imminent migration by companies from EDI to APIs, some, such as Erik Kiser (Founder and CEO of Orderful), foresee APIs as “eliminating EDI altogether” in as little as “five to ten years”. Similarly, Gartner predicts that over half of all B2B transactions will take place via real-time APIs by 2023.

What are APIs?

An API, or Application Programming Interface, is a collection of rules and protocols used by software developers which specifies how the different components of applications should interact. By exposing a particular API, a business can enable partners to access selected data directly, without the need for this information to be requested and delivered.

How APIs are changing B2B integration

Essentially HTTP-based APIs represent a natural development from RPC (remote procedure call), SOA (service oriented architecture) and SOAP (simple object access protocol), which have been around for decades. Following the same conceptual approach as RPC and SOA/SOAP, modern APIs have proved popular thanks to their ease of use and the existence of better support and more advanced technology. In particular, modern APIs are well suited to enterprise application integration (EAI) and in environments where the developer has control of the system and can dictate the process.

In theory, by allowing direct, real-time access to relevant information from trading partners, modern APIs have the potential to streamline B2B interactions by providing faster system integration. However, talk of APIs replacing EDI is short-sighted and in many ways mirrors similar discussions around the turn of the millennium concerning XML doing the same. For example, Nate Haines’s recent article ‘EDI Must Die’, in which he claims EDI to be an “outdated technology that companies should actively work on abandoning in order to move into the modern digital age” shares much with Uche Ogbuji’s 2001 article ‘XML – The Future of EDI?’ in which he argues that XML “has the potential of taking EDI from an arcane, if venerable technique to the rapidly developing center of enterprise information technology”. In the articles both authors argue that EDI is undermined by the fact that traditional formats are hard to read compared to XML/JSON, with Haines calling the JSON body of an API call “far superior” to the equivalent “unwieldy block of EDI text”. Unfortunately, this completely overlooks the fact that EDI messages are not designed to be human-readable; they are designed to facilitate the most efficient data exchange possible, which happens to be machine-to-machine with minimal human interaction. Likewise, although bandwidth availability is growing and data storage is cheap, message size is still important, and EDIFACT considerably outperforms both XML and JSON in this respect.

Another common argument for APIs over EDI is that APIs allow businesses to design more bespoke processes. However, whilst potentially useful on a small scale, this approach becomes increasingly impractical the larger the supply chain.

Consider a global supplier with 500 supermarket partners, for example. With every partner using APIs, it is possible that each would require the supplier to follow a different process with different data.

Three examples of such different processes might be:

• The supermarket wants the supplier to expose an API and pushes the data there
• The supplier is expected to pull the order from the API of the supermarket
• The supplier is expected both to pull the order by calling the API from the supermarket and to confirm the receipt of the order via a push to a different API

Typically, as the buyer, the supermarket dictates the process, which the supplier must then adhere to. That includes the protocols being used as well as the data formats being exchanged. Such a jumble of processes is not conducive to efficient data exchange for various reasons:

• There is no standardised way of designing APIs. One partner might request pull, one pull and yet another a mix of both approaches.
• The underlying process is not standardised. While one partner might request a purchase order response, another might not care about the response and instead take the successful order placement as confirmation. Meanwhile a different partner might request the use of purchase order changes. Thus, APIs typically differ in regard to the supported process choreography.
• The semantics of the exchanged data is not standardised. Classic EDI standards such as ANSI X12 or EDIFACT strongly build on the concept of information identifiers. These information identifiers are based on globally accepted code lists and unambiguously define the semantics, e.g., of a purchase order reference, an acknowledgement identifier, a date format, etc. APIs do not follow such globally agreed concepts, thus, greatly increasing the risk of reinventing the wheel with every API implementation.
• The payload of an API call does not define the encoding. In particular with modern JSON/REST API it is the transport protocol, namely HTTP, which must define the encoding, in which the data is being sent. Otherwise the receiver has no chance to process the received information correctly. While in most cases UTF-8 is used as the standard encoding for messages exchanges, other encodings such as ISO-8859-1, ISO-8859-2 etc. are often used by the IT systems generating a business document as well. In contrast to EDIFACT or XML, where the encoding is defined in the message itself (namely the UNB segment in case of EDIFACT or the processing instruction in case of XML), JSON does not foresee such a mechanism.
• API documentations are not standardised. Although there is tool support for documenting APIs, there is no common and standardised approach regarding how an API is documented for business analysts and software developers alike.
• APIs often miss routing-critical information such as logical sender address, logical receiver address or document type definitions. While these fields are not necessary in a point-to-point integration scenario, they are of utmost importance when communicating with third-party-networks, which in particular large corporations heavily rely on.

By contrast, exchanging self-contained messages in an asynchronous way offers much more reliable cross-company integration. By using for instance EDIFACT, all of the challenges mentioned above can easily be met.

But it is not only the technology that matters. The real challenges of modern EDI don’t concern syntax or communication protocols, but the following:

• Coordinating what data has to be exchanged between sender and receiver (on a business/conceptual level)
• Setting up new relations, including testing of all the different business scenarios, e.g. invoices containing different VAT rates, surcharges/rebates, purchase order changes, etc.
• Getting the right data in/out of the ERP system (this can still be cumbersome)
• Translating/mapping the semantics between different ERP Systems, e.g. mapping information from document level to line item level
• Having a streamlined and efficient onboarding process

With APIs only point-to-point integrations can be achieved in an EDI scenario. Unfortunately, this does not scale when connecting a larger number of EDI partners. By contrast EDI networks help to scale by quickly establishing connectivity and integration with a larger number of EDI partners.

Yet API integration is by no means an inferior technology to EDI. APIs are simply better suited for different application scenarios than EDI. Integrations based on APIs excel when it comes to the direct integration of various systems in the context of enterprise application integration – for instance connecting a CRM system to an ERP system. Similarly, this technology is useful when it comes to interfaces of the public administration, where a single API is used by all companies due to legal requirements. An example for this is the United Kingdom’s MTD (Making Tax Digital) initiative. Other examples include Web Services offered by governments for electronic invoicing such as the SDI system in Italy. However, also in these domains we already see a strong uptake of Peppol, an EDI communication protocol for electronic invoices. In this case, as is often so, it is the EDI technology replacing point-to-point API integration approaches and not vice versa.

Bearing the above in mind, the following result of a survey conducted by Project 44 among 200 supply chain executives is not unsurprising. Although 63% predicted APIs will play a significant role in the future of B2B integration, only 5% predicted that EDI, by contrast, will abandon its key role.

In short, both EDI and API technologies have their own specific application domains in which they both perform exceptionally well. As such, neither technology is on a collision course with the other (as suggested by some). When it comes to the next ten years, we are likely to see highly flexible and loosely coupled integration scenarios using message-based systems dominate supply chains. APIs will coexist in these scenarios and perform well when it comes to deeply integrated system-to-system integration. Meanwhile EDI will remain the main workhorse of any logistic or financial supply chains.

Blockchain

Identified by TechCrunch as “the next step in the integration evolution”, blockchain, like API technology, has often been cited as posing a threat to traditional EDI.

What is blockchain?

Originally developed to power Bitcoin, Blockchain is a ledger-based technology that records changes/developments relating to anything of value (e.g. goods or currency). Blocks of data are linked chronologically, with new blocks created and added to the end of the chain to log any changes made to the information concerned. Once created, each block is essentially a read-only record of a change. As blockchain was designed to be decentralised, before a new block can be added to the chain, the computer seeking to add the block must solve a puzzle and provide proof-of-work to other computers on the network, which must in turn verify the information. Once created, blocks then can’t be tampered with. This system ensures data accuracy whilst enabling maximum visibility for all parties.

Blockchain and EDI

So how exactly could blockchain impact EDI and supply chain data exchange? Many believe that digital shared ledgers (DSLs) will become more popular as organisations move away from point-to-point communication towards a more collaborative approach in search of faster, more reliable B2B communication and increased data visibility. Whilst IBM has identified the positive capacity for blockchain to deliver “a tamper-proof record of relevant events […] for all supply chain participants”, several have also noted the potential for blockchain to boost supply chain analytics and data error monitoring. Meanwhile, Stan Gibson of Digitalist points to the enormous benefits for supply chain organisations concerned with provenance (or where exactly products come from).

For example, blockchain could prove very helpful to businesses in the meat industry as it allows for potentially universal access to key information such as where the cattle was grown, where the slaughtering took place, where the meat was processed and deep frozen, etc.

Some, such as Karthikeyan Mani, CEO of ByteAlly Software, believe blockchain will become the preferred medium for EDI messages to be transmitted, completely removing the need for trading partners to exchange files. Thanks to the advantages of improved data visibility, Mani notes “There is simply too much to gain […] for us to ignore blockchain as the transmission medium of EDI”.

Certainly, there does seem to be increased interest in blockchain, with Matthias Roese (Chief Technologist for Manufacturing, Automotive and IoT at Hewlett Packard) noting that “everyone is looking into it and doing pilots”. Indeed, according to IDC, investment in blockchain is almost doubling year on year and is expected to exceed £7.5 billion by next year.

However, as identified by Bilgin Ibryam (Principal Architect at Red Hat), blockchain becomes complicated in a multi-party B2B integration landscape. In his article The next integration evolution – blockchain, Ibryam explains that in order for blockchain to be successful in supply chains, businesses which “do not trust each other” must agree to implement “a new breed of […] technology that relies not only on sharing of the protocols and contracts, but sharing of the end-to-end business processes and state”.

Yet even if businesses are successful in doing this, most acknowledge that this doesn’t signal the end for EDI. Whilst traditional EDI may admittedly need to evolve in order to enable businesses to experience some of the benefits of blockchain technology, as IBM clarifies, “EDI is alive and well and will remain critical to business for many years to come”. Even if blockchain was to become EDI’s principal transmission medium, similar transitions (such as the move to web-based protocols kickstarted by Walmart in 2002) have happened before with little negative impact on EDI as a whole.

In short, whilst blockchain is a great concept for generating trust in a decentralised network, this is not the principal problem that EDI is focused on fixing. EDI is concerned with solving integration challenges, which blockchain is unable to help with. Even if EDI is done via blockchain moving forward, the need for integration between information in the blockchain and the ERP systems will remain. So, therefore, will the need for EDI.

Essentially, though they may both play a significant role in B2B interactions in the near future, as EDI and blockchain solve different problems, for the moment at least they cannot be combined. Rather than merging, they will work in parallel with one another, as shown in the diagram below.

Artificial Intelligence (AI)

Although less frequently touted as a potential successor to EDI, AI is increasingly being discussed in conversations concerning the future of EDI, with IBM noting that “the true future lies in using and evolving EDI alongside disruptive technologies such as IoT, blockchain and AI, to deliver innovative levels of multi-party supply chain collaboration”.

What is AI?

In simple terms, AI is ‘intelligent’ software / technology that has been developed to learn patterns and solve problems in an almost human way.

How could AI change EDI?

One of the key benefits of modern EDI is the extent to which it is able to streamline B2B data exchange and remove the need for time-intensive and error-prone manual processes. However, all traditional EDI systems require maintenance to ensure they continue to function at maximum efficiency. AI could potentially reduce the effort required to keep systems running at optimum level and ensure errors are caught and resolved faster.

For example, AI could learn to spot patterns in customer ordering and flag when this pattern is interrupted as a usual order is missing. Similarly, AI could be used to automatically correct certain data exchange errors rather than simply flagging them for a human to resolve. AI could even be used to benefit business strategy by making recommendations based on advanced data forecasting by identifying patterns in customer demand and preparing to adapt accordingly, for example. Another key use of AI could be helping to prepare mappings if the requirements of both sides are known.

Unfortunately, however, AI is unlikely to be able to help streamline the most time-consuming steps in the EDI process today – namely the human coordination between different parties during partner onboardings, semantic discussions and definition of import/export formats.

Whilst AI could help to augment EDI moving forward through improving message conversion, it has little relevance to message transmission and thus, like APIs and blockchain, falls short of constituting a threat to the future of EDI as a whole. Rather, like APIs and blockchain, AI will evolve alongside EDI, with improvements in both helping businesses to streamline essential business processes.

Conclusion

With so many new and powerful technologies and such renewed interest in B2B integration, the coming years should bring exciting developments. As recent projects such as Peppol have shown, we are slowly moving away from point-to-point connections towards a more collaborative B2B environment with better standardised communication between networks. Further, APIs, blockchain and AI could potentially dramatically increase the efficiency and transparency of important data exchange, with IDC research suggesting businesses will gain a 308% ROI with modernised B2B integration – or more than £4 in benefits per £1 invested!

As we have explored, however, none of these new developments or technologies signal significant change to the role of EDI in the future of supply chain communication. Amongst the clamour of voices every year heralding a new era in B2B integration, it is important to remember that unlike API, blockchain and AI, EDI itself is not so much a technology as a concept. Ultimately anything that can be classified as computer to computer exchange of B2B documents is electronic data interchange. In as far as EDI is considered to have challenges and issues, therefore, those issues are not solved by changing the syntax from EDIFACT or X12 to JSON, as has been proven by similar discussions concerning XML in the past.

Simply put, as long as companies need to communicate with one another, EDI, and the concept of data exchange networks, will exist. As a result, despite the gloomy predictions of some commentators, Grand View Research forecasts that the global EDI market will be worth nearly six billion dollars by 2025 with a cumulative annual growth rate of (CAGR) of 9.4%.

Alongside APIs, blockchain, AI and other upcoming technologies that are enabling businesses to improve more and more business processes, EDI continues to solve a crucial problem for supply chain organisations, and as such isn’t going anywhere. However, whilst none of the technologies we’ve looked at in this article are capable of replacing EDI, as they evolve alongside one another, what exactly EDI will look like in another ten years is up for debate.

Discover more about our updated product, ecosio.flow.

References:

1. BP, 2019, ‘BP Statistical Review of World Energy’, accessed 31 December 2019, https://www.bp.com/content/dam/bp/business-sites/en/global/corporate/pdfs/energy-economics/statistical-review/bp-stats-review-2019-full-report.pdf
2. Christopher, Claire, 2019, ‘5 EDI Software Trends: The Future of EDI’, accessed 31 December 2019, http://sandhill.com/article/5-edi-software-trends-the-future-of-edi/
3. Gartner, 2019, ‘Use APIs to Modernize EDI for B2B Ecosystem Integration’, accessed 31 December 2019, https://www.gartner.com/doc/reprints?id=1-1OC4DRR1&ct=190730&st=sb
4. Haines, Nate, 2019, ‘EDI Must Die’, accessed 31 December 2019, https://www.dsco.io/blog/article/edi-must-die/
5. IBM, 2019, ‘The Future of EDI: An IBM Point-of-View’, accessed 31 December 2019, https://www.ibm.com/downloads/cas/WQB6NBJ7
6. Ibryam, Bilgin, 2019, ‘The Next Integration Evolution – Blockchain’, accessed 31 December 2019, https://techcrunch.com/2019/02/05/blockchain-as-integration-evolution/
7. Ogbuji, Uche, 2001, ‘XML The future of EDI?’, accessed 31 December 2019, http://uche.ogbuji.net/etc/tech/articles/xmledi.html
8. O’Shaughnessey. Kim, 2019, ‘EDI Software Trends: The Future of EDI for 2020’, accessed 31 December 2019, https://www.selecthub.com/electronic-data-interchange/edi-software-trends/

Der Beitrag The Future of EDI erschien zuerst auf ecosio.

But EDI integration in modern ERP systems is a complicated process and one that requires significant expertise if a long-lasting solution is to be achieved. While there are many things that can go wrong when implementing/migrating to a new EDI solution, there are four main hurdles that must be overcome: standards, technology, processes and legal requirements…

Hurdle 1: Standards

EDI document standards were created to make supply chain automation easier by providing a set structure for commonly used B2B documents. However, as EDI has evolved over the decades, more and more standards have been created to cater to increasingly specific requirements across different industries and geographical areas. The image below, for example, illustrates how the need for increasingly specific formats has led to the creation of a multitude of subsidiary standards under the umbrella of the EDIFACT core standard.

Faced with this ever-growing maze of standards and formats, businesses require the ability to send messages via various protocols and convert messages easily between multiple different formats. Given most businesses have only minimal in-house EDI expertise, it’s no surprise that the technical effort involved in automating the conversion between message formats is one of the most common hurdles on the path to EDI supply chain success.
 

Hurdle 2: Technology

Thanks to recent innovations such as APIs and common import and export interface standards of ERP systems (e.g. based on XML or JSON), businesses have ostensibly never been better positioned to achieve widespread supply chain automation.

Unfortunately, however, many businesses are hampered by extremely complicated legacy IT landscapes and are therefore unable to experience the benefits of streamlined EDI. As illustrated by the diagram below (which shows the genuine IT landscape of a large retailer pre-upgrade), often legacy systems include several separate information silos and connections to multiple service providers. With no central governance and such a wealth of areas where errors could occur, internal teams are often scared to touch anything in case they disrupt or break mission critical processes.

Similarly, some ERP systems are so basic that they are unable to exchange structured files. This capability must therefore be implemented before EDI functionality can be integrated.

Hurdle 3: Processes

Whilst selecting middleware that can handle your business’s technical requirements is obviously important, even more important is establishing the right processes, as without these lasting success is impossible. Though integration admittedly requires expert knowledge, the technical aspect of integration is often the easiest part, with Gartner noting that:

“Only 5% of the interface is a function of the middleware choice. The remaining 95% is a function of application semantics.”

Successful EDI supply chain automation relies on efficient processes. For example, monitoring and support processes are essential if errors are to be identified and resolved before they impact partners.

Generally, successful EDI processes rely on the following key factors:

• Deep application and domain know-how of the business involved
• Technical capabilities
• Available resources
• Project management skills
• Project management support (e.g. onboarding tools)

Hurdle 4: Legal requirements

In an effort to save costs and gain more transparency regarding B2G invoices, many governments have introduced legislation dictating how companies should format and transmit structured electronic invoices (a subject we cover in detail in our e-invoicing white paper). Since April 2020, the majority of European government bodies have been required to accept electronic invoices. Moreover, many countries are seeking to make all B2B and B2G e-invoicing mandatory in an attempt to reduce the so-called VAT gap between expected and collected VAT revenues.

Given the geographic reach of most EDI supply chains and the pace at which e-invoicing legislation in particular is being created and amended, staying on top of regulations is no easy task. Non-compliance with regulations is not an option, however, as it can bring large fines.

If you want to stay on top of e-invoicing regulations, why not sign up to our E-invoicing Updates Newsletter? By doing so you’ll get all the most important e-invoicing updates and helpful e-invoicing assets direct to your inbox every two months!

Want more information on how to overcome these hurdles?

This article is a snippet from our white paper Unlocking the Secrets to Successful EDI Integration. In this paper we explore the development of ERP systems, what makes an EDI supply chain resilient, how to avoid common integration headaches, the benefits of full EDI integration and how to ensure your integration project is a success.

Download your copy of “Unlocking the Secrets to EDI / ERP Integration Success” and find out how you can implement (and benefit from) a solution that is able to overcome all four of the hurdles discussed in this article, simply fill in your details.

Alternatively, if you have any questions about supply chain automation or anything else EDI related, feel free to get in touch! We are always happy to help!

Der Beitrag EDI Supply Chain Automation – The Four Main Hurdles erschien zuerst auf ecosio.

• Microsoft Dynamics 365 lacks native EDI capabilities, requiring businesses to choose between in-house integration or external managed solutions
• In-house EDI integration demands significant internal expertise, including mapping, routing, partner coordination, and 24/7 monitoring
• Managed EDI services like ecosio offer swift, secure connections, handling all EDI tasks and providing a single point of contact
• ecosio’s solution provides deep API integration, offering full data visibility within D365 and adapting to evolving EDI requirements

With the rapid expansion of geographical markets and rising customer expectations in recent years, partner trading cycle automation has become essential for supply chain businesses. Whereas previously EDI may have been a “nice-to-have” and something only larger organisations could benefit from, the emergence of cloud-based managed solutions has meant that EDI is now accessible to businesses of all sizes – with effective EDI solutions becoming increasingly essential for even smaller suppliers to keep pace with competitors.

Unfortunately, however, as integrating an EDI solution can be a complicated process, many businesses using Microsoft Dynamics’ 365 (D365) range of business software struggle to identify an effective solution. Too often D365 users will opt for external EDI software solutions rather than those offering genuine end-to-end automation. By failing to consider the additional costs and resources (both initial and ongoing) involved in enabling external EDI software to communicate with Microsoft Dynamics, as well as the limited data visibility and monitoring such solutions typically offer, businesses are missing a crucial opportunity to boost the efficiency of key supply chain processes.

What are my D365 EDI integration options?

As Microsoft Dynamics has no inbuilt EDI capability, D365 users looking to automate data exchange processes have two main options: handle everything in-house or opt for a managed external solution.

1) In-house data process automation

If your business has EDI expertise and sufficient IT resources, you may want to consider implementing an EDI solution via an integration platform – also known as middleware, integration platform as a service (iPaaS) or a comprehensive integration system (CIS).

Whilst this approach enables you to retain full control and ensure your EDI user interface is consistent with D365, there are a number of significant downsides:

• Internal expertise needed! – As implementing an EDI solution is a complex process, you will need significant internal EDI knowledge to be able to handle D365 EDI integration in-house. Given the crucial nature of the business information being exchanged via EDI, should the process be handled incorrectly the results can be damaging.
• A slower solution – The difficulty of in-house teams balancing existing tasks and ongoing responsibilities with integration of an EDI solution will inevitably result in an elongated implementation period. In short there is little hope of matching the implementation speed offered when an experienced external provider is used.
• Thorough testing required – To ensure your EDI connection is reliable it is important that all relevant business cases are tested in advance of going live. When testing transmission of invoices, for example, all possible variations (such as those including allowances, surcharges and with/without tax) should be tested. As internal teams are unlikely to have an established EDI testing procedure, it is easy for key checks to be missed during this phase. In turn these oversights can lead to costly errors once your solution is live.
• Staying on top of your data flow – Once your implementation of your D365 EDI solution via middleware has been completed it is important to note that work is still required to maintain the system’s efficiency. In addition to constant monitoring of inbound/outbound messages, updates will also need to be implemented and partners onboarded as your EDI needs inevitably change over time. In short the internal resources needed to ensure your system continues to operate at optimum level should not be underestimated.

2) EDI via a fully managed service provider

If your business doesn’t have a wealth of EDI expertise and internal resources, the most viable option for integrating an EDI solution in Microsoft Dynamics is to use a managed EDI provider (also known as a VAN). Given their experience in establishing end-to-end EDI connections they should be able to implement a swift and secure connection with your ERP customiser.

Key benefits of enlisting the help of a VAN to implement your D365 EDI solution include:

• No in-house knowledge required – As we touched on above, the complexity of integrating an effective EDI solution into Microsoft Dynamics is such that the knowledge and resources required to handle implementation in-house are significant. When using a managed EDI service provider no internal expertise is needed before or after implementation, leaving your in-house teams to continue to focus on what it is they do best.
• Save time, money and stress! – Without a doubt, the most compelling reason to select a managed D365 EDI solution is the cost and time benefits it will bring by reducing required in-house resources to an absolute minimum. Often overlooked, too, is the considerable peace of mind you will gain from outsourcing the management of key B2B data processes. 

These are not the only possible benefits of integrating a managed EDI solution into Microsoft Dynamics, however. Some solutions, such as ecosio’s, also offer additional advantages, including…

• Maximum data visibility via deep API integration in D365 – Managed EDI solutions offering a deep API-ERP connection provide users with unparalleled end-to-end data visibility. With such a connection EDI message statuses can be viewed in your existing D365 user interface, removing the need to navigate to another platform.
• A future-proof solution – To ensure your business continues to experience effective, automated data exchange, comprehensive message monitoring is required. Though not offered by all EDI providers, 24/7 monitoring and support in addition to implementation of ongoing updates is offered as part of the best managed solutions. This can prove particularly important when key EDI developments occur – many providers are unable to offer customers access to Peppol, for example.
• Flexibility – Every business is unique. As such, it follows that no two D365 users will have the exact same EDI needs. Your business’s EDI needs are also likely to evolve over time. As a result, the best EDI solutions include modular elements which can be combined and added as requirements change. This way you are only ever paying for the solution you need.

What successful EDI integration in D365 really looks like

A detailed example of what EDI integration in D365 looks like in practice, detailing how eurotrade Munich Airport implemented ecosio EDI as a Service managed solution, can be found here. Alternatively, please see our blog article on what exactly is involved in an EDI implementation project.

How ecosio can help

At ecosio we’re experienced in handling EDI integrations in D365 and know exactly what lasting success requires. While our unique API allows for extraordinary data visibility and ease of use, our comprehensive service ensures EDI implementation and operation is as simple as possible. By enlisting the help of our experts, your business can enjoy the many benefits of automated document exchange without any of the hassle. Moreover, thanks to our flexible, modular solutions, you can enjoy peace of mind that your EDI solution can adapt as your needs change over time.

Find out more

For more information on ecosio EDI as a Service solution and to find out how your business could benefit from deep EDI-ERP integration, contact us or use our chat. We are always happy to answer any questions you have!

Der Beitrag Effective EDI Integration in Microsoft Dynamics 365 (D365) erschien zuerst auf ecosio.

In this article we will look specifically at the four most commonly used EDI protocols: AS2, OFTP2, HTTP and REST APIs.

What is an EDI protocol?

An EDI protocol describes and defines the exchange of data between computers and is used by the communication software/application. In essence each protocol is like a separate language, as unless the trading partners are using a VAN, the computers of both parties must use the same protocol in order to communicate. 

The chosen protocol also determines the level of message encryption, what software and hardware will be required and the ease with which transmissions can be received (i.e. whether both sides’ machines have to be online at the same time for message exchange to occur or not).

Although EDI can theoretically be conducted between two partners via any electronic method capable of transmitting the relevant information, the vast majority of EDI today is conducted over the internet. With the emergence of new technology came the need for standardised protocols. Naturally, over the past few decades the number of these protocols has increased. Thankfully, however, most supply chain organisations today use one of the following exchange channels:

HTTP

First established in 1991, HTTP, or Hypertext Transfer Protocol, is a well-known and popular file transfer protocol. Since its inception four subsequent updates have been released, with the fifth and latest (confusingly called version 3.0) having come out in 2018.

As it only requires a web browser and no additional installation, HTTP constitutes a simple method of completing person to server and person to person file transfers. As anyone who uses the internet is likely to recognise, HTTP resources can be easily located on the network through URLs (or Uniform Resource Identifiers).

The downside of HTTP’s simplicity is the lack of security it offers, however. Although not as prone to firewall issues as File Transfer Protocol (FTP), HTTP is unable to secure data or meet regulatory measures. Due to the security disadvantage plain HTTP is therefore not recommended and at least the use of HTTPS with TLS (transport layer security) should be considered. Similarly, as HTTP doesn’t offer users the ability to receive receipts automatically, it is lacking when it comes to message traceability.

Advantages of HTTP

• Simple to implement
• Ease of use (only requires a web browser)
• Less prone to firewall issues than other protocols due to standard port range

Disadvantages of HTTP

• Not very secure
• No process traceability

AS2

AS2 (or Applicability Statement 2) rose in popularity drastically after the turn of the millennium following the move by Walmart to require its suppliers to use it. Many other large retailers followed suit, meaning AS2 quickly became the most popular EDI protocol across many industries for point-to-point connections.

Unlike many other protocols, AS2 was developed specifically for B2B document exchange. As a result it offers several advantages over HTTP, including better security and the ability for acknowledgements and transactions to happen in real time. 

AS2 uses the HTTP(S) protocol to send EDI messages through an encrypted tunnel. In a standard AS2 message files are transmitted as ‘attachments’. All file formats can also be handled and messages can be signed to provide authentication if required. As virtually no ERP system offers inbuilt AS2 capability, however, this must be integrated separately. To do this requires detailed knowledge and can lead to long troubleshooting if the administrator is not well versed with AS2 and its functionalities.

In order to improve traceability AS2 requires receipts, or Message Disposition Notifications (MDNs) to confirm message delivery/receipt. In contrast to AS1 and AS3 protocols, AS2 offers multiple MDN return options, including the ability to return synchronous or asynchronous MDN..

Thanks to its compliance with the Health Insurance Portability and Accountability Act of 1996 (HIPAA), AS2 is particularly popular in the healthcare industry today. 

Advantages of AS2

• No limit on the amount/size of data you can exchange
• As long as your organisation’s server is live, so is your AS2 connection
• Ability to exchange all file formats
• No yearly or transaction fees
• Possible via point-to-point or indirectly via a VAN
• Widespread adoption throughout EDI users

Disadvantages of AS2

• Requires integration of separate application
• Requires specific AS2 knowledge to setup, maintain and troubleshoot 

OFTP2

Like AS2, OFTP, or ODETTE File Transfer Protocol, was specifically designed for B2B document exchange by the Organisation for Data Exchange by Tele Transmission in Europe (ODETTE) in the mid 1980s. 

In 2007, the OFTP2 protocol was developed specifically to be used over the internet. This update included important improvements over OFTP such as improved data security (via exchange of digital certificates) and the capacity for high compression.

In addition to allowing for very secure exchange of high volumes of data via dedicated servers, OFTP2 is remarkably simple to use compared to other protocols, with only 14 commands.

Crucially, unlike with AS2, with OFTP it is possible to push and pull information (rather than just pushing). It also gives the user the ability to request signed receipts, further improving data security.

For temporary issues, OFTP2 offers transmission restarts. This is preferable to the alternative method of causing an error and aborting the session, which in turn requires the message to be resent in a following session.

OFTP2 is widely used in the automotive industry in Europe, though is also popular across retail, manufacturing, banking and government industries among others.

Advantages of OFTP2

• Simple to use
• Allows for high-volume data exchange (up to 9 Petabytes)
• Ability to push and pull messages
• Highly secure
• Automatic file restart
• Widespread adoption throughout process and automotive industries

Disadvantages of OFTP2

• Requires integration of separate application
• Requires specific knowledge
• Requires all participants to have the capability, which limits its adoption. 
• Requires registration with the ODETTE organisation to receive accredited Odette ID

REST API

An API, or Application Programme Interface, is a combination of rules and mechanisms which dictates how two endpoints are able to interact and share information. 

In theory data exchange via APIs offers a great advantage to businesses as it allows for free access to important B2B data without the need for participation of the partner or availability in the moment of transmission. Once an API has been set up, data can be accessed instantly and whenever convenient. Companies are also able to ensure a high level of security by the ability to restrict access as required. 

As there is little standardisation or restriction surrounding how APIs should be created and used, however, using APIs for B2B data exchange can become difficult the more partners your business has as you effectively have to reinvent the wheel for each connection. Unlike with AS2 or OFTP2, which adhere to predetermined standards, APIs can be used in different ways. For example, one trading partner could request to pull the files, one only accepts pushing files onto his server and yet another a mix of both approaches. Similarly, the semantics of the data being exchanged is also not standardised with data exchange via APIs. Whereas traditional EDI protocols rely on universally accepted document standards (e.g. EDIFACT), this is not the case with APIs, meaning each connection requires additional work. APIs can be very useful for EDI, however, as we explore in more detail in the article “Conducting EDI via API – What are the benefits?”.

REST, which stands for Representational State Transfer, is not a protocol itself, but rather a common method of writing API. APIs themselves lack a uniform structure. Instead structure is created through messaging formats such as JSON. Like AS2, REST relies on HTTP(S). 

Advantages of REST API

• Flexible data exchange either by pulling whenever ready or receiving data immediately via POST
• Widespread knowledge for implementation not limited to EDI users of specific industries, but generally web developers, therefore e.g. enabling could ERP users to directly exchange messages

Disadvantages of REST API

• Lack of standardisation
• Becomes increasingly inefficient as an EDI method the larger your partner network, and often requires an API management layer
• Web programming expertise required if handled in-house

What is the simplest way to send EDI messages via these protocols?

For small and medium-sized suppliers, by far the easiest solution for trading EDI messages is to use an EDI service provider – or VAN (Value Added Network). 

Unfortunately, setting up point-to-point EDI connections is a complicated process and requires a lot of technical expertise. Plus, although certain protocols are favoured by particular industries, as your supply chain grows you will undoubtedly encounter requests to conduct EDI over different exchange channels. 

By selecting a fully managed EDI solution all connection issues are taken care of by your provider. With just a single connection to ecosio’s cloud-based EDI solution (our Integration Hub), your business will be able to send automated messages to your entire partner ecosystem… and any future partners. In addition to allowing you to experience the cost benefits of fully automated EDI, this approach completely removes the responsibility for establishing, monitoring and troubleshooting your B2B message exchange processes, leaving your staff free to focus on more value-adding activities.

Find out more

For more information on EDI protocols and how to get started with B2B data exchange automation, contact us today.

Der Beitrag The Four Most Common EDI Protocols Explained erschien zuerst auf ecosio.

In this article we will attempt to help you answer that question, looking at the potential benefits of EDI integration, the advantages and drawbacks of different integration methods, and what exactly EDI NetSuite integration via a managed EDI service provider involves.

What is electronic data exchange (EDI)?

For any organisation exchanging a high number of business documents, electronic data interchange (EDI) offers an efficient way to streamline the process. Today’s supply chains are more complex than ever, with partners requiring frequently used documents such as invoices and delivery notes to be delivered in different formats, at different times and over different communication protocols. As a result, the use of EDI is becoming increasingly widespread as more and more businesses require an automated method of managing this exchange and ensuring data is sent and received in the correct form.

EDI with NetSuite

Thankfully, such has been the advancement in software in recent years that even small businesses can now benefit from EDI. This is particularly significant as many large retailers require suppliers to have EDI capability before they can become trading partners. As NetSuite does not offer inbuilt EDI capability, however, Oracle users must look to external EDI providers to achieve an effective solution. 

Given the wealth of different solutions available, selecting the right provider can be a confusing exercise, particularly for supply chain managers and IT decision-makers unfamiliar with EDI. Further, even those who have a good understanding of EDI may be under intense time pressure to find a solution to their business’s current EDI issues. As a result, many organisations regrettably invest in sub-standard, ill-suited or short-term solutions.

As we shall explore, with the right solution and approach, effective EDI integration in Oracle NetSuite can bring a host of benefits and set your business up well for the future. Plus, handled correctly, integration itself needn’t be the headache-inducing process many predict.

What are the benefits of EDI NetSuite integration?

• Speak the same language as your partners – Once you have successfully integrated an EDI solution into NetSuite, your system will automatically send and receive messages in the correct format and over the appropriate protocol without the need for manual intervention and keying of business documents (e.g. orders).
• Error reduction – By automating key data processes, potentially costly manual errors will be eliminated, resulting in reliable data exchange and a streamlined supply chain.

“What NetSuite EDI integration options do I have”?

Businesses looking to achieve an effective EDI solution in NetSuite have two options:

1) In-house NetSuite EDI integration

If you have sufficient resources and internal EDI expertise it may be possible to attempt EDI integration via an integration platform – also often referred to as middleware, comprehensive integration system (CIS) or integration platform as a service (iPaaS). 

This approach will give you full control of the integration and will mean your EDI user interface is consistent with your business’s other ERP elements. However, it does come with several drawbacks:

• Speed – Understandably, when it comes to the time needed to complete the implementation, internal teams will never be able to compete with experienced external teams who are used to implementing NetSuite EDI solutions – particularly when you factor in that internal teams will also be juggling existing responsibilities.
  
• In-house knowledge and resources – Given the complexity of integration, it is extremely important that you have sufficient in-house expertise and resources before attempting NetSuite EDI integration internally. If the process is handled incorrectly, thanks to the business-critical nature of the data exchanged via EDI, the consequences can be disastrous.
  
• Testing – Thorough testing is key if you are to ensure your new EDI solution is secure, efficient and reliable. Unfortunately, testing takes time, as it is important to test all relevant business cases. For example, rather than just testing standard invoice transmission, it is important to test all invoice variations, such as those with surcharges, allowances, and including and excluding tax etc. Understandably, in-house teams are unlikely to have a thorough EDI testing procedure set up. Unfortunately, this lack of experience can result in the testing phase not being completed to a sufficient standard, in turn leading to potentially costly issues further down the line.
• Monitoring / updates – Once NetSuite EDI integration has been completed in-house via an integration platform there is still a considerable amount of effort required to maintain an efficient EDI system, from continual monitoring of message status, to implementing updates and ensuring compliance with e-invoicing regulations (among other responsibilities). In short, due to the business critical nature of the processes and information involved, thorough monitoring of your EDI solution is essential.

2) NetSuite EDI integration via a managed EDI service provider

For businesses keen to ensure data integrity but lacking extensive in-house EDI knowledge and resources, the more sensible option may be to opt for integration via a managed EDI service provider, or VAN. These providers are extremely familiar with integration projects and should be able to ensure a swift and secure connection in partnership with your ERP customiser. 

The key benefits offered by NetSuite EDI integration via a VAN are:

• No need for in-house expertise during or after integration! – As already mentioned, the resources needed to handle EDI internally are by no means insignificant. By integrating a managed EDI solution into NetSuite you will remove the need for in-house expertise and relieve pressure on internal teams.
  
• Time and cost saving – Perhaps the most compelling reason to integrate a managed EDI solution into NetSuite is the time and money it can save your business by hugely reducing the in-house effort required to maintain data processes and allowing you to reallocate internal resources.

Some managed EDI providers may also offer additional services and benefits, such as:

• Improved visibility via a deep API-NetSuite connection – A deep NetSuite EDI connection (such as that offered via ecosio’s cloud-based EDI solution – our Integration Hub) offers the ability to view message statuses directly in your ERP’s user interface, meaning there is no need to navigate to, or become familiar with a new system. 
• A future-facing approach – To experience the full benefits of an efficient managed EDI service it is important to select a provider who is able to future-proof your business’s data processes. In order to achieve this, the best managed solutions will include 24/7 monitoring and support in combination with implementation of ongoing updates. Sadly this is not a priority for many providers, whose customers then suffer following important EDI developments (many providers do not offer access to Peppol for example).
  
• Batch message processing – Batch processing involves combining multiple documents in a single EDI message for increased efficiency, much like sending multiple letters to the same address in one envelope. Unfortunately, batch processing (inbound as well as outbound) is not supported by most standard ERP system interfaces. Integration of a managed solution (such as ecosio’s EDI solution) that offers a deep ERP-EDI connection will enable this useful functionality.

How to integrate managed EDI with Oracle NetSuite

Integration of an external, managed EDI solution into NetSuite can happen in one of two ways; via a connector or directly. You will require an ERP customiser for both approaches.

Click image to enlarge

1) Integrating EDI solution into NetSuite via a connector:

The easiest way to integrate an EDI solution into NetSuite is to do so via an ERP customiser offering a tailored connector. The benefit of using a connector is principally the speed with which the connection can be completed. Once a customiser has developed a connector between NetSuite and your chosen EDI solution, the steps required to integrate the same solution into future customers’ NetSuite systems are greatly reduced. Think of it like a builder turning up at a job with all the necessary tools and equipment as opposed to one who first has to assess the situation and go out and buy the required materials. 

Thanks to the minimal adaptations required when using a connector to integrate a managed EDI solution in NetSuite, this approach also has the benefit of low initial costs and reduced mapping costs.

In 2018 ecosio developed a NetSuite-EDI connector in partnership with ERP customisers and Oracle integration experts CW Global Partners.  

Utilising a modern REST-API, this unique connector integrates ecosio’s EDI solution directly into NetSuite via a single standardised transmission channel and a unified document format. The result is seamless integration of the complete scope of ecosio’s API and an ERP environment that is 100% EDI optimised.

Following integration via this connector, NetSuite users will benefit from:

• Accurate delivery/fetching of messages – Once the connection with the ecosio cloud-based EDI solution (our Integration Hub) has been established, the receiver can set up regular requests to check if new messages have arrived. Alternatively, new messages can be transferred proactively from the Integration Hub to the recipient. 
• End-to-end message monitoring – Thanks to the depth of the connection, there is no need to log into an independent EDI monitor. Users will instead receive feedback directly into their NetSuite user interface that their partner has acknowledged the message. 
• Full-text search – Messages can be searched by content. For example, if required, a user could locate a document by searching by document number, interchange reference or protocol ID (OFTP2 or AS2 Message-IDs).
• Error handling – NetSuite EDI integration via a connector will ensure the user has access to valuable information if and when errors occur. In addition to being able to see why the transmission failed, users can also identify where the error occurred and what needs to be fixed.

2) Direct NetSuite EDI integration

The second method for implementing a managed EDI solution in NetSuite is via direct integration. This process works as follows:

• NetSuite will expose an HTTP endpoint for the EDI provider to push inbound messages to your ERP.
• Your chosen EDI provider will expose an HTTP endpoint for NetSuite to push outbound messages to them.
• Content is transferred in a JSON format and the required fields need to be defined from scratch between EDI system and NetSuite for every new project.

While just as valid an approach as integration via a connector, direct NetSuite EDI integration differs in several ways. In particular, the last bullet point above represents a key disparity. Unlike when using a connector – where import/export formats (including the information/fields that are transferred) are ready to implement – each of these elements needs to be defined from scratch during direct integration. More generally, the amount of work required to set up a direct NetSuite EDI connection means that it will undoubtedly cost more and take longer than integration via a connector. Further, functionality after implementation will also be different, as customers opting for direct integration will not benefit from error-handling, end-to-end monitoring or full-text search capabilities.

Key differences at a glance

NetSuite EDI connection via connector

• Only minor adaptations required before the interface is ready to use
• Minimal initial costs and mapping costs
• Tried and tested method
• End-to-end monitoring
• Error handling
• Full-text search

NetSuite EDI connection via direct integration

• Higher implementation costs
• Longer implementation time / more complicated setup 
• EDI functionality limited to sending and receiving messages (no end-to-end monitoring)
• No error handling capability
• No full-text search

How ecosio can help

At ecosio we have done, are happy to do, both direct and connector-enabled NetSuite EDI integration. By integrating our unique API as a native feature in NetSuite, in addition to experiencing all the benefits of a regular managed EDI solution, you will benefit from:

• 24/7 support and monitoring
• Implementation of ongoing updates
• Excellent customer service
• Ability to view business-critical data in your existing user interface
• One contact person – one EDI partner – one interface

To find out more about our solution or if you have any questions about NetSuite EDI integration please contact us. We’re happy to help!

Der Beitrag Achieving NetSuite EDI Integration erschien zuerst auf ecosio.