EANCOM® 2002 Syntax Version 3 - IMPLEMENTATION OF EANCOM® -

EANCOM^® 2002 S3, Edition 2008	Part I
	IMPLEMENTATION OF EANCOM^®

Language select:

3.0 MAINTENANCE AND IMPLEMENTATION OF EANCOM^®

3.1 Maintenance Aspects

3.1.1 Policy

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

3.1.2 Processing a Change Request (CR)

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:

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

All change requests must conform to the following criteria before being submitted to the GS1 Member Organisation:

Type of change	Requirements
Addition of new segment.	Identification of the message and the position within the message where the segment is to be added. Changes requesting the addition of new segments to an EANCOM^® message MUST be supported by a proposal as to the data elements required in the segment and their statuses, as well as the code values required for use with the data elements.
Addition of a new code value to the code list for use in all messages.	Identification of the data element for which the code is to be added and the segment in which the code is proposed for use. Changes requesting the addition of new codes to EANCOM^® (i.e., ones that do not exist in the currently used UN/EDIFACT directory) MUST be supported by a clear definition of the code. Under no circumstances will a code with a definition of ‘self explanatory’ be accepted for inclusion in EANCOM^®.
Addition of a new code value to the code list for use in a specific segment within a specific message.	Identification of the message, segment, and data element in which the change applies. Changes requesting the addition of new codes to EANCOM^® (i.e., ones that do not exist in the currently used UN/EDIFACT directory) MUST be supported by a clear definition of the code. Under no circumstances will a code with a definition of ‘self explanatory’ be accepted for inclusion in EANCOM^®.

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

The MO will inform the submitter on the GSMP outcome.

3.1.3 Yearly Code Lists

Annually a new version of the EANCOM^® 2002 codes list will be issued, reflecting changes to codes as the result of successfully processed change requests. These new versions do not constitute an integral part of the EANCOM^® 2002 standard. As a matter of fact, accepted change requests that cover additional business functionality can only be implemented under a bi-lateral agreement among the trading partners. It must be clearly stated in the interchange contract that the additional functionality is agreed to be used as an add-on to the functionality provided in the EANCOM^® 2002 standard.

3.2 Implementation Aspects

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 under "Products & Solutions > eCom > EANCOM > Implementation" at www.gs1.org.

3.2.2 EANCOM^® Manual

The EANCOM^® manual is distributed via the GS1 Member Organisations. Interested companies should contact their national 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. The 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.

2008-10-01