3.1.1 Policy

In terms of future maintenance and processing of new user requirements, work requests will be processed only against the EANCOM® 2002 standard. 

3.1.2 Processing a Work Request (WR)

When implementing EANCOM®, user companies might find that some business requirements are not met. They might wish to enhance the standard and draft proposals for new codes, data elements, segments or messages, covering their genuine requirements.

The following procedure is applicable when changes or additions to EANCOM® are requested:

1. A Work Request drafted by a user company must be addressed to the GS1 Member Organisation (MO) where the company is registered.

2. All Work Requests must conform to the following criteria before being submitted to the GS1 Member Organisation: 

3. The MO will assess the WR and, if no solution is available within the current EANCOM® manual, enter it into the GS1 Global Standards Management Process (GSMP).

4. The MO will inform the submitter on the GSMP outcome. 

3.1.3 Code List Publication

A new edition of the GS1 EANCOM® 2002 Manual is published every two years. It contains changes made in the standard based on Work Requests processed up to the end of the year preceding the publication, Edition 2016 (published in 2017) contains changes accepted up the end of 2016.

The codes added in periods between the editions are published in the Global Data Dictionary - GDD. The new codes can be added to GDD up to 4 times a year, upon approved Work requests.
The codes added to EANCOM by GS1 are submitted to UN/CEFACT to be included in the next EDIFACT Directory. If the new code is urgently needed by the requestor, GS1 may assign a GS1 Temporary Code, which will be replaced by the final code value assigned by UN/CEFACT.

It is important to note that the GS1 Temporary Codes and the final codes assigned by UN/CEFACT have always different values. Thus, the GS1 Temporary Codes can only be implemented under a bi-lateral agreement among the trading partners, bearing in mind that they will need to be updated.

The GS1 Temporary Codes for which the final EDIFACT value is assigned, will be marked for deletion in the nearest EANCOM edition and physically deleted in the subsequent edition.

The codes assigned by GS1 that are not to be submitted to UN/CEFACT are marked as GS1 Permanent Codes. Their values will not be changed.

Code lists based on UN/ECE Recommendations, such as DE 4053, 6411, 7065 and 8067, contain URL to the website of the Managing Agency. In the ENCOM Edition 2016, the codes coming from the Recommendations have been marked for deletion. In Edition 2018 they will be removed and replaced just by the reference to the UN/ECE website, only the GS1 Temporary Codes will be listed in the EANCOM specification. The aim is to maintain ongoing consistency with the parent code list.

The management of GS1 code lists is explained in detail in the Code List Maintenance Policy, published on GS1 website. 

3.2.1 Publications

The implementation of an EDI project involves many detailed steps. GS1 has published more detailed documents introducing scenarios for each EANCOM® message and guidelines on how they should interact.

Currently available documents can be found on the GS1 website.

3.2.2 EANCOM® Manual

The EANCOM® manual is distributed via the GS1 Member Organisations. Interested companies should contact their local Member Organisation to obtain additional copies of the documentation and further information.

It is important that EANCOM® users are properly identified, to keep them abreast of the evolution of the standard and provide them with all relevant documentation.

3.2.3 EANCOM® and Data Alignment

The effective and efficient use of EANCOM® messages relies on data accuracy.

Parties involved in an EDI transaction must be able to use and interpret data consistently.

Establishment of aligned data between trading partners is the recommended first step in any EANCOM® implementation, as this alignment will greatly increase efficiency and accuracy at later stages in the trading relationship.

The alignment of data between trading partners, and the later use of the GTIN and the GLN provides EANCOM® users with the opportunity to reengineer their processes by removing any data or activities which may be superfluous at certain steps in the supply and data chain.

3.2.4 EANCOM® Translation Tables

One of the first steps to be taken in an EANCOM® implementation is the creation of EANCOM® translation tables, which are used to map application data into the EANCOM® messages.

Such mapping tables act as an intermediate step between the in-house application and the EDI translator software.

While it is possible to create EDI software translation tables which are specific to each trading relationship, this is not recommended since separate translator tables would be required, should you wish to extend your EDI trading links to other parties from other industry sectors.

In order to avoid this potential problem, it is strongly recommended to use a translator table which supports the full EANCOM® message structure.

Such a decision will protect your translator investment, should you wish to extend your EANCOM® links in the future.

3.2.5 Support of Message Versions

A condition for successful implementation of EDI is the stability of the standard used, including the syntax, the messages, the data elements and definition of codes. The shortest period between two versions of EANCOM® messages has been set to two years.

As it is unlikely that all trading partners will migrate to the next version at the same time, it is recommended that users should be able to handle concurrently more than one version of the same message i.e. the latest and preceding versions.