Thankfully there’s no need for EDI errors to be a common occurrence, though. In this article we’ll explore why EDI errors happen and what you can do to safeguard your system against them.

The architecture of a typical EDI landscape

The typical modern EDI landscape has four main points (or ‘corners’, as they are often called). As shown in the diagram below, these are…

1. Your ERP system
2. Your EDI system and/or VAN
3. The EDI system of your partner and/or VAN
4. Your EDI partner’s ERP system

Although this model is the most efficient EDI landscape as far as the ease and efficiency of setting up EDI connections are concerned, the fact that multiple steps are involved means that there are several places where EDI errors can occur.

In the following section we’ll look at the five most common EDI error types and show you where each occurs on this same EDI architecture diagram.

The five most common EDI errors

1) Message content errors

What are message content errors?

Content errors happen when the EDI message in question contains missing or incorrect information. For example, a message may have the wrong item number (e.g. GTIN) or be missing a number such as the invoice recipient’s GLN (NAD+IV in case of EDIFACT).

How can I fix message content errors?

To correct content errors the exact source of the error needs to be located in the originating system (usually the ERP system) and manually updated.

How can I avoid message content errors?

Message content errors can be avoided if EDI onboarding is conducted correctly and master data is maintained properly. During EDI onboarding all potential message variants (e.g. in case of invoices) must be tested thoroughly. In addition, automated validations, which are executed as part of the document mappings, also help to prevent such errors.

Once a content error has been spotted in a message it is important to check that the issue didn’t stem from inaccurate master data, as the same error will happen again in the future if this was the cause and the master data is left unchanged.

2) Message sequence errors

What are message sequence errors?

Message sequence errors are when an EDI message is rejected because the intended target has not yet received a previous message. For example, if a buyer has not yet received an order response (ORDRSP), they may well not be able to acknowledge a despatch advice message (DESADV).

How can I fix message sequence errors?

In order to resolve this error the previous message in the workflow must be sent successfully. This may involve identifying and tackling a separate error, depending on why the previous message was not received.

How can I avoid message sequence errors?

Avoiding message sequencing errors requires your EDI solution to be set up in such a way that the system would recognise that the previous message has not yet been received and halt the transmission of further messages. Usually this can be achieved by setting up dedicated rules in the ERP system, preventing messages from being released where the necessary preceding documents have not yet been released.

3) Connection errors

What are connection errors?

Connection errors happen between your EDI provider/VAN and the EDI provider/VAN of your partner. For example, your EDI message may become stuck because an AS2 or X.400 server is not operational.

How can I fix connection errors?

Typically it isn’t possible for internal teams to resolve connection errors directly, as message exchange is normally handled by a service provider or VAN. However, good message monitoring processes will ensure you are aware of the issue as early as possible and can alert the relevant internal parties so they are informed about the connection outage. In addition your EDI service provider will have to try to restore the connection and resend any pending documents as soon as the connection is available again.

How can I avoid connection errors?

Due to the fact that EDI involves distributed systems where you are not in control of every node, you cannot fully avoid connection errors. The best way to reduce the impact of EDI connection errors is to work with an EDI service provider that offers proactive connection monitoring and error resolution. In case a connection error occurs, the EDI service provider will take all necessary steps to restore connectivity. In most cases your internal teams and business departments will not even realise that there was a connectivity hiccup.

Furthermore it helps to focus on EDI data visibility – e.g. integrating an EDI solution that utilises API. This way relevant internal teams such as procurement or sales can see when a connection issue arises as well and are proactively informed about the issue.

4) EDI routing errors

What are EDI routing errors?

EDI routing errors occur when the incorrect EDI sender/receiver configurations are present. For example, a message may become stuck due to erroneous UNB sender/receiver IDs in the case of EDIFACT.

How can I fix EDI routing errors?

Fixing an EDI routing error may require master data to be corrected and the message resent from your ERP system.

How can I avoid EDI routing errors?

An efficient EDI solution can avoid EDI routing errors by visualising the error directly in the ERP system. Consequently business users are immediately aware of the faulty configuration, can correct it and then resend the message. A proactive EDI service provider (such as ecosio) will also chase stuck messages and inform you proactively.

5) Configuration errors

What are configuration errors?

Configuration errors occur when key setups are missing in the ERP system. Without the correct logic in place, messages can become stuck, meaning potentially important information is never received. Usually this means that the necessary EDI messages are not being triggered in the ERP system, e.g. because the setup for a new Sold-to party is missing.

How can I fix configuration errors?

Fixing configuration errors will likely require master data updates. In addition it may also require technical work to ensure your EDI solution is integrated fully into your ERP system, e.g. by setting up validation routines which check for missing EDI configurations.

How can I avoid configuration errors?

In addition to maintaining good master data protocols, one good way to avoid configuration errors is to implement automated setup routines. This way business users cannot save new partner records (e.g. Bill-to or Sold-to), unless they have provided the necessary EDI configuration.

What can I do to avoid EDI errors?

In order to build a system resilient to EDI errors, there are two key steps businesses can take…

1) Ensure internal visibility of EDI traffic

If EDI errors are to be eliminated, business departments need visibility of the EDI process. Rather than EDI being a black box, with departments such as sales and procurement unable to access data, EDI traffic up to the EDI system and/or VAN of the EDI partner should ideally be visible directly in the ERP’s user interface for those who need it.

With good internal EDI data visibility, business users can easily see if something is wrong and react accordingly to prevent failure and frustration.

2) Establish reliable message monitoring processes

Whatever type of EDI solution you select, it is important to ensure that EDI traffic is supervised and overseen by experienced individuals.

For companies with extensive internal resources and EDI expertise it may be possible to do this in-house. For those businesses not in this situation, an EDI as a Service approach offers the most sensible solution. This way, not only are connections set up by your EDI provider, they are monitored and maintained by them too – leaving internal teams free to focus on more value-adding activities.

Want to eliminate EDI headaches once and for all?

EDI should be an asset, not a hassle, and the more time internal teams have to spend resolving EDI issues, the less they can devote to more value-adding activities.

At ecosio we’re well aware of just how difficult handling EDI can be for internal teams, which is why we’ve dedicated ourselves to helping businesses achieve maximum automation with minimum effort.

From initial setup right through to ongoing operation and error resolution, our EDI experts take care of all EDI tasks so you don’t have to. Plus, thanks to the modular and cloud-based nature of our solution, there’s no need to worry about the future, as your solution can easily be adapted to suit your changing needs.

Find out more about how ecosio could help you save time, save money, reduce risk and increase your competitive advantage, or get in touch today!

Der Beitrag Common EDI Errors and How to Fix Them erschien zuerst auf ecosio.

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.

• Lack of internal resources/expertise – The more EDI connections your internal team has to maintain, the more resources and expertise will be required.
• Difficulty of tracing messages and spotting/resolving errors – Thanks to poor data visibility, should an error occur when routing messages via VANs it can be hard to identify where this happened and how to resolve it.
• Costs – From the per-message costs demanded by VANs to related staffing and server/maintenance costs, VAN connections can prove expensive.

Thankfully these issues can be resolved with the right approach. What’s more, this is true even for businesses with the most complex VAN landscapes. The key lies in VAN consolidation and efficient ERP integration.

The benefits of a single EDI connection

Unsurprisingly, the best way to eliminate the complications relating to multiple/inefficient VAN connections is to replace them with a single, fully managed connection to an EDI solution provider which itself acts as a Value Added Network. Nota bene: technology leaders in the field of EDI, such as ecosio, prefer the term “B2B network” instead of Value Added Network. Such a move provides numerous benefits, in particular relating to…

• Internal work – As explored in detail in our infographic “The Business Benefits of EDI”, fully managed providers offer invaluable help at all stages of the EDI process, meaning minimal internal work is required to ensure the continued success of structured message exchange with partners.
• Costs – Without the need to invest in expensive hardware or additional staff to handle message exchange via an EDI converter, businesses are able to save a significant amount of money by switching to a fully managed provider.
• Partner onboarding – Unlike connecting to partners via unmanaged VANs, connecting to partners via a fully managed VAN is a different experience altogether. With ecosio, for example, clients are provided with a dedicated project manager who oversees all connections from start to finish. As a result, connections are reliable (thanks to comprehensive testing), and can be completed quickly.
• Message monitoring / error resolution – Perhaps the biggest benefit of moving to a fully managed EDI solution is the enormous difference this will make to the ease of monitoring messages and identifying and resolving errors. Whereas (as we have covered) tracking messages is extremely difficult in complicated multi-VAN environments, this is not the case with fully managed solutions. With ecosio EDI as a Service solution, for example, automated alerts can be set up in case of failure, plus the monitor platform enables clients to see exactly where a message has failed and what is needed to resolve it. Significantly, too, ecosio’s EDI experts provide round-the-clock monitoring and will work proactively to resolve any errors – a far cry from legacy EDI landscapes where messages can fail silently with both sides unaware!
• Accountability – Another significant plus to enlisting the help of a fully managed VAN is the fact that by doing so you pass the responsibility for successful message exchange (and resultant accountability) completely to them.
• Flexibility – On top of all these features, a fully managed VAN also offers flexibility. Should your requirements change for any reason, amending your EDI connections is simple and fast, as a fully managed VAN should have the ability to conduct message exchange over all main protocols (e.g. AS2, AS4, OFTP2, X.400 etc.). Similarly, some providers, such as ecosio, also offer additional Web EDI and supplier relationship management modules (e.g. supplier self assessment or audit management), which can be added on as required. In short with a connection to a fully managed VAN your EDI solution will adapt and grow alongside your business.

Want more information on optimising your VAN landscape?

This article is a snippet from our white paper Everything You Need to Know About VANs. In this paper we explore the different types of VANs, the complications associated with handling VAN connections in-house and how deep ERP integration can help (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 VAN connections and streamline your EDI landscape.

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

Der Beitrag Improving Your VAN landscape erschien zuerst auf ecosio.

In this article we’ll explore five reasons why you should avoid conducting EDI in-house via an EDI converter if you need to route messages through VANs.

1) The need for EDI expertise and internal resources

Undoubtedly the main hurdle stopping businesses from attempting to manage EDI in-house is the complexity of EDI processes. Unfortunately, given the way in which EDI has developed over the decades and the myriad of formats and protocols available to businesses today, managing EDI requires significant technical expertise which is rare among in-house IT professionals. Further, even when a business does have sufficient EDI expertise, they may not have enough resources to cope with system setup and/or ongoing operation. Unless you are willing to invest in new staff members to cope with the additional workload, you risk overloading your IT team and increasing the likelihood of errors as a result.

2) Maintenance of various different servers

When handling EDI via an EDI converter it is often necessary to maintain various different servers. These are needed to enable the transmission of certain document formats over different protocols to various VANs and partners. For example (as pictured below) you might easily need to maintain an X.400 mailbox as well as both an AS2 and an SFTP server to be able to reach all your business partners. In such a scenario you also need to monitor and maintain the connections to and from these servers, including any interconnects to different VANs.

Click to enlarge

Further, as EDI enables the transmission of business-critical documents such as orders and invoices, it is imperative that total system failure is safeguarded against. The only way to do this properly is to maintain multiple redundant servers so that all message exchange and archived messages are backed up. However, as this involves investing even more on hardware etc. than the already significant amount required to maintain a single server, many businesses opt not to provide EDI systems in a redundant manner. In so doing, these businesses risk catastrophic financial consequences should total system failure occur.

3) Monitoring of connections and interconnections with different VANs etc.

There are many problems with having to juggle multiple VAN connections. In short, these issues concern the difficulty of message tracing, maintaining multiple VAN mailboxes and resolving errors (something made particularly hard by the fact there is often no clear point of contact). Unfortunately, these issues are unavoidable for companies that choose to handle EDI internally, as the only future-proof way to simplify messy EDI landscapes is to pass the management of VAN connections to an EDI solution provider such as ecosio.

4) High likelihood of errors occurring

Whereas fully managed VANs will have rigorous and reliable testing, onboarding and verification procedures in place, this is often not the case with in-house arrangements. As in-house teams often have a large and varied workload it is easy for oversights to occur during system setup which are hard to correct further down the line (neglecting to test for every possible iteration of an invoice, for example). Also, the more VANs that are being used, the higher the likelihood of errors occurring.

5) The cost!

Unsurprisingly conducting EDI in-house is not cheap. Not only does purchasing the necessary hardware and software require significant outlay (particularly if multiple servers are required), the time and staff costs are also considerable.

Want to solve your VAN connection headache?

This article is a snippet from our white paper Everything You Need to Know About VANs. In this paper we explore the different types of VANs, the benefits of doing EDI via API and the practical 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 now!

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

Der Beitrag Five Reasons Handling VAN Connections In-house is Unwise erschien zuerst auf ecosio.

1. Managing EDI with SAP PI or SAP PO internally yourself
2. Installing a local EDI converter and connecting to SAP PI or SAP PO
3. Outsourcing to a fully managed EDI service provider

We will show you which EDI functionalities you can implement in your company with the respective solution and which questions decision-makers can use to help themselves in choosing the right solution.

EDI and B2B integration with SAP PI or SAP PO – What do I need to know?

SAP Process Integration (SAP PI) is a comprehensive software component that enables data exchange between the SAP system and internal and external systems. SAP PI uses various Java-based routing and integration mechanisms as well as various adapters that can be used to implement transport protocols and format conversions.

SAP Process Orchestration (PO) is an SAP PI installation variant (with different license models) that has been enhanced to include functionality in the area of “business process modeling and implementation”. In addition to the classic SAP PI capabilities of message routing, mapping and connectivity, PO also includes parts of SAP Business Process Management and SAP Business Rules Management.

In terms of EDI, the core technical functionalities of SAP PI and SAP PO are:

• Connectivity
• Mapping
• Routing

Under Connectivity, SAP PI offers a range of adapters that can be used to convert various message transport protocols. These include many protocols that are required for electronic message exchange with external partners, such as AS2, X.400, OFTP2, SFTP, RESTful Web Services, and so on. Mappings can be used to implement translations between SAP internal formats (for example, IDoc) and external EDI formats such as EDIFACT, XML, ANSI ASC X.12, and so on. Mappings can be converted using a graphical editor, based on XSLT, or using a Java program. Routing controls message delivery to different recipients based on information in the message.

All three solutions presented in the same way are based on these core functionalities of SAP PI or SAP PO, but differ essentially in the following factors in EDI operation or in the following questions that the decision-maker can ask himself:

• How much internal EDI capacity (i.e. personnel & EDI expertise) can I use for mapping, routing, 24/7 monitoring, troubleshooting and maintenance of the connections? Do I want to manage EDI completely internally or do I want to relieve my internal teams and outsource EDI?
• Which technical requirements does my EDI solution have to meet? Which document types, protocols, formats and legal requirements regarding electronic invoicing (e.g. XRechnung in Germany or FatturaPA in Italy) do I need for my B2B network?
• What EDI capabilities does my B2B network require? Do I need access to Value Added Networks (VANs)? Do I want or need to connect to Peppol? Do I have suppliers without EDI capabilities that I still want to connect to automated message exchange (with Web EDI?)
• How flexible or scalable do I want to design my EDI solution? Can I rely on a rigid implementation in the long term or do I want to become more resilient and future-proof with regard to the technical requirements?

If you know the answer to all these questions for your company, you will be able to make the right choice for your business. Keeping the questions in mind, we will now look at the three technical approaches for an EDI implementation in SAP PI and SAP PO.

1. Managing EDI with SAP PI or SAP PO internally

SAP PI and SAP PO are extremely complex and extensive software components that allow for internal implementation of some EDI functionalities. According to the point-to-point principle, automated EDI connections to individual partners can be established by appropriately qualified personnel.

However, one of the main challenges during implementation is precisely the complexity of the software. One does not get the proverbial hammer and nail in the hand, but a very extensive toolset. For the independent configuration and the ongoing operation of EDI connections via SAP PI or SAP PO, highly qualified employees with corresponding EDI expertise are therefore required. If smooth EDI operation is to be guaranteed 24/7, these employees must be available on a continuing basis.

Furthermore, not all required EDI functionalities (current and future) may be supported or require the use of additional solutions, as shown in the graphic:

SAP PI/PO handled in-house

If you want to implement EDI internally purely with SAP PI or SAP PO, you will therefore have to do without some functions (or implement them as a third-party solution), but you will also need highly qualified personnel, EDI know-how and sufficient resources to cope with:

1. Mapping and routing of all necessary connections
2. Ongoing maintenance of the connection parameters and regular renewal of certificates
3. Ongoing maintenance of mapping tables and industry internal practical knowledge about the implementation of special formats (e.g. VDA)
4. Ongoing coordination with the B2B partners and procurement of all necessary information (especially in the onboarding process)
5. 24/7 monitoring and troubleshooting

Incidentally, those who only want to work with SAP PI have to accept a major restriction – this only allows flat file formats via SFTP/SOAP/REST/HTTP protocols. If you want to use “classic” EDI formats (such as EDIFACT or ANSI ASC X12) and protocols (such as AS2 or X.400), you must have either a special package from a third-party manufacturer or the “B2B Add-on” from SAP – but this is only available with the SAP PO license (even if no other SAP PO functions are required).

The issue of X.400 costs should also be mentioned. If messages have to be transmitted to third-party networks that are subject to charges, these costs can be quite high. As an individual company, often only poor rates are available due to the relatively small amount of data being exchanged.

Internal implementation of EDI with SAP PI and SAP PO offers you a very high degree of functionality and flexibility. However, configuration, operation and maintenance also require the use of appropriate resources, which must be included in the total cost of ownership analysis. These costs must also be taken into account when using a local EDI converter, the option we present next…

2. Installing a local EDI converter and connecting to SAP PI or SAP PO

Another possibility is the acquisition and operation of a local EDI converter, which is connected to SAP PI or SAP PO. This is a software to be installed locally that converts documents from SAP internal IDoc format to partner format and vice versa.

Converter solutions are individually adaptable, but are potentially cost-intensive due to individually payable license costs for various functionalities, formats and upgrades in combination with long-term maintenance contracts. For example, support for protocols such as X.400 or services such as VAN connectivity must be purchased separately.

Local converter solutions must also be operated completely by internal teams, just as in the previous solution (implementing and operating EDI in SAP PI or SAP PO internally). This includes particularly time-consuming processes such as mapping, testing and 24/7 monitoring. This again requires appropriately trained employees.

SAP PI/PO with local EDI converter

It should also be considered that both the software itself and the individual mappings age. In other words, over time new releases of the converter will be published, which do not necessarily allow an upgrade from the existing version and mappings. This results in corresponding migration projects that have to be realised internally or with the help of an external consulting company.

3. Outsourcing to a fully managed EDI service provider

Fully managed EDI is a cloud-based EDI solution where a company is connected to a specialised EDI service provider via a single connection. This service provider then takes over all EDI functions and processes, depending on your company’s requirements.

If your company uses SAP PI or SAP PO, all you need for a successful connection to ecosio as your EDI service provider is the snap ecosio Bridge for SAP and its turnkey integration flows in SAP PI or SAP PO, which was especially created by SNAP Consulting.

Deep EDI Integration in SAP with snap ecosio Bridge for SAP and iFlow/ICO

In this solution the EDI service provider creates and ensures all technically desired EDI prerequisites, such as routing via various protocols, VANs and Peppol or conversion into all common and necessary formats, including legal requirements in the field of e-invoicing. Further, operation, 24/7 monitoring and partner onboarding (including partner communication) are also handled by the service provider.

The deep integration of the EDI functionalities into the SAP system also enables your business department to:

• Jump to the original EDI message for incoming messages, directly in SAP – without need for an extra login
• Jump to the generated EDI message for outgoing messages – again without extra login
• Track the EDI message status directly in SAP by changing the IDoc status of sent EDI messages to status 40 or 41 – depending on whether the recipient received the message or not
• Conduct a full text search of all messages and documents
• Benefit from automatic alerts/notification if messages are incorrect or could not be delivered

Updates, the ongoing certification of protocols and new SAP versions (such as SAP S/4HANA) are easily adopted and supported. Fully managed EDI offers companies the possibility to use all EDI functions without an expiration date – providing maximum EDI efficiency with minimum internal effort.

Summary

You now know the three possible technical approaches for implementing EDI on the basis of SAP PI or SAP PO and which criteria and questions you should use to select the most suitable one for your company. Essentially, you need to assess how much capacity you have internally to cope with implementing and operating an EDI solution.

Independent EDI implementation or the use of a local EDI converter enables a company to send and receive EDI messages, but requires a high level of internal effort, and highly qualified personnel. In addition, some functionalities may have to be purchased externally.

Outsourcing to a fully managed EDI service provider offers you all the EDI functionalities available with SAP PI and SAP PO but in a flexible and freely scalable way. The entire effort, from mapping and routing to monitoring and troubleshooting, is taken over by the EDI service provider, relieving internal teams.

Want more information?

Discover more about our updated product, ecosio.flow.

Do you still have questions about SAP PI data exchange or EDI with an SAP ERP system? Feel free to contact us, we would love to help you!

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 Alternative Solutions for EDI in SAP PI and SAP PO erschien zuerst auf ecosio.

Often these reasons are further buttressed by decision makers’ confusion regarding the exact nature of the often labyrinthine data exchange systems currently in place in their organisation. Due to the gradual and organic nature in which legacy data processes evolve to cope with the constantly changing requirements of growing businesses, clarity regarding networks, connections, mappings etc. is often lost along the way. Unfortunately, in these situations it is impossible for EDI to be used as a strategic instrument. Instead, complex and outdated processes are likely to lead to dangerous errors.

Having an outdated EDI process in place today is more dangerous than ever. Things can spiral downwards extremely quickly as unreliable data exchange leads to you getting a bad ranking as a supplier, in turn leading to reduced quality ratings and ultimately to you occupying a much worse negotiating position in future customer discussions. You could even end up on the dreaded no-bid list!

Given the business-critical nature of the information being exchanged and the dangers of retaining outdated or overly complex systems, the decision to transition to future-proof your B2B integration processes is an extremely important one. This article aims to provide you with a simple list of things to think about to help you identify whether or not your current VAN is well-placed to help your business grow, what is involved in switching providers and when to move on.

What is a value added network (VAN)?

Simply put, a VAN is a privately hosted service which provides a means for companies to trade data with partners. These networks provide benefit to businesses by simplifying the means of communication. As we will explore, however, a VAN provider can offer far more than simply acting as a data conduit between business partners.

For a more detailed explanation, you can check our introductory article on the subject “Value Added Network (VAN) – Key Questions Answered”.

Is your current set-up working for you?

Too many VANs spoil the broth

As we’ve already touched on, one commonly experienced issue with legacy data systems is their complexity. One factor often adding to this complexity is the use of multiple VAN providers. While this may not immediately seem like a problem, it does come with various downsides, including:

• Higher costs – While you might not be paying each of your current VAN providers much, the combined total for managing data exchange processes via multiple VAN providers will inevitably cost more than if you were to transition to a single provider.
• No single responsibility – A huge benefit of outsourcing critical data processes such as e-invoicing is the ability to pass the responsibility for monitoring messages to a third party. This benefit is hugely undermined when multiple providers are involved.
• Less flexibility – Whether it’s changing trading partners or switching focus to a new market or region, businesses are constantly evolving. In order to cope with this change it’s important that your B2B processes are flexible. Unfortunately, when multiple VAN providers are involved flexibility is compromised, leading to frustration and delays surrounding updates and adjustments.

Can your VAN supplier meet your current AND FUTURE needs?

Without visibility of what else VAN suppliers may be able to provide it can be difficult to identify areas where a new or existing VAN system is lacking. Further, too many businesses fail to consider the extent to which their B2B integration partner will be able to meet their future requirements. Below is a list of things to consider when assessing potential providers to ensure you benefit from a reliable, flexible and future-proof system:

• Data transparency and ease-of-use – Access to real-time information regarding your EDI via a user-friendly platform is important to monitor current performance and identify areas for improvement. With this in mind, check that your prospective provider can offer the following:

1. Status overview of all sent and received messages
2. Full text search of all sent and received documents
3. Flexible message statistics and graphical representation of your communication flow
4. Message archive with customisable retention periods
5. Download option for local processing
6. User management with unlimited users

The ideal EDI solution is one which is embedded in your existing ERP system, enabling EDI processes to be seamlessly integrated into your user interface.

• Scalability – As your business grows and your partners and inbound/outbound messages increase in number it’s important that your key logistics processes are able to keep up. Choosing a provider that can offer additional benefits when needed, such as supplier relationship management features or web-based EDI connection, will ensure you are fully prepared for any future growth.
• Support – While most VAN suppliers will offer “support”, the level and accessibility of this support varies greatly. In addition to checking how easy it is to get hold of someone who can help you fix any issues quickly, make sure you select a provider that offers proactive (rather than simply reactive) support, as this will ensure potential issues are caught before they are able to develop.
• Ease of partner integration – Onboarding partners is often viewed as a time-consuming and headache-inducing process. By selecting a VAN provider that will manage the onboarding process from start to finish this need not be the case. If you are likely to be interacting with partners who don’t currently have EDI systems in place, selecting a provider that can offer them a web-based EDI connection is also extremely important.
• Monitoring and proactive alerting – Whether you’re concerned about checking that messages have been sent and received, renewing certificates or ensuring correct e-invoicing protocols are followed, choosing a provider that offers efficient round-the-clock monitoring of data processes and proactive alerting can provide peace of mind and relieve pressure on in-house teams.
• Analytics / SRM – Access to key performance indicators (KPIs) and metrics relating to your suppliers can be hugely useful in helping you to identify areas for improvement. A good VAN provider may even allow businesses to set targets for partners, in turn helping them to meet expectations.
• Ongoing updates – Although EDI is far from a new technology, data exchange processes and protocols are constantly improving. Unfortunately, however, many VAN providers are not future-focussed and may neglect to implement important updates relating to key new requirements. For example, not every VAN provides access to Peppol, which in turn can cause a big issue with e-invoicing. By choosing a VAN provider that is committed to implementing updates in line with these ongoing developments you will ensure your organisation’s data exchange processes to continue to function at optimum level.
• Pricing structure – Just like the levels of support and quality of monitoring offered by VAN providers, pricing structures can also vary greatly. Even if you are satisfied with the price quoted to handle your current EDI needs, make sure to consider whether their structure suits your future needs. Many contracts include prohibitive “price cliffs” which can prove extremely costly if your EDI usage changes.

For a detailed breakdown of how much work is done by different EDI providers, download our infographic on this topic.

Other things you may want to consider before switching:

• Do they have experience in your industry?
• What is their reach geographically?
• Are case studies available?
• What is included in the service – will the EDI provider look after mapping and conduct thorough testing?

Our decision guide compares on-premise v cloud managed EDI services in detail

What’s involved in switching VAN provider?

Arguably the biggest reason businesses put off changing VAN providers is fear of what the process will involve and the potential consequences if things were to go wrong.

It’s true that, handled incorrectly, switching VANs could result in not being able to send or receive information if messages are sent to the wrong place or a VAN doesn’t recognise traffic due to routing or mapping issues for example. However, this is not a problem when the process is handled by a capable provider. In addition to having experience in connecting to all commonly used VANs internationally, from Ariba to X.400, a good provider will provide a dedicated project manager to oversee the migration process from start to finish, ensuring the switch is as fast and efficient as possible.

While the time needed to complete migration depends entirely on your particular situation, with an experienced provider offering expert support there should be no issues or disruption to you or your partners’ businesses.

“When should I switch?”

Once you’ve decided to move away from your existing VAN it makes sense to go ahead with the data migration process as soon as you are able to. Often switching VAN suppliers comes at the end of a long period of assessment of and/or dissatisfaction with existing providers – why stretch the process out any more? The sooner you switch, the sooner you can experience the benefits of efficient B2B integration!

Find out more

For more information about ecosio’s unique B2B integration solution and how it could help your business, you can visit our Integration Hub page.

Alternatively, if you have questions about your specific situation please contact us or use our chat – we are happy to help!

Der Beitrag When Should I Replace My VAN Provider? erschien zuerst auf ecosio.

An EDI VAN, or Value Added Network is a closed-circuit network to which companies can be connected, and over which EDI data is exchanged via different protocols. To communicate with a company using a VAN, you generally require a VAN of your own. As we shall cover, however, this does not have to be something you manage in-house – and indeed shouldn’t be unless you have sufficient in-house expertise.

The three different ways to exchange EDI messages

Historically, there are three ways you can exchange EDI messages with trading partners…

1. One-to-one connections
2. Many-to-many connections
3. One-to-many connections

One-to-one connections

One-to-one connections (also known as point-to-point connections) are custom-built to transfer messages independently and exclusively to each partner, as illustrated in the image below:

One-to-one relationship

One-to-one connections require technical expertise to build as each connection is bespoke. For growing businesses or large enterprises it doesn’t make sense to build custom connections this way, as it is time-consuming and will overburden in-house resources, who may not have sufficient expertise in the first place. Outsourcing professional services to a third-party IT services company to build the connections for you may not be the lesser evil either, since you have to ensure governance, monitoring, maintenance, updates and other changes, which may lead to further complications when scaling.

As automation becomes an increasingly integral part of supply chain communications, the requirements for B2B connections are also growing. Businesses are now demanding analytics for insights and intelligence, proactive alerting & troubleshooting and self-service functionality. Point-to-point connections are not suited to such swift change, as each connection needs to be individually upgraded. It is only possible to leverage economies of scale by enlisting the help of a specialised third-party EDI provider.

Many-to-many connections

Before the adoption of the cloud or the World Wide Web, large enterprises would avoid the challenges seen in one-to-one relations and share information across private telecommunication networks. This is called a many-to-many (or any-to-any) approach, as any company that is connected to the network can in principle exchange documents with anyone else in that network. Many-to-many relations enable network effects, as each participant in the network can add to or gain value from the network by connecting to it (suppliers and buyers in this case).

You can see how this works in the figure below using the example of supplier-buyer relations.

Many-to-many connections for suppliers and buyers

One-to-many connections

While a many-to-many approach is by far the most efficient design for VANs to use, many providers still use a one-to-many approach. In this type of system, the partner community is ring-fenced and the connections are exclusive to the customer, as shown in the image below:

One-to-many relation

In a one-to-many scenario, if you presume the company is a supplier and wants to do business with different customers by connecting via EDI, each connection with the “EDI Hub” is independent. This means the connections are not reusable by other suppliers as the instance of the Hub is separate from a shared network (even if hosted on the cloud). This can greatly impact time-to-value of onboarding new partners and making changes, as connections are not operating across a single platform network.

What to look for in a good EDI Value Added Network

If you are looking to use an external EDI VAN provider, be sure to ask the following questions:

Do they operate a many-to-many or one-to-many approach?

If you value flexibility and speed, be sure to opt for a solution that uses a many-to-many approach. You can check this by asking if providers allow for reuse of existing connections in their partner network and how those connections are facilitated across their systems to see if it makes sense to your business. Often traditional vendors have federated legacy systems which can cause further issues or charge extra to be part of their network. Modern B2B IT vendors should not be charging extra for being part of their network.

What value do they add?

While every VAN will be able to connect you with trading partners in the network, some will offer much more than others. For example, some network providers may offer additional services including:

• Self-service for relevant teams to view, access and edit EDI information
• Proactive support, to ensure issues and errors are identified and resolved as fast as possible
• Monitoring, visibility and analytics, so users can track end-to-end performance of messages in real-time

When deciding on a VAN it’s important to think about the additional elements listed above, which are often mission critical to supply chain success. Many EDI vendors and providers overstate their capabilities, which can lead to further issues later on, e.g. delays, message errors, additional costs or even lost sales.

One way to measure a Value Added Network or EDI provider’s ability to execute in a modern hyper-connected environment is to look at the latest innovations or key product releases to determine whether they really are updating their offering over time.

How much in-house work will be required?

If you don’t have in-house EDI expertise, it makes sense to minimise the amount of tasks you handle internally. While there are some businesses who can operate an efficient EDI solution in-house, as we will cover in the next section, the far safer and more efficient approach for most businesses is to outsource EDI tasks to an experienced EDI VAN provider.

For those businesses that wish to outsource EDI tasks completely, a fully managed VAN, such as ecosio, offers the perfect solution. Not only does a fully managed provider deliver messages via the required network, they also handle everything from the initial technical setup and mappings right through to message monitoring and error resolution. Plus you may even be able to integrate the solution into your existing ERP system via API.

To view a detailed comparison of the amount of work done by different EDI providers, download our infographic on this topic.

Five reasons to avoid using in-house EDI converters

1) The need for EDI expertise and internal resources

Undoubtedly the main hurdle stopping businesses from attempting to manage EDI in-house is the complexity of EDI processes. Unfortunately, given the way in which EDI has developed over the decades and the myriad of formats and protocols available to businesses today, managing EDI requires significant technical expertise which is rare among in-house IT professionals. Further, even when a business does have sufficient EDI expertise, they may not have enough resources to cope with system setup and/or ongoing operation. Unless you are willing to invest in new staff members to cope with the additional workload, you risk overloading your IT team and increasing the likelihood of errors as a result.

2) Maintenance of various different servers

When handling EDI via an EDI converter it is often necessary to maintain various different servers. These are needed to enable the transmission of certain document formats over different protocols to various VANs and partners. For example (as pictured below) you might easily need to maintain an X.400 mailbox as well as both an AS2 and an SFTP server to be able to reach all your business partners. In such a scenario you also need to monitor and maintain the connections to and from these servers, including any interconnects to different VANs.

Click to enlarge

Further, as EDI enables the transmission of business-critical documents such as orders and invoices, it is imperative that total system failure is safeguarded against. The only way to do this properly is to maintain multiple redundant servers so that all message exchange and archived messages are backed up. However, as this involves investing even more on hardware etc. than the already significant amount required to maintain a single server, many businesses opt not to provide EDI systems in a redundant manner. In so doing, these businesses risk catastrophic financial consequences should total system failure occur.

3) Monitoring of connections and interconnections with different VANs etc.

There are many problems with having to juggle multiple VAN connections. In short, these issues concern the difficulty of message tracing, maintaining multiple VAN mailboxes and resolving errors (something made particularly hard by the fact there is often no clear point of contact). Unfortunately, these issues are unavoidable for companies that choose to handle EDI internally, as the only future-proof way to simplify messy EDI landscapes is to pass the management of VAN connections to an EDI solution provider such as ecosio.

4) High likelihood of errors occurring

Whereas fully managed VANs will have rigorous and reliable testing, onboarding and verification procedures in place, this is often not the case with in-house arrangements. As in-house teams often have a large and varied workload it is easy for oversights to occur during system setup which are hard to correct further down the line (neglecting to test for every possible iteration of an invoice, for example). Also, the more VANs that are being used, the higher the likelihood of errors occurring.

5) The cost!

Unsurprisingly conducting EDI in-house is not cheap. Not only does purchasing the necessary hardware and software require significant outlay (particularly if multiple servers are required), the time and staff costs are also considerable.

Final thoughts

To take advantage of a hyper-connected world, it’s important to leverage many-to-many networks to drive commerce with your trading partners. It increases speed and agility to ultimately achieve the best outcomes for your business. Although this service has been in place since the 1980’s it’s crucial to consider additional benefits as part of a B2B e-commerce network, e.g. self-service, support, monitoring, analytics and troubleshooting. In the future these will be necessary requirements for any Value Added Network.

As many traditional EDI vendors and solutions overstate their capabilities, it’s important to look at proof of continued innovation and to understand clearly how your proposed supplier’s support model works.

Want to solve your VAN connection headache?

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

Download your copy and find out how you can optimise your processes now!

Alternatively, if you have any questions about VANs or anything else EDI related, feel free to get in touch. We’re always happy to help!

Der Beitrag Value Added Network (VAN) – Key Questions Answered erschien zuerst auf ecosio.

• X.400 is a message transfer protocol similar to e-mail but over a dedicated network, often called a Value Added Network (VAN) in the B2B sector
• X.400 was adopted in 1984 by the CCITT (now ITU) and extended in 1988, with IPM84 networks remaining compatible with newer IPM88 networks
• X.400 has secured a niche in EDI message transmission, supported in Germany as BusinessMail X.400 and still used alongside protocols like AS2
• X.400 networks use mailboxes managed by message stores and transfer via message transfer agents, with structured addressing and improved security from a separate authenticated network

The simple answer to the question “What is X.400?” is that “it is a message transfer protocol – in principle very similar to e-mail, but over a dedicated network rather than the internet”.

Yes, although it is hard to imagine in this day and age, there are other networks that exist parallel to the Internet. In the B2B sector these networks are often called Value Added Networks (or VANs). Of these the X.400 network is probably the best known.

However, there is much more to X.400 than this, as we’ll explore in this article…

A quick review…

Before we go into the technical details, let’s turn back the clock a little: 30 years ago, in 1984, the Comité Consultatif International Téléphonique et Télégraphique (CCITT), now the International Telecommunication Union (ITU), first adopted X.400 as a standard. In 1988, the X.400 standard was extended. This distinction is still noticeable today, as some (sub)networks are still based on the old IPM84 (IPM stands for Interpersonal Messaging Standard, and 84 for the year 1984). Fortunately, however, these are largely compatible with the “newer” IPM88 networks.

The name IPM already indicates that X.400 should initially be positioned as a general mail or messaging system. At the same time, work on an e-mail system was already underway in the context of Internet protocols. The protocols SMTP, POP and IMAP – with the establishment of the Internet in our daily lives – then became established in the late 1990s as global standards for interpersonal messaging, i.e. e-mail. As we will see later, X.400 and Internet e-mail (i.e. SMTP/POP/IMAP) are relatively similar in their topology and mode of operation. However, X.400 is considered a much more complex protocol family, not least because of its additional functionalities.

While X.400 has been completely replaced by Internet e-mail in the interpersonal messaging sector, it has been able to secure a niche existence for the transmission of EDI messages. In Germany, access to the X.400 network is marketed by Deutsche Telekom under the name BusinessMail X.400 – formerly Telebox or Telebox400. Therefore the term Telebox is often still used today as a synonym for an X.400 mailbox. Besides AS2, X.400 is the most used protocol for the transmission of EDI messages today. While AS2 is not yet offered by every company for the transmission of EDI messages, the acceptance of X.400 for the exchange of EDI data can be described as very high.

Due to the not inconsiderable costs for the transmission of the messages – Deutsche Telekom still charges in kilobytes (!) – AS2 connections are increasingly in demand for medium to high message volumes. In order to save costs at low message volumes, it makes sense for SMEs and other supply chain organisations to enlist the help of an EDI provider. As providers purchase a higher volume of messages than individual supply chain businesses, they are able to achieve a better per-message cost. Suppliers can then pass these savings (as ecosio does) onto their customers. But this is a subject for another time. For now, let’s look further into the technical structure and functionality of X.400.

Structure of X.400 networks

As with Internet e-mail, communication takes place via mailboxes. An X.400 mailbox is managed by a Message Store (MS) and identified by a unique address. Messages are transmitted to a mailbox via so-called Message Transfer Systems (MTS) or Message Transfer Agents (MTA) Users access their X.400 mailbox via User Agents – i.e. client software. The following figure provides a simplified overview of the topology of X.400 networks.

X.400 Network Topology

X.400 has a two-tier domain structure: An ADMD is a so-called public service area. ADMDs are usually operated by telecommunications companies – such as Deutsche Telekom. Several ADMDs can exist in a country. A PRMD is a so-called private utility area and is managed independently by companies for better organization. The distinction between ADMDs and PRMDs is an interesting technical detail – but in practice it hardly plays a role any more. Today, a company usually operates a single X.400 mailbox for the exchange of EDI messages or a few if it is a large company and there is a functional separation (e.g. ordering and invoicing processes).

Addressing in the X.400 network

Each X.400 mailbox is identified by a unique address – just like Internet e-mail. X.400 addresses are semantically structured similar to SMTP e-mail addresses, but are somewhat more complex in notation and often longer. Let’s look at the following example to explain the attributes of an address and how to read them:

G=Max; S=sample man; O=sample company; OU=purchasing; A=X400EXAMPLE; C=AT

This example address would identify the X.400 mailbox of Max Mustermann, who works in purchasing at Musterfirma. The mailbox would be hosted directly in the Austrian ADMD X400EXAMPLE – without using a PRMD. The attributes used in this example

• C (Country name)
• ADMD (Administration Management Domain)
• O (Organisation name)
• OU (Organisational Unit Names)
• G (Given name)
• S (Surname)

are used very frequently in addresses. A more detailed overview of the use of addresses in networks is given in RFC 1685 or Harald T. Alvestrand’s X.400 Website (from 1995):

Deutsche Telekom also uses the attributes CN (Common Name) and n-id (User Agent Numeric ID) in its X.400 network (VIAT). Using these attributes can cause problems when addressing from/into an older IPM84 network (e.g. MARK400). The simplest workaround is to simply omit these attributes – the unique identification of the X.400 mailbox in the VIAT network can also be done without CN and n-id (if the parameters G and S are used).

Confirmation of message receipt

One feature – which is almost indispensable when transmitting EDI – is the notification of the sender that a message has been successfully received. X.400 knows two types of notifications.

• Delivery Notification (DN): is generated by the server that places the message in the mailbox of the recipient and transmits to the sender MTA. This means the confirmation is generated by the server (on which the X.400 mailbox is hosted) and transmitted to the sender. The negative counterpart of the DN is the so-called Non-delivery Notification (NDN) and is transmitted to the sender in case of an error.
• Receipt Notification (RN): can be generated by the recipient’s client software and is transmitted to the sender – in practice, the RN is hardly ever requested or supported in automated transmission. The negative counterpart of the RN is the Non-receipt notification (NRN).

The sequence is shown as an example in the following diagram.

X.400 Notifications

Although in practice the Receipt Notification (RN) has hardly any significance, with the receipt of the Delivery Notification (DN) it can already be assumed that the EDI system of the recipient has received the message – at least on a technical level. The sender is then usually informed of any processing problems with the message via e-mail or telephone.

Importance of X.400 for EDI today

The end of X.400 message transmission has often been predicted – not least because of the high costs. But it is still impossible to imagine the EDI sector without it. In addition to the principle (particularly prominent in EDI) “never touch a running system”, the security aspects are a major advantage: After all, it is a separate network, physically separated from the Internet. Every participant is authenticated, which reduces the potential for abuse compared to SMTP/email to a minimum.

If you want to use an X.400 mailbox for your EDI data exchange or would like to reduce your existing X.400 costs, contact us today. We are always happy to answer any questions!

Der Beitrag X.400 – What is it and Why is it Still Around? erschien zuerst auf ecosio.