| EANCOM® 2002 S4, Edition 2016 | Part I |
|
|
In terms of future maintenance and processing of new user requirements, work requests will be processed only against the EANCOM® 2002 standard.
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:
|
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. User community is informed about the addition of the new segment when the new EANCOM® edition is published (see 3.2.5). |
|
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®. |
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.
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 http://www.gs1.org/eancom.
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.
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.
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.
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.
|