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

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

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

EDI’s History

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

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

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

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

Why EDI is still standing

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

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

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

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

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

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

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

API

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

What are APIs?

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

How APIs are changing B2B integration

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

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

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

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

Three examples of such different processes might be:

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

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

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

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

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

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

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

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

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

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

Blockchain

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

What is blockchain?

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

Blockchain and EDI

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

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

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

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

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

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

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

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

Artificial Intelligence (AI)

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

What is AI?

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

How could AI change EDI?

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

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

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

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

Conclusion

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

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

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

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

Discover more about our updated product, ecosio.flow.

References:

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

Der Beitrag The Future of EDI erschien zuerst auf ecosio.

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.

Example of a UBL order

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:

1. 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.
2. 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.

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.

Example of a UBL order

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:

1. 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.
2. 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.

So what does this mean in concrete terms?

Hybrid e-invoices – man and machine-friendly

So-called ‘hybrid’ e-invoices are easy to understand. Such documents can be read and archived by humans as well as automatically processed by machines. Essentially, a hybrid invoice is an e-invoice in PDF format, in which structured invoice data is embedded in the form of an XML file. This holds several benefits for the recipient, allowing them to:

• print PDFs and process them as paper invoices
• integrate PDF documents into existing workflow processes
• process XML files automatically

ZUGFeRD/Factur-X was introduced as a standard for hybrid e-invoices in Germany and France at the beginning of 2018 as part of a German-French cooperation and is internationally compatible. ZUGFeRD 2.0 (the previous German standard) and Factur-X are technically identical.

Currently the PDF/A-3 format is used with an embedded XML file based on UN/CEFACT Cross Industry Invoice. This offers the following advantages:

• Suitable for long-term archiving
• EU conformity (EN standard 16931 is fulfilled)
• International compatibility
• Equally suitable for SMEs and larger corporations
• ZUGFeRD has already been used in various industries since 2014

ZUGFeRD/Factur-X invoices can be sent directly or via service providers such as ecosio. The service provider then takes care of the secure electronic delivery of the invoice data to all customers, as well as validation and possible conversion from a sender’s format. On the recipient side, the invoices are validated and checked, converted into the in-house format and archived.

ZUGFeRD/Factur-X is now also in Switzerland

A specially created working group of GS1 Switzerland came to the conclusion that given the advantages of ZUGFeRD/Factur-X mentioned above, all the necessary criteria for a common hybrid invoice format are also fulfilled in Switzerland.

This standard is now officially recommended.

However, it is not intended to replace existing EDI procedures. In Switzerland, the EDIFACT EANCOM standard is still popular for merchandise management and operating cost calculations. However, if it cannot be used, ZUGFeRD/Factur-X should be used as a simple alternative and hybrid invoice to replace paper invoices in the long term.

The advantages of ZUGFeRD/Factur-X

For both billers (suppliers or service providers) and bill recipients, this results in some exciting advantages. Not only are savings made on paper and postage costs and processing work.

Benefits for billers:

• Savings in process costs (no printing, packaging, postage etc.)*
• Quota increase of the automated allocation of payments to the corresponding invoices
• Payment is received earlier by the customer due to the efficient invoice verification process
• Reduced reminder and clarification effort
• Legally compliant invoice archiving
• Increased customer satisfaction and loyalty due to process and system integration

*In real terms this can mean a savings potential of between CHF 1.50 and 4.00 per invoice.

Benefits for invoice recipients

• Savings in process costs (automated order allocation)
• Unpacking and stamping of paper invoices is no longer necessary
• No manual invoice entry (or scanning or OCR) required
• More efficient invoice verification, payment processes and account assignment 
• Reduced downtimes
• Faster availability of data
• No physical archive necessary

Savings of CHF 5.00 up to 50.00 per invoice are possible here – depending on the complexity of the invoice control processes and the number of approval levels.*

Further information can also be found on the GS1 Switzerland website.

*Source: Electronic hybrid invoice PDF with XML. GS1 Switzerland.

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

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

Want more information?

At ecosio we’re more than happy to help you successfully implement and deploy ZUGFeRD/Factur-X and support you in exploiting all the advantages of hybrid e-invoices in your company. Contact us today for more information.

Der Beitrag ZUGFeRD/Factur-X in Switzerland – Can your business benefit? erschien zuerst auf ecosio.

Due to the increasing spread of electronic invoices, the Republic of Hungary is now also relying on the use of electronic invoices (via the NAV system). The aim is to facilitate the reporting of VAT-related data to companies, increase transparency for invoice issuers, invoice recipients and the Republic of Hungary and, finally, fight sales tax fraud.

Those affected by the new law in Hungary are:

• Hungarian companies
• Foreign companies with a branch in Hungary
• From July 2020, anyone who issues an invoice to another domestic taxable person where the transaction is carried out in Hungary (regardless of VAT content)

For businesses, this means that invoices must be reported electronically through a centralized system. Invoicing data are transmitted electronically in XML format to the Hungarian NAV system. For companies that cannot generate XML documents, there is also a web-based interface available, via which the invoicing data can be entered manually. Due to the manual processing, the web interface is only convenient with a very small invoice volume.

The notification to the Republic of Hungary must be made within three days – and ideally directly after the invoice is created.

Technical Realisation

Invoices are sent to the NAV system in Hungary via a web service, whereby the invoice data must be transmitted in XML format. The official NAV website of the Republic of Hungary provides a detailed technical description of the web service as well as the XML schemas.

Website of the NAV system

The information is available in Hungarian, English and German, although not all parts of the website have been translated into English and German.

A look at the WADL file shows the methods offered by the Web service:

Web service operations of the NAV system

As can be seen, all communication is handled using HTTP POST operations. RESTful purists may raise their eyebrows at this.

The exact sequence of the individual web service calls and the code examples in Java can be found in the Technical Guide on the NAV website.

Transmission from the ERP System

When automatically transferring invoice data to the NAV system, the invoice data is taken directly from the ERP system. This means that in addition to issuing a regular invoice, an invoice artefact for the NAV system must be generated. For this, a corresponding copy control must be set up in the ERP system.

As shown in the following figure, the invoice document is transferred to ecosio in the ERP export format (e.g. IDoc in the case of SAP). ecosio converts the ERP export format into the desired target format of the NAV system, according to the official OSA XML schema. Subsequently, the invoice document is transmitted.

Transfer of data from the ERP system

The Web Service returns a confirmation message about the processing of the delivered invoice as an XML document. This XML document is converted by ecosio into a message state (invoice successfully transmitted, or invoice not successfully transmitted) and, if desired, can also be sent back to the ERP system as a separate XML document.

In the case of an SAP system, a confirmation can, for example, be based on a SYSTAT01 IDoc, which can be used to change the status of the originally transmitted invoice IDoc (for example, to status 41 – application document created in the target system).

Depending on the ERP system, the integration can be implemented as desired, allowing feedback in Microsoft Navision / Dynamics, Oracle, abas ERP, etc.

Registration

To file invoices in accordance with the Hungarian legislation, registration via the NAV system is necessary.

For companies from the DACH area, this means that the representative of the Hungarian branch must complete this registration and then create a technical administrator in the system. Using the access data of this technical administrator, an EDI service provider such as ecosio can then carry out the next setup steps and start the tests.

Developers have their own test platform available.

Questions?

Do you still have questions about e-invoicing in Hungary or are you looking for a solution to automatically transfer invoicing data to the NAV system? Please contact us or check out our chat – we are happy to help!

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

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

Der Beitrag Electronic Invoicing in Hungary – Transmission to the NAV System 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.

In the Document Viewer

© 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.

• IDoc instance includes a control record, data records and status records stored in SAP tables EDIDC, EDID4 and EDIDS, viewable via transaction BD87
• Logical message type (<MESTYP>) defines business document intent (e.g. ORDERS for orders), linking it to application logic in the SAP system
• IDoc basic type (<IDOCTYP>) defines structure/layout, and one basic type like DELFOR02 can support multiple message types (e.g. DELINS, DELJIT)
• Extension types (starting with Z) add segments to standard basic types to support custom requirements

IDoc – conceptual differentiation

IDocs are a vital tool for the import and export of data to and from an SAP system. The basic idea behind an IDoc was introduced in a previous blog post.

Unfortunately, the term IDoc is not always used consistently. An ABAP programmer may understand something different when referring to an IDoc, than an SAP consultant or EDI project manager for example. In this post we want to define the following five IDoc terms and take a closer look at their specific concepts.

1. IDoc Instance
2. IDoc File
3. Logical Message Type
4. IDoc Basic Type
5. IDoc Extension Type

IDoc instance

In computer science an instance is an occurrence of an object during the runtime of a program. An IDoc instance is of no difference here — it is a concrete occurrence of a document object.

IDocs are stored internally in a persistent manner in the database in SAP, whereby the following tables are filled:

• EDIDC
  Contains one Control Record per IDoc with one unique IDoc number.
• EDID4
  Contains one or more Data Records. The reference to the Control Record is done via the unique IDoc number.
• EDIDS
  Contains one or more Status Records. The reference to the Control Record is done via the unique IDoc number.

Usually the user will not access the database tables directly but use the appropriate SAP transaction, like BD87. The following image shows IDoc Nr. 1068215 in transaction BD87.

IDoc Instance in transaction BD87

© 2020. SAP SE or an SAP affiliate company. All rights reserved. Used with permission of SAP SE.

File

To exchange an IDoc between SAP and an external system, an IDoc instance will be serialised to an export format and written into a physical file. There are two ways to represent the data – ASCII-based IDocs or XML-based IDocs. Modern SAP systems predominantly make use of XML-based IDocs.

The following image shows an XML IDoc of a delivery forecast. This XML IDoc was sent to the SAP system where it was saved as IDoc Nr. 1068215.

IDoc XML-file

© 2020. SAP SE or an SAP affiliate company. All rights reserved. Used with permission of SAP SE.

The hierarchy of the IDoc as seen in the XML tree is similar to its display in transaction BD87. The following image shows the stored IDoc 1068215 in transaction BD87.

IDoc tree in transaction BD87

© 2020. SAP SE or an SAP affiliate company. All rights reserved. Used with permission of SAP SE.

Logical message type

The message type describes the type of business document in an SAP system – e.g., an ORDERS IDoc message type is used to describe — as the name already indicates — an order document. A message type can support different use cases. The message type ORDERS for example can be used for an outbound order (sent to a supplier) or an inbound order (received from a customer).

In an IDoc XML, the logical message type can be found in element <MESTYP>, a sub element of <EDI_DC40>. This is also depicted in the XML screenshot of the IDoc further up this post.

The logical message type defines which application logic is being applied to the IDoc in the SAP system. Thus, the logical message type provides the connection between the structure of the information and the application logic.

The structure of the logical message type is further described by the IDoc basic type, which we will present in the next section.

IDoc basic type

The IDoc basic type provides the structure for the logical message type. The following image shows the structure of IDoc Nr. 1068215 in transaction WE19. In this case the utilized IDoc basic type is DELFOR02.

IDoc structure in transaction WE19

© 2020. SAP SE or an SAP affiliate company. All rights reserved. Used with permission of SAP SE.

The IDoc basic type can manifest itself in multiple logical message types. An ORDERS05 basic type is the foundation for an order (ORDERS), an order change (ORDCHG), an order response (ORDRSP), a quote request (REQOTE) etc.

In the XML representation of an IDoc, the basic type can be found in element <IDOCTYP>, which is a sub element of <EDI_DC40>.

To get a list of all basic types and their logical message types, one may start a query via the following three tables.

• EDIMSG (Message types and their assigned IDoc types)
• EDBAS (Basic types)
• EDBAST (Short description of the basic type)

It is possible to use the QuickViewer under transaction SQVI to access these tables.

IDoc tables in QuickViewer

© 2020. SAP SE or an SAP affiliate company. All rights reserved. Used with permission of SAP SE.

The two logical message types for the IDoc basic type DELFOR02 are for example DELINS (Delivery Schedule) and DELJIT (Delivery Schedule Just-In-Time).

IDoc Extension Type

An IDoc extension type is an IDoc basic type with one or multiple additional segments. Following the SAP naming convention, IDoc extension types begin with a Z.

Any questions?

Do you have any further questions about IDocs, SAP or Electronic Data Interchange? Please do contact us or use our chat — we’re more than happy to help!

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 IDoc Message Type and IDoc Basic Type – IDoc Basics Explained erschien zuerst auf ecosio.

• IDocs are the central SAP format for structured data exchange and exporting one as XML allows you to retrieve it locally without triggering unintended system actions such as duplicate DESADV dispatches
• You do not need ABAP code to perform this operation
• Open transaction SE37 and run the function module IDOC_XML_TRANSFORM to display the IDoc as XML
• Copy the XML into an editor using Ctrl+A and Ctrl+C and then remove the spaces around the angle brackets to correct the output formatting

IDocs in SAP

IDocs are the central import and export format of SAP ERP systems. They can therefore be used for data exchange with other software systems, e.g. when transferring customer data from a CRM system. IDocs are also particularly relevant in electronic data interchange (EDI) with external suppliers and customers. Further, much like saving an IDoc to your hard drive, deleting an IDoc, or reprocessing an IDoc, exporting an IDoc as an XML isn’t too difficult.

No matter which application scenario, you will often encounter the issue where you will need a specific IDoc as an XML file on your local hard drive. Repeatedly exporting files through a partner profile configured in transaction WE20 is ill advised due to uncontrolled side effects, e.g. repeating DESADV dispatches to clients.

The XML file is thus the best way forward, as it has many advantages and can for example be used to debug incorrect behaviour in software downstream from SAP. There are various functions available for exporting IDoc data in SAP. In a previous article we explained how to export IDoc data in Excel format. SAP also offers functions for exporting an IDoc as an XML file however.

In the following section, we will present you with an approach where it is not required to use your own ABAP code. With this approach, you will not have to create an ABAP code or transport it on a P-level. This method is also well suited for debugging on a P-system, under the condition that the user has the needed permissions for transaction SE37.

Do you have questions about Idocs and XML data? Feel free to contact us, we would love to help you! You can also chat directly with one of our experts online.

Export an IDoc as an XML

To export an IDoc as an XML, you will first need to open transaction SE37.

Transaction SE37 in SAP

© 2020. SAP SE or an SAP affiliate company. All rights reserved. Used with permission of SAP SE.

Enter the element IDOC_XML_TRANSFORM in the function block and execute it by clicking on F8. As you can see on the picture below, the IDoc is now shown as an XML data.

Enter the IDoc Number

© 2020. SAP SE or an SAP affiliate company. All rights reserved. Used with permission of SAP SE.

Now enter the IDoc number that is to be exported in the DOCNUM field. Before the value can be entered, the zeros must be removed. Then execute the transaction with F8. The IDoc is now displayed as an XML file, as shown in the following image:

XML Representation of the IDoc

© 2020. SAP SE or an SAP affiliate company. All rights reserved. Used with permission of SAP SE.

Pressing ctrl+A, ctrl+C or ctrl+V will allow you to view the XML content with any editor.

As shown in the screenshot, the generated XML file has a small flaw: the opening angle brackets (< und </) of the elements are followed by spaces, and the closing angle brackets (>) have spaces before them. This means that this XML is not formatted properly.

To correct this, you can copy the XML data into an editor (Notepad++ e.g.) and search and replace the spaces around the angle brackets.

Summary

By using the method, you will be able to quickly and easily export IDoc data as XML files from an SAP system. The only disadvantage is that the resulting XML file is not valid and needs to be corrected with an editor, before it can be transmitted to further applications.

Do you have any questions?

Do you still have questions about Idocs and XML data? 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 How to Save an IDoc as an XML – A Guide erschien zuerst auf ecosio.

XRechnung overview

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

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

But what exactly is an XRechnung?

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

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

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

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

Learn how to unlock the potential of EDI with ERP integration

Why Peppol?

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

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

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

Peppol consists of:

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

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

Do you have any questions?

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

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

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

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

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

Since March 2015 the Italian administration has accepted invoices in electronic format (FatturaPA) over the Sistema di Interscambio (SdI). Italy is thus following the European (and increasingly global) trend of e-invoicing for Business-to-Government (B2G). Certain countries, such as Denmark, have been enforcing e-invoicing for over a decade, whilst Latin and South America in particular are also ahead of the curve in this area.

Italy however decided to take it one step further and make e-invoicing mandatory for Business-to-Business (B2B). Since 1.1.2019, Italian regulations have required all invoices between businesses registered in Italy to be exchanged via Sistema di Interscambio. From 2022 this will extend to all cross-border invoicing too. This concerns all domestic companies in Italy who own a VAT-ID, as well as providers and suppliers who are registered in Italy. Therefore, any company from the UK, Germany, Switzerland, Austria, etc. who has branches in Italy must comply.

Distinction of the term

A lot of the terms around FatturaPA are not used in the right context or not interpreted in the correct way. This may be due to the fact that most documentation only exists in Italian.

We have listed the most important terms here for you…

FatturaPA

Abbreviation for Fatturazione Elettronica verso la Pubblica Amministrazione, or in English E-Invoicing for the Public Administration. This is the umbrella term that describes the technical and organisational steps taken in Italy around e-invoicing to the public administration. Those steps were extended to invoicing between all businesses in Italy from 1.1.2019. You will find more information on this topic on the official website.

InvoicePA

InvoicePA is the XML format that needs to be used for invoices exchanged within the FatturaPA system.

Sistema di Interscambio (SdI)

SdI refers to the central data hub that the invoice data needs to be transmitted to. Several channels are available for the delivery and extraction of the invoices, such as web interfaces or web services.

AgID – Agenzia per l’Italia digitale

AgID is a public facility that drives digitisation topics in Italy. It was created in 2012 under Monti’s government. It is relevant for FatturaPA, since all archiving solutions for e-invoicing need to certified by AgID.

Registration process for FatturaPA

In order to exchange invoices compliant to FatturaPA, you will need to undertake a few organisational and technical steps, as detailed below.

Instead of registering one’s company, an external service provider such as ecosio may be hired. The external service provider then submits and receives invoices on behalf of the company. Thereby, the difficult registration process may be skipped.

If a company wants to register itself with FatturaPA, this will need to be done by an employee of the Italian branch with signing authority. To register, the following access data can be used:

• Entratel
• Fisconline
• Carta Nazionale dei Servizi

You will need to discuss this with the contact at your Italian branch, as it is possible that one of the above listed option is already available and can be used for that purpose. Once you’ve registered, you need to define a technical contact to set up the connection. The norm is here to choose a technical contact from your EDI provider, so that he can take over the coordination from then on.

The next step is to register a technical communication channel. To do so, you will need the following information:

• Name of the company
• Italian Tax number
• PEC email address
• Website
• Name, email and phone number of the contact person in the company

Once the registration process is completed, technical details such as certificates and login details will be sent to the PEC email address entered during registration.

Sending the invoice data

Following are the channels allowing the exchange of e-invoice data to FatturaPA. We are differentiating between manual and automated processes.

Manual process:

A manual process indicates the need of human intervention, which makes it inadequate for high invoice volumes or a fully automated transmission. Both of the following channels are available for manual processes:

• Transmission via certified email (PEC)
• Input of the invoice data through a web form

Automated process

In this case the data transmission happens automatically, without human intervention. This allows for the data to be directly exported from your ERP system and sent to FatturaPA. Thus, this process is more suitable for high invoice volumes. These are the automated channels available:

• SDICoop Web Service
• SPCoop Web Service
• SDIFTP Service

ecosio uses SPCoop Web Service to support the transmission, thereby allowing a deep integration of the invoice exchange into the ERP system. Deep integration gives you the opportunity to transfer receipt and processing confirmation from the FatturaPA system into the ERP system.

Data integration from the ERP system

The below example illustrates the transfer of an invoice to FatturaPA using Web Service via ecosio.

Invoices are automatically created in the ERP system and sent to ecosio. This can be done with any communication protocol and the invoices can be in any ERP export format. However, all the conditions required by FatturaPA need to be fulfilled.

ecosio extracts the ERP export data, translates it to the InvoicePA format and transfers it using Web Service via SdI.

Transmission of Electronic Invoices using FatturaPA

Next, the SdI Web Service sends a receipt confirmation back, which will either be positive or negative. A negative confirmation is sent when, for example, the data in the invoice was incomplete or the wrong recipient ID was entered. If SdI sends a positive confirmation back, this means that the invoice was received correctly from a technical point of view. This doesn’t mean yet that the recipient accepted or processed it, as there is a second confirmation for this.

The SdI service forwards the invoice to its final recipient. As soon as the invoice has been received by the final recipient, a positive business acknowledgement is returned to the sender. If after 15 days the invoice has not been received by the recipient, the SdI service automatically sends an expiration note which will result in the invoice being voided.

ecosio can upon reception make both confirmations in an ERP import format available, allowing the reception and processing status to be integrated into the ERP system.

The suppliers can thus see in real time whether their invoice has been processed by the recipient or not.

Invoice format

The electronic invoice transfer format used by FatturaPA is the InvoicePA XML format. You can find the corresponding XML template under this link. Before sending the XML data, it needs to be secured with a digital signature. The below two signature formats are allowed:

• CAdES-BES (CMS Advanced Electronic Signature)
• XAdES-BES (XML Advanced Electronic Signature)

The digital signature will be added by ecosio on behalf of the customer before sending.

Data archiving

The Italian legislation foresees certain conditions with regard to the storage of invoices that were exchanged via SdI. To begin with, invoices need to be archived for at least 10 years. Then the archived invoices need to be secured with a qualified digital signature. Most importantly, whichever archiving solution you choose, it needs to be AgID certified, hence guaranteeing that the solution complies with the rules of the Italian authorities.

Questions?

Do you have any more questions about e-invoicing with FatturaPA? Please do contact us or use our chat – we’re more than happy to help!

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

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

Der Beitrag Sending E-Invoices with FatturaPA using Sistema di Interscambio in Italy erschien zuerst auf ecosio.