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.

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

Boots at a glance

• Founded in 1849, Boots recently celebrated its 170 year anniversary
• The UK’s largest chain of pharmacies
• Merged with Walgreens in late 2014
• Presence in Asia and the West Indies
• Over 2,500 stores in the UK and Ireland

EDI with Boots

Before being able to trade with Boots via EDI, you will first need to understand their partner onboarding process and know the exchange protocols and document types they use…

Boots supplier onboarding process

1. A connection is setup through a VAN mailbox or directly through Boots’ EDI providers.
2. The connection is tested by sending generic files between the supplier and Boots.
3. Test documents for all relevant message types are exchanged and verified via the connection.
4. Before full go-live EDI orders will be exchanged in parallel with those sent via email to ensure everything is working correctly.
5. Following successful testing your connection will go live. The exact date will be agreed between you and your Boots contact.

What EDI standards and document types do Boots use?

As illustrated below, Boots requires partners to be able to exchange orders, advanced shipping notifications, invoices, credit notes and remittance advice messages via EANCOM and TRADACOM standards.

Suppliers should be aware that there is a difference in the mappings required for retail and pharmacy mappings, whilst credit notes are only necessary for pharmacy suppliers.

Click to enlarge

Setting up an EDI connection to Boots

In order to exchange commerce critical data with Boots via EDI an exchange channel using the necessary EDI protocol first needs to be set up.

Boots uses OpenText as its EDI provider, meaning a connection to their platform TRADANET must be set up in order for you to exchange EDI messages with Boots. ecosio already offers integration with TRADANET, meaning a single connection from your ERP system to ecosio’s cloud-based EDI solution (our Integration Hub)  will fulfil all exchange protocol requirements.

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

Connection timeline

Whilst Boots aims for all connections to go live within two months, they acknowledge that this process may take longer if issues are encountered during testing. 

Generally speaking it is hard to predict exactly how long establishing a secure connection will take, as every business is different and will have different routing and mapping requirements.

Undoubtedly the fastest way to connect to Boots is to enlist the help of a managed EDI provider, and ideally one that is able to provide a dedicated project manager to oversee the onboarding from start to go-live. A good managed EDI service should also include 24/7 monitoring to ensure any errors are caught and resolved as soon as possible.

Below is a simple diagram showing the connection process.

How ecosio can help

ecosio can ensure your business is doing EDI with Boots in no time!

With our flexible managed EDI services there’s no need to worry about time-consuming and resource-heavy mapping, routing and monitoring of data. Achieve peace of mind regarding critical data exchange with a single connection to our unique Integration Hub.

Benefits at a glance

• All EDI needs handled via one managed connection
• No need for EDI experience
• Translation to all common EDI formats and via all protocols
• Fast onboarding of trading partners 
• End-to-end data monitoring in your ERP system

Get in touch!

Still have questions about doing EDI with Boots? 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, Iceland, M&S, Morrisons, Ocado, Sainsbury’s, Tesco and Waitrose.

Der Beitrag Doing EDI with Boots: A Supplier’s Guide erschien zuerst auf ecosio.

Tesco at a glance

• Founded in 1919, Tesco recently celebrated its 100 year anniversary
• One of the UK’s largest supermarket chains
• A presence in several other countries across Europe and Asia
• Over 6,500 stores worldwide 
• An expected centenary year revenue of over £60 billion

EDI with Tesco

Before you are able to start EDI with Tesco, the following three things should first be considered: Tesco’s partner/supplier onboarding process, what exchange protocols they use, and which document formats they require.

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

Tesco supplier onboarding process

1. Tesco’s EDI team will work with your EDI partner to help you set up a connection.
2. After you have been able to set up the required EDI document mappings, Tesco will provide you with documents to test and validate the formats and content of the files. You will then need to send back the relevant documents. Tesco’s EDI onboarding team should execute a variety of test cases, covering the specific message types required by your relationship with Tesco.
3. After successful completion of testing, your EDI process will be put into production and your company will be able to enjoy an efficient trading relationship with Tesco.

What EDI standards and document types does Tesco use?

Tesco uses both TRADACOMS and EANCOM standards and requires suppliers to be able to exchange orders, forecasts (product planning reports) and invoices/credit notes, as illustrated below.

Click to enlarge

Setting up EDI with Tesco

Before your business can exchange documents with Tesco, an exchange channel using an EDI protocol must first be established. 

Tesco uses GXS as its EDI provider, meaning a connection to GXS Trading Grid must be established to allow suppliers to exchange messages with the retailer. As ecosio cloud-based EDI solution (our Integration Hub) already offers integration with GXS Trading Grid, one link between your ERP system and our Integration Hub will fulfil all exchange protocol requirements.

Connection timeline

It is tough to determine exactly how long it will take your business to establish a secure EDI connection with Tesco as this will depend entirely on your organisation’s unique situation and how much mapping and routing is required. The simplest and fastest way to achieve a reliable connection is to use an experienced B2B integration partner. A good EDI service provider should be able to provide a dedicated expert to oversee the connection from start to finish, and even handle data monitoring after go-live.

A simple outline of the steps involved in setting up an EDI connection with Tesco can be found below.

How ecosio can help

With ecosio’s help your business could be enjoying a connection in no time!

At ecosio we allow you to concentrate on whatever it is that your business does best by taking care of all routing and mapping for you. All you need to enable your business to exchange messages with Tesco in the correct format and via the required protocol is one connection to the ecosio cloud-based EDI solution (our Integration Hub).

ecosio EDI as Service solution is different to those offered by other EDI service providers as ecosio’s API is embedded directly in the user’s ERP system. As a result of this deep API-ERP connection, visibility is hugely improved, with data processes seamlessly integrated into your ERP’s user interface. 

Benefits at a glance

• All EDI needs met via one connection to the ecosio cloud-based EDI solution (our Integration Hub).
• No EDI expertise needed within your business
• All common EDI formats and protocols supported
• Hassle-free connection of partners 
• Increased data visibility thanks to direct API-ERP integration

Get in touch!

Still have questions about doing EDI with Tesco? Feel free to contact us, we’d love to help!

Der Beitrag Tesco EDI Partner Connection Guide erschien zuerst auf ecosio.

Sainsbury’s at a glance

Having been in existence now for a remarkable 150 years, Sainsbury’s is one of the UK’s largest supermarket chains, reporting over £28 billion in revenue in 2018. While a proposed merger with Asda in 2018 (which would have given the company control of almost a third of the market) was blocked by UK regulators, Sainsbury’s alone holds over a 15% share in the supermarket sector and represents an exciting connection for suppliers.

Setting up an EDI with Sainsbury’s as a supplier

Suppliers interested in doing EDI with Sainsbury’s need to consider all of the following: their onboarding process, which document formats they use and their preferred exchange protocols.

Sainsbury’s supplier onboarding process

1. Sainsbury’s EDI team will work with your EDI supplier to help establish the EDI connection.
   
2. After you have set up the required EDI document mappings, Sainsbury’s will send you test orders which you will be required to send back. Sainsbury’s EDI team will execute various test cases to ensure all possible EDI interactions between your business and Sainsbury’s are covered.
3. After testing has been completed, your new EDI connection will go live and you will be able to exchange messages with Sainsbury’s.

What are Sainsbury’s preferred EDI standards and document types?

The different document types and formats used by Sainsbury’s can be found in the table below (outbound from Sainsbury’s unless specified):

*    Optional
**   If supplier delivers direct to depot
***  If supplier delivers to second tier location, such as a bonded warehouse

Setting up an EDI connection to Sainsbury’s

To enable an exchange of relevant documents with Sainsbury’s via EDI, it is first necessary to set up an exchange channel using an EDI protocol. 

Sainsbury’s uses several different EDI networks. Their EDI setup is such that prospective suppliers have the opportunity to connect via a direct AS2 connection or via multiple VAN providers. ecosio’s cloud-based EDI solution (our Integration Hub) provides a direct AS2 EDI connection to Sainsbury’s, fulfilling all exchange protocol requirements.

Connection timeline

Depending on each organisation’s individual situation and the extent of mapping and routing required, the time it will take to establish a secure EDI connection with Sainsbury’s will vary. The easiest and most effective way to achieve a connection is to use an experienced B2B integration partner. Ideally, they should be able to provide a project manager to ensure the success of the connection from start to finish. Ideally they will also be able to handle monitoring after go-live too.

Below is a brief overview of the stages involved in setting up a connection with Sainsbury’s.

How ecosio can help

Setting up an EDI connection with Sainsbury’s is a simple process with ecosio. 

ecosio’s managed EDI service supports all EDI formats and protocols. We take care of all routing and mapping so you can get on with what you do best! A single connection to ecosio’s cloud-based EDI solution (our Integration Hub) is all that is required to ensure information is automatically exchanged with Sainsbury’s via the correct exchange protocol and in the desired format.

ecosio EDI as a Service solution is different to the managed connections offered by many other providers in that our API is embedded directly in your ERP system. As a result, you benefit from improved visibility, as EDI processes are seamlessly integrated into your system’s user interface. 

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

Benefits at a glance

• All EDI needs met via one connection to our Integration Hub
• No EDI expertise needed within your business
• All common EDI formats and protocols supported
• Hassle-free connection of partners 
• Increased data visibility thanks to direct API-ERP integration

Do you have any questions?

Still have questions about doing EDI with Sainsbury’s? Feel free to contact us, we’d love to help!

Der Beitrag An Introduction to Doing EDI with Sainsbury’s erschien zuerst auf ecosio.

M&S at a glance

For well over a century Marks & Spencer has been a staple of the UK high street. As well as being the first British retailer to make a pre-tax profit exceeding £1 billion in the late 90s, in 2007 M&S was one of the first large retailers to introduce a major sustainability plan. Despite a recent shift in the concentration of their business away from clothing and towards food, M&S remains a giant of the retail world with over 1,400 stores today.

Setting up an EDI connection with Marks & Spencer as a supplier

Suppliers looking to start electronic data interchange (EDI) with Marks & Spencer need to consider the following three important aspects: the onboarding process, document formats and exchange protocols…

M&S supplier onboarding process

1. Marks & Spencer’s EDI team will work with your EDI service provider to help you set up the EDI connection.
2. After the necessary EDI document mappings have been set up on your side, Marks & Spencer will provide you with EDI test orders. You will then need to send back the necessary documents, e.g. order responses and invoices. Marks & Spencer’s onboarding team will also execute various test cases, covering the different aspects of your business relationship to Marks & Spencer, e.g., different types of deliveries.
   
3. After the test phase has been completed successfully, your EDI process will be put into production and your company will start to exchange EDI messages with Marks & Spencer.

What EDI standards and document types does M&S use?

The below table shows the different document types and formats used by M&S:

Setting up the connection with M&S (exchange protocols)

To allow for an exchange of EDI documents with Marks & Spencer, an exchange channel using an EDI protocol must be set up. 

As M&S uses OpenText as its EDI provider, prospective suppliers require a connection to OpenText Business Network to be able to exchange messages. ecosio cloud-based EDI solution (our Integration Hub) already offers integration with OpenText Business Network, meaning a connection from your ERP system to our Integration Hub would fulfil all exchange protocol requirements.

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

Connection timeline

The time needed to complete a connection to Marks & Spencer will depend entirely on your individual situation and the amount and complexity of mapping and routing required. The fastest and most efficient way to establish a connection with M&S is to use an experienced B2B integration partner who is able to provide a dedicated project manager to oversee the connection from first contact to go-live (and even handle monitoring afterwards).

Below is a view of the steps involved in setting up your connection to trade with M&S.

How ecosio can help

ecosio will ensure that setting up an EDI connection with M&S is a fast and hassle-free process. 

As a managed service we support all commonly used, secure EDI protocols and EDI formats – there is no need to worry about document types or formats. With a connection to our Integration Hub messages will automatically be exchanged with M&S over the correct exchange protocol and received by both parties in the necessary format.

Unlike managed connections offered by other providers, ecosio EDI as a Service solution is embedded directly in your ERP system as a native feature. Through the integration of our API in your ERP system, EDI processes are seamlessly integrated into your system’s user interface, enabling end-to-end monitoring. 

Benefits at a glance

• All your EDI requirements met via a central connection to ecosio cloud-based EDI solution (our Integration Hub)
• No special EDI know-how needed within your business
• All commonly used EDI protocols and EDI formats supported
• Worry-free EDI partner connection from first contact to monitoring
• Direct integration in your ERP system, so the delivery status of messages can be viewed via your ERP

Do you have any questions?

Still have questions about setting up an EDI connection with Marks & Spencer? Feel free to contact us, we’d love to help!

Der Beitrag How to Set Up an EDI Connection with M&S 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.

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.

Before we get into looking at DESADV with SSCC in detail, it is first necessary to understand the context. The retail trade has seen substantial changes in recent years. Most small grocery stores have closed down and branches from big retailers dominate the market. The difference between these small grocery stores (also known as convenience stores) and the modern supermarkets from today is, that supermarkets offer a much larger variety of products, which suppliers need to keep restocking.

An old fashioned grocery store

For retailers however this means that the ordering and shipping of goods from the manufacturers to the branches must take place smoothly and efficiently.
Depending on the type of goods, the companies rely on a direct store delivery or warehouse delivery.

Two things are crucial when it comes to deliveries:

• The goods arrival needs to be announced on time to allow correct planning of the inbound logistics for the retailer.
• The announced delivery and the physical delivery need to be clearly assigned.

The first case scenario is supported by the DESADV EDI message type. This EDI message needs to be sent before the goods physically arrive at the warehouse, as it describes the exact structure and content of the delivery.

The second case scenario is supported with identifiers, so called SSCC numbers (Serial Shipping Container Code). This number is fitted on the delivery as a physical, machine readable sticker with a barcode and is also contained in the DESADV message.

This allows the delivery process to the warehouse as illustrated in the image below: On the left side, we can see the goods have arrived in the warehouse and are being distributed to the correct shelves. In case of a cross docking delivery, the storing is bypassed and the goods are to be loaded on another truck right away.

Inbound logistics in a warehouse

Thanks to the supplier’s prior notice, the warehouse employees can plan the shelf space and immediately know where the pallets need to go.

Furthermore the pallets are fitted with the SSCC labels, which the warehouse employees can scan by hand (see illustration below). The employees scan the SSCC numbers and compare them with the data from the DESADV that was sent earlier. This way, they can verify whether the quantity or the structure of the shipment is correct.

A hand scanner being used in a warehouse.

What becomes clear with the above description of the process, is that the cooperation of the suppliers is vital to ensure a smooth running of the logistics. The DESADV messages have to be sent electronically and long enough before the arrival of the goods, and they must contain the SSCC numbers, which are also mentioned in the label of the shipped goods.

SSCC number example

SSCC numbers are used for the clear identification of shipping units.

SSCC numbers are based on a GS1 company prefix, just like most GS1 identification numbers. Other GS1 identification numbers include for instance GLNs and GTINs. A GLN – Global Location Number is a global, unequivocal and non-overlapping identification for a specific business. GTINs (Global Trade Item Number) are used to clearly identify products.

SSCCs have 18 digits and are set up as follows:

• 1 reserve digit
• 7 – 9 digits of the GS1 company prefix
• A consecutive number for the shipping unit. The allowed length depends on the length of the GS1 company prefix.
• A verification number.

Let’s use the ecosio InterCom GmbH GLN 4260304620007 as an example to create a SSCC number. The GS1 company prefix is 426030462:

• Reserve number: 3
• GS1 company prefix: 426030462
• Consecutive number for the shipping unit: 1234567
• Verification number: 8

We now have the SSCC 342603046212345678. This number can be used for the clear identification of the shipping unit. Since it is built using the GS1 company prefix, it is guaranteed that this SSCC will not be used by another company.

Here you can find out more about creating a SSCC number.

SSCC transport label

In order to easily and efficiently process the SSCC number in the logistic chain, it is necessary to display it as a machine readable barcode. The barcode can be captured by an optical reader, thus allowing a complete delivery to be unloaded in the warehouse, without anyone having to manually type any data.

This is exactly what the GS1 transport label is for. Not only does it contain information that the human eye can read, but also machine readable data contained in the barcode. The following picture illustrates the set up of a GS1 transport label:

Set up of a GS1 Transport Label

The label is composed of a header segment, which contains free formatted information about the sender and receiver. The middle segment contains information in clear text, whose size can vary, depending on what it is used for. It must contain the SSCC number. The footer segment only contains the machine readable GS1-128 barcode.

The picture below depicts an example of a transport label. You will find in the middle segment, next to the SSCC number, the GTIN, the production date as well as the lot number. The bottom part contains two barcodes, the first one stands for the GTIN, production date and lot. The second stands for the SSCC number.

Example of a GS1 Label with SSCC

Incorporating the SSCCs on pallets

As the type and structure of the shipping unit can differ, using boxes or pallets for example, so can the incorporation of the SSCC labels. If the label needs to be put on a box whose dimensions are smaller than 1 meter, then you need to follow the instruction sbelow:

Example of a SSCC label on a box

The SSCC label must be present on at least two sides, the distance between the label and the bottom of the box needs to be at least 32 mm and 19mm from the right and left edges. In the logistic trade, boxes are mostly stacked on pallets, these can contain one sort of boxes or mixed boxes.

An unmixed pallet only contains goods which have the same article number, e.g. “gherkins in glass, 250g, GTIN 9001234567896”. The SSCC labels will need to be fitted on the pallet the same way as for the boxes, at least two of them on different sides.

Mixed pallets are pallets on which you will find goods with different article numbers. To allow them to be sorted, sandwich pallets will often be used. This type of stacking might remind one of a classic club sandwich. Tasty!

Club Sandwich

Mixed pallets are mostly used for direct store deliveries. Unmixed pallets and sandwich pallets are predominantly used for warehouse deliveries and in cross docking scenarios.

In a sandwich pallet, every single pallet will have its own SSCC label and the sandwich pallet itself will have a master SSCC label. The master label aggregates the SSCC labels from all the layers. The picture below illustrates this concept:

Example of an SSCC Label on a Sandwich Pallet

As you can see on the left side, each pallet layer has its own SSCC label (Layer SSCC Label). The sandwich pallet is wrapped in a plastic film, thus creating a new and unique shipping unit. The shipping unit as a whole has a Master SSCC label, as seen on the right side of the picture. When the goods arrive at their first unloading point, the warehouse employees will only scan the master SSCC label, since the plastic wrap often makes the scanning of the labels underneath impossible.

If the single pallets are isolated further down the processing line, the employees will then use the layer SSCC labels to clearly identify the layers.

Use of a SSCC in a DESADV

When DESADV messages are used to announce a delivery, the EANCOM Standard defines four different scenarios:

1 – No SSCC and no Shipping Structure

In this scenario only the article numbers and total quantities of the shipping are stated. There is no representation of the shipping structure and no SSCCs are being used. The shipping structure defines which boxes are on which pallets, how many pallets are being sent etc. This type of representation and its content correspond to a basic delivery note on paper.

2 – SSCC per Pallet without Shipping Structure

In this version article numbers and total quantities are given. The packages are also identified with the SSCCs. However, the shipping structure is not described.

3 – SSCC per Pallet with Shipping Structure

This option clearly describes the hierarchy of the shipping structure up to the content of the pallets. The DESADV will contain information about the article numbers and total quantity of the boxes per pallet. Furthermore it will contain the description of the hierarchy of the composition of the delivery (number of pallets, number of boxes per pallet, etc…). Each pallet will be clearly identified thanks to the SSCC. Sandwich pallets will have every layer also identified with their own SSCC.

4 – SSCC per Box and Pallet and with Shipping Structure

In this last option, the hierarchy of the shipping structure is described. Both pallets and boxes have SSCC numbers.

Example of an unmixed pallet

In the case of an unmixed pallet, the packing hierarchy can be described in two levels:

Level 1 = the whole shipping, which corresponds to three euro pallets in the example below.

Level 2 = per single pallet. This level dictates the representation of every single pallet, even if all pallets contain the same articles. The delivered units, usually boxes, are represented with GTINs. In the DESADV, you will find the distinction for the level hierarchy in the CPS segments.

Let us take a look at the three unmixed pallets below as an example. Each pallet has its own SSCC number. You will find different article types in each pallet, packed in individual boxes. The boxes have their own GTINs.

Example of three unmixed pallets

The resulting structure of the DESADV looks as follows (to make it clearer, we will only be showing the relevant CPS segments):

CPS+1'
PAC+3++201'
CPS+2+1'
PAC+1++201'
PCI+33E'
GIN+BJ+342603046212345678'
LIN+1++4260304629994:EN'
QTY+12:10:PCE'
CPS+3+1'
PAC+1++201'
PCI+33E'
GIN+BJ+342603046212345685'
LIN+1++4260304629987:EN'
QTY+12:20:PCE'
CPS+4+1'
PAC+1++201'
PCI+33E'
GIN+BJ+342603046212345692'
LIN+1++4260304629970:EN'
QTY+12:30:PCE'

The meaning of each segment is as follows:

CPS+1'

Corresponds to the highest order level.

PAC+3++201'

Number of packages in the whole delivery (3 euro pallets).

CPS+2+1'

Second hierarchy level (1st pallet). The 1 refers to the shipping. The 2 is the consecutive number of the hierarchy level.

PAC+1++201'

Number of packages in the current hierarchy level ( Pallet 1 = 1 euro pallet).

PCI+33E'

This shows the package is identified with an SSCC.

GIN+BJ+342603046212345678'

The SSCC number from pallet 1.

LIN+1++4260304629994:EN'

The GTIN of the delivered unit in pallet 1 (of the boxes).

CPS+3+1'

Second hierarchy level (2nd pallet). The 1 refers to the shipping. The 3 is the consecutive number of the hierarchy level. The other segments for pallets 2 and 3 are to be read in the same way.

Example of a sandwich pallet

In a sandwich pallet, the articles of the same type are stacked on each other. The single layers are separated by a euro pallet and have their own SSCC number. The whole pallet is then wrapped in plastic film and has its own master SSCC number. This number allows for the different layers underneath to be recognised during the unloading process.

The difference between unmixed and sandwich pallets is that the latter will have to have one more level in their hierarchy. Level 1 and 2 will be the same as for an unmixed pallet, however the master SSCC will be found on level 2. The delivered units are therefore represented in the third level.

Let us have a look at the sandwich pallet below with three levels.

Example of a sandwich pallet

Here is how the DESADV structure would look like:

CPS+1'
PAC+1++201'
CPS+2+1'
PAC+1++201'
MEA+PD+LAY+PCE:3’
PCI+33E'
GIN+BJ+342603046212345104'
CPS+3+2'
PAC+1++201'
PCI+33E'
GIN+BJ+342603046212345692'
LIN+1++4260304629970:EN'
QTY+12:30:PCE'
CPS+4+2'
PAC+1++201'
PCI+33E'
GIN+BJ+342603046212345685'
LIN+1++4260304629987:EN'
QTY+12:20:PCE'
CPS+5+2'
PAC+1++201'
PCI+33E'
GIN+BJ+342603046212345678'
LIN+1++4260304629994:EN'
QTY+12:10:PCE'

Here is what these segments mean:

CPS+1'

Stands for the first level (the actual shipping)

PAC+1++201'

Number of packaging in the whole shipping ( 1 euro pallet)

CPS+2+1'

Second level (the sandwich pallet)

PAC+1++201'

Number of packaging in the current level (1 euro pallet)

MEA+PD+LAY+PCE:3’

Number of layers in the sandwich pallet

PCI+33E'

Indicates a SSCC labeling is present

GIN+BJ+342603046212345104'

The SSCC number of the pallet (=Master SSCC)

CPS+3+2'

Third level for the description of the first layer. It refers to the pallet (with the “`2““)

PAC+1++201'

Number of packages (1 euro pallet)

PCI+33E'

Indicates a SSCC labeling is present

GIN+BJ+342603046212345692'

SSCC from the first layer

LIN+1++4260304629970:EN'

The GTIN from the delivered unit in the first layer

QTY+12:30:PCE'

The number of delivered units in the first layer

CPS+4+2'

Third level describing the second layer. The description for layer 2 and 3 is the same as for layer 1.

Benefits for all involved

Using DESADV messages with SSCC labels can be cumbersome at times, however the use of SSCCs has its advantages for the parties involved. It can help reduce the sending and picking times on the side of the supplier in the warehouse processing. The advanced notice of the delivery and the use of the SSCC allows the retailer to plan their logistics widely and optimise their workload and warehouse capacity.

As soon as the supplier delivers the goods, the unloading and storing can happen much quicker, reducing the time the trucks have to stay. The supplier then has more flexibility when booking time slots for the delivery. The retailer also benefits from the simplified processes when storing the goods. SSCCs can also guarantee transparency by complying with the legislation on products origins and tracing them back.

The automation of receiving goods also has benefits on the following processes, such as product recalls, confirmation of the goods reception etc. The use of DESADV with SSCC makes the suppliers competitive, as they can comply with the expectations of the retailers.

Should you wish to consult your crystal ball to see the future of DESADVs with SSCC in the retail industry, all you need to do is look at the the delivery processes in the automotive industry. The advanced notice of a delivery and the labelling are mandatory, so much so that it is a necessary pre-condition in establishing a partnership between a supplier and a buyer.

Do you have any questions?

You still have questions about DESADV and SSCC, or you need to implement those processes for one of your clients or suppliers? Feel free to contact us, we would love to help you!

Image credits

• An old fashioned grocery store: GNU Free Documentation License, Version 1.2, via Wikimedia Commons
• Club sandwich, Creative Commons CC0 1.0 Universal Public Domain Dedication

Der Beitrag What is a DESADV with SSCC and Why Should I Care? erschien zuerst auf ecosio.

EDIFACT stands for Electronic Data Interchange for Administration, Commerce and Transport and has been in constant development by the United Nations since 1986. This standard is known under the name UN/EDIFACT. Whilst working on standardising the UN/EDIFACT format, numerous requirements from all industries needed consideration. However, although this may have helped broaden the UN/EDIFACT standard and make it more flexible, it also complicated its actual use.

A simple invoice may, for instance, include many optional elements and different identifiers may be used for the identification of the involved companies and products, etc. Before they can create an actual EDIFACT invoice, the sender and receiver need to agree on the subset of segments they will be invoked when exchanging files. If it were the case, that both parties always needed to agree on a specific subset, this would inevitably lead to a huge and unnecessary number of different subsets, and therefore reduce the benefits of EDI through the time needed to make the subsets compliant.

It is therefore advisable to agree on certain standard EDIFACT-subsets. These EDIFACT subsets are derived from the EDIFACT standard and were tailored to suit a specific user group. Mandatory elements are defined according to the EDIFACT subset and additional specifications laid down (e.g. identifiers to use, date formats, code lists, etc.).

These subsets apply to whole industries (e.g. paper, steel or consumer goods industry), including at the corporate level.

The diagram below illustrates the subset approach.

EDIFACT Subsets

Individual subsets based on the UN/EDIFACT standard were defined for different industries. The globally most used EDIFACT subset is EANCOM (abbreviation of EAN + Communication) and GS1 is continuing its development for the consumer goods industry. Other subsets include, for instance, EDIGAS (gas industry) or EDIFICE (high-tech industry).

EANCOM exists today in three different versions (D93A, D96A and D01B). Major companies such as REWE or Metro are also defining their own subsets based on the EANCOM subset.

EANCOM-Subset

EANCOM is being developed by the GS1 organisation for global standards and is a 100% subset of the UN/EDIFACT standard for the consumer goods industry. Since the EANCOM standard is highly popular, it is by now also used in other industries, such as the health sector. As opposed to the very extensive UN/EDIFACT standard, EANCOM reduces the various EDI messages to essential fields that are mandatory to specific business processes or for specific message types. The EANCOM standard currently includes about 50 different message types.

As the name suggests already, the EANCOM standard is based on the GS1 identification system (GLN, GTIN,SSCC, etc.). The use of globally unique GS1 identification allows effective and uniform processing of EDI messages. Every sender and recipient will, for instance, be uniquely identified by it’s GLN – thus excluding confusion caused by proprietary identifiers. The same applies to product identification using GTINs and identification of packages using SSCCs.

EANCOM also defines the logical sequence of messages used in a specific business area. The diagram below illustrates message flows that may be depicted with EANCOM. In addition to buyers and sellers, communication between logistics service providers and banks is also included.

EANCOM – Participating Companies

The individual EANCOM message types may be roughly classified into the following four categories:

• Master data reconciliation
  These message types are used for the exchange of master data for products and for involved trading partners. The master data is therefore stored in the systems of the involved partners and used for message transactions afterwards. This will, for instance, ensure that only the most recent product identifiers and prices will be used.
• Transactions
  These message types are used to order goods, organise their transportation and pay for goods received.
• Reporting and planning
  These message types are used for the exchange of data allowing future planning. Examples include Sales Reports or Inventory Reports, used to communicate current product sales figures to a supplier. The supplier may use this information to plan his own production.
• Miscellaneous
  The message types in this category serve various purposes, such as the exchange of additional information required by the different industries.

Overview of EANCOM message types

The diagram below offers an overview of the most important EANCOM message types and the order of the message exchange.

EANCOM Message sequence

The three most important message types by far are ORDERS (order), DESADV (despatch advice) and INVOIC (invoice).

Price list/Catalogue (PRICAT)

A supplier will send a PRICAT message with a list of all relevant product data to his customers. A supplier will send a PRICAT message to customers whenever the product range changes.

Order (ORDERS)

A customer will transmit an ORDERS message to a supplier to order products and services. An order will typically also include the required quantity, date and place of delivery. The GTIN codes for the ordered products and services and the GLNs used will typically have been received via a previous PRICAT message.

It is also possible to leave out the master data reconciliation using PRICAT, if the parties have exchanged beforehand the lists with the product codes, e.g. on an Excel sheet. However, this might present a few drawbacks, such as input errors due to media faults, etc…

Transport order (IFTMIN)

A supplier will transmit an IFTMIN message to a logistics service provider to order transportation of goods.

Despatch message (DESADV)

Suppliers will send a DESADV message to notify customers of impending deliveries, prior to arrival of the goods at the customer. DESADV messages are particularly relevant to large companies since DESADV messages will allow coordination of their own goods receipt logistics (such as cross-docking warehouses).

Transport status (IFTSTA)

Logistics service providers will use IFTSTA messages to confirm shipment of an order to their client (in this case the supplier). The time of sending this message will be agreed on between the shipping agent and supplier. An IFTSTA message may, for instance, be sent once every day, at the time a shipment is executed, etc.

Arrival message (IFTMAN)

A shipping agent may send an IFTMAN message to the recipient of the goods (in this case the customer) to notify of imminent delivery. Similar to a DESADV, the purpose would be better planning of goods receipt logistic by the customer.

Goods receipt notification (RECADV)

Customers may send a RECADV message to confirm receipt of a specific shipment. This will allow the customer to, for instance, notify the supplier of deviations of quantities supplied or of his rejection of specific shipments.

Invoice (INVOIC)

The supplier may use an INVOIC message to transmit an invoice to his customer.

Banker’s order (PAYMUL)

The customer may use a PAYMUL message to transmit payment instructions to his bank. The bank will on receipt of this message pay the invoice amount to the account of the supplier.

Credit note (CREMUL)

A bank will use a CREMUL message to inform the supplier of payments made by his customer.

Questions?

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

Der Beitrag Overview of the EDIFACT EANCOM format erschien zuerst auf ecosio.