Return to Table of Contents

Code lists are the standardised lists of values allowed at the given location of the GS1 EDI message. GS1 uses values from two types of sources:

• Code lists defined and maintained outside of GS1 - by external organisations (agencies)
• Code lists defined and maintained by GS1

Note: The details of GS1 EDI code list maintenance in GS1 can be found in the following document: Code List Maintenance Policy.

Code lists defined and maintained outside of GS1

Most code lists used in GS1 GS1 EDI standards are defined and maintained outside the GS1 community, usually by other standard bodies, e.g. Country Codes, ISO 3166-1:1997. GS1 uses international standard code lists whenever available in the following order of priority:

• ISO
• UN/ECE
• UN/CEFACT
• International Vertical Organisations, e.g. World Customs Organisation
• Codes created by GS1

If a suitable code list exists at a higher level, a code list from a lower level is not used. For example, if there are a suitable code lists managed by ISO and UN/ECE, the ISO list will be used in the GS1 XML 3.x

Regional standards, such as CEN and ANSI, are not used except for purely regional standards and extensions.

The re-use of existing standard lists allows implementers of GS1 standards avoid mapping of different code values from different code lists representing the same information.

GS1 subsets of code lists

Based on the user requirement, GS1 can create a code list that is a subset of the managing agency’s list. It ensures interoperability for trading partners by adopting the list of values from the managing agency, while limiting the list to values needed to support the specific business requirements of the GS1 community.

Example

The UN/EDIFACT code list: 4221 “Discrepancy nature identification code” has been restricted to three values relevant for the GS1 users. The list has been named ‘RemainingQuantityStatusCode’ and is published in the BMS eCom Common Library.

GS1 extensions of code lists

Whenever a value needed by the GS1 users is missing in a non-GS1 code list, it can be added as a “GS1 Code”. In parallel GS1 will submit a request to the managing agency to formally add the code value to the original list.

This approach allows extensibility of existing Agency Code Lists, enabling trading partners to use GS1-developed codes when needed.

Example

The UN/ECE code list: ‘PackageLevelCode’ (see: BMS eCom Common Library) has been extended by adding one GS1 value “1E Highest (GS1 Code)”.

Note 1: GS1 assigns a temporary code value that will be changed by the managing agency once the code is approved as a formal addition to the original code list. Thus, the early implementers should be aware that the code value will change over time.

Note 2: In some exceptional cases, GS1 may assign codes that are not submitted to the managing agency. They will be flagged and ‘GS1 permanent Code’. Such flag will also be used if the managing agency refuses to add the new code value and there is a clear requirement from GS1 users to add this value.

Restricted list of code lists

This is a type of code list where each value identifies a code list that can be referenced for the list of values. Trading partners are expected to mutually agree which list will be used, then select and send the code list value that matches the business requirement.

This approach provides flexibility for trading partners to select the code list appropriate to their usage, while also restricting the list to those that have been identified as valid options to support a specific context.

Example

A Colour Code List with values such as “1” representing the “National Retail Federation (NRF) – Standard Colour & Size Codes”; “2” representing the “Pantone Matching System”.

If the restricted list selected by trading partners is the “National Retail Federation Standard Colour Code List”, and the manufacturer wants to send a colour code that represents “dark blue”, they could send the code value of “401” (the NRF 3-digit numeric code for dark blue).

Bilaterally defined code lists

These code lists should be mutually agreed between trading partners, because GS1 does not specify the code list to be used. They are typically used when there are multiple code lists that could be implemented depending on the industry, geopolitical region, e.g. regulatory or tax codes.

It provides flexibility for trading partners to mutually define the code list appropriate to their usage.

Example

These lists are defined as the ‘CodeType’ containing a number of optional attributes that allow provide the code list properties necessary to fully identify the list used.

The ‘CodeType’ structure

Code lists defined and maintained within GS1

GS1 develops its own code lists only if no suitable international standard exists. Whenever possible, the international standard code lists are used.

Example

The ‘BarCodeTypeCode’ published in the BMS Shared Common Library.

Storing of code list values

Most code lists values are stored outside of the XML schemas. Thus, the user needs to look up the permissible values in the BMS documentation or the GS1 Global Data Dictionary (GDD).

This approach allows decoupling the code list management from the schema versioning – the values can be added between schema releases. It increases speed of implementation for messages where only a code addition is needed.

Code list values are enumerated in the schema only if all the following criteria are met:

• Values are “Intrinsic” to the message – essential  to the processing of the message (e.g. type of invoice) and not reused by any other messages
• Code lists are immutable – not capable of or susceptible to change
• Code lists have manageable size – under 50 values

The code lists whose values are enumerated within the XML schema are referred to as “enumerations”.

Example

The “Day of the Week Enumeration” or “Document Status Enumeration” published in the BMS Shared Common Library.

Code list versioning

The code lists not enumerated in the schema can be updated when needed, which means that new values requested by the users are added as soon as they are approved. 

Each revision will be identified with a sequential number, starting from r1, the next one will be r2, r3 and so on. The publication date will be included in the header data of each code list.

Example