GS1 has been leading the way in B2B integration and EDI message standards for over four decades. By providing standards for B2B and B2G exchanges, GS1 helps to simplify supply chain communication. Essentially, GS1 is responsible for clarifying the parameters for message exchanges across many industries and are constantly looking to update and improve standards to benefit those businesses that use them every day.

GS1 UK and ecosio

The UK arm of GS1, GS1 UK, is a not-for-profit organisation. Their goal, to “to harness the power of standards to transform the way people work and live”, is strikingly similar to ecosio’s own vision, “To maximise supply chain efficiency through automated B2B communication”.

As such it is no surprise that ecosio and GS1 UK have collaborated several times in the past, with ecosio co-founder Philipp Liegl speaking at several of their events.

A partnership is born

ecosio is now proud to be a partner of GS1 UK. We look forward to working directly with GS1 UK to help shape the future of GS1 standards and support industry-wide development.

Here you can see our partner listing on the GS1 UK site.

Want to learn more about EDI standards?

If you would like to learn more about how EDI standards work and how they are used to streamline business communication, why not check out the article about EDI file formats?

You may also be interested in our stat-packed, printable infographic which details five of the main benefits that EDI can offer…

We also have a multitude of free infographics, white papers and webinars that you may find interesting.

Der Beitrag ecosio Becomes a Partner of GS1 UK erschien zuerst auf ecosio.

If you are not already familiar with X12 file structure and ANSI messaging terminology, you may wish to read our article on the structure of an X12 file before continuing.

If you use EDIFACT instead, read our article on using EDIFACT parties. 

What are ANSI X12 parties?

As their name suggests, party identifiers are used in X12 messages to identify certain X12 parties in a particular transaction, such as the shipping party or the receiving party. The party can be an organizational entity, a physical location, property or an individual. The identifiers themselves sit at the start of an N1 segment and are 2-3 characters long.

The full list of X12 party identifiers includes over 1,300 different parties, however most exchanges will only require a few of these. The most commonly used identifiers are listed here:

For completeness, we have also included the full list of X12 party identifiers at the bottom of this article.

Why is getting X12 party identifiers wrong a common issue?

Within the ANSI ASC X12 standard, there are a multitude of different possible parties that can be involved in a certain transaction. Some of these X12 parties may, in certain cases, be the same as other parties. For example, Bill To and Ship To could easily contain the same information in a particular transaction. Crucially, however, this will not necessarily be true for other transactions.

Unfortunately, confusion over this (or exactly what each party identifier refers to) can lead to poor master data maintenance and incorrect data being exchanged.

Why getting X12 parties right matters

If the correct X12 parties aren’t used, sooner or later errors will occur. These errors can have significant consequences and cost implications. Larger partners, for example, will refuse any invoice that contains data that doesn’t match their records.

Further, correcting master data issues once an issue has been discovered can be time consuming and complicated.

What can I do to avoid using identifiers incorrectly?

In order to avoid future issues, those using X12 parties should…

• Double check the EDI message implementation guideline or “MIG” (and any other relevant documentation) to ensure parties are being used as intended.
• Cross check with other messages in the same chain in case there are interdependencies. For example, an X12 invoice message will usually include the same party identifiers as the preceding order or despatch advice message, but may also include other X12 parties too.

If in doubt, simply check with your partner or EDI service provider. It is always better to ask and get it right first time than to assume.

Want more information?

If you would like more advice on using ANSI ASC X12 parties correctly or streamlining B2B integration more generally, please get in touch. We are always happy to help!

Our resources section also houses a wide selection of articles, webinars, white papers and infographics that you may find useful.

Der Beitrag The Most Common ANSI ASC X12 Parties and How to Use Them erschien zuerst auf ecosio.

Why master data errors happen

One of the most common sources of master data issues is the conflation of EDIFACT parties – i.e. the parties referenced in EDIFACT messages. To those inexperienced with EDI and EDIFACT, it may not seem like an issue to use certain EDIFACT parties interchangeably if the underlying information is the same for a certain transaction. However, just because Buyer and Ultimate consignee or Invoice recipient may be the same value in a B2B transaction with business partner A, for example, that doesn’t mean they always will be in all other B2B transactions with other business partners.

The two core principles one must adhere to here are:

• Always consult the respective EDI message implementation guideline and potentially accompanying documents, to check which partner role is required where.
• Always cross check with other document types in the same process choreography, to spot potential interdependencies. E.g. an INVOIC usually must contain the same role identifiers (AKA party codes) as the underlying ORDERS and DESADV. It may of course also contain additional role identifiers, not contained in the underlying document types.

Making the wrong assumptions and not cross-checking exactly with the requirements will ultimately lead to errors and the swift deterioration of your master data’s integrity.

Admittedly, setting up EDI connections with certain partners can be challenging, as you may encounter requirements, such as those 3M sends to their partners (pictured below).

In such cases it is even easier for users to confuse EDIFACT parties.

The impact of master data errors

Without trained personnel and processes and procedures in place to protect the integrity of your master data (such as conducting a full master data sync before onboarding a new partner), data quality is likely to deteriorate over time. In such situations, the only solution is a time-consuming audit and correction process.

Meanwhile, in the short term even the smallest error can have significant repercussions. For example, large consumers will often reject an invoice, no matter how big, if the data on it does not align with their records.

To help you avoid making expensive mistakes, in the following sections we will explore the subject of EDIFACT parties in detail, looking at the three popular EDIFACT subsets (EANCOM, EDITEC and VDA).

Before diving into these subsets, however, let’s first look quickly at EDIFACT as a whole…

Understanding EDIFACT and EDIFACT parties

UN/EDIFACT stands for the United Nations rules for Electronic Data Interchange for Administration, Commerce, and Transport. It is a set of internationally agreed standards that was created to facilitate the exchange of structured data between business partners.

As UN/EDIFACT is used across many different industries, the list of UN/EDIFACT parties (also known as “party function code qualifiers” and by the code “3035”) that can be used in B2B exchanges is very long. The full list of UN/EDIFACT party codes in the D01B version of the standard, which are used for the NAD (name and address) segments of EDI messages, can be found here.

As no company would ever need to use all of these party codes (and maintaining so many master data fields accurately would be virtually impossible), UN/EDIFACT users rely on standard subsets instead. These subsets are tailored towards specific industries and reduce the various EDI messages to essential fields that are mandatory to specific business processes or for specific message types. As a result, companies are only required to recognise and use a fraction of the available EDIFACT party codes.

Now let’s look at the key parties in each of these subsets and how they differ from one another, using the example of an INVOIC (invoice) transaction in each case.

EDIFACT subset 1: EANCOM (D01B INVOIC)

EANCOM is arguably one of the most popular subset of the UN/EDIFACT standard. Initially created for the retail industry, EANCOM is now also used by some other industries too.

The EANCOM standard currently includes about 50 different message types. For the purposes of this article look at one of these – the D01B INVOIC – as an example.

From the hundreds of parties available under the extensive UN/EDIFACT standard, the EANCOM D01B INVOIC guideline uses just 35. The most commonly used of these, and their descriptions, are listed below…

In most EANCOM D01B INVOIC transactions you are unlikely to need to refer to any party outside the nine listed above. However, there are a number of others that may be required from time to time.

These less commonly used EDIFACT parties are listed below:

EDIFACT subset 2: EDITEC (INVOIC 4.1)

The EDITEC subset offers standards for the communication between the plumbing/heating/air conditioning industry (in German: SHK for Sanitär-Heizung-Klima) and the respective wholesale sector. This is also known as the Heating, Ventilation & Air Conditioning industry – better known as HVAC (although this does not include plumbing).

EDITEC’s INVOIC 4.1 standard uses six party function code qualifiers. These are listed below:

EDIFACT subset 3: VDA (VDA 4938)

VDA stands for “Verband der deutschen Automobilindustrie” (German Automobile Industry Association). Unsurprisingly, given its name, VDA is almost used exclusively by the German automotive industry.

Within VDA’s INVOIC standard (VDA 4938) the ten most commonly used EDIFACT parties, or party function code qualifiers, are…

Want more information?

If you would like help or advice on using EDIFACT parties correctly, avoiding master data issues or any other EDI topics, please get in touch. We are always happy to help!

You can also find a wide selection of articles, webinars, white papers and infographics in our resources section.

Der Beitrag Using EDIFACT Parties Correctly – A Breakdown 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.

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

Hurdle 1: Standards

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

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

Hurdle 2: Technology

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

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

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

Hurdle 3: Processes

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

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

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

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

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

Hurdle 4: Legal requirements

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

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

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

Want more information on how to overcome these hurdles?

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

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

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

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

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.

For more information on using X12 party identifiers correctly, please see our article “The Most Common ANSI ASC X12 Parties and How to Use Them” on this topic.

Segments as basis in the structure of an ANSI X12 file

EDI files essentially consist of segments that contain the basic information. Every EDI message is created from these segments, as with ANSI ASC X12. For example, if we simply want to send the name of a partner company, we can use the so-called NM1 segment (easy: NM stands for “name”).

Our example segment could now look like this:

Structure of an ANSI X12 file Example of an ANSI X12 segment

Designations

Segment Name: Stands for the name of the segment. NM1

Element Separator: For separation before data elements. *

Segment Separator: This determines the end of the segment. ~

Data Element: Specified data. 808, 5, NAME ORGANISATION, XX

Composite element: Several data elements can be grouped into a logical unit. A:B:C

Composite Element Separator: Composite elements can be separated. :

The delimiters for the correct reading (“parsing”) of the data or data elements by the EDI solution are element separator, segment separator and composite element separator. Data elements can, for example, simply be text (such as our example company), numbers, time or date specifications, identifiers, etc. Data elements have a certain minimum and maximum length. For example, text is usually longer than a time specification. EDI parsers can also check the permitted length in the structure of the ANSI X12 file.

The ISA segment in the structure of an ANSI X12 file

At the beginning of an EDI file there is the ISA segment, also called Interchange Control Header. The delimiters or separators mentioned above, which the EDI solution uses to divide and read the segment, are determined here and communicated to the EDI solution.

This works because the ISA segment is defined at exactly 106 characters. This means that the EDI solution can search for the character itself at the corresponding position in the segment:

ISA*00*          *00*          *01*069167604     *ZZ*PLANT-MX       *170614*0808*^*00401*000000003*0*T*:~'

Data Element Separator: Character No. 4: *

Repetition Element Separator: (for repeating data elements): Character no. 83: ^ (U would stand for “unused” by the way)

Composite Element Separator: Character Nr. 105: :

Segment Separator: Character Nr. 106: ~

When the structure of an ANSI X12 file becomes more complicated

EDI messages can sometimes become very large. To counteract the complexity, two elements were created for ANSI X12:

Composite Elements

Sometimes a single data element is not specific enough for a message. Then a composite element can be used to help. This is defined in the ISA (Interchange Control Header) segment at the very beginning of a complete EDI message, which we will discuss below. In our case it is :. The EDI solution can then recognize such data elements in the composite and distinguish them by the character. 

Recurring elements

With version 5010 X12, repeating data elements (repeating elements) can also be defined. This allows information to be specified more specifically in a segment by using the same data element for more information. This also works with composite data elements. The separator for the EDI solution is again defined in the ISA segment.

For example, we have a CLM segment (CLM stands for “claim”) whose element CLM05 consists of three components: Claim Facility Code Value, Claim Facility Code Qualifier and Claim Frequency Type Code. CLM05 is represented as a composite element with 11:B:1:

CLM*A37YH556*500***11:B:1^12:B:2*Y*A*Y*I*P. 

This is now, indicated by ^, cemented with a new composite element 12:B:2.

More questions?

If you have questions about ANSI X12 or EDI more generally, please contact us. We are always happy to help!

More information can also be found on the official ANSI ASC X12 homepage is also worth a click.

Der Beitrag The Structure of an ANSI ASC X12 File erschien zuerst auf ecosio.

For more information on using X12 party identifiers correctly, please see our article “The Most Common ANSI ASC X12 Parties and How to Use Them” on this topic.

Segments as basis in the structure of an ANSI X12 file

EDI files essentially consist of segments that contain the basic information. Every EDI message is created from these segments, as with ANSI ASC X12. For example, if we simply want to send the name of a partner company, we can use the so-called NM1 segment (easy: NM stands for “name”).

Our example segment could now look like this:

Structure of an ANSI X12 file Example of an ANSI X12 segment

Designations

Segment Name: Stands for the name of the segment. NM1

Element Separator: For separation before data elements. *

Segment Separator: This determines the end of the segment. ~

Data Element: Specified data. 808, 5, NAME ORGANISATION, XX

Composite element: Several data elements can be grouped into a logical unit. A:B:C

Composite Element Separator: Composite elements can be separated. :

The delimiters for the correct reading (“parsing”) of the data or data elements by the EDI solution are element separator, segment separator and composite element separator. Data elements can, for example, simply be text (such as our example company), numbers, time or date specifications, identifiers, etc. Data elements have a certain minimum and maximum length. For example, text is usually longer than a time specification. EDI parsers can also check the permitted length in the structure of the ANSI X12 file.

The ISA segment in the structure of an ANSI X12 file

At the beginning of an EDI file there is the ISA segment, also called Interchange Control Header. The delimiters or separators mentioned above, which the EDI solution uses to divide and read the segment, are determined here and communicated to the EDI solution.

This works because the ISA segment is defined at exactly 106 characters. This means that the EDI solution can search for the character itself at the corresponding position in the segment:

ISA*00*          *00*          *01*069167604     *ZZ*PLANT-MX       *170614*0808*^*00401*000000003*0*T*:~'

Data Element Separator: Character No. 4: *

Repetition Element Separator: (for repeating data elements): Character no. 83: ^ (U would stand for “unused” by the way)

Composite Element Separator: Character Nr. 105: :

Segment Separator: Character Nr. 106: ~

When the structure of an ANSI X12 file becomes more complicated

EDI messages can sometimes become very large. To counteract the complexity, two elements were created for ANSI X12:

Composite Elements

Sometimes a single data element is not specific enough for a message. Then a composite element can be used to help. This is defined in the ISA (Interchange Control Header) segment at the very beginning of a complete EDI message, which we will discuss below. In our case it is :. The EDI solution can then recognize such data elements in the composite and distinguish them by the character. 

Recurring elements

With version 5010 X12, repeating data elements (repeating elements) can also be defined. This allows information to be specified more specifically in a segment by using the same data element for more information. This also works with composite data elements. The separator for the EDI solution is again defined in the ISA segment.

For example, we have a CLM segment (CLM stands for “claim”) whose element CLM05 consists of three components: Claim Facility Code Value, Claim Facility Code Qualifier and Claim Frequency Type Code. CLM05 is represented as a composite element with 11:B:1:

CLM*A37YH556*500***11:B:1^12:B:2*Y*A*Y*I*P. 

This is now, indicated by ^, cemented with a new composite element 12:B:2.

More questions?

If you have questions about ANSI X12 or EDI more generally, please contact us. We are always happy to help!

More information can also be found on the official ANSI ASC X12 homepage is also worth a click.

Der Beitrag The Structure of an ANSI ASC X12 File erschien zuerst auf ecosio.

First, though, it’s important to note that the Peppol ID is only one of several crucial identifiers required for successful document exchange via Peppol…

The three most important identifiers used in Peppol exchanges

The three main identifiers found in messages sent via Peppol are:

1. Peppol Participant Identifiers (or Peppol ID)A Peppol Participant Identifier, also known as a Peppol endpoint ID or simply a Peppol ID, is the unique reference that is used to establish the identity of connected parties.
   
   As explored in more detail below, the syntax for a Peppol ID is
   <BusDoxParticipantIdentifier>::<IssuingAgencyCode>:<Code>.
2. Document IdentifiersUnsurprisingly, Document Identifiers are used to indicate which document is being exchanged.
   
   The syntax of Document Identifier is <DocumentIdentifier> = <RootNamespace>::<documentLocalName>##<CustomizationID>::<Version> Within this, <Version> refers to the version of the underlying syntax (i.e UBL 2.1), while Customisation ID specifies the standardised transaction (e.g. invoice) and related Peppol extension. The full syntax of the Customisation ID in turn is <transactionId>:# <extensionId>[#<extensionId>].
   
3. Process IdentifiersProcess identifiers are used to specify what process should be used for the transaction (e.g. invoice only or catalogue only).
   
   The BusDox* Process Identifier scheme used by Peppol is cenbii-procid-ubl. Peppol processes are identified by the respective BII processes and therefore the process identifier must match the BII profile ID. A list of the different Profile IDs can be found in the OpenPeppol eDEC Code List.

Below is an example of a Peppol message, in which it is possible to see where all the above identifiers are located.

Peppol example message

Why do I need a Peppol ID?

Every buyer and supplier within the Peppol network must have a Peppol ID. Without a Peppol ID you will be unable to send or receive invoices via the network.

Once you have a Peppol ID your business can exchange automated messages with all other connected companies that support the necessary document types. As discussed in more detail below, a list of the document types that other businesses support can be found via the Peppol directory.

How do I get a Peppol ID?

Peppol IDs are obtained through Peppol Access Point providers. All that is required in order to get an ID is to register with your preferred provider.

What does a Peppol ID look like?

As Peppol doesn’t have its own unique system for identifying connected parties, the network instead employs a federated system based on the ISO 15459 format scheme for unique identifiers. There is a set number of Issuing Agency Codes (IACs) that are acceptable for Peppol compliance. The Peppol ID (or Peppol Party Identifier) you are given will be a combination of the IAC and the value given by the agency issuing the code.

For example, ecosio’s full Peppol ID is iso6523-actorid-upis::0088:9110019474691.

This full endpoint ID is comprised of the BusDox Participant Identifier prefix, the Issuing Agency Code for GS1 (Global Standards 1), and the GLN (Global Location Number), as illustrated below.

What’s needed for Peppol message exchange?

Peppol uses the BusDox infrastructure for message exchange. Within Peppol, BusDox is only concerned with the services that the receiver participant can handle as this is the key information in any exchange. The receiver participant can be a supplier, customer or another business role depending on what is being sent. Significantly, there is also no agreed relationship in Peppol specifications between identifiers used in the document transport infrastructure and in-message identifiers.

When it comes to message exchange in Peppol, BusDox requires the document sender to identify both the receiver participant and the recipient service (this is often their Access Point provider). Generally this is achieved by searching for the relevant Service Metadata Publisher (SMP) in the Service Metadata Locator (SML) to discover the required endpoint address – the endpoint address is the service, or Access Point, address and is different to the endpoint ID used in the document itself. Given this process it is important that the documents and services that the receiver can handle are clearly defined.

In short, every message exchange via Peppol requires the following information:

• The document to be exchanged
• The recipient’s Peppol ID (aka Peppol Participant Identifier)
• The necessary document type ID and process ID

A detailed explanation of how document exchange in Peppol takes place can be found on the website “Peppol Practical – Document exchange explained”. Likewise, a detailed look at the types of message response found in Peppol exchanges can be found in our article “Peppol Message Responses – A Helpful Guide”.

Using the Peppol directory

The Peppol directory is intended to help businesses to identify prospective/existing partners on the network. It can prove particularly useful in the following two scenarios, for example:

• If a business is looking to send invoices via Peppol moving forward and wants to see which of its current trading partners is capable of receiving invoices in the format dictated by Peppol BIS (Business Interoperability Specifications).
• If a business wishes to set up an alert to see when current trading partners join the Peppol network so that future exchanges can take place via Peppol.

Currently anyone is able to search the Peppol directory via this web interface by entering the name, address, ID or any other keyword relating to the entity they want to find. If the business is found, the page will then display key business information (country, entity name, geographical information, website and full Peppol participant ID) in addition to listing all document types supported by the entity.

Planned Peppol directory improvements

Peppol has also outlined the following three improvements that they would like to make in the future. These are:

• Free text search
  This functionality would enable the searcher to enter any phrase or list of characters and find all listings that contain that string of text in their Peppol ‘business card’.
• Identifier search
  This proposed update to the Peppol directory would allow users to search for a business with a certain identifier and specific BIS capabilities. This identifier would not have to be a Peppol ID, however, and could be a VAT or legal identifier. In turn, this would enable businesses to monitor when a specific business gains the ability to send/receive certain documents via Peppol without knowing their Peppol ID.
• API search
  Rather than having to conduct the search through a separate web interface, users in the future will have the option of accessing the directory via API. This will allow businesses to benefit from automated searches within their existing ERP systems, vastly improving ease of use.

ecosio – your trusted Peppol Access Point provider

ecosio was one of the first certified Peppol Access Points in Europe and is now one of a limited number of Access Point providers that are both AS2 and AS4 compliant.

With a single connection to the ecosio cloud-based EDI solution (our Integration Hub), you will be able to exchange messages with all Peppol-enabled companies.

Want to learn more about Peppol?

For more information on Peppol our white paper “Peppol: What you need to know” can be downloaded at any time.

Alternatively, if you would like advice concerning your specific situation or would like to know exactly what it takes to obtain a Peppol ID and get connected to the network, contact us! We are always happy to answer your questions.

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

* BusDox is a set of specifications designed by OASIS for Peppol document exchange

Der Beitrag How Peppol IDs Work erschien zuerst auf ecosio.

• EDI file formats standardise how B2B documents are structured for automated exchange
• Popular formats include EDIFACT, TRADACOMS, X12, VDA, and UBL, each suited to specific industries
• Each format follows different rules, like delimiters or fixed-length fields
• When partners use different formats, conversion is essential and often handled by a managed EDI provider

Document standards are an essential part of electronic data interchange (EDI). In short, EDI standards (aka EDI file formats) are the specific guidelines that govern the content and format of B2B documents such as orders, invoices and order responses. These documents are then sent via EDI protocols to the service provider / business partner.  

For more information on ecosio EDI as a Service solution and to find out how we could help your business move to the next step, get in touch today or chat with our Sales team now!

How EDI file formats work

Sending documents according to an EDI standard ensures that the machine receiving the message is able to interpret the information correctly as each data element is in its expected place. Without such standards the receiver’s system will be unable to identify what part of the message is what, making automated data exchange impossible.

Although EDI documents may seem like a random mix of letters and symbols, all EDI messages conform to very strict rules. Typically EDI standards are based on the following four principles:

Syntax

Syntax rules determine what characters can be used and in what order.

Codes

Codes are used to identify common information such as currencies, country names or date formats.

Message designs

The message design defines how a particular message type (e.g. invoice or purchase order) is structured and what subset of rules from the prescribed syntax it uses.

Identification values

The means by which values in an EDI file are identified, e.g. by its position in the file or via the use of separators. These changes from standard to standard.

Most EDI standards also include the following three components: 

• Elements – The smallest part of a message, providing submitted values (e.g. “50” or “KGM” or “Potatoes”)
• Segments – A collection of elements or values logically combined to provide an information (e.g. Quantity 50 kilograms of potatoes)
• Transaction sets – A collection of segments, composing a message (e.g. an Invoice for the sale of 50 kilogram of potatoes)

Essentially different formats are like different languages, with the elements and segments of a certain standard mirroring the words and sentences of a regular language.

A brief history of EDI document standards

In the very early days of EDI it quickly became evident that document standards were required to avoid confusion and improve the efficiency of even paper-based supply chain communication. Following the advent of file transfer between computers (FTP) becoming possible, in 1975 the very first EDI standards were published by the Transportation Data Coordinating Committee (an organisation formed by US automotive transport organisations in 1968). In 1981 the American National Standards Institute then published the first multi-industry national standard, X12. In turn this was followed by the creation by the UN of a global standard, EDIFACT, in 1985. 

No one attempt to unify standards has ever been completely successful, however. As technology has evolved and industry specific needs have become increasingly disparate, new standards have steadily been introduced over the decades. Somewhat counterintuitively, therefore, today there is no such thing as a single all-encompassing EDI standard for every document type. Instead, businesses choose their preferred document standard from a number of options (usually opting for the one most widely used in their industry). When trading with partners using different standards, businesses then have to ensure that their messages are correctly converted to the recipient’s required format. This process is called mapping.

The 5 most used EDI file format standards:

1) UN/EDIFACT

The most popular EDI file format standard today outside North America is UN/EDIFACT, which stands for United Nations rules for Electronic Data Interchange for Administration, Commerce and Transport. These international B2B message guidelines are extremely widely used across many industries. 

In fact, given the scope of EDIFACT’s adoption, several industries have developed subsets of the main standard which allow for automation of industry-specific information. One well-known subset is EANCOM, for example, which is used in the retail industry.

EDIFACT document file types are identified by a six letter reference. For example, three of the most common of these references are:

• ORDERS (for purchase orders)
• INVOIC (for invoices)
• DESADV (for despatch advice)

All of these EDIFACT messages have the same basic structure, consisting of a sequence of segments:

• UNA – separators, delimiters and special characters are defined for the interpreting software 
• UNB – file header (with the file end UNZ this makes up the envelope, containing basic information)
• UNG – group start
• UNH – message header
• UNT – message end
• UNE – group end
• UNZ – file end

Example EDIFACT order

[segment tags shown in bold]

As well as transmission format, the EDIFACT standard also defines delivery requirements. EDIFACT provides set guidelines, for example, concerning the exact structure of specific message exchanges, which might themselves contain several individual EDIFACT files.

For a more detailed look at the structure of an EDIFACT file, see our blog post “EDI Standards Overview – Structure of an EDIFACT File” on this topic.

2) TRADACOMS

Despite being less widely-used than EDIFACT, the TRADACOMS standard was released several years before the UN standard. Designed primarily for UK domestic trade (and particularly popular in the retail industry), TRADACOMS is made up of a hierarchy of 26 messages. Like EDIFACT, each message is also given a six letter reference.

TRADACOMS does not use a single message format. Instead, a transmission to a trading partner will consist of a number of messages. For example, one purchase order will often contain an Order Header (ORDHDR), several Orders (ORDERS) and an Order Trailer (ORDTLR). Multiple individual order messages can repeat between the ORDHDR and the ORDTLR.

As with EDIFACT standards, the TRADACOMS standard uses segments for ease of translation. Below are four of the most common segments:

• STX – Start of Interchange
• MHD – Message start
• MTR – Message end
• END – End of Interchange

Example TRADACOMS order

[segment tags shown in bold]

3) ANSI ASC X12

ANSI ASC X12 stands for American National Standards (ANSI) Accredited Standards Committee (ASC) X12, though (for obvious reasons) this is often abbreviated to just X12.

Though initially developed in 1979 to help achieve EDI document standardisation across North America, X12 has been adopted as the preferred standard by approaching half a million businesses worldwide.

Compared to other EDI standards organisations, X12 has a particularly comprehensive transaction set. There are over 300 X12 standards, all of which are identified by a three digit number (e.g. 810 for invoices) rather than the six letter code system used by EDIFACT and TRADACOMS. These EDI file format standards fall under X12’s different industry-based subsets:

• AIAG – Automotive Industry Action Group
• CIDX – Chemical Industry Data Exchange
• EIDX – Electronics Industry Data Exchange Group (CompTIA)
• HIPAA – Health Insurance Portability and Accountability Act
• PIDX – American Petroleum Institute
• UCS – Uniform Communication Standard
• VICS – Voluntary Interindustry Commerce Standards

With each containing slight variations, these subsets are used by different industries as appropriate (apparel retail businesses use VICS for example).

In addition, the hundreds of document types are divided into 16 helpful message series, from ‘order’ to ‘transportation’, with each containing the relevant individual message types.

As with Documents conforming to X12 standards are made up of several segments, some of which are optional and some mandatory. Below is a list of the mandatory segments:

• ISA – Start of interchange
• GS – Start of functional group
• ST – Start of transaction set
• SE – End of transaction set
• GE – End of functional group
• IEA – End of Interchange

As with all EDI documents, these segments in turn are comprised of elements, as can be seen in the example X12 document below:

Example X12 order

[segment tags shown in bold]

For more information on the X12 format, please see our more recent article “EDI Standards Overview – Structure of an EDIFACT File”.

4) VDA

The Association of the Automotive Industry (Verband der Deutschen Auto­mobil­industrie in German, or VDA for short) was established in 1901 by German automobile businesses.

The VDA was one of the first associations to develop EDI file formats in 1977, making VDA standards even older than EDIFACT. 

Like X12 standards, every VDA message standard has a unique identification number (four digits long in this case). For example, VDA EDI file format 4905 is a delivery forecast.

As worldwide use was not expected when the standards were developed, all VDA standards were published in German – something that continues to this day. This can make interpretation difficult, particularly concerning German business terms. Likewise, as VDA also does not use a naming convention for each element, knowledge of German is required to identify them. 

Unlike EDIFACT and X12 standards, VDA standards do not use segments or separators. Instead data elements with a constant length, known as fixed length format elements, are used. When the data to be transmitted is shorter than the required length, spaces are used to fill the gaps. Unfortunately, this fixed length format means that the amount of data that can be transmitted is limited, meaning conversion to/from other EDI standards can be difficult.

Because of these issues, VDA fixed length document standards are slowly being replaced by EDIFACT document types. Today, VDA standards are effectively a subset of the EDIFACT standards used extensively by the automotive industry (much like the EDIFACT subset CEFACT is used by retail businesses).

To aid those using their standards, the VDA have published suggestions regarding transition to EDIFACT. 

Example VDA delivery forecast

[segment tags shown in bold]

For more information on VDA standards, please see our dedicated VDA blog post for a more comprehensive explanation.

5) UBL

The Universal Business Language, or UBL, is a library of standard XML-based business document formats. UBL is owned by Organisation for the Advancement of Structured Information Standards (OASIS), who have made it available to all businesses for free.

As UBL uses an XML structure it differs from other more traditional EDI document formats. Perhaps the biggest difference is the fact that XML-based transmissions are easier to read than other EDI file formats. However, XML file sizes are considerably larger than those of other EDI file formats, though this is no longer a problem following the advent of broadband internet. 

When first established in 2003, UBL had seven EDI file format standards. By the time version 2.1 was released over a decade later this number had increased to 65, and the release of version 2.2 in 2018 further increased the number of document types to over 80.

Significantly CEN/TC434 recently named UBL as one of two EDI syntaxes which comply with new EU regulations regarding e-invoicing. As such, as the use of PEPPOL grows, so the use of UBL is also likely to increase.

Like X12, UBL message types are split into higher level categories. These categories include pre-award sourcing, post-award sourcing, procurement and transportation. UBL messages themselves, meanwhile, include validators, generators, parsers and authoring software.

Example XML order (ecosio ERPEL)

How to exchange different EDI file formats with your trading partners

Whilst each of the above document standards is widely used, particularly within certain industries, unfortunately no one set of document standards is universally used by all supply chain businesses. As a result, if you wish to grow your business and to automate B2B data exchange with your partner network to achieve the cost benefits of automation you will need the ability to translate data between numerous formats.

Given the amount of technical expertise EDI file format translation requires, the fastest and most efficient way to gain this capability is to enlist the help of a managed EDI solution provider such as ecosio. In addition to enabling you to transfer documents in any required format and over any EDI protocol via a single connection to the ecosio cloud-based EDI solution (our Integration Hub), ecosio’s managed services remove virtually all internal effort concerning EDI. For example, new onboardings are handled by a dedicated project manager who is experienced in liaising between both sides to achieve fast, hassle-free and successful connections. Similarly, ecosio’s unique API ensures users are able to send and receive data directly from their ERP’s existing user interface.

For more information on ecosio EDI as a Service solution and to find out how we could help your business move to the next step, get in touch today or chat with our Sales team now!

Der Beitrag EDI file formats explained: key standards and differences erschien zuerst auf ecosio.