Der Beitrag EDI Interfaces Explained erschien zuerst auf ecosio.
]]>- EDI interfaces enable automated exchange of structured business data, converting internal formats into standardised ones like EDIFACT or XML to reduce manual input and errors
- The process relies on connectivity, conversion and communication, involving agreed formats, mapping to EDI standards, and secure protocols such as AS2, OFTP2 or REST API
- Common problems include lack of user-friendliness, limited flexibility, dependence on in-house expertise, and rushed implementation
- A good interface offers seamless integration, flexibility, security, scalability, monitoring, and especially data visibility, which is enhanced through API connections enabling real-time status tracking and error resolution
As the old saying goes, time is money; and nowhere is this more relevant than in the world of B2B transactions. From data entry errors to message failures and delays, inefficient B2B processes can cost businesses dearly. By offering a means to automate B2B communication, electronic data interchange (EDI) and EDI interfaces enable businesses to both save time and improve efficiency – in turn resulting in significant cost savings!
Contrary to what many think, setting up a successful EDI interface isn’t rocket science. In fact, with the support of the right EDI provider, you can start reaping the benefits of a good EDI interface in no time. But what exactly makes a good EDI interface? How does an EDI interface work, and what benefits can a good interface offer? In this article we’ll answer all of these questions and more.
What is an EDI interface?
An EDI interface is a technical platform that enables the electronic exchange of structured business data between different systems. EDI interfaces are crucial in business communication, where they automate the manual exchange of documents (such as purchase orders, invoices and shipping notifications).
Simply put, an EDI interface converts data from internal systems (e.g. accounting software) into a standardised format – and vice versa. Once in standardised format, the data is automatically sent to the relevant external party (e.g. a customer or supplier). Not only does this automated process save time, it also greatly reduces the potential for errors, as the need for manual data input is removed on both the sender and receiver’s sides.
How does an EDI interface work?
An EDI interface can be set up via different communication channels: via the internet, via direct connections between systems or via special EDI networks.
The data transfer between sender and receiver is based on the three “C”s: connectivity, conversion and communication.
- Connectivity. Before anything else, the sender and receiver must define a common, structured data format, e.g. EDIFACT or XML, which is then used for all exchanges via the EDI interface. In most cases the format to be used is dictated by the customer via a message implementation guideline (MIG).
- Conversion. Once this format has been chosen, mapping must be done to ensure that data is correctly converted from whatever inhouse format is being used (e.g. IDocs in SAP systems) to the agreed EDI format. This step involves a lot of technical expertise and testing.
- Communication. Once mapping has been set up, the next step is handling how the data is transferred – i.e. what transfer protocol should be used. Protocols are the means by which data is securely transferred to the recipient, with popular protocols including AS2, HTTP, OFTP2, REST API and web services.
On the recipient’s side, the process then takes place backwards: they receive the data via their EDI interface and convert it into its internal format before validating and processing it. After processing, the receiver sends a response to the sender to confirm the successful receipt of the data as well as its processing. In the event that processing problems occur, the response may also include error messages.
The four most common problems with EDI interfaces
As we’ve mentioned already, when implemented well, an EDI interface can provide many benefits, from helping businesses save time and money, to reducing risk and boosting attractiveness to partners. However, there are many things that can prevent an interface from delivering maximum value. These include…
- Not being user-friendly. Given the extent of the technical work required to send and receive EDI messages, EDI interfaces are often complicated to use, with data accessible only to IT personnel. In such situations, IT can easily become a bottleneck, and the potential value that EDI can offer is limited.
- Lack of flexibility. Whether due to internal or external factors, EDI requirements inevitably change over time. Unfortunately, not all EDI interfaces lend themselves to quick adjustments, however. For example, if an EDI interface is maintained by in-house staff members who have other responsibilities – as opposed to external experts – tasks such as onboarding new partners or changing complicated mappings may take a long time to complete.
- Dependence on in-house technical expertise. The implementation of a good EDI interface requires a lot of technical expertise, both during setup and ongoing operation. If EDI tasks are to be handled internally and inhouse resources are lacking, this can be a real issue.
- Rushed implementation. Despite the fact that EDI is essential in modern B2B relationships, it’s rarely given sufficient consideration in ERP migration projects. As a result, EDI interfaces are often implemented at the end of migration projects, with ERP customisers rushing to find something that can do the job rather than taking the time to select a well-suited, futureproof solution.
What makes a good EDI interface?
A good EDI interface is characterised by several features.
- It should allow seamless integration to ensure smooth data exchange between different systems.
- It should be flexible and support diverse data formats to meet the requirements of different business partners.
- It should be secure and provide mechanisms for data encryption and authentication in order to guarantee the confidentiality and integrity of the transmitted data.
- It should be scalable and able to adapt as your EDI needs evolve over time.
- It should have extensive message monitoring and error handling functions to allow for errors to be spotted and resolved quickly.
Perhaps the most important feature of a successful EDI interface, however, is data visibility.
Given the significance of the data being exchanged via EDI, relevant departments having real-time visibility of key information – such as whether or not a partner has received or opened an invoice – is extremely important. Similarly, having access to an EDI dashboard which offers a helpful overview of EDI message flow can make message monitoring much easier.
Despite this, such functionality is only offered by a minority of EDI interfaces – namely those which utilise an API connection…
How an API connection can boost efficiency
As a collection of rules and protocols, an API connection defines how the various exchange formats, exchange protocols and security requirements of an EDI interface should interact. The main advantage of EDI interfaces based on API connections is that the data is accessed directly. This means that no metadata is lost and important information such as whether an invoice has been received by the EDI service provider or by the final message recipient can be displayed in real time in the existing user interface of the user’s ERP system. This improves supply chain efficiency and minimises the occurrence of errors.
When errors do occur, the data transparency offered by API connections is also extremely helpful, as the user can easily determine where the problem lies and what needs to be done to resolve it. EDI interfaces which utilise API connections may also offer added benefits such as full-text search functionality, which allows EDI messages to be found quickly by searching for any known identifier, such as article number or transmission ID.
Another key benefit of connecting an EDI interface via API is that specialist teams such as sales or purchasing don’t need to go through IT to get key information. By improving data visibility and accessibility and allowing relevant employees to access data directly in their ERP system, using an API connection eliminates internal bottlenecks.
In short, EDI interfaces that utilise an API connection help businesses to streamline B2B processes by ensuring that all relevant parties have real-time visibility of important information, that information can be located easily, and that errors can be resolved quickly.
Want to know more?
Want to know more about EDI and how ecosio’s unique EDI as a Service solution could help you? Then contact us today! Our EDI experts will be more than happy to show you how you could leverage efficient EDI to save time, save money, reduce risk and boost your competitive advantage.
Discover more about our updated product, ecosio.flow.
Der Beitrag EDI Interfaces Explained erschien zuerst auf ecosio.
]]>Der Beitrag Common EDI Errors and How to Fix Them erschien zuerst auf ecosio.
]]>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…
- Your ERP system
- Your EDI system and/or VAN
- The EDI system of your partner and/or VAN
- 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.
]]>Der Beitrag Peppol Message Responses – A Helpful Guide erschien zuerst auf ecosio.
]]>In this article we explore some of the technical aspects of Peppol – namely the three types of message response supported by Peppol, Peppol transport acknowledgements, message level responses and business level responses. Looking at each one by one, we’ll examine what they do, how they work and how they differ from one another. To skip to a particular section, please click the relevant section heading below:
- Peppol’s four corner model
- Transport Acknowledgements (Acks)
- Message level responses (MLRs)
- Business level responses (invoice responses)
If you would like a more general overview of what Peppol is and the benefits it can offer, please find our downloadable white paper “Peppol: What You Need To Know”.
The structure of the Peppol network
Before we jump into the three different types of Peppol message responses, it is first important to understand the underlying network structure behind Peppol. This is known as the four corner model.
The “four corners” of this network model refer to
- the message sender,
- the message sender’s Peppol access point,
- the Peppol access point of the message recipient, and
- the message recipient themselves
This arrangement is fundamental to Peppol message exchange as, along with strict rules regarding which standards and protocols can be used, it makes message exchange as simple as possible. The easiest way to understand the benefits is by comparing to the alternative models:
The two corner model
With direct automated message exchange (AKA a two corner model) each connection requires time-consuming set-up by inhouse IT teams or an external consultant. Connections are not reusable for multiple partners, meaning every new partner requires a completely new setup.
Two corner model
The three corner model
In a three corner model on the other hand, message routing is done via a central service provider hub. Though this may be preferable to a two corner model, it still lacks flexibility, as both sender and receiver must have the same service provider, making it badly suited to large supply chains. In addition this model typically results in one of the parties being forced into a contract with the service provider of their partner.
Three corner model
The four corner model
By contrast, Peppol’s four corner model doesn’t require unique point-to-point connections or for both parties to use the same provider.
Once a connection to an access point has been established, the Peppol Participant ID is sufficient to send an electronic message to any Peppol partner of choice (and be reached by other Peppol-connected companies). Message validation is handled by the sender’s access point and both sender and receiver’s access points can access a service metadata locator (SML) and service metadata publishers (SMP) as required.
The Peppol four corner model
How Peppol message responses fit in
To help provide a framework for understanding the more detailed descriptions of each Peppol message response type below, this diagram shows how they fit into the four corner model. All messages and acknowledgements are exchanged via the access points of the sender and the receiver. The dashed arrows indicate, to which component of the exchange infrastructure an acknowledgement or a response message belongs to.
Where message responses fit in
A transport acknowledgement is the most basic type of confirmation and is an integral part of Peppol’s AS4 protocol. Message level responses are generated by the receiver’s messaging system and are intended for the sender’s messaging system. Finally, a business level response is intended to be processed by the sender’s ERP system.
Now let’s examine each, starting with transport acknowledgements…
1) Transport acknowledgements
What is a transport acknowledgement (Ack)?
A transport acknowledgement is an electronic receipt sent from the receiving access point (C3) to the sending access point (C2) following the transmission of a structured message such as an invoice. The acknowledgement notifies the sending party if technical delivery was successful and can include relevant information such as why delivery of a message was unsuccessful. Importantly, however, acknowledgements do not say anything about the validation of the message or whether the contents were correct, for example.
In Peppol, communication takes place via the protocol AS4 (previously AS2). Acknowledgements are a key feature in AS4 communication, where an acknowledgement is referred to as a SignalMessage.
There are three types of SignalMessage:
- SignalMessage/Receipt
- SignalMessage/Error
- SignalMessage/PullRequest (not used in the context of Peppol)
What does a Peppol acknowledgement achieve?
Transport acknowledgements help to enforce data integrity and non-repudiation. In simple terms they clarify that a message has definitely been received and ensure that the recipient can’t deny receipt of that message.
In turn, this helps to speed up partner communication and make transactions more transparent.
A breakdown of the process
Essentially it works like this:
- The sender assigns the outgoing message a unique ID (this happens automatically by the sender’s access point)
- Once the outgoing message is received by corner three access point, the SignalMessage (Peppol acknowledgement) is returned. This message has a unique ID as well and carries a reference to the message it acknowledges. Thereby, a SignalMessage can carry a positive or a negative acknowledgement. Positive acknowledgements are submitted using SignalMessage/Receipt and negative acknowledgements are submitted using SignalMessage/Error.
2) Message level response (MLR)
Arguably the most important part of automated message exchange is message validation – i.e. where a message is checked against the agreed specifications (syntactical and semantic).
In Peppol, message level responses, or MLRs, serve to inform the sender of the success (or otherwise) of validation. Helpfully, in the case of failure, these messages also detail what went wrong, such as a specific syntax error relating to a missing closing tag. It is important to note that MLRs will not identify if a certain value is correct in the context of a certain message, but merely that it is in accordance with the agreed specifications. For example, an MLR would not notify you if an article number was wrong, but would alert you if an article number is missing (for a full rundown of what errors a message level response is capable of alerting you to, please check the external article “BIS Message Level Response 3.0”).
MLRs can communicate three things to the sender of the original message:
- The message contained errors and failed validation.
- The message did not contain errors and passed validation.
- The message has been received, but is not yet validated.
Technically MLRs are returned using UBL Application Response 2.1 messages.
3) Business level response
What is a business level response (AKA invoice response)?
The final Peppol message response type is the business level response and is used to inform the sender of a message about the status or outcome of corner four processing the message. In the case of invoices the business level response is called the invoice response message and could for instance contain a rejection, because the referenced purchase order number in the invoice is invalid.
In general an invoice response message supports the following status codes:
- AB – basic message acknowledgement
- AP – accepted
- RE – rejected
- IP – in progress
- UQ – under query
- CA – conditionally accepted
- PD – paid
While Peppol BIS does not require corner four to support all these codes, the first three (AB, AP and RE) must be supported as a minimum. Peppol BIS also requires that the initial sender (AKA corner one) must receive this response within three working days.
How a business level response works and what it looks like
In the event that an invoice is rejected (RE), put under query (UQ) or conditionally accepted (CA), corner four must provide information to help corner one resolve the issue. Status Reason codes and Status Action codes provide a means of doing this. Detailed information can also be added via a free text field which is supported by Peppol.
Like a message level response, a business level response is also based on a UBL Application Response 2.1. The following snippet shows an exemplary invoice response.
Business level response example (click for larger version)
Want more information?
At ecosio we are experts in Peppol and e-invoicing and were one of the very first Peppol Access points in Europe. To date we have helped hundreds of companies to integrate efficient e-invoicing processes into existing systems and experience the benefits of Peppol.
For more information on Peppol please feel free to get in touch with our experts via our chat or our contact form. We are always happy to help!
Have you tried our free XML/Peppol document validator?
To help those in need of a simple and easy way to validate formats and file types, from CII (Cross-Industry Invoice) to UBL, we’ve created a free online validator.
Der Beitrag Peppol Message Responses – A Helpful Guide erschien zuerst auf ecosio.
]]>Der Beitrag Peppol Message Responses – A Helpful Guide erschien zuerst auf ecosio.
]]>In this article we explore some of the technical aspects of Peppol – namely the three types of message response supported by Peppol, Peppol transport acknowledgements, message level responses and business level responses. Looking at each one by one, we’ll examine what they do, how they work and how they differ from one another. To skip to a particular section, please click the relevant section heading below:
- Peppol’s four corner model
- Transport Acknowledgements (Acks)
- Message level responses (MLRs)
- Business level responses (invoice responses)
If you would like a more general overview of what Peppol is and the benefits it can offer, please find our downloadable white paper “Peppol: What You Need To Know”.
The structure of the Peppol network
Before we jump into the three different types of Peppol message responses, it is first important to understand the underlying network structure behind Peppol. This is known as the four corner model.
The “four corners” of this network model refer to
- the message sender,
- the message sender’s Peppol access point,
- the Peppol access point of the message recipient, and
- the message recipient themselves
This arrangement is fundamental to Peppol message exchange as, along with strict rules regarding which standards and protocols can be used, it makes message exchange as simple as possible. The easiest way to understand the benefits is by comparing to the alternative models:
The two corner model
With direct automated message exchange (AKA a two corner model) each connection requires time-consuming set-up by inhouse IT teams or an external consultant. Connections are not reusable for multiple partners, meaning every new partner requires a completely new setup.
Two corner model
The three corner model
In a three corner model on the other hand, message routing is done via a central service provider hub. Though this may be preferable to a two corner model, it still lacks flexibility, as both sender and receiver must have the same service provider, making it badly suited to large supply chains. In addition this model typically results in one of the parties being forced into a contract with the service provider of their partner.
Three corner model
The four corner model
By contrast, Peppol’s four corner model doesn’t require unique point-to-point connections or for both parties to use the same provider.
Once a connection to an access point has been established, the Peppol Participant ID is sufficient to send an electronic message to any Peppol partner of choice (and be reached by other Peppol-connected companies). Message validation is handled by the sender’s access point and both sender and receiver’s access points can access a service metadata locator (SML) and service metadata publishers (SMP) as required.
The Peppol four corner model
How Peppol message responses fit in
To help provide a framework for understanding the more detailed descriptions of each Peppol message response type below, this diagram shows how they fit into the four corner model. All messages and acknowledgements are exchanged via the access points of the sender and the receiver. The dashed arrows indicate, to which component of the exchange infrastructure an acknowledgement or a response message belongs to.
Where message responses fit in
A transport acknowledgement is the most basic type of confirmation and is an integral part of Peppol’s AS4 protocol. Message level responses are generated by the receiver’s messaging system and are intended for the sender’s messaging system. Finally, a business level response is intended to be processed by the sender’s ERP system.
Now let’s examine each, starting with transport acknowledgements…
1) Transport acknowledgements
What is a transport acknowledgement (Ack)?
A transport acknowledgement is an electronic receipt sent from the receiving access point (C3) to the sending access point (C2) following the transmission of a structured message such as an invoice. The acknowledgement notifies the sending party if technical delivery was successful and can include relevant information such as why delivery of a message was unsuccessful. Importantly, however, acknowledgements do not say anything about the validation of the message or whether the contents were correct, for example.
In Peppol, communication takes place via the protocol AS4 (previously AS2). Acknowledgements are a key feature in AS4 communication, where an acknowledgement is referred to as a SignalMessage.
There are three types of SignalMessage:
- SignalMessage/Receipt
- SignalMessage/Error
- SignalMessage/PullRequest (not used in the context of Peppol)
What does a Peppol acknowledgement achieve?
Transport acknowledgements help to enforce data integrity and non-repudiation. In simple terms they clarify that a message has definitely been received and ensure that the recipient can’t deny receipt of that message.
In turn, this helps to speed up partner communication and make transactions more transparent.
A breakdown of the process
Essentially it works like this:
- The sender assigns the outgoing message a unique ID (this happens automatically by the sender’s access point)
- Once the outgoing message is received by corner three access point, the SignalMessage (Peppol acknowledgement) is returned. This message has a unique ID as well and carries a reference to the message it acknowledges. Thereby, a SignalMessage can carry a positive or a negative acknowledgement. Positive acknowledgements are submitted using SignalMessage/Receipt and negative acknowledgements are submitted using SignalMessage/Error.
2) Message level response (MLR)
Arguably the most important part of automated message exchange is message validation – i.e. where a message is checked against the agreed specifications (syntactical and semantic).
In Peppol, message level responses, or MLRs, serve to inform the sender of the success (or otherwise) of validation. Helpfully, in the case of failure, these messages also detail what went wrong, such as a specific syntax error relating to a missing closing tag. It is important to note that MLRs will not identify if a certain value is correct in the context of a certain message, but merely that it is in accordance with the agreed specifications. For example, an MLR would not notify you if an article number was wrong, but would alert you if an article number is missing (for a full rundown of what errors a message level response is capable of alerting you to, please check the external article “BIS Message Level Response 3.0”).
MLRs can communicate three things to the sender of the original message:
- The message contained errors and failed validation.
- The message did not contain errors and passed validation.
- The message has been received, but is not yet validated.
Technically MLRs are returned using UBL Application Response 2.1 messages.
3) Business level response
What is a business level response (AKA invoice response)?
The final Peppol message response type is the business level response and is used to inform the sender of a message about the status or outcome of corner four processing the message. In the case of invoices the business level response is called the invoice response message and could for instance contain a rejection, because the referenced purchase order number in the invoice is invalid.
In general an invoice response message supports the following status codes:
- AB – basic message acknowledgement
- AP – accepted
- RE – rejected
- IP – in progress
- UQ – under query
- CA – conditionally accepted
- PD – paid
While Peppol BIS does not require corner four to support all these codes, the first three (AB, AP and RE) must be supported as a minimum. Peppol BIS also requires that the initial sender (AKA corner one) must receive this response within three working days.
How a business level response works and what it looks like
In the event that an invoice is rejected (RE), put under query (UQ) or conditionally accepted (CA), corner four must provide information to help corner one resolve the issue. Status Reason codes and Status Action codes provide a means of doing this. Detailed information can also be added via a free text field which is supported by Peppol.
Like a message level response, a business level response is also based on a UBL Application Response 2.1. The following snippet shows an exemplary invoice response.
Business level response example (click for larger version)
Want more information?
At ecosio we are experts in Peppol and e-invoicing and were one of the very first Peppol Access points in Europe. To date we have helped hundreds of companies to integrate efficient e-invoicing processes into existing systems and experience the benefits of Peppol.
For more information on Peppol please feel free to get in touch with our experts via our chat or our contact form. We are always happy to help!
Have you tried our free XML/Peppol document validator?
To help those in need of a simple and easy way to validate formats and file types, from CII (Cross-Industry Invoice) to UBL, we’ve created a free online validator.
Der Beitrag Peppol Message Responses – A Helpful Guide erschien zuerst auf ecosio.
]]>Der Beitrag Integrating an XML Checker into Your ERP System erschien zuerst auf ecosio.
]]>In this article we’ll explore the importance of XML document validity and how simple it is to integrate an XML checker into your system to enable you to start experiencing more of the benefits of supply chain document exchange automation.
Why is validity of e-documents so important?
As XML is machine-readable rather than human readable (see the example UBL order below), it is difficult to tell without the aid of a validation tool whether an XML document has been structured and populated correctly.
Those who want to delve deeper into the logic behind XML validation can find a useful tutorial series here.
Without a system for checking that XML documents are valid, the structured documents exchanged with partners may well contain errors.
In turn, these errors can prove both time-consuming and costly to fix. Even if the error is immediately spotted, simply getting hold of the relevant person at the other end can be a challenge, while pinpointing exactly what needs to be amended in order to resubmit the message successfully can also be tricky. Worse still, the error may not initially be spotted if validation systems are not in place, which can lead to more complex issues requiring even longer and labour-intensive resolutions. This can end up costing a business dearly, not only in terms of the resource cost, but also through damaging partner relations.
Further, over the last decade many countries (particularly those in Europe) have begun to introduce strict regulations concerning the exchange of structured business documents. As many of these new regulations concern B2G e-invoicing and the digitisation of tax reporting, the consequences for non-compliance can be significant. For example, in Ireland, companies can be fined over €1,500 for each incorrect invoice, plus an additional personal fine of €950. Meanwhile in Sweden, non-compliance with e-invoicing regulations (deliberate or not) can result in up to two years in prison! Even in countries with less severe penalties, however, simple errors such as the incorrect VAT number on an invoice/invoices can result in massive financial repercussions, as such a mistake will make the recipient ineligible for VAT for the relevant transactions.
So what is validation?
XML validation is a process whereby XML documents can be checked instantly by software to confirm that they have been constructed and populated correctly.
Validity of an XML document means:
- Logical formatting
An XML document is well formed if it adheres to the XML syntax rules. E.g. it only contains valid Unicode characters, elements are property closed, etc. - Schema-conformant
An XML document is schema-conformant if all rules in the associated XML Schema (e.g, a UBL invoice Schema) are fulfilled. - Schematron-conformant
An XML document is schematron-conformant if all rules of the associated Schemtatron file are fulfilled.
This is particularly useful in two scenarios:
- When connecting to new partners: Without a validation tool, a constant back and forth is required between the two businesses wishing to establish an EDI connection to ensure that messages are coming through correctly during testing. With an integrated XML checker, however, it is possible to remove the dependence on the other party for feedback during the testing phase. Instead, the sender sees instantly if their document is formatted correctly and can make the necessary adjustments straight away, saving both parties time, money and stress.
- During ongoing EDI operation: In addition to proving useful during the testing stage of partner onboarding, validation should ideally be the final step in every XML document creation process. As changes are constantly being made to live IT environments – both systems and processes – it is important to ensure that this doesn’t disrupt the accuracy of the XML documents generated. The only reliable and efficient way to ensure this is by integrating an XML checker as a final internal step. This way you can be sure that you never send an incorrectly formatted document – which as we have explored can have significant consequences.
What does a comprehensive XML checker provide?
While the exact monetary value of integrating an XML validator is hard to quantify, as it is impossible to predict how many errors you would experience without one, and how costly they would be, the benefits an XML checker can provide are clear. ecosio’s XML validation tool, for example, offers the following key advantages:
- Simple error descriptions – Non-technical and easy-to-understand error messages allow issues to be resolved by non-experts, minimising the chance of bottlenecks.
- Shareable test report – For those who wish to share test reports with colleagues etc., ecosio’s validator generates a concise, downloadable report.
- Zero maintenance – As the tool is maintained by ecosio, there is no need to install any updates or adjust the tool in-house. All necessary changes will be made to the tool directly by ecosio, with zero disruption to your business.
- Simplification of message exchange testing – Both parties save valuable time and money during onboarding as the need for bilateral testing is reduced.
- All major XML document types covered – From Cross Industry Invoice (CII) to Universal Business Language (UBL) file formats, ecosio’s tool covers all common XML file types.
- One click for all formats – The validation tool is as easy to use for complex XML file types as for the most basic ones. All that is required is a single click!
- Clear and unambiguous versioning
The full list of the XML document types that ecosio’s validator tool can check is located on the online tool page.
Before and after implementation – a comparison
Let’s look at how the installation of a validation tool can optimise EDI processes in practice by considering the same example with and without an XML checker. Imagine you wish to send an invoice to one of your partners using the European e-Invoice standard EN 16931 (let’s assume that you sent a Universal Business Document file, though a Cross Industry Invoice would also be feasible).
Without an integrated XML checker:
- Invalid characters could “sneak” into the document. This is typically a master data issue, if for example the business copy and pastes something in a header text or an item description.
- A change in one of the generating routines in the ERP could alter the namespace string, leading to an invalid XML.
- A missing master data entry could lead to a VAT-ID being missing in the XML document, which leads to non-VAT-deduction – depending on the invoice amount.
With an integrated XML checker:
- It is still possible for the things above to occur, but at least you will notice them before your business partner does.
How do I implement a validation tool into my system?
As with many software adjustments, there are two main options for companies looking to integrate an XML checker into their system – A) handle integration in-house, or B) outsource to the experts. The second of these options offers the far simpler option, not least because the first is likely to require the construction of the tool itself as well as its integration into your system.
At ecosio (as with our wider EDI solution) we offer integration of our comprehensive tool via an API connection. This way the tool is embedded directly in your existing ERP system. There is no requirement to navigate to another platform etc. Further, with such a connection you do not need to install updates when the tool is adjusted. Instead, the tool is updated centrally, meaning your validator is always up-to-date and reflects the most recent XML rule sets.
For more information on how to integrate ecosio’s XML checker into your system, or to find out more about the benefits this tool could offer your business in particular, contact us today. We are more than happy to answer any questions you have!
Der Beitrag Integrating an XML Checker into Your ERP System erschien zuerst auf ecosio.
]]>Der Beitrag Integrating an XML Checker into Your ERP System erschien zuerst auf ecosio.
]]>In this article we’ll explore the importance of XML document validity and how simple it is to integrate an XML checker into your system to enable you to start experiencing more of the benefits of supply chain document exchange automation.
Why is validity of e-documents so important?
As XML is machine-readable rather than human readable (see the example UBL order below), it is difficult to tell without the aid of a validation tool whether an XML document has been structured and populated correctly.
Those who want to delve deeper into the logic behind XML validation can find a useful tutorial series here.
Without a system for checking that XML documents are valid, the structured documents exchanged with partners may well contain errors.
In turn, these errors can prove both time-consuming and costly to fix. Even if the error is immediately spotted, simply getting hold of the relevant person at the other end can be a challenge, while pinpointing exactly what needs to be amended in order to resubmit the message successfully can also be tricky. Worse still, the error may not initially be spotted if validation systems are not in place, which can lead to more complex issues requiring even longer and labour-intensive resolutions. This can end up costing a business dearly, not only in terms of the resource cost, but also through damaging partner relations.
Further, over the last decade many countries (particularly those in Europe) have begun to introduce strict regulations concerning the exchange of structured business documents. As many of these new regulations concern B2G e-invoicing and the digitisation of tax reporting, the consequences for non-compliance can be significant. For example, in Ireland, companies can be fined over €1,500 for each incorrect invoice, plus an additional personal fine of €950. Meanwhile in Sweden, non-compliance with e-invoicing regulations (deliberate or not) can result in up to two years in prison! Even in countries with less severe penalties, however, simple errors such as the incorrect VAT number on an invoice/invoices can result in massive financial repercussions, as such a mistake will make the recipient ineligible for VAT for the relevant transactions.
So what is validation?
XML validation is a process whereby XML documents can be checked instantly by software to confirm that they have been constructed and populated correctly.
Validity of an XML document means:
- Logical formatting
An XML document is well formed if it adheres to the XML syntax rules. E.g. it only contains valid Unicode characters, elements are property closed, etc. - Schema-conformant
An XML document is schema-conformant if all rules in the associated XML Schema (e.g, a UBL invoice Schema) are fulfilled. - Schematron-conformant
An XML document is schematron-conformant if all rules of the associated Schemtatron file are fulfilled.
This is particularly useful in two scenarios:
- When connecting to new partners: Without a validation tool, a constant back and forth is required between the two businesses wishing to establish an EDI connection to ensure that messages are coming through correctly during testing. With an integrated XML checker, however, it is possible to remove the dependence on the other party for feedback during the testing phase. Instead, the sender sees instantly if their document is formatted correctly and can make the necessary adjustments straight away, saving both parties time, money and stress.
- During ongoing EDI operation: In addition to proving useful during the testing stage of partner onboarding, validation should ideally be the final step in every XML document creation process. As changes are constantly being made to live IT environments – both systems and processes – it is important to ensure that this doesn’t disrupt the accuracy of the XML documents generated. The only reliable and efficient way to ensure this is by integrating an XML checker as a final internal step. This way you can be sure that you never send an incorrectly formatted document – which as we have explored can have significant consequences.
What does a comprehensive XML checker provide?
While the exact monetary value of integrating an XML validator is hard to quantify, as it is impossible to predict how many errors you would experience without one, and how costly they would be, the benefits an XML checker can provide are clear. ecosio’s XML validation tool, for example, offers the following key advantages:
- Simple error descriptions – Non-technical and easy-to-understand error messages allow issues to be resolved by non-experts, minimising the chance of bottlenecks.
- Shareable test report – For those who wish to share test reports with colleagues etc., ecosio’s validator generates a concise, downloadable report.
- Zero maintenance – As the tool is maintained by ecosio, there is no need to install any updates or adjust the tool in-house. All necessary changes will be made to the tool directly by ecosio, with zero disruption to your business.
- Simplification of message exchange testing – Both parties save valuable time and money during onboarding as the need for bilateral testing is reduced.
- All major XML document types covered – From Cross Industry Invoice (CII) to Universal Business Language (UBL) file formats, ecosio’s tool covers all common XML file types.
- One click for all formats – The validation tool is as easy to use for complex XML file types as for the most basic ones. All that is required is a single click!
- Clear and unambiguous versioning
The full list of the XML document types that ecosio’s validator tool can check is located on the online tool page.
Before and after implementation – a comparison
Let’s look at how the installation of a validation tool can optimise EDI processes in practice by considering the same example with and without an XML checker. Imagine you wish to send an invoice to one of your partners using the European e-Invoice standard EN 16931 (let’s assume that you sent a Universal Business Document file, though a Cross Industry Invoice would also be feasible).
Without an integrated XML checker:
- Invalid characters could “sneak” into the document. This is typically a master data issue, if for example the business copy and pastes something in a header text or an item description.
- A change in one of the generating routines in the ERP could alter the namespace string, leading to an invalid XML.
- A missing master data entry could lead to a VAT-ID being missing in the XML document, which leads to non-VAT-deduction – depending on the invoice amount.
With an integrated XML checker:
- It is still possible for the things above to occur, but at least you will notice them before your business partner does.
How do I implement a validation tool into my system?
As with many software adjustments, there are two main options for companies looking to integrate an XML checker into their system – A) handle integration in-house, or B) outsource to the experts. The second of these options offers the far simpler option, not least because the first is likely to require the construction of the tool itself as well as its integration into your system.
At ecosio (as with our wider EDI solution) we offer integration of our comprehensive tool via an API connection. This way the tool is embedded directly in your existing ERP system. There is no requirement to navigate to another platform etc. Further, with such a connection you do not need to install updates when the tool is adjusted. Instead, the tool is updated centrally, meaning your validator is always up-to-date and reflects the most recent XML rule sets.
For more information on how to integrate ecosio’s XML checker into your system, or to find out more about the benefits this tool could offer your business in particular, contact us today. We are more than happy to answer any questions you have!
Der Beitrag Integrating an XML Checker into Your ERP System erschien zuerst auf ecosio.
]]>Der Beitrag Supplier EDI Onboarding – The Seven Key Steps erschien zuerst auf ecosio.
]]>With this in mind, in this article we will take you chronologically through a thorough supplier EDI onboarding process, from kick-off to go-live – looking at what’s needed from you and your suppliers along the way. Hopefully by the end you will know exactly what a successful project involves and be more confident in making the right choice of solution.
Step 1 – Kick off and definition of EDI requirements
Unsurprisingly the first step in any supplier onboarding project is for your provider to identify exactly what it is that you want. Though there is no one way to achieve this, it is generally best if both you and your EDI provider have a clear point of contact, as this will increase the project’s speed and efficiency.
Once your internal team has been agreed, your provider will liaise with them to find out what your requirements are. This involves discussing:
- Processes – How are orders, deliveries and invoices handled?
- Document types – What document types need to be realised? For example, are you looking to trade invoices only, or do you also want to exchange other common document types, such as orders and despatch advices (aka INVOIC, ORDER and DESADV for EDIFACT messages and 810, 850 and 856 for X12 messages, for example). More sophisticated EDI integrations will also enable automated transmission of sales data reports (SLSRPT / 818), inventory reports (INVRPT / 846) and receiving advice messages (RECADV / 861).
- Message data granularity – Which data elements do you want to be included in each message? In addition to the basics (price, quantity, article number) do you require additional information, such as descriptions or best-before dates?
- Message / process semantics – What is the structure and content of your exchange messages? Usually the ERP system has a preferred (data model) exchange format. This needs to be communicated to the EDI provider for the creation of the dataΩmapping.
- Message protocols – How is your EDI data exchanged with your back-end system? This can be handled via a number of different protocols, such as API, SFTP and HTTPs.
It is tough to give an estimate of how long this process will take given the bespoke nature of the process, but if you are aware of your requirements in advance and have assigned a dedicated project leader internally, this step can take as little as a couple of days. Usually the process will take longer than this, however, and typically involves a fair amount of back and forth.
Step 2 – Creation of Message Implementation Guide (MIG)
Having completed the fact-finding step, your EDI provider will then create your message implementation guide (or MIG). A MIG is basically a ‘how to’ guide for your partners which details your business’s EDI requirements and the specifics of your preferred message formats etc. This normally takes around two days of work per MIG to complete.
As the success of this step has a knock-on impact on the success of the rest of the EDI onboarding process, it is particularly important that this is completed carefully. To ensure the reliability of the MIG, fully managed EDI providers, such as ecosio, will send sample messages to your system. They may even enlist the help of one of your close suppliers to conduct a parallel phase to check everything is functioning correctly. All that is required on your side is to check the messages and flag if anything needs altering.
Sadly, with non fully-managed EDI solutions this phase is often rushed, with little or no testing conducted, leading to errors further down the line.
Step 3 – Creation of Web EDI platform
If you are looking to automate as much as possible of your supply chain’s document exchange, you may also intend to connect suppliers who do not have EDI capability using Web EDI (see our white paper for more information on Web EDI and how it can benefit you).
If this is the case, it is important that the scope of your Web EDI platform matches the scope of message types used with suppliers via “classic” integrated EDI. For example, you may need to exchange non-mainstream documents such as SLSRPT, INVRPT or RECADV in addition to orders, despatch advices and invoices – in which case care should be taken to select a provider, such as ecosio, that can support this (as this functionality is rare).
Your Web EDI platform will be built in parallel with the creation of your MIG(s). This process involves a one-time connection of the EDI solution to your ERP system and subsequent configuring of the platform to meet your requirements. Your supplier should be able to send test documents via the platform according to your MIG (for you to then check). As with the creation of the MIG, you may also want to enlist the help of a close supplier to help test the platform before wider rollout.
As Web EDI requires suppliers to put in manual effort in order for you to experience full automation, platforms are not always hugely popular with suppliers. As a result, selecting a Web EDI system, like ecosio’s Web EDI solution, which is able to minimise effort on your suppliers’ side through features such as semi-automatic document creation, PDF printing and batch support can greatly increase take-up across your supply chain.
Step 4 – Prioritising / approaching your partners
Once your MIG and Web EDI platform have been created it is time to begin onboarding your partners. Before approaching them, however, it is important to agree a strategy with your EDI provider. With large supply chains, it can take a while for partners to be onboarded. As such it makes sense to prioritise onboarding certain partners first so you get maximum benefit from your new system. For example, you may wish to prioritise your biggest suppliers, or those with whom you are closest. As your EDI solution provider will have handled similar projects many times before, they should be able to offer valuable input here.
Once the supplier EDI onboarding strategy has been agreed, your provider should approach each supplier to clarify details such as identifiers (e.g. GLN number), current capabilities (e.g. what types of documents they can exchange via EDI) and which type of connection they would prefer (e.g. AS2, X.400, VAN etc.).
During this process your EDI provider should also share your new message guidelines with your suppliers, allowing them to know what your system requires and how to create valid outgoing documents, which brings us on to…
Step 5 – Message exchange testing / validation
The testing phase involves your provider sending your supplier documents in order for them to send back the necessary responses (e.g. an Order and Order Response).
If your supplier returns an incorrect message they should be informed by your provider what the errors are, enabling them to be corrected. This is known as validation.
Validation can be done manually by checking the message against the MIG. This is a tedious and error-prone method, however. Instead, validation is better handled automatically, by employing in-built validation checks on the integration software, or semi-automatically, by using external software capable of checking message syntax.
Automatic checks (such as those completed by ecosio’s cloud-based EDI solution (our Integration Hub)) can immediately return error reports via email or web portal to the document issuer. Manual checks, on the other hand, involve much more effort, meaning more time until the error report is ready
Once any errors have been corrected and your supplier is able to send a response that conforms to your MIG, the message will be sent to your internal team to check. If a fully managed provider is opted for, this checking should be the extent of the input required from you.
Step 6 – Go-live
When you are happy with the responses from your supplier the connection can be put live. In some cases you may wish to run a parallel phase (alongside a continuation of your previous message exchange method), for several months to ensure that everything is functioning smoothly.
With suppliers being connected via Web EDI the process is even simpler, as they simply need to be activated on the platform. If your Web EDI portal is sufficiently intuitive / user-friendly, training may not even be needed. Alternatively it can be provided in the form of pre-recorded videos / documentation.
Step 7 – Post go-live
Whilst go-live might well signal the end of the EDI onboarding process, it is far from the end of the work when it comes to ongoing document exchange with your partners. For example, your supplier may conduct (as ecosio does) ongoing validation mapping checks to ensure that message details match the requirements of your MIG – thus avoiding the complications associated with incorrect details being transmitted to your ERP.
In order to benefit from a successful and future-proof system, processes also need to be in place covering message monitoring and error handling. Significantly, with many solutions go-live effectively signals the end of your EDI partner’s active involvement, meaning these responsibilities fall to internal teams. However, this is not the case if a fully managed EDI provider such as ecosio is opted for.
Ideally your EDI provider will continue to oversee your business’s EDI connections, acting as a point of contact for your suppliers (both those using classic EDI and Web EDI) and working proactively to correct errors and ensure connections are functioning at maximum efficiency. This way you benefit from both more reliable EDI and the time and cost savings associated with less pressure on internal teams.
As your needs are likely to change over time, it also makes sense to consider investing in a solution that can adapt alongside your business. For example, clients of ecosio are able to add additional Supplier Relationship Management (SRM) modules as required.
Discover a fully managed approach to EDI onboarding with ecosio
As every supply chain is different, every business faces unique challenges when it comes to connecting to suppliers. To be successful, electronic data interchange requires not only technical expertise during set-up and onboardings, but also ongoing time and effort in the form of message monitoring, error handling and installation of updates etc. after go-live. Simply put, each of the steps we have covered is crucial to the lasting health and reliability of your EDI connections.
At ecosio we understand the effort involved in establishing and maintaining efficient EDI, which is why we aim to help businesses avoid the time and stress it can cause by minimising internal effort. As well as making sure connections are as secure as possible through conducting thorough testing, ecosio’s experts manage the entire EDI onboarding process, from kick-off to ongoing operation (unlike other providers). Essentially we do the work so you don’t have to! The upshot is a more cost-effective outcome, faster connections and peace of mind.
To find out more about ecosio’s fully managed solution and how we can help you benefit from simple, efficient and intelligent EDI, contact us today! We are always happy to answer your questions.
Der Beitrag Supplier EDI Onboarding – The Seven Key Steps erschien zuerst auf ecosio.
]]>Der Beitrag Supplier EDI Onboarding – The Seven Key Steps erschien zuerst auf ecosio.
]]>With this in mind, in this article we will take you chronologically through a thorough supplier EDI onboarding process, from kick-off to go-live – looking at what’s needed from you and your suppliers along the way. Hopefully by the end you will know exactly what a successful project involves and be more confident in making the right choice of solution.
Step 1 – Kick off and definition of EDI requirements
Unsurprisingly the first step in any supplier onboarding project is for your provider to identify exactly what it is that you want. Though there is no one way to achieve this, it is generally best if both you and your EDI provider have a clear point of contact, as this will increase the project’s speed and efficiency.
Once your internal team has been agreed, your provider will liaise with them to find out what your requirements are. This involves discussing:
- Processes – How are orders, deliveries and invoices handled?
- Document types – What document types need to be realised? For example, are you looking to trade invoices only, or do you also want to exchange other common document types, such as orders and despatch advices (aka INVOIC, ORDER and DESADV for EDIFACT messages and 810, 850 and 856 for X12 messages, for example). More sophisticated EDI integrations will also enable automated transmission of sales data reports (SLSRPT / 818), inventory reports (INVRPT / 846) and receiving advice messages (RECADV / 861).
- Message data granularity – Which data elements do you want to be included in each message? In addition to the basics (price, quantity, article number) do you require additional information, such as descriptions or best-before dates?
- Message / process semantics – What is the structure and content of your exchange messages? Usually the ERP system has a preferred (data model) exchange format. This needs to be communicated to the EDI provider for the creation of the data mapping.
- Message protocols – How is your EDI data exchanged with your back-end system? This can be handled via a number of different protocols, such as API, SFTP and HTTPs.
It is tough to give an estimate of how long this process will take given the bespoke nature of the process, but if you are aware of your requirements in advance and have assigned a dedicated project leader internally, this step can take as little as a couple of days. Usually the process will take longer than this, however, and typically involves a fair amount of back and forth.
Step 2 – Creation of Message Implementation Guide (MIG)
Having completed the fact-finding step, your EDI provider will then create your message implementation guide (or MIG). A MIG is basically a ‘how to’ guide for your partners which details your business’s EDI requirements and the specifics of your preferred message formats etc. This normally takes around two days of work per MIG to complete.
As the success of this step has a knock-on impact on the success of the rest of the EDI onboarding process, it is particularly important that this is completed carefully. To ensure the reliability of the MIG, fully managed EDI providers, such as ecosio, will send sample messages to your system. They may even enlist the help of one of your close suppliers to conduct a parallel phase to check everything is functioning correctly. All that is required on your side is to check the messages and flag if anything needs altering.
Sadly, with non fully-managed EDI solutions this phase is often rushed, with little or no testing conducted, leading to errors further down the line.
Step 3 – Creation of Web EDI platform
If you are looking to automate as much as possible of your supply chain’s document exchange, you may also intend to connect suppliers who do not have EDI capability using Web EDI (see our white paper for more information on Web EDI and how it can benefit you).
If this is the case, it is important that the scope of your Web EDI platform matches the scope of message types used with suppliers via “classic” integrated EDI. For example, you may need to exchange non-mainstream documents such as SLSRPT, INVRPT or RECADV in addition to orders, despatch advices and invoices – in which case care should be taken to select a provider, such as ecosio, that can support this (as this functionality is rare).
Your Web EDI platform will be built in parallel with the creation of your MIG(s). This process involves a one-time connection of the EDI solution to your ERP system and subsequent configuring of the platform to meet your requirements. Your supplier should be able to send test documents via the platform according to your MIG (for you to then check). As with the creation of the MIG, you may also want to enlist the help of a close supplier to help test the platform before wider rollout.
As Web EDI requires suppliers to put in manual effort in order for you to experience full automation, platforms are not always hugely popular with suppliers. As a result, selecting a Web EDI system, like ecosio’s Web EDI solution, which is able to minimise effort on your suppliers’ side through features such as semi-automatic document creation, PDF printing and batch support can greatly increase take-up across your supply chain.
Step 4 – Prioritising / approaching your partners
Once your MIG and Web EDI platform have been created it is time to begin onboarding your partners. Before approaching them, however, it is important to agree a strategy with your EDI provider. With large supply chains, it can take a while for partners to be onboarded. As such it makes sense to prioritise onboarding certain partners first so you get maximum benefit from your new system. For example, you may wish to prioritise your biggest suppliers, or those with whom you are closest. As your EDI solution provider will have handled similar projects many times before, they should be able to offer valuable input here.
Once the supplier EDI onboarding strategy has been agreed, your provider should approach each supplier to clarify details such as identifiers (e.g. GLN number), current capabilities (e.g. what types of documents they can exchange via EDI) and which type of connection they would prefer (e.g. AS2, X.400, VAN etc.).
During this process your EDI provider should also share your new message guidelines with your suppliers, allowing them to know what your system requires and how to create valid outgoing documents, which brings us on to…
Step 5 – Message exchange testing / validation
The testing phase involves your provider sending your supplier documents in order for them to send back the necessary responses (e.g. an Order and Order Response).
If your supplier returns an incorrect message they should be informed by your provider what the errors are, enabling them to be corrected. This is known as validation.
Validation can be done manually by checking the message against the MIG. This is a tedious and error-prone method, however. Instead, validation is better handled automatically, by employing in-built validation checks on the integration software, or semi-automatically, by using external software capable of checking message syntax.
Automatic checks (such as those completed by ecosio’s cloud-based EDI solution (our Integration Hub)) can immediately return error reports via email or web portal to the document issuer. Manual checks, on the other hand, involve much more effort, meaning more time until the error report is ready
Once any errors have been corrected and your supplier is able to send a response that conforms to your MIG, the message will be sent to your internal team to check. If a fully managed provider is opted for, this checking should be the extent of the input required from you.
Step 6 – Go-live
When you are happy with the responses from your supplier the connection can be put live. In some cases you may wish to run a parallel phase (alongside a continuation of your previous message exchange method), for several months to ensure that everything is functioning smoothly.
With suppliers being connected via Web EDI the process is even simpler, as they simply need to be activated on the platform. If your Web EDI portal is sufficiently intuitive / user-friendly, training may not even be needed. Alternatively it can be provided in the form of pre-recorded videos / documentation.
Step 7 – Post go-live
Whilst go-live might well signal the end of the EDI onboarding process, it is far from the end of the work when it comes to ongoing document exchange with your partners. For example, your supplier may conduct (as ecosio does) ongoing validation mapping checks to ensure that message details match the requirements of your MIG – thus avoiding the complications associated with incorrect details being transmitted to your ERP.
In order to benefit from a successful and future-proof system, processes also need to be in place covering message monitoring and error handling. Significantly, with many solutions go-live effectively signals the end of your EDI partner’s active involvement, meaning these responsibilities fall to internal teams. However, this is not the case if a fully managed EDI provider such as ecosio is opted for.
Ideally your EDI provider will continue to oversee your business’s EDI connections, acting as a point of contact for your suppliers (both those using classic EDI and Web EDI) and working proactively to correct errors and ensure connections are functioning at maximum efficiency. This way you benefit from both more reliable EDI and the time and cost savings associated with less pressure on internal teams.
As your needs are likely to change over time, it also makes sense to consider investing in a solution that can adapt alongside your business. For example, clients of ecosio are able to add additional Supplier Relationship Management (SRM) modules as required.
Discover a fully managed approach to EDI onboarding with ecosio
As every supply chain is different, every business faces unique challenges when it comes to connecting to suppliers. To be successful, electronic data interchange requires not only technical expertise during set-up and onboardings, but also ongoing time and effort in the form of message monitoring, error handling and installation of updates etc. after go-live. Simply put, each of the steps we have covered is crucial to the lasting health and reliability of your EDI connections.
At ecosio we understand the effort involved in establishing and maintaining efficient EDI, which is why we aim to help businesses avoid the time and stress it can cause by minimising internal effort. As well as making sure connections are as secure as possible through conducting thorough testing, ecosio’s experts manage the entire EDI onboarding process, from kick-off to ongoing operation (unlike other providers). Essentially we do the work so you don’t have to! The upshot is a more cost-effective outcome, faster connections and peace of mind.
To find out more about ecosio’s fully managed solution and how we can help you benefit from simple, efficient and intelligent EDI, contact us today! We are always happy to answer your questions.
Der Beitrag Supplier EDI Onboarding – The Seven Key Steps erschien zuerst auf ecosio.
]]>Der Beitrag The Real Cost of EDI: Considerations When Selecting a Solution erschien zuerst auf ecosio.
]]>With limited experience of EDI and faced with a choice between multiple different solutions, it is understandable that many people use the price of the solution as a key selection criterion. However, as we shall explore in this article, when it comes to EDI solutions, focusing principally on price is unwise. In fact, opting for a cheaper package that is less well suited to your current and future needs will almost always end up costing your business more than implementing a more comprehensive solution.
Implemented correctly, EDI solutions can bring substantial long term cost savings and hugely reduce internal effort and associated complications. By opting for a substandard solution, however, many of the key benefits of efficient EDI (and attendant savings) are negated.
To see exactly where savings are lost, let’s look at some of the common areas where EDI solution buyers typically experience problems.
Mapping / Routing
As mapping and routing is the bread and butter of EDI providers and something that everyone considering EDI requires, EDI users understandably do not expect to be charged extortionate amounts to test connections, to send/receive a new document type or to exchange messages via a new communication channel.
Unfortunately, however, this is exactly the situation many businesses face once tied into a contract. By failing to check exactly how much work their contract obliges their provider to do or what functionality their package contains, customers run the risk of encountering large license fees or activation charges. Despite the fact that activation of new functionalities (e.g. exchanging via AS2) often requires no effort on the part of the EDI software vendor, something as simple as gaining an license key to activate a new function can cost thousands of pounds! Obviously this quickly eradicates whatever savings a business intended to achieve by selecting the cheaper solution.
A common example of such a situation can be found below:
- A supplier is faced with an immediate request to enable the receipt of purchase orders and the transmission of invoices over EDI. Due to their contract volume, this customer is very important and therefore needs to be satisfied or will otherwise look for a different supplier.
- The supplier tries to fulfill this need with the least amount of effort involved and with little time left. The decision process therefore does not involve a true internal discussion of the real needs and capabilities of internal teams such as current IT backend systems, the sales department, logistics etc.
- Due to this, often the lowest bidder wins the race. Issues are not identified before the solution is purchased, resulting in more problems down the line when a unfitting EDI solution needs to be implemented
- As a result, EDI stakeholders are unhappy about the speed and quality of the implementation, encounter problems with its capability and ease of use and are faced with additional charges to bring the EDI solution closer to the real needs.
Partner onboarding
Like mapping and routing, partner onboarding is an essential part of EDI for growing businesses. Predictably, therefore, it is another key area where solution buyers become frustrated with substandard service from EDI software vendors.
As anyone who has had to onboard partners themselves will recognise, onboarding requires a huge amount of effort. In addition to sorting the technical details (e.g. setting up test connections etc.), liaising with partners to get the necessary connection information can be a very time-consuming process.
With a fully comprehensive EDI software vendor this process is handled by the solution provider. Ideally, a dedicated project manager will be assigned to oversee the connection process. This involves chasing partners for relevant details, validating information and overseeing document implementation. In addition to removing all internal effort, this drastically improves the speed of connections.
By contrast, some EDI software vendors offer remarkably little help when it comes to partner connections. Whilst they may claim to provide assistance with onboarding, the contract may only specify that they are obliged to send a single email requesting relevant requirements from your prospective partner, for example. Solution buyers therefore experience neither fast, nor hassle-free connections and are left having to chase both their partners and their EDI software vendor to achieve results. Obviously, as with extortionate costs for unlocking new mapping/routing capabilities, this can quickly erase whatever savings were made by selecting a cheaper solution.
Maintenance and updates
As EDI is constantly evolving, it is necessary to implement regular updates to keep a system functioning at optimum level. Updates can relate to many different things, such as document standards, EDI protocols or e-invoicing regulations.
For example…
- In recent years there was a switch from OFTP1 to OFTP2 connections in the automotive industry. This involved all existing connections between thousands of suppliers and their OEM customers and other suppliers requiring work. Due to the changes involved in this many EDI solutions needed additional licenses or adapters to meet the requirements of OFTP2. Further, additional security options such as encryption and message signature meant that EDI users needed to be trained and capable of understanding the principles behind the communication protocol to correctly setup and troubleshoot OFTP2 connections.
- Similar efforts and effects need to be assumed for changes in e-Invoicing for governments, such as with FatturaPA in Italy. As the systems are still relatively new they are subject to a significant amount of changes, on both the technology side and the regulation side. They may include smaller changes such as a renewed certificate, but can also affect business processes and regulations.
Therefore an experienced integration partner that knows about the business level as well as the technological implications should be selected.
The larger a business’s partner network, the more updates have to be implemented, the more work is required to do so, and the higher the risk of failing to make the changes.
With the best fully managed EDI solutions such updates are implemented as required with zero effort needed from the customer. Cheaper and less comprehensive packages, on the other hand, will not include updates. Customers then face a choice between attempting to fix issues in-house (and running the risk of making costly mistakes while doing so), or paying for their service provider or an external consultant to update their system.
Further, by selecting a substandard solution which does not offer ongoing maintenance and automatic implementation of updates businesses may not even be aware of new and potentially crucial updates. Over time this can cause a significant reduction in process efficiency and security. Businesses in this situation also run the risk of experiencing sudden errors across a large proportion of their supply chain, which can be extremely expensive to rectify.
Error handling
As costly as issues relating to mapping, routing, partner onboarding and maintenance can be, arguably the area where EDI solution buyers experience the most frustration with non-comprehensive EDI software vendors is error fixing.
Although many solutions claim to offer support, the quality of this support differs hugely from one provider to the next. Whilst a fully comprehensive EDI provider may offer 24/7 support, cheaper providers’ support will be limited. Often ‘support’ is limited to a single phone number or email address, via which it is typically extremely difficult and time-consuming simply to get through to anybody, let alone the right person.
Unfortunately, many businesses neglect to investigate the quality of their chosen provider’s support prior to signing a contract. When errors then occur, valuable time is lost trying to fix the issue. Further, the longer it takes to resolve the issue, the more likely it is to escalate or for similar issues to appear elsewhere in your supply chain, a scenario that can easily result in spiralling costs.
How to secure a good value contract with an EDI software vendor
1 – Conduct a thorough requirement analysis
Possibly the single most useful step you can take before starting the process of selecting your EDI supplier is to conduct a thorough requirement analysis. Though this takes some time, it is well worth the effort and will ensure you don’t get stuck in the wrong contract. Some key questions to ask during this stage might be:
- Do we have sufficient EDI knowledge in-house to operate an on-premise system?
- Are we able to develop effective testing processes to ensure the security of new connections?
- What functionality are we likely to need in the future?
- Are internal teams capable of protecting data security by staying on top of updates?
- Do we need a provider that can respond quickly to resolve errors?
- Is simplifying partner onboarding a priority?
2 – Don’t underestimate the effort required to setup and operate effective EDI
Although fully automated EDI hugely reduces the amount of manual effort required to exchange business documents, there are still many processes even after setup, such as error handling and message monitoring, that require management by someone to keep your system running smoothly.
A common error made by those selecting an EDI software vendor is to focus on the capabilities of the software, without considering who will be in charge of making sure things function correctly. Ultimately, even if you purchase the most incredible software, if you don’t know how to use it effectively or don’t have sufficient internal resources, you won’t see any benefit. Businesses in this situation are therefore forced to hire the required resources, change their EDI solution altogether or enlist the help of another third party supplier in the form of an EDI consultant (and in so doing commit to another contract).
With a comprehensive EDI solution these problems do not arise. Whilst operating an EDI solution in-house makes sense for those businesses with sufficient internal resources/knowledge and for whom EDI is a central part of the business, this is not the case for others. By far the most sensible option for businesses new to EDI or without EDI experience in-house is to opt for a fully managed solution. As opposed to the hands-off approach of other providers, a fully managed EDI solution provider will handle everything from the initial setup to ongoing operation, virtually eliminating the need for internal involvement. In addition to offering much better value, this approach ensures optimal system performance and frees up time for internal teams, allowing businesses to focus on what they do best.
A detailed breakdown of the differences between different EDI provider solutions can be found in our infographic on this topic.
3 – Consider future needs
Choosing a flexible solution is one of the best ways to ensure you achieve value over the course of your EDI contract. From a change in the amount of monthly messages you send, to needing the ability to send information in different formats and via different communication protocols, your EDI needs can easily shift over time. It is essential, therefore, that you select a solution that is able to help your business as you grow and requirements change. Sadly too few businesses consider this and are forced to pay through the nose to achieve simple functionality as their needs evolve.
Don’t let that be your business! By considering future needs and choosing a flexible, comprehensive EDI solution you can ensure that your business avoids surprise fees and continues to benefit from efficient, hassle-free EDI for the duration of your contract.
4 – Make sure you know what your package does and doesn’t include
Though it sounds obvious, clarifying exactly what your package includes can save you a huge amount in the long run. If a provider seems to be offering the same service for considerably less, this is very unlikely to be the case! By failing to identify the difference between the two before making your decision you are likely to pay for it later.
A concise list of five things to consider when selecting a vendor can be found in our article “5 Key Components to Consider When Selecting an EDI Vendor”.
Can ecosio’s comprehensive EDI solution help you?
For more information on ecosio’s unique, fully managed EDI solution and to find out how we could help your business to benefit from efficient B2B document exchange with minimal internal effort, contact us today.
Der Beitrag The Real Cost of EDI: Considerations When Selecting a Solution erschien zuerst auf ecosio.
]]>Der Beitrag Create and Process UBL Documents with Attachments in SAP erschien zuerst auf ecosio.
]]>As of November 27th 2019, all federal agencies in Germany must be able to receive and process XRechnung. XRechnung is the German CIUS (Core Invoice Usage Specification), which originated from the EU standard EN 16931 . EN 16931 provides two types of XML schemas: Universal Business Language (UBL) and UN / CEFACT Cross Industry Invoice (CII). As a result, the ability to process CII and UBL documents is becoming increasingly important.
Companies that are contractors of public institutions must be able to create and send XRechnung. Furthermore, the billing format is also used in the B2B sector, which is why it makes sense for companies to make their ERP system fit for the creation, transmission, and receiving of XRechnung.
SAP ERP is one of the most popular ERP systems in the world but cannot create, convert or read documents out of the box according to the UBL standard. This means that without add-on modules, SAP ERP cannot work with the standard XRechnung and companies must look for suitable solutions.
Create UBL documents in SAP using the EPO connector
The SAP ERP system cannot generate XML files from the SD and FI modules that conform to the UBL specification. However, a solution can be created by using middleware in conjunction with a service provider. The EPO Connector happens to be a middleware solution that is integrated directly into the SAP system and helps connect further external products and services to the SAP. This means additional functions can be added to SAP cost effectively without having to intervene in the system itself.
In the following, we’ll look at how to use the EPO Connector to create UBL files with attachments, and also send and receive them.
Create and send XRechnung with attachments
Using the EPO Connector, e-Invoices can be created in UBL format from SD and FI documents. Since the middleware is written in ABAP and thus runs directly in SAP, no external tool is necessary, and the invoice workflow can be completely mapped in SAP. In addition, the EPO Connector can be used to integrate attachments into UBL that are directly embedded as Base64-encoded character strings in the document. For this purpose, UBL has its own attachment elements (cac: AdditionalDocumentReference):
Extract of a Base64-encoded Attachment in UBL
The EPO Connector takes care of the correct coding and embedding of the desired attachments and creates the final UBL file according to the XRechnung specification. In order to be able to transmit the created e-Invoice to the recipient, a service provider such as ecosio can be connected to the middleware. ecosio reads out the sender and recipient ID as well as the document type and sends the invoice to the bill-to party via the required channel. This results in a consistent and seamless invoice delivery and invoice receipt process. Peppol (Pan-European Public Procurement Online), which was developed by the European Union to facilitate the exchange of data between companies and public authorities, must be used for the automatic sending of XRechnung. In this case, the service provider connects to the recipient’s Peppol access point, which receives the transmitted XRechnung and forwards them for processing.
Receive and process XRechnung with attachments
The invoice receipt process using the EPO Connector is like sending invoices. The EDI service provider receives invoices via the required protocols (e.g. Peppol) and transfers them to the EPO Connector, which controls the transfer of the documents to the SAP system of the company. Since SAP cannot work with the XML format UBL, the received documents must be converted to the required SAP format. The EPO Connector is responsible for the correct conversion and unpacks any attachments from the UBL.
Invoice Book for Incoming Invoices Provided by the EPO Connector.
© 2020. SAP SE or an SAP affiliate company. All rights reserved. Used with permission of SAP SE.
These attachments are appended to the final SAP document and can be viewed in the system as usual. The approval workflow can now be started in SAP and invoices released accordingly for payment.
© 2020. SAP SE or an SAP affiliate company. All rights reserved. Used with permission of SAP SE.
Transmission of UBL invoices by ecosio
Thanks to ecosio’s connection to the SAP system, documents can be sent in various structured formats via all common EDI protocols. In addition to the usual document exchange protocols such as X.400, AS2, SFTP, SMTP, OFTP2, as well as EDI networks such as GXS, INOVIS, etc., files can also be accessed via special platforms such as Peppol, FACe (Spain) or the Sistema di Interscambio (Italy).
This makes it quick and easy to send and receive UBL documents via the Peppol network.
Conversion and Dispatch of UBL Documents with the EPO Connector and ecosio
Since ecosio allows the connection of any partner via different protocols, companies do not need to worry about expensive special programming in SAP. In conjunction with the EPO Connector, companies stay up to date with the technological requirements surrounding EDI and can focus on their core business.
Summary
The EPO Connector allows companies to convert invoices in SAP into XML format UBL and add attachments. Likewise, UBL documents can be received, converted into an SAP format and then edited. In conjunction with ecosio, the generated invoices can be sent via all standard exchange protocols. It is also possible to send and receive XRechnung via Peppol with ecosio.
Thus, companies are not dependent on expensive additional software for SAP but can pursue a long-term and cost-saving strategy to meet the ever-increasing requirements for e-Invoices.
Any questions?
Do you still have questions about UBL documents in SAP and how they can be created and sent? Feel free to contact us or check out our chat, 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 Create and Process UBL Documents with Attachments in SAP erschien zuerst auf ecosio.
]]>