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.

Thankfully, it is possible to eliminate data issues across individual partner connections by conducting a master data synchronisation (or master data sync). In this article we look at what a master data sync is, why it’s needed, where people often go wrong, and the correct way to handle one.

What is a master data synchronisation?

A master data sync is a process in which you and your business partner examine your master data to ensure that you are both using the same master data elements and the same information for each element.

Data must be consistent within each individual message exchange and across multiple exchanges to ensure streamline B2B integration. Usually, EDI heavily builds on unique identification numbers for all involved parties, goods and services and does not rely on natural language descriptions. E.g. one does not refer to a supplier as “Supplier A Ltd” or a customer as “Customer B Inc.”. Instead unique IDs are used, which must be known to all involved parties. For example, if you refer to a supplier as “A” and a customer as “B”, your partner must adopt the same identification approach to avoid your ERP system (and theirs) pulling through the wrong information from EDI messages.

Typically it is the larger partner – i.e. the “onboard-er” rather than the “onboard-ee” – that dictates what should be used.

Why is syncing master data important?

EDI messages save businesses a significant amount of time and money by optimising B2B processes through automation. If master data is not aligned, however, data errors will occur – and worse still, these errors may not be immediately obvious.

If spotted, errors can be fixed through time-consuming manual intervention. If not spotted, simple errors such as an incorrect delivery address for a large order can ultimately disrupt your entire supply chain and cost your business dearly.

Syncing master data thus provides peace of mind and helps ensure your supply chain runs smoothly.

When should I do a master data sync?

Master data should always be synced before a partner onboarding and whenever there is a change/update of master data on the side of one partner that is relevant to the other partner. This way there is a much reduced risk of errors happening once your connection is up and running. The mapping process is also much faster and simpler when master data has been synced in advance.

What are the most commonly used master data elements?

While master data can extend to include whatever data you want, the most common types of master data in the context of EDI are as follows…

Mailbox IDs (AKA technical sender / receiver information)

This is the ID of the mailbox that the invoice (or other message) is sent to. It is not the same as the invoice recipient or the delivery point. Essentially the Mailbox ID is like the information you put on an envelope; it may not bear any resemblance to the information contained in the letter inside. Though often overlooked, Mailbox ID is an important master data element and should be stored in the ERP system along with the above elements.

Usually unique IDs such as Global Location Numbers (GLN) or DUN & Bradstreet Numbers (DUNS) are being used. However, bilaterally agreed IDs are also possible.

The following example shows two mailbox IDs in action in an EDIFACT purchase order message.

UNA:+.? ‘
UNB+UNOC:3+7810029032309:14+7347339003422:14+211025:1750+138841++ORDERS+++4711′
UNH+1+ORDERS:D:01B:UN:EAN010′

In the example above 7810029032309 uniquely identifies the sender’s mailbox and 7347339003422 the receiver’s mailbox. Both IDs are Global Location Numbers (GLN).

Involved business partners and their IDs

As with Mailbox IDs, unique IDs such as GLN or DUNS numbers are being used to identify business partners. In some scenarios custom IDs, such as the customer’s business partner IDs can be used as well (though this is discouraged by EANCOM).

The following example shows two business partners in an EDIFACT message.

NAD+BY+7870037600032::9′
NAD+SU+7365339000045::9′

The first line identifies the buyer using a GLN and the second line identifiers the supplier using a GLN.

Usually, EDI files contain some of the following roles (non exhaustive list):

• Supplier – The party supplying the item(s) being purchased.
• Customer / Buyer – The party purchasing said item(s).
• Delivery point / Ship to – The delivery address (this should not be confused with any other address connected with the customer).
• Ultimate consignee – The party that will ultimately receive the final item(s).
• Invoice recipient – The party that receives the invoice. Significantly this is not necessarily the customer. For example, if a shop was to buy something, the invoice recipient may well be their headquarters rather than that particular shop.

For more information on the various parties used in EDIFACT, see our blog post on how to use EDIFACT parties correctly.

Usually, an EDI message exchange consists of multiple different messages, e.g. in case of EDIFACT:

• ORDERS (Purchase Order)
• ORDRSP (Purchase Order Response)
• DESADV (Despatch Advice)
• INVOIC (Invoice)

In such a case it is important that the used IDs remain consistent among the exchanged document types. If the buyer is identified in the original ORDERS message as for instance:

NAD+BY+7870037600032::9′

…the exact same GLN 7870037600032 must be provided as the NAD+BY in all other consecutive messages as well (ORDRSP, DESADV, INVOIC).

Exchanged material and service identifiers

The materials or services associated with an EDI message are identified using a unique number as well. Instead of using the supplier’s article numbers or the customer’s article numbers, usually a globally accepted and unique system is adopted. Similar to Global Location Numbers (GLN) for identifying the involved parties and mailbox IDs in EDI, Global Trade Identification Numbers (GTIN) can be used to uniquely identify exchanged goods and services. Oftentimes a combination of both is used – e.g., GTINs are used alongside with the supplier’s article numbers. Thus, the receiving system can be built on any of the two numbers.

The following examples shows an exemplary line item from an EDIFACT message.

LIN+1++4347256156543:SRV’
PIA+1+3345005260:BP’
PIA+1+34559560323:SA’
IMD+F++:::STRAWBERRIES 5X1KG RB’

The first line is the GTIN of the exchanged product. In addition the second line provides the buyer’s article number and the third line the supplier’s article number. Line four contains the free text description of the product for informational purposes only.

These are only a handful of the many possible master data parties. Different industries have different essential master data parties, and some businesses prefer to exchange more granular data than others. For example, the full codelist for parties in EDIFACT can be found here. Please note that different EDI standards use different codes/names for master data parties.

Where people go wrong

Just as IT systems and EDI solutions typically grow and evolve over time, so master data, too, is often historically grown. Over the years it is common for certain master data fields to be conflated, with conflation of a company address and delivery location being possibly the most common example.

Another very common issue concerns the use of the “technical sender / receiver” (AKA “Mailbox ID”) element, which may be, but crucially does not have to be identical to the IDs used in the EDI message.

But master data errors can happen across any of the hundreds of different master data parties. What’s more, these errors will multiply over time unless necessary measures are taken. As a result, by far the biggest master data mistake companies make is not conducting a thorough master data sync before a new onboarding.

Who should handle a master data synchronisation?

While it may seem like your EDI provider would be the most logical candidate to handle master data synchronization, in reality the best person to handle such a project is the person best acquainted with the data and how it is used by your business. Although your EDI service provider may be very knowledgeable about your partner connections, they would only act as a middleman in a master data sync project as they are not able to make key business decisions when it comes to how you want data to be used/stored. The fastest and most efficient way to complete such a project is through direct communication between the employees with the most relevant experience in both you and your partner’s organisations.

However, your EDI provider may certainly help you with decisions on how and where to store EDI IDs in your ERP system. In particular if deep EDI/ERP integration solutions are used, such as ecosio’s integrations for ERP systems like SAP, Microsoft, Infor and the like.

Want more information?

If you would like help or advice on master data, partner onboarding, 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 What is Master Data Synchronisation and Why is it Needed? 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.

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

Morrisons at a glance

• Over 120 years old (founded in 1899)
• Bought Safeway in 2004 to boost presence in South England, Scotland and Wales
• Annual revenue of around £17 billion
• Around 500 large UK stores

Morissons EDI – Where to start?

There are basically three key things you need to know to begin EDI with Morissons: what their supplier onboarding process is, which exchange protocols they use and their preferred EDI document types

What is Morrisons’ onboarding process?

1. A direct contact with Morrisons’ EDI team is established. You will also receive access to a testing portal.
   
2.  A direct connection to Morissons via AS2 communication protocol is set up.
3. Then comes the test phase – referred to by Morissons as “Supplier Onboarding Verification”. This phase involves sending and receiving EDIFACT messages to verify functionality.
4. The so-called “live-proving” phase comes last. During this phase suppliers need to confirm they will be able to receive and process orders in their live system as well as providing the turnaround messages.

What are Morrisons’ document exchange requirements?

As illustrated in the image below (which can be expanded by clicking on it), Morrisons trade the following documents via EDI: purchase orders, purchase order amendments, invoices, credit/debit memos and advanced shipment notifications.

Morrisons EDI requirements have also recently changed. Although they previously required partners to send documents in TRADACOMS formats, they are now using the EDIFACT D96A standard. ecosio is able to connect to Morrisons old TRADACOMS interface or their new EDIFACT interface.

Click to enlarge

* for “fresh” warehouses

Setting up an exchange channel to trade with Morissons

Setting up an exchange channel (utilising the required EDI protocol) is an essential step of establishing an EDI connection with Morrisons.

As Morrisons’ EDI provider is OpenText, suppliers will need to connect to OpenText’s TRADANET platform before being able to exchange EDI with Morissons. Because ecosio’s cloud-based EDI solution (our Integration Hub) already offers integration with TRADANET, suppliers can satisfy all requirements with one connection to ecosio. Consequently, no connection to OpenText’s TRADANET is necessary for suppliers.

How long will it take?

This is a tough question to answer accurately, as it will be different for each supplier depending on their unique routing and mapping needs and the means by which they choose to establish a connection (e.g. in-house or via a managed EDI provider).

In order to ensure a fast, efficient and secure connection it is advisable to use a managed EDI provider. The best EDI solution providers will not only assign a specific project manager to your business to the speed and success of onboarding, but may also offer round-the-clock support and monitoring.

The basic process is shown in the diagram below.

How ecosio can help

ecosio will take the stress out of doing EDI with your partner network.

With our team of EDI experts on your side there’s no need to worry about any document exchange issues. Our flexible and affordable managed solutions will enable you to concentrate on growing your business, safe in the knowledge that key supply chain processes are functioning at optimum level.

Benefits at a glance

• All key B2B document exchange requirements met via one platform
• Zero EDI expertise required
• Translation to all document formats and over all exchange protocols
• Swift partner onboarding 
• Unparalleled supply chain data visibility

Get in touch!

Want help or advice on setting up an EDI connection to Morissons? Feel free to contact us, we’d love to help!

Please also see our other articles for the EDI requirements of similar retailers including ASDA, Boots, Iceland, M&S, Ocado, Sainsbury’s, Tesco and Waitrose.

Der Beitrag Morrisons EDI: Get Yourself Connected! erschien zuerst auf ecosio.

The PRI segment is used in EDIFACT to provide price information. It is used in EDIFACT documents such as ORDERS or INVOIC. The structure of the PRI segment is as follows. The example was taken from a UN / CEFACT INVOIC D07A INVOIC.

UN/CEFACT INVOIC D07A Standard

To highlight the price type, the first composite data element 010 is rather important.

PRI  PRICE DETAILS

Function: To specify price information.

010    C509 PRICE INFORMATION                          C    1
       5125  Price code qualifier                      M      an..3
       5118  Price amount                              C      n..15
       5375  Price type code                           C      an..3
       5387  Price specification code                  C      an..3
       5284  Unit price basis quantity                 C      n..9
       6411  Measurement unit code                     C      an..8

020    5213 SUB-LINE ITEM PRICE CHANGE OPERATION CODE  C    1 an..3

Example:

PRI+AAB:14.3330:::100:PCE'

This means that the gross price for 100 pieces of product xyz (not specified here, since the other segments, such as IMD, PIA, etc. are not listed) is 14.3330 Euro.

The data element 5125 can be used to define the type of price, which is then specified in the data element 5118.

The two most important Price Code qualifiers are AAA (Calculation Net) and AAB (Calculation Gross).

Gross vs. net price

The interpretation of gross and net price in a PRI segment can easily lead to confusion.

Gross and net in this case have nothing to do with taxes. Prices are always stated in EDIFACT exclusive tax. The gross price is the regular price of a product, while the net price is the price that the customer pays.

Here the EDIFACT definition:

5125  Price code qualifier                                    [C]


Desc: Code qualifying a price.

Repr: an..3

Code Values:

AAA   Calculation net
         The price stated is the net price including allowances/
         charges. Allowances/charges may be stated for
         information only.

AAB   Calculation gross
         The price stated is the gross price to which allowances/
         charges must be applied.

 ...

Calculation Gross is therefore the price without discounts / surcharges and Calculation Net the price with discounts / surcharges.

Unfortunately, this is not universally valid. While there is agreement on discounts, the Message Implementation Guide (MIG) determines whether the net price includes surcharges or not.

For example, in the INVOIC EDILEKTRO-MIG of the German Association of Electric Wholesale (VEG) e.V. metal surcharges are explicitly not included in the net price.

Do you still have questions about EDIFACT or EDIFACT INVOIC?

Do you still have questions about EDIFACT or EDIFACT INVOIC? 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.

Der Beitrag EDIFACT PRI Segment – Calculation Net vs. Calculation Gross erschien zuerst auf ecosio.

The exchange of business documents is part of a procurement process between suppliers and buyers, whether in retail, automotive or other production industries transacting goods and services on a regular basis. The following figure represents the typical flow of the seven most common EDI documents between a buyer and seller in a trading partner cycle, which I will explain further below.

buyer and seller in a trading partner cycle

Price Catalog (PRICAT)

The first step of the exchange process between trading partners, is the price catalog and is required when the supplier provides the buyer with a current list of its products, product details, as well as price information. This process is commonly referred to as the product master data exchange, however, is not that common in modern trading partner cycles.

Purchase Order (ORDERS)

Once a buyer decides on the parameters of purchase from its supplier, the buyer must send a purchase order in order to receive those good. As such, this document is a necessary EDI transaction used by a customer, e.g. Sainsbury’s or Skanska, to place an order with one of its suppliers, e.g. Nestle or Tata Steel. This will contain the same information included in a traditional paper purchase order (PO), such as specific items and quantities to be produced, pricing and applicable discounts and shipping details. With EDI, the message includes coded information about the buyer, supplier, delivery point, products, etc. This means that unique identifiers such as global location numbers (GLNs) or global trade identification numbers (GTINs) are used for the identification of the involved trading partners and their goods. GLNs and GTINs are mostly found in retail and wholesale – manufacturing and the automotive industry often build on supplier’s or customer’s article numbers for material identification. In regard to partner identification bilaterally agreed IDs (e.g. JLR for Jaguar Landrover) or DUNS numbers are often used.

The benefit of using purchase orders via EDI allows businesses to avoid data entry errors associated with manually entering data into your system. It also reduces time delays and speeds up the process of sending and receiving documents, as well as, eliminating duplicates.

Order Change (ORDCHG)

A buyer may wish to request to change the quantity of goods ordered or the requested delivery date by emitting an order change message, indicating to the supplier a change of the initial purchase order.

Order Response (ORDRSP)

The supplier may acknowledge a received order message or a received order change message using an order response message. The order response can also be used as an Order Confirmation so as to recap and confirm what was in the purchase order. The supplier is essentially telling the customer that the order was received and they will take the job. It closes the loop and confirms the order electronically, without a follow up call or fax. The document can also indicate that the purchase order was accepted or rejected. It can even indicate any changes in pricing or quantity, alert the customer of product availability (in stock or backorder) and provide ship and delivery dates.

An automatic update of confirming an order or response will prevent confusion or mistakes when the invoice is sent later down the line. Time and money is saved by not having to follow up manually and check.

Dispatch Advice (DESADV)

A supplier notifies the buyer of the shipped good the buyer can expect to receive. Using the dispatch advice message, the supplier provides the buyer with information about the shipment including number of pallets, pallet identification numbers such as serial shipping container codes (SSCC), net and gross weight, identification of the transport vehicle such as license plate number of the truck, etc.

The benefit of this is that the buyer may coordinate the arrival and processing of the goods-to-arrive, e.g., in case of cross-docking-scenarios, frozen goods, etc. Furthermore, the buyer may verify the completeness of the shipment by comparing the received goods with the information provided in the previously received dispatch advice message.

Receipt Advice (RECADV)

After the goods have been received by the buyer, the buyer may emit a receipt advice message, confirming the amount of received goods. The amount of confirmed goods in the receipt advice may be different from the amount communicated by the supplier in the dispatch advice. Reasons for such a deviation may for instance be damaged goods the buyer refuses to accept or a wrong number of goods shipped by the supplier.

Invoice (INVOIC)

An outbound EDI document that replaces the traditional paper invoice. This document basically says that your order is complete and has shipped, so now we are billing you. Invoice details typically include goods provided, shipping particulars and payment terms. If your EDI is embedded, the invoice data is usually translated directly out of your accounts receivable module into the EDI document and subsequently into the accounts payable module of the customer.

Questions about the trading partner cycle of document types?

If you’d like more help with gathering your requirements from your supply chain, you can reach out – we’d be happy to help. or check out our chat.

Der Beitrag The 7 EDI Documents Typically Found in a Trading Partner Cycle erschien zuerst auf ecosio.

Today, standards based on UN/EDIFACT, ANSI ASC X12 or XML are primarily used for the exchange of EDI messages. A Message Implementation Guideline (MIG) refines a generic EDI standard such as UN/EDIFACT (Electronic Data Interchange For Administration, Commerce and Transport) and limits it to use in specific domains or companies. UN/EDIFACT is developed by the United Nations and is the most widely used EDI standard in the world, along with the North American ANSI ASC X12 format.

UN/EDIFACT contains various requirements from different application areas, which makes the standard very extensive. To make working with UN/EDIFACT clearer, different EDIFACT subsets have been developed that are adapted to different industries. For example, EANCOM was created in the retail sector, VDA in the automotive industry, EDILEKTRO in the electrical industry and EDITEC in the HVAC and plumbing sector. These subsets are refinements of the UN standard, in which, for example, permissible code values as well as obligatory fields are defined. Based on these sub-formats, many companies have in turn developed their own versions.

In order for business partners to be able to conduct EDI, the document structures must be implemented on the basis of the partner’s MIGs at the beginning of a cooperation.

A MIG can only tighten up a standard, which means that, for example, no new elements may be added. However, elements can be set to “mandatory” or “not used”. As shown in the following diagram, the basis of all derivatives of EDIFACT standards is the UN/EDIFACT standard. Subsets for different industries are derived from this standard. Companies then use these subsets to create their own variants.

Various industries and companies create subsets of the UN/EDIFACT standard

For the refinement of the standard, own codes are used, which are mostly listed at the beginning of a MIG in the footer of the document. The following excerpt shows the breakdown of codes for a MIG from EDEKA.

Description of the codes used in the EDEKA ORDERS MIG

M indicates that the specification is mandatory and C marks a segment/element as optional. D means that the use of the segment/element is dependent on the use of another segment/element. The dependency is usually explained in the explanatory text. X means that a certain segment/element is not used.

Structure of a Message Implementation Guideline (MIG) using EDIFACT ORDERS

In the consumer goods industry, the EDIFACT subset EANCOM of GS1 is mostly used. EANCOM reduces the UN standard to the most important fields that are obligatory in trade and comprises about 50 different message types. One of these message types is ORDERS – a Purchase Order, which is sent by a customer to a supplier to order products/services.

The following figure shows an excerpt of an EANCOM EDI ORDERS guideline.

Restricting the possible codes for a document to a discrete set of allowed values in EDEKA’s MIG

As can be seen, the use of the data element 1001, for example, is restricted to a list of permissible values. Without this restriction, all values from the general UN/EDIFACT standard could be used.

The EANCOM Message Implementation Guideline for ORDERS can be viewed online and can also be used as a reference for developing your own subset. In addition, the various segments and their meaning in the message structure can also be viewed there.

All permissible codes and their meaning are also broken down here. The graphic representation of the message structure (a so-called branching diagram) and a list of business terms are further important components that are helpful in the implementation of the MIG.

An EDIFACT ORDERS message consists of three parts:

1. The header, in which the business partner, delivery conditions, payment conditions, etc. are listed.
2. The item part, in which the GTIN, as well as the quantity and price of the ordered items are indicated.
3. The total part, which contains the number of item lines of the message.

The ORDERS message for a normal order can look like the one shown in the left column of this graphic:

EANCOM example of an ORDER

We have already presented the exact structure of an EDIFACT ORDERS message in detail in a previous article.

Advantages of using Message Implementation Guidelines

As mentioned at the beginning, the exchange and implementation of message implementation guidelines is particularly relevant for the connection of suppliers. Typically, in trade and in the automotive industry, the guidelines are specified by the buyer. This means that suppliers usually work with many different subsets of the UN/EDIFACT standard and have to implement them.

The following figure shows a section of the MIG for the message type INVOIC of the company BMW AG.

MIG for the EDI document type INVOIC from BMW

As a supplier to the automotive industry, all MIGs of the different automotive customers have to be supported. Although these are often based on the same EDI standard (mostly VDA), they often differ in terms of structure and filling.

How do I get a Message Implementation Guideline?

If a company wants to create its own MIG, all the necessary data of the various processes must first be collected. For example, what data does the ERP system need to process orders, delivery notes, invoices, etc.?

After defining which fields the different document types need, the guideline can be created. However, these are not written in a program such as Word, but use software developed specifically for this application. An example of this is the desktop application GEFEG.FX, which considerably simplifies the creation of a MIG for the various EDI message types. The following screenshot shows the interface of the GEFEG software:

User interface of the GEFEG.FX software

The software is used to load a basic standard (e.g. EANCOM) and then to refine this standard. For example, optional fields (C – conditional) are set to required (R – required). Segments that are not required are deleted. At the same time, the individual segments are backed up with sample data, which helps the reader’s understanding.

Afterwards, the finished Message Implementation Guideline can be exported from GEFEG.FX as a Word document or PDF. To make it easier for suppliers to access this document, it is a good idea to create a separate portal page on the Internet. Employees of the IT team or the partner’s EDI service provider are thus able to download the required documents and implement the document structures using the MIGs. Furthermore, it is advisable to also provide suppliers with sample files for the different formats and application scenarios.

Companies can also hire an EDI service provider to draft and create the Message Implementation Guidelines, as well as to provide a portal page. For example, the EDI document types and MIGs used by HORSCH can be viewed and downloaded on a dedicated website.

HORSCH EDI portal

Summary

Message Implementation Guidelines specify how EDI documents must be structured so that the recipient can process them. This can reduce errors during data exchange and speed up processes.

If you want to develop your own guidelines, they can be created with the help of special software (e.g. GEFEG FX).

Got any questions?

Still have questions about EDI Message Implementation Guidelines? Contact us or use our chat – we are always 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 out our free Peppol tool for yourself.

Der Beitrag What is an EDI Message Implementation Guideline (MIG)? erschien zuerst auf ecosio.

DUNS numbers were introduced by the company Dun & Bradstreet in 1962. Dun & Bradstreet, whose head office is in New Jersey, USA, is currently the largest provider of business information about companies in the world.

A Screenshot of the Dun & Bradstreet Website

Worldwide there are regional companies, who offer company data and ratings about customers, suppliers and potential business partners to their clients. This data contains information about branches, the number of employees, turnover, etc… and information to payment behaviour. This is all shown through a score, which predicts a specific reliability and financial stability.

In order to enter this information into the database accurately, the DUNS number was created in 1962 (the correct name is D&B D-U-N-S® number). This number is unique worldwide and does not overlap with any other number.

Today, DUNS numbers are not only used by many companies, but also by the United Nations, the European Union, the American National Standard Institute (ANSI) and even the American government, to name the most well known establishments.

In the United Kingdom, DUNS numbers are used mostly in the industry sector and related companies, such as the automotive or chemical industry. It is also reflected in the EDI standards that were developed by the corresponding industry associations, for instance ODETTE and their respective EDIFACT standards.

How to apply for a DUNS number

As mentioned above, Dun & Bradstreet have an abundance of local companies, which look after the national clients. In the UK, this company is Dun & Bradstreet UK.

The single purpose of a DUNS Number is to identify companies and lenders. These are e.g. company divisions, branches, but also public institutions, tradesmen and other self-employed persons. DUNS numbers cannot be given to private persons.

Companies can apply for a DUNS Number free of charge on the Dun and Bradstreet platform for the UK. The processing time for the creation of a DUNS number in the UK is five working days. Before they can create your DUNS number, Dun & Bradstreet need to thoroughly check the entered data about the company, hence the processing time.

Structure of DUNS numbers

A DUNS number is composed of 9 digits and is unique worldwide, therefore it does not overlap with any other DUNS number. Even when a company discontinues trading activities (bankruptcy, merging with another company, etc.), their DUNS number will not be reused. This is guaranteed by Dun & Bradstreet central distribution in their distribution policies.

Die DUNS®-Nummer der ecosio InterCom GmbH lautet beispielsweise: 341301537

Who does a DUNS number belong to?

If you need to find out to which company a given DUNS number belongs to, you can also use the Dun & Bradstreet UK platform.

A Screenshot of the Dun & Bradstreet UK Platform

You just need to enter the DUNS® number to search for the company it belongs to. Alternatively, you can also look for the DUNS number of a company by entering the company name and address.

Do you have any questions?

Do you still have questions about DUNS numbers or electronic data interchange? Feel free to contact us, we would love to help you!

Der Beitrag What are DUNS Numbers? erschien zuerst auf ecosio.

Through electronic data interchange between companies, structured documents are exchanged between buyers and sellers. These documents are created by ERP systems, and are sent and received automatically.

Businesses such as retail, will exchange different documents between their ERP systems:

1. PRICAT: The supplier sends his customer price catalogue data, which he can then save in his ERP system
2. ORDERS: The customer sends an order to the supplier
3. ORDCHG: The customer changes the placed order
4. ORDRSP: The supplier confirms whether he accepts the order or not
5. DESADV: The supplier sends a despatch advice to the customer, which contains details about the delivery
6. RECADV: The customer confirms the supplier the amount of received goods
7. INVOIC: The supplier invoices the delivered goods to the customer

These document types are not necessarily used in every business scenario, and the type and use differ from branch to branch. The last possible document type that can be sent is a REMADV, which we will have a closer look at below.

Learn how fully managed EDI could help to boost your business

REMADV message in the EDI document flow

REMADV (Remittance Advice) is an EDI document, which a company will send to their supplier in order to inform them when and how much they will pay them for the received goods or services.

This allows suppliers to know when exactly they will receive which payment, thus allowing them to better plan and control their financial situation.

In EDIFACT, this document type is REMADV, in ANSI X12 it is an 820 message. The document flow described above would therefore look as follows with an REMADV:

EDI document flow for procurement with REMADV

A remittance advice messages contains various data in regard to the payment of goods. This includes for example the invoice number and amount, surcharge or reduction reasons and amount (e.g., discount), any amount that has already been transferred or is still due, etc. The remittance advice can furthermore refer to different business processes and the corresponding financial transactions.

Here is an example of how a REMADV document can look like in EDIFACT EANCOM D01B format:

UNA:+.? '
UNB+UNOC:3+1234567890123:14+1234567890124:14+190311:1137+00000000004711++REMADV'
UNH+1+REMADV:D:01B:UN:EAN004'
BGM+481+0024103741+9'
DTM+137:20190227113719:204'
DTM+203:20190301000000:204'
FII+RB+GB32100600003200765324:John Doe Ltd.+SPAODEGFXXX::17'
NAD+PR+1234567890125::9'
CTA+AD'
COM+0044 89 477 23 23:TE'
COM+0044 89 477 28 99:FX'
COM+0044 89 477 23 28:TE'
NAD+SU+1234567890126::9'
CUX+2:EUR:11'
DOC+380+4365384323'
MOA+39:53800.12'
MOA+52:1076.00'
MOA+12:52724.12'
DTM+137:20190213000000:204'
UNS+S'
MOA+39:53800.12'
MOA+12:52724.12'
MOA+138:1076.00'
UNT+22+1'
UNZ+1+00000000004711'

How are businesses benefitting from using REMADV documents?

The information from the REMADV message is automatically imported in the ERP system, which prevents manual interventions. This allows a business to save on internal resources and to reduce the rate of processing errors. It also makes it easier to compare the actual with the target status, so the business can respond accordingly.

A REMADV allows businesses to plan their finances more precisely and in a more reliable way, since their ERP system already has the information about the payments of the invoices before they have reached their accounts. This gives a business the opportunity to create important reports and forecasts, which are needed for the financial planning before the amounts have been paid.

To Sum Up

REMADV is currently hardly used compared to other document types in the EDI world. However, once it has been set up, the advantages are countless. A REMADV is not only helpful when planning your finances, but it also allows you to recognise payment errors early and automatically. Especially large enterprises work with this document type and request its implementation more and more from their business partners.

Do you have any questions?

Do you still have questions about REMADV or about electronic data interchange with an ERP system? Feel free to contact us, we would love to help you!

Der Beitrag What is a REMADV Message? erschien zuerst auf ecosio.