eMessaging
GS1 EANCOM®
GS1 EANCOM provides a standardised and predictable structure for electronic business messages, enabling business partners to communicate business data rapidly, efficiently and accurately, irrespective of their internal hardware or software types.
EANCOM is fully based on the UN/EDIFACT (United Nations Electronic Data Interchange for Administration, Commerce and Transport), which comprises a set of internationally agreed standards, directories and guidelines for the electronic interchange of data.
EANCOM is a detailed implementation guideline of the UN/EDIFACT standard messages. UN/EDIFACT messages are often complex and users may easily misunderstand the principles and original intentions of message's designers. EANCOM guideline is a subset of UN/EDIFACT messages, providing clear definitions, explanations and examples which allow trading partners to exchange commercial documents in a simple, accurate and cost effective manner.
EANCOM also incorporates into the electronic messages, the GS1 standards of physical identification of trade items, logistics units and the Global Location Numbers (GLN's)
identifying the trading partners. It allows to integrate the physical flow of goods with related information sent by electronic means.
Release information
Syntax Version 3 - 2002
The GS1 EANCOM syntax version 3 - 2002 release is based on UN/EDIFACT directory D.01B. This service is provided by GS1 Australia free to those companies wishing to prepare for their Electronic Data Interchange (EDI) migration to GS1 EANCOM 2002.
This implementation guideline is the manual for the GS1 EANCOM syntax version 3 - 2002 release. It is based on UN/EDIFACT directory D.01B, syntax version 3 which was released by UN/CEFACT in 2001. This implementation guideline is developed by GS1 Global and is an integral part of the suite of GS1 supply chain solutions. In this context, the GS1 EANCOM manual should be read in conjunction with the General GS1 Specifications Manual which describes the GS1 numbering and barcoding standards.
Note: To receive a copy of the GS1 EANCOM User Manual, please contact GS1 Australia.
It is important to note that GS1 EANCOM syntax versions 3 and 4 - 2002 release replaces the GS1 EANCOM syntax version 3 - 1997 release which was based on UN/EDIFACT directory D.96A. Therefore, at the time of publication of this implementation guideline, the GS1 EANCOM syntax versions 3 and 4 - 2002 release becomes the GS1 EANCOM standard.
In terms of future maintenance and processing of new user requirements, change requests will be processed only against EANCOM syntax versions 3 and 4 - 2002 release.
For a copy of the GS1 EANCOM implementation guideline please contact GS1 Australia's Standards Department on 1300 366 033.
For implementation assistance ask for Marcel Sieira, Manager Business Development.
Structure and segment changes (GS1 EANCOM 97 to GS1 EANCOM 2002)
As industry verticals move towards GS1 EANCOM 2002 based Message Implementation Guidelines (MIGs), it is important to identify all relevant changes.
These documents detail changes relating to message structure and message segments from GS1 EANCOM 97 to GS1 EANCOM 2002.
Downloads
Segments changed
download
[format: pdf - date: April 2005 - size: 64kb]
Structure changed
download
[format: pdf - date: April 2005 - size: 16kb]
New codes for GS1 EANCOM 2002
The file below contains approved Change Requests (CR) for GS1 EANCOM 2002 since its release. This file should be used in conjunction with your copies of EANCOM 2002. If searching for a particular code, it means that this is another document to check before requesting a CR.
Downloads
EANCOM 2002 approved change requests
download
[format: xls - date: August 2006 - size: 83kb]
Australian Best Practice
In GS1 EANCOM B2B implementation it is possible to send multiple messages per single interchange. This means one interchange, may contain multiple messages sent to a single recipient.
Based on industry user poll, the feedback showed the following are the preferred options when implementing GS1 EANCOM in the GS1 Australia community.
Implementers may adopt either option.
- Option A (single message per interchange)
e.g. one interchange with one invoice. - Option B (multiple same type messages per interchange)
e.g. one interchange with three invoices.
The practice of (multiple different messages per interchange) is not recommended.

