PART I :

EANCOM PART I : EANCOM & EDIFACT

3. IMPLEMENTATION OF EANCOM

The implementation of an EDI project involves many detailed steps. These steps, along with helpful advice, are documented in an EAN International publication called 'An Introduction to EDI'. In addition to the basic EDI introduction, EAN International has published more detailed documents introducing scenarios for each EANCOM message and guidelines on how they should interact. Currently available in this series are the documents ‘An Introduction to EANCOM in Trade and Transport’ and ‘An Introduction to EANCOM in Trade and Finance’.

These publications, which are all available from all EAN Numbering Organisations, are ideal documents to explain EDI and EANCOM in simple to understand language and may be used and understood by people at all levels in your company.

3.1 EANCOM manual

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

It is important that EANCOM users are properly identified so that they can be informed on a continuous basis about the evolution of the standard and get all relevant documentation.

3.2 Message versions

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

User companies are asked to migrate from one version to the new one as soon as possible and not later than one year after the publication of a new version.

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

3.3 Codes list

The EANCOM codes list will be issued annually and will contain codes added as a result of successful change requests.

3.4 Change requests

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. These requirements must be stated clearly and supported by coherent business reasons to support the acceptance of the requested change.

It should be noted that change requests to EANCOM will only be considered when made against the current published version (no maintenance of previous versions).

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 Numbering Organisation where the company is registered. It is recommended, for administration purposes, that each change request be uniquely numbered by the requesting party. When reporting back the status of any individual change request the secretariat will always quote the requesting party’s change request identity number.
All change requests must conform to the following criteria before being submitted to the Numbering 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 status's, and 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 against 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 D.96A 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 D.96A 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.

All change requests. MUST be supported by business justifications explaining the concept of the change and how the acceptance of the change request will facilitate this business justification.

The Numbering Organisation will acknowledge receipt and make an initial assessment of the request.
If it has not been resolved, the change request will be forwarded, in a typed format, by the Numbering Organisation to the EAN secretariat where it will be registered and classified.
As a matter of course, requests for change can be addressed directly by Numbering Organisations.
Change requests must be submitted by numbering organisations to, and received by the EAN secretariat, at least 30 days before a meeting of the Communication Systems Committee (CSC) to ensure that they are processed at the next CSC meeting.
The EAN secretariat will submit the change request to the Communication Systems Committee. Incomplete or not properly documented change requests (see points 2, 3, and 4 above) will be returned to the originator.
The Communication Systems Committee will accept or reject the request, or ask for more information. Accepted changes will be consolidated and incorporated in the next release of the EANCOM manual or the codes list. There will be no interim release of the manual to incorporate accepted change requests. Users may, bi-laterally agree to include the functionality of an accepted change request into their EANCOM procedures as soon as the change request is accepted by the Communication Systems Committee.
The EAN secretariat will advise the Numbering Organisation of the decision of the committee and a justification of that decision.
The issuer of the change request will be informed by the Numbering Organisation about its status within a maximum of twelve weeks of the request being received by EAN.

The change request form follows. Please make copies of the
original provided.

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 status's, and 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 against 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 D.96A 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 D.96A 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.
All change requests.	MUST be supported by business justifications explaining the concept of the change and how the acceptance of the change request will facilitate this business justification.