Release 9.0, Approved, Feb 2020
GS1 System Architecture Document
How GS1 standards fit together
- 1 Introduction
- 2 Overview of the GS1 System Architecture
- 3 General considerations
- 4 Identify – GS1 identification keys
- 5 Capture – Physical data carriers and data capture infrastructure
- 6 Share – Business data and communication
- 7 GS1 Services
- 8 Glossary
- A Summary of GS1 standards: Identify, Capture & Share
- B Summary of GS1 application standards & solutions
- Change Log
Contents
- 2.1 The role of standards
- 2.2 Open value networks
- 2.3 GS1 standards: Identify, Capture, Share
- 2.4 Digital value networks
- 3.1 Standards, guidelines, data services, so...
- 3.2 GS1 System Architecture vs. End user sys...
- 3.3 Scope of standards
- 3.4 Consistency across data standards – the ...
- 4.1 Data modelling terms
- 4.2 GS1 identification keys, key qualifiers,...
- 4.3 Classes of GS1 identification keys
- 4.4 Identifier Syntax: Plain, GS1 element st...
- 5.1 Data capture architecture
- 5.2 Data carrier independence of data
- 5.3 Translation of data during physical data...
- 5.4 Data capture infrastructure standards
- 6.1 Content of standardised business data
- 6.2 Communication of business data
- 6.3 Data and service discovery
- 6.4 Worldwide federation
- 6.5 Layering of interface standards – Conten...
Legacy standard
You are viewing a standard that has since been updated. View the current standard.
1 Introduction
This document defines and describes the architecture of the GS1 system of standards. The GS1 system is the collection of standards, guidelines, solutions, and services created by the GS1 community.
The primary audience for the GS1 System Architecture includes end users, solution providers, GS1 Member Organisations, and others engaged in the definition and implementation of the GS1 system.
This document has several aims:
■ To introduce each of the components that are part of the GS1 system and to show how they are related. It also shows the relation between GS1 standard components and standards published by other organisations such as ISO, UN/CEFACT or W3C.
■ To explain the underlying technical foundations that guide the design of individual standards and service components within the GS1 system.
■ To provide architectural guidance to end users and solution providers who want to use the GS1 system and to set expectations as to how these elements function.
Other resources provide the technical details required to implement the GS1 system. Specifically:
■ Individual data, software and hardware interfaces, as well as their use in open value network applications. These interfaces are defined by GS1 standards developed by the GS1 Community through the Global Standards Management Process (GSMP).
■ Hardware and software components that implement GS1 standards. Implementers are free to innovate in the design of components, so long as they implement the interface between components in accordance with GS1 Standards.
■ GS1 Data Services that are operated and deployed by GS1 itself, by other organisations to which GS1 delegates responsibility or by third parties.
Many parts of the GS1 system are well-established and covered by GS1 standards. Other parts of the GS1 system are evolving to meet needs that are determined by industry-prioritised use cases. For those elements of the system that are evolving, architectural analysis may be underway within the GS1 Architecture Group for the purpose of ensuring that the GS1 system remains cohesive.
This document identifies which parts of the GS1 system are well-established architecturally and which parts are expected in the near future.
2 Overview of the GS1 System Architecture
2.1 The role of standards
2.2 Open value networks
2.3 GS1 standards: Identify, Capture, Share
2.4 Digital value networks
The GS1 system is based on globally unique identification and digital information. GS1 standards have the following objectives:
■ To facilitate interoperability in open value networks
Parties exchanging information must have agreement on the structure, meaning and mechanism of data exchange. The GS1 system includes standards for physical data carriers (i.e., barcodes and RFID tags), data standards (e.g. application identifiers) and information exchange standards (e.g. Electronic Data Interchange).
■ To foster the existence of a competitive marketplace for interoperable system components
GS1 standards define interfaces between system components that may be produced by different vendors or by different organisations’ in-house development teams. This enables choice and leads to economies of scale that reduces costs for end users.
■ To encourage innovation
GS1 standards define interfaces. Interface standards ensure interoperability between competing systems. By building upon a standard foundation, implementers can have greater confidence in the eventual adoption of their products and systems and, therefore, increased confidence to invest in innovation.
A value network is a set of parties who are involved in business relationships with one another. In many cases, value networks are concerned with the trade of physical objects such as products, parts, raw materials or digital objects such as music downloads, video-on-demand, data services, and so on.
An open value network is one where the complete set of trading partners is not known in advance and changes over time and where, to a certain degree, trading partners are interchangeable. This has great significance for the architecture and design of information systems. Interfaces between different system components form the basis of interoperability. In a value network, the most important interfaces are those that exist between different organisations.
Figure 2‑1 Open value network
The open nature of value network interfaces manifests itself in two ways, as illustrated in the above figure.
Firstly, an interface may exist between two companies that do not have a direct business relationship. For example, a manufacturer may mark a product with machine-readable data in a barcode, the product may then be sold to retailers through distributors. In this case, the barcode can be read by all retailers who receive the product (because of the use of a common standard). In this example, the barcode is an interface between the manufacturer and the retailers, but the manufacturer’s only direct business relationship is with their distributors.
Secondly, a company may find over time that it needs to extend an existing interface to communicate data to new companies. For example, suppose that Companies A and B are in a trading relationship and utilise an electronic interface for exchanging purchase order and invoicing information. Companies C and D are in a similar relationship. Sometime later, Company A may find that it needs to trade with Company D, and likewise C may find that it needs to trade with B. The fact that all four companies already use common data interface standards enables Company A to use the identical interfaces and supporting information systems to trade with D as it does to trade with B, and likewise for C as it trades with B and D.
To ensure that standards are broadly adopted, interface definitions need to be negotiated and implemented outside the context of any trading relationship. Then, they need to be adhered to by all parties to ensure interoperability. For a standard to be adopted broadly, it must enable interoperability and be maximally applicable to a broad range of business contexts. These are precisely the foundation that underlie GS1 standards.
GS1 standards support the information needs of end users that interact with each other in value networks. The subjects of such information are the entities that are part of those business processes. Entities include things traded between companies, such as products, raw materials, packaging, and so on; equipment needed to carry out the business processes such as containers, transport, machinery; physical locations where business processes are carried out; legal entities such as companies; service relationships; business transactions and documents; and others.
Entities may exist in the physical world (such entities are generically called physical objects in this document) or may be digital or conceptual. Examples of physical objects include a consumer electronics product, a transport container, and a manufacturing site (location entity). Examples of digital objects include an electronic music download, an eBook, and an electronic coupon. Examples of conceptual entities include a trade item class, a product category and a legal entity.
GS1 standards may be divided into the following groups, according to their role in supporting information needs related to entities in value network business processes:
■ Identification Standards: These provide the means to Identify entities so that electronic information may be stored and/or communicated about them among end users. GS1 identification keys and key qualifiers may be used by an information system to refer unambiguously to an entity such as a trade item, logistics unit, physical location, document or service relationship.
■ Capture Standards: These provide the means to automatically Capture data that is carried directly on physical objects, bridging the world of physical things and the world of electronic information. GS1 data capture standards currently include specifications for barcode and radio-frequency identification (RFID) data carriers. Capture standards also specify consistent interfaces to readers, printers, and other hardware and software components that read the content of data carriers and connect this data to relevant business applications. The industry term Automatic Identification and Data Capture (AIDC) is sometimes used to refer to the standards in this group, though in the GS1 System Architecture a clear distinction is maintained between identification and data capture because not all identification is automated and not all data capture is identification.
■ Share Standards: These standards provide the means to Share information, both between organisations and internally, providing the foundation for electronic business transactions, electronic visibility of the physical and digital world, and other applications. GS1 standards for information sharing include standards for master data, business transaction data, and visibility event data, as well as communication standards for sharing this data between applications and trading partners. Other information sharing standards include discovery standards, which help locate where relevant data resides across a network.
While GS1 standards may be used in any combination, the “Identify, Capture, Share” paradigm is pervasive in situations where GS1 standards apply, and most business applications employ GS1 standards from all three groups.
For example, consider the business processes that support the retail sale of consumer goods. GS1 standards are commonly used as follows:
■ Identify: Each class of trade item is assigned a Global Trade Item Number (GTIN) following GS1 identification standards. Because of this, any retailer is assured of having a unique way to refer to a given trade item in its information systems, regardless of which trade items it chooses to carry. Each product brand owner need only assign a single identifier to its trade item for use globally.
■ Capture: Each trade item carries its GTIN directly on the product package using a barcode that complies with GS1 barcode standards, possibly also using a GS1-compliant RFID tag. Data capture infrastructure is used to automatically record trade items as they move through the value network, from shipping to receipt to point-of-sale.
■ Share: Brand owners may share product master data with retailers through GS1 master data standards. GS1 Electronic Data Interchange (EDI) standards may be used by the retailer to reorder products from the manufacturer when supplies run low. GS1 visibility event data standards may be used to provide detailed information about the movements of goods, such as what products entered and exited each store.
The relationship between GS1 standards for identification, capture, and share is depicted below.
Figure 2‑2 Identify, Capture and Share relationship
The key relationships are as follows:
■ Both capture and share standards make use of unique identifiers for entities. There is a dependency between the capture/share standards and the identification standards.
■ Where an entity exists in the physical world, physical data carriers are used to bridge the physical and digital worlds. In such situations, GS1 capture standards come into play, and sit between the identification standards and the sharing standards.
■ There are other situations in which identification is used directly by sharing standards without any physical data capture. For example, master data describing a trade item may be shared between trading partners without any physical product having been produced yet.
Within each broad category of standards for identification, capture, and share, there are many individual standards that may be classified into subcategories. The following figure illustrates all GS1 standards and how they fit into this taxonomy. They are discussed at greater length in the following sections.
Figure 2‑3 Visual representation of the Identify, Capture and Share layers
The central idea of a digital value network is that all information exchange is carried out electronically, through network pathways that effectively parallel the physical path taken by goods. In a fully realised digital value network, physical objects carry only a globally unique GS1 identification key and all other information is communicated digitally, using the unique identifiers to link the information to the physical objects. Changes in information needs may be accommodated without the need to re-engineer the business processes for marking and scanning physical objects. The use of global standards facilitates the rapid integration of new partners into the overall open value network.
The digital value network is based on the following principles:
■ Globally unique identification: All objects of interest in the value network should be identified with a globally unique identifier at the lowest level.
■ Affixing as few data carriers as possible: If an object is physically handled, ideally only one physical data carrier should be affixed to carry the object’s unique identification and no other information.
■ Use master data to carry object attributes: All relevant descriptive attributes of an object should be carried in master data associated with the object’s unique identification and communicated between parties using synchronisation or other means.
■ Use common data definitions in business documents, internal and external: Business data exchanged between applications within a company and between companies should refer to objects using their unique identification. Descriptive information about those objects needed to process the data may then be obtained through master data.
This approach is directly supported by GS1 standards for Identification, Capture, and Sharing.
3 General considerations
3.1 Standards, guidelines, data services, solutions
3.2 GS1 System Architecture vs. End user system architecture
3.3 Scope of standards
3.4 Consistency across data standards – the Global Data Dictionary
There are four types of artefacts that make up the GS1 system:
■ GS1 standard: Normative specifications and rules agreed, per due process, by industry and GS1 Member Organisations to meet a business need of the GS1 community. Standards contain normative statements and are written in such a way that conformance to the normative statements is sufficient for a system component to achieve the interoperability or other goals for which the standard is designed.
■ GS1 guideline: Document that provides information considered useful in implementing one or more GS1 standards. A GS1 guideline never provides additional normative content beyond the standards to which it refers. GS1 standards typically focus on “what” a system component is or must do, whereas GS1 guidelines may provide additional suggestions for “how” such a component may be implemented. GS1 guidelines may be general in nature or may be specific to a limited number of use cases or industries.
■ GS1 service: GS1 standards-based tool and/or capability (e.g., software, training) offered to Industry (by Global Office via GS1 Member Organisations or by Member Organisations themselves) to address a specific business need. For example, GEPIR is a lookup service coordinated by the GS1 GO that provides all end users with the ability to look up information about GS1 identification keys.
■ GS1 solution: GS1 offering to Industry (by Global Office via GS1 Member Organisations or by Member Organisations themselves) that combines GS1 standards, services, guidelines, and/or other activities to address a specific business need. An example of a GS1 solution is GS1 traceability which includes standards, data services, trainings, certification, guidelines, etc.
GS1 standards may be further distinguished according to the type of normative content they contain, as follows:
■ Technical standards: A technical standard is one that defines a set of behaviours for a system component. Technical standards focus on “what” a system component must be or do to be in conformance with the standard. Technical standards may define standardised data models and/or standardised interfaces for the exchange of data. Technical standards are typically written to be as broadly applicable as possible across business sectors and geographic regions.
■ Application standards: An application standard is one that specifies a set of technical standards to which end user systems must conform to support a particular business process application. Application standards provide a convenient way for different end users to express their agreement to follow certain standards, in order to achieve mutually agreed interoperability goals in a given application context.
The following diagram illustrates how systems deployed by end users make use of GS1 system artefacts.
Figure 3‑1 Use of GS1 standard components in End user systems
The GS1 system is a collection of interrelated standards, guidelines, services, and solutions. End users deploy systems that make use of elements of the GS1 system. Each end user will have a system architecture for their deployment that includes various hardware and software components. These components may use GS1 standards to communicate with each other and with external systems. They may also make use of GS1 data services to support certain tasks. An end user’s system architecture may also use alternative or additional standards, including data and interfaces beyond those governed by GS1 standards.
The GS1 System Architecture is a conceptual model of the GS1 system. It does not define a system architecture that end users must implement, nor does it dictate hardware or software components an end user must deploy. GS1 standards only define data and interfaces that the end user’s components may implement. An end user system architecture may need to employ only a subset of the GS1 standards and GS1 services. The mapping between hardware and software components depicted in this document and actual hardware or software components deployed by an end user may not necessarily be one-to-one. The roles depicted in this document may be carried out by end user system components that may have additional responsibilities outside the scope of the GS1 System Architecture.
To the greatest extent possible, the components of the GS1 system are designed to be broadly applicable across all industry sectors and geographical regions. However, there are often needs that exist only within a sector. A similar pattern sometimes arises among smaller groups of trading partners within an industry and even among the divisions of a single company.
This leads to a hierarchy of standards, illustrated below:
Figure 3‑2 Scope of standards
The hierarchy is as follows:
■ Global, cross-sector: At the core of any implementation are the components of the GS1 system that have broad applicability across industry sectors and geographical regions. Most of the GS1 technical standards fall into this foundational layer. Some GS1 Application Standards are global and cross-sector.
■ Sector / Regional: An industry sector may develop GS1 Application Standards for use within that industry and/or region. There are also certain GS1 data standards that are sector specific. Sector-specific standards apply to all geographical regions and are developed globally via GSMP.
Regional requirements may be addressed via GS1 Application Standards or by other normative documents created by GS1 Member Organisations to serve their respective geographical regions. Such documents may also be sector-specific, or they may be cross-sector.
Both sector and regional standards should always be designed to be used seamlessly with the global standards. It is essential that users who do not use sector or regional standards are not disrupted by others’ use of them.
■ Trading group: A trading group within an industry sector or region may establish specific rules for use among themselves, building upon the GS1 system. Such rules may be developed outside of GS1, but can reference GS1 standards, guidelines and/or services.
■ Company: Individual companies are encouraged to develop their own internal architectural standards to drive the consistent use of GS1 standards across the enterprise.
Great care must be taken so that sector, regional, trading group, or company standards do not inadvertently create problems. A sector, regional, or trading group standard can create problems if some companies find themselves having to operate within two or more such sectors, regions, or trading groups that have mutually incompatible requirements. Ideally, requirements are pushed to the global level (and into global standards) whenever possible.
Many GS1 standards include normative definitions of data. These include definitions of individual data elements, definitions of “documents” comprised of many individual data elements, and definitions of messages that are exchanged between system components.
Each GS1 standard that defines data is designed to be self-contained and so includes a normative definition of each data element; however, many data elements recur across different GS1 standards and so some means of achieving consistency is required. The GS1 Global Data Dictionary (GDD) is intended to serve this purpose.
The GDD is a compendium of the data elements defined across all GS1 standards. The GDD is not itself a GS1 standard, but rather is a tool that helps to ensure consistency across all GS1 standards. It provides definitions for each distinct data element that may occur across several standards.
The current state of the GDD is not comprehensive nor fully up to date. GS1 is working on a plan to provide a Web GDD with the goal to arrive at a true “Single Semantic Model”. This approach will ensure full interoperability between implementations of different standards because they will all be based on the same definitions and process models.
4 Identify – GS1 identification keys
4.1 Data modelling terms
4.2 GS1 identification keys, key qualifiers, and supplementary data
4.3 Classes of GS1 identification keys
4.4 Identifier Syntax: Plain, GS1 element string, EPC URI, GS1 Digital Link URI
This section defines common data modelling terms that apply to GS1 standards for identification.
4.1.1 Entities
An entity is something that is the subject of information in an information system. An entity may be:
■ Physical: A physical object to which a data carrier (barcode or RFID tag) may be physically affixed.
■ Digital: An artefact that exists in information systems and which has a recognisable lifecycle. Examples include a music download, an eBook and a digital coupon.
■ Abstract: A virtual object or process, including legal abstractions (e.g., a party), business abstractions (e.g., a class of trade item), intangible items which forms part of a trading relationship (e.g., repair of an item or a haircut).
4.1.2 Attributes
Information systems are concerned with associating information with entities. The items of associated information are called attributes.
■ Attribute: A piece of information associated with an entity. Something can be recognised as an attribute if one can construct a sentence of the following form: “The [attribute name] of [entity] is [attribute value].”
Attributes can be classified based on how frequently they change.
■ Static attribute: An attribute whose value does not change over the life of the entity. E.g., the load capacity of a specific forklift.
■ Dynamic attribute: An attribute whose value changes frequently over the life of the entity. E.g., the price of a product.
4.1.3 Keys
Information systems refer to an entity by means of a key.
■ Key: An attribute or group of attributes of an entity that serves to uniquely identify that entity. An information system uses a key as a proxy for the entity itself.
Often a single attribute is usable as a key, but sometimes a group of attributes is required. In data modelling terminology, these are called simple keys and compound keys, respectively.
■ Simple key: A single attribute that serves as a key. (E.g., a Global Service Relation Number assigned by a hospital to a patient).
■ Compound key: Two or more attributes that together serve as a key. (E.g., the combination of a GTIN and serial number identifies an individual instance of a trade item).
In order to be usable as a key, an attribute or set of attributes must have certain properties:
■ Uniqueness: A given key value corresponds to one and only one entity within the specified domain; two different entities within the specified domain must have different values of their keys.
■ Completeness: There exists a key value for every entity within the specified domain.
■ Persistence: The same key value denotes a given entity throughout the entity's life, including its representation in digital form.
4.1.4 Terms relating to construction of keys
In many applications, and in the case of GS1 identification, keys are designed specifically for the purpose of being a key. When developing GS1 identification keys, some design considerations apply:
■ Syntax: Common syntax rules include a choice of character set, limits on length, specifying fixed or variable length, having a grammar that supports a hierarchical structure.
■ Capacity: The uniqueness and completeness requirements for being a key are affected by the capacity that is implied by the syntax rules.
■ Assignment methodology: Keys can be assigned centrally from one single coordinating body or in a distributed manner. When intended to be assigned in a distributed manner, a hierarchical structure is often used, where some portion of the key is assigned by a central party and the assignment of the remainder is delegated to other parties, who may in turn delegate a portion of their portion, etc. This is the way GS1 has organised the assignment of GS1 identification keys, in a three-level hierarchy: GS1 Global Office, GS1 Member Organisation, GS1 licensee.
■ Resolution: The ability to locate data related to a specific value of a key, or at least to determine an entry point to locate such data.
■ Non-significance: A key is non-significant to the extent that it does not embed business information about the entity it identifies; such information is instead associated with the key.
The goal of GS1 data standards can be understood as defining standardised attributes for entities, including standardised attributes that may be used as keys to refer to specific entities.
■ GS1 identification key and key qualifiers: The term “GS1 identification key” refers to those identifiers which are simple keys (GTIN, SSCC, etc.), and “key qualifier” refers to additional attributes that are designated for use as part of a compound key (e.g., GTIN + serial number is a compound key, with the serial number being a key qualifier for the GTIN).
■ Supplementary data: Attributes of entities defined by GS1 standards, other than GS1 identification keys and key qualifiers, which are capable of being directly affixed to an entity using a GS1 data carrier, e.g. best before date. While these are architecturally part of the Share layer, the Capture layer defines the syntax for including them in GS1 data carriers.
■ Other business data: Any data element that is not an identification key or key qualifier, e.g. product description. These are part of the Share layer of the GS1 System Architecture.
GS1 identification keys, key qualifiers and supplementary data are themselves identified using GS1 Application Identifiers (AIs). An AI is a short string (2, 3, or 4 characters) that identifies the data element, its brevity is particularly suited to identifying data elements when encoded into GS1 physical data carriers.
The following table summarises the GS1 identification keys in relation to the definitions in Section 4.1.3. The “candidate key” column in the table below indicates what combination of GS1 identification keys and other data elements may serve as a “key” (in the data modelling sense) for the entity listed in the first column.
Table 4‑1 Entities identified by GS1 identification keys and candidate keys
Entity | Physical / Digital / Abstract | Candidate key |
Trade item class | Abstract | GTIN |
Trade item batch or lot | Abstract | GTIN + AI 10 (Batch or lot number) |
Trade item instance | Physical or Digital | GTIN + AI 21 (Serial number) |
Individual trade item piece | Abstract | ITIP |
Logistic unit | Physical | SSCC |
Legal entity (Party) | Abstract | GLN (AI 417, Party GLN) |
Physical location | Physical | GLN (AI 414, Id of a physical location) |
Physical location + extension | Physical | GLN + AI 254 (GLN extension component) |
Digital location | Digital | GLN |
Function | Physical or Abstract | GLN |
Returnable asset class | Abstract | GRAI without optional serial number |
Returnable asset instance | Physical | GRAI with serial number |
Individual asset | Physical or Digital | GIAI |
Document type | Abstract | GDTI without optional serial number |
Document instance | Physical or Digital | GDTI with serial number |
Service relation provider | Physical or Abstract | GSRN (AI 8017) |
Service relation provider instance | Physical or Abstract | GSRN (AI 8017) + AI 8019 (Service Relation Instance Number) |
Service relation recipient | Physical or Abstract | GSRN (AI 8018) |
Service relation recipient instance | Physical or Abstract | GSRN (AI 8018) + AI 8019 (Service Relation Instance Number) |
Consignment | Abstract | GINC |
Shipment | Abstract | GSIN |
Payment slip | Physical or Digital | GLN + AI 8020 (Payment slip reference number) |
Coupon | Physical or Digital | GCN without optional serial number |
Coupon instance | Physical or Digital | GCN with serial number |
Component / part class | Abstract | CPID |
Component / part instance | Physical | CPID + AI 8011 (CPID serial number) |
Product model | Abstract | GMN |
The GS1 identification keys are the foundation of the GS1 system. However, some GS1 standards make provision for the use of other systems of identification for which some organisation other than GS1 is the issuing authority. For this reason, a classification of keys, drawn from a GS1 perspective, clarifies the relationship between a key and the rest of the GS1 system.
The following classification of keys is used:
■ Class 1: Keys administered by GS1 and fully under its control
■ Class 2: Keys whose framework is controlled by GS1 and for which a portion of the identification capacity is allocated to an identification scheme administered by an external agency
■ Class 3: Keys fully administered and controlled outside GS1, but which are supported in some parts of the GS1 system
■ Other keys: Keys that are entirely outside the GS1 system, i.e. all identifiers that meet the technical definition of “key” but are not in the first three classes.
This classification is described in more detail below.
4.3.1 Class 1 keys
A class 1 key has its structure, allocation, and lifecycle rules defined by GS1. A GS1 Prefix is a unique string of two or more digits issued by GS1 Global Office and allocated to GS1 Member Organisations to issue GS1 Company Prefixes, individual GS1 keys or allocated to other specific areas. A GS1 Company Prefix is a unique string of four to twelve digits issued by a GS1 Member Organisation and used to issue GS1 identification keys.
Class 1 keys always incorporate a GS1 Prefix or a GS1 Company Prefix licensed by a GS1 Member Organisation (MO) or by the GS1 Global Office to a user company. In some cases, class 1 keys are licensed one by one by MOs to user companies, using a GS1 Company Prefix licensed by an MO to itself for that purpose. They are subject to allocation rules defined in GS1 standards, and their association with attributes is governed by validation rules also defined in GS1 standards.
The class 1 keys are GTIN, SSCC, GLN, GRAI, GIAI, GSRN, GDTI, GSIN, GINC, GCN, CPID and GMN.
4.3.2 Class 2 keys
A class 2 key starts with either a GS1 Prefix or a GS1 Company Prefix, incorporates a key administered by an external organisation, and includes a check digit if required by its corresponding class 1 key format. Class 2 keys are unique with respect to class 1 keys of the same type. Their allocation and lifecycle rules, however, are defined by an organisation external to GS1. The degree to which these rules are compatible with those of the corresponding class 1 keys is specific to each class 2 key.
Examples of class 2 keys include:
■ The International Standard Serial Number (ISSN) used with GS1 Prefix 977 to form a key compatible with GTIN-13.
■ The International Standard Book Number (ISBN) is issued using GS1 Prefixes 978 and 979 to form a key compatible with GTIN-13.
□ A subset of ISBNs starting with 9790 are reserved for the International Standard Music Number (ISMN).
■ GS1 Prefix 34 is used with Club Inter Pharmaceutique (CIP) codes for pharmaceuticals in France to accommodate national numbers inside the GTIN number range.
■ The Produce Electronic Identification Board uses the GS1 Company Prefix 033383 issued by GS1 US combined with a commodity code issued by the Produce Manufacturers Association to create “PEIB UPCs” inside the GTIN number range.
The arrangements leading to the existence of class 2 keys are exceptional and subject to accreditation agreements between GS1 GO or MO and the third party. A GS1 Policy on the Licensing of GS1 Identification Keys by Third Parties governs the establishment of such arrangements.
4.3.3 Class 3 keys
A class 3 key has its structure and its rules for use defined, administered and managed by an organisation external to GS1. This organisation enters into an agreement with GS1 that enables its keys to be used in selected GS1 standards; for example, within an EPC header.
It is intended that class 3 keys are used in selected GS1 standards without disrupting users of class 1 and class 2 keys, but:
■ GS1 gives no assurance that class 3 keys will be recognised by users of class 1 and class 2 keys
■ GS1 has no expectation that systems relying upon class 3 keys should recognise keys from class 1 or class 2
■ GS1 has no expectation that systems relying upon one type of class 3 key should recognise other types of class 3 keys.
Companies can take advantage of GS1 technology, network, and communications standards for class 1, 2, and 3 keys, but should not expect full interoperability between keys in classes 1 and 2 and keys in class 3.
Keys in class 3 at the present time are:
■ The Auto-ID Center General Identifier (GID)
■ Keys compliant with US Department of Defence (USDoD) and Airline Transport Association (ATA) standards that are based on the Commercial and Government Entity (CAGE) and Department of Defense Activity Address Code (DoDAAC) identification standards.
■ Bureau International des Containers (BIC) codes
■ International Maritime Organization Vessel Number (IMO)
These keys are supported in the GS1 EPC Tag Data Standard and, consequently, have EPC URIs that can be used in EPCIS.
4.3.4 Other keys
Other keys are administered and managed externally to GS1 and are not accommodated by any GS1 standard as a key (primary identifier). Examples include:
■ Data Universal Numbering System (DUNS);
■ Vehicle identification number (VIN);
4.3.5 Summary
The following table summarises the key classification discussed above.
Table 4‑2 Classes of GS1 Identification keys characteristics
Class | Managed | Contract | GS1 Prefix | Interoperability* |
1 | By GS1 | N/A | Yes | Full |
2 | Externally | Required | Yes | Variable |
3 | Externally | Required | No** | Limited |
Other | Externally | No | No | None |
* Interoperability is the ability to use the key within the context of business processes supported by GS1 standards. ** One exception is GID GS1 Prefix 951. While the key itself does not contain a GS1 Prefix, the portion of the key that semantically corresponds to the GS1 Prefix is 951, and this GS1 Prefix is reserved for that use to avoid confusion with class 1 and 2 keys. |
When a GS1 identification key or other identifier is used in an information system, it is necessarily represented using a specific syntax. The syntax that is used may depend on the medium in which the identifier exists; for example, an XML message is text-oriented, while the memory of an RFID tag is binary-oriented.
GS1 standards provide four different syntaxes for identifiers that support progressively broader application contexts:
■ Plain: This syntax is just the GS1 identification key with no additional characters or syntactic features. For example, a Global Location Number (GLN) is represented as a 13-character string, each character being a digit. The plain syntax is usable in a context where only a single type of key is expected. Examples of such single-key contexts include: a barcode symbology that is defined to only hold one type of key (e.g., ITF-14 which can only hold a GTIN), a column in a database table that is intended to hold only a single key.
■ GS1 element string: This syntax consists of a short (2-4 character) “application identifier” that indicates what type of GS1 identification key follows, followed by the key itself. This allows one type of GS1 identification key to be distinguished from another. Related to the GS1 element string is the “concatenated element string”, in which two or more AI-value pairs are concatenated into a single string (with delimiters, if needed). This provides a syntax for compound keys such as GTIN + serial number. The “GS1 element string” syntax is used in the Capture Layer as a means for carrying multiple data elements in a single barcode.
■ Electronic Product Code (EPC) URI: This syntax is a Uniform Resource Identifier (URI), specifically a Uniform Resource Name (URN) beginning with urn:epc:id:… and the remainder having a syntax defined by the GS1 EPC Tag Data Standard. This provides a syntax for any key that identifies a specific physical or digital object, including some class 3 keys as defined in section 4.3.3. Objects that are not identified at the instance-level are either expressed as an EPC Class URI (urn:epc:class:...) or an EPC Pattern URI (urn:epc:idpat:...).
■ GS1 Digital Link URI: The GS1 Digital Link URI provides a syntax for expressing GS1 Identification Keys, Key qualifiers and data attributes in a format that can be used on the Web in an intuitive manner (via a straightforward Web request) to enable direct access to relevant information and services about products, assets, locations, etc.
While any given GS1 identification key may be represented in more than one of the above four syntaxes, its meaning is always the same regardless of syntax. The following table illustrates a GS1 Global Returnable Asset Identifier (GRAI) in each of the four syntaxes:
Table 4‑3 Example of GS1 identification key representation in identifier syntaxes
Syntax | Example | Remarks |
Plain | 0614141234561789 | A GRAI composed from GS1 Company Prefix 0614141, asset type 23456, check digit 1, and serial component 789 |
GS1 element string | (8003) 00614141234561789 | The GS1 Application Identifier 8003 indicates the following key is a GRAI. The GS1 element string for GRAI also includes an extra “0” padding digit immediately following the GS1 Application Identifier. The remainder of the element string is the same as the plain syntax. |
EPC URI | urn:epc:id:grai:0614141.23456.789 | The “urn:epc:id:grai:” header specifies that this EPC URI corresponds to a GRAI. The GS1 Company Prefix, asset type, and serial component are separated by dot (“.”) characters. The check digit is not included in this syntax. |
GS1 Digital Link URI | https://id.gs1.org/8003/00614141234561789 | GS1 Digital Link URI on the id.gs1.org domain |
5 Capture – Physical data carriers and data capture infrastructure
The “Capture” standards in the GS1 system are standards for automatically capturing identifying information and possibly other data that is associated with a physical entity. A physical data carrier is a representation of data in a format that is designed to be machine-readable. Data carriers range in capability, from the simplest barcodes whose only function is to deliver a GS1 ID key when read, to complex barcodes capable of holding multiple data elements with error correction, to the most sophisticated RFID tags which are themselves small computing devices. Interaction with RFID tags may include more than only “data capture,” though the term “capturing” is still used as a general label for that process of encoding and/or decoding data into/from physical data carriers. The processes involved in putting data into physical data carriers, including printing of barcodes and programming of RFID tags, are also included under the label of “data capture.”
This section outlines the general foundations of GS1 standards for data capture.
5.1 Data capture architecture
5.2 Data carrier independence of data
5.3 Translation of data during physical data capture
5.4 Data capture infrastructure standards
The purpose of physical data carriers in the GS1 system is to provide a reliable way to automatically capture a GS1 identification key, key qualifiers and supplementary data, and link to the data held on computer systems as part of a workflow. In a GS1 compliant application of physical data carriers, a GS1 identification key must always be present.
Within a given data capture workflow there may be many individual interactions with physical data carriers. A data capture workflow may also involve interaction with humans, as well as with “back end” information systems such as Enterprise Resource Planning (ERP), Warehouse Management System (WMS), etc. All these things combine to create a business context within which the data capture workflow takes place, and this gives meaning to the act of capturing the data from the physical data carrier.
For example, at a point of sale terminal, the business context is usually such that scanning a barcode containing a GTIN means that one instance of a product whose class is identified by the GTIN has just been purchased by the customer engaged in the checkout process. However, at the returns desk, scanning the same barcode may instead mean that the product is being returned rather than purchased. In each case, the business context gives meaning to each barcode scan.
The figure below shows the elements of a typical data capture application architecture. The exact architecture for any given data capture application will vary from case to case – for example, not all data capture applications use both barcodes and RFID, some data capture applications print barcodes rather than scanning them, etc. – but the diagram shows the commonly occurring relationships between components and how GS1 standard interfaces fit in.
Figure 5‑1 Overview of the elements of a typical data capture application architecture
At the centre of any data capture application is the data capture workflow that defines the business process step(s) within which data capture takes place. This typically includes custom logic that is specific to the application. Beneath the data capture workflow is the data path between the workflow and GS1 data carriers.
The interfaces between layers of a data capture architecture isolate the different levels. The Enterprise application is isolated from the process of data capture and choice of data carrier by the data capture application.
GS1 defines business data elements in a data carrier-neutral way so that their semantics are the same regardless of which data carrier, or electronic messaging, is used.
Figure 5‑2 Three GS1 data carriers encoding the same business information GTIN value 9506000134352
5.2.1 Different types of GS1 data carriers
There are a multitude of different data carriers, each optimised for specific physical and performance constraints. Each define a carrier-specific representation of data elements, allowing the data to be encoded in a manner compatible with the physical constraints of the carrier. For example, in a GS1 DataMatrix, the barcode data elements are first arranged into “GS1 element strings” using GS1 Application Identifiers. In a Gen 2 EPC/RFID tag, those same data elements are separated into different memory banks then encoded into a highly compacted binary form.
For all GS1 data carriers there are three levels of abstraction through which the data passes. From highest to lowest, they are:
■ Application data: These are GS1 data elements defined in a data-carrier neutral way. A business application sees the same data regardless of data carrier used.
■ Transfer encoding: This is the representation of data used in the interface between a capturing application and the hardware device that interacts with the data carrier (barcode scanner or RFID Interrogator).
■ Carrier internal representation: This is the representation of data in the data carrier itself. In a barcode, this is the pattern of light and dark bars, squares or dots. In an RFID tag, this is the binary data stored in the digital memory of the RFID chip.
Table 5‑1 Data carrier representations and the corresponding GS1 standards
Abstraction level | Data representation | Corresponding GS1 standard | ||
Barcode | RFID | Barcode | RFID | |
Application data | Plain data values EPC URI GS1 Digital Link Standard (URI) | GS1 General Specifications EPC Tag Data Standard GS1 Digital Link Standard | ||
Transfer encoding | Plain data values or GS1 element string (Application Identifiers) | EPC Tag URI OID/value pairs EPC binary encoding ISO/IEC 15962 binary data | GS1 General Specifications | EPC Tag Data Standard |
Carrier internal representation | Barcode symbology | EPC binary encoding ISO/IEC 15962 binary data | GS1 General Specifications | EPC Tag Data Standard |
There are three types of data that may be involved in carrier internal representation and in transfer encoding:
■ Application data: Data that is delivered from the Capture layer to the Share layer. Application data is data carrier independent.
■ Control data: Data that is used to control interaction with the data carrier.
■ Carrier data: Data that describes the data carrier itself.
Table 5‑2 Summary of data types by GS1 data carrier
Data Type | Barcode | RFID |
Application data | GS1 Data Elements and/or EPC URI and/or GS1 Digital Link URI | |
Control data | FNC1 indicator | EPC Header Filter value PC/XPC bits |
Carrier data | Symbology identifier | TID XTID |
To illustrate control data and carrier data, a few examples are described in more detail below:
■ In the Code 128, DataMatrix, and QR barcode symbologies, Function Code 1 (FNC1) is a special symbol used to indicate if the subsequent data is encoded in a GS1-compliant way. This FNC1 character is control information that the data capture layer uses to understand how to interpret the data in the barcode. (When these barcodes include FNC1, they are called GS1-128, GS1 DataMatrix, and GS1 QR Code, respectively).
■ In certain non-GS1 data carriers that can encode a web URI, the encoding of a GS1 Digital Link URI is possible without any control data or symbology identifier.
■ In RFID tags, the filter value is control information that is used to distinguish different tag populations. For example, item-level tags may have one filter value, and pallet-level tags may have a different filter value. This allows the RFID Interrogator to broadcast a command to “turn off” tags having an item-level filter value, so that the pallet level tag may be read without having to spend time reading the much more numerous item-level tags. The filter value is control information used by the data capture layer to optimise reading performance but is not application data.
■ Barcode scanners include a symbology identifier in the transfer encoding, which is a 3-character string that indicates what kind of barcode was read (GS1-128, GS1 DataBar, EAN/UPC, etc.). This is carrier data that describes the data carrier itself.
As mentioned above, different representations of GS1 data are used at different levels of abstraction in a typical data capture architecture. This implies that there is a process of translation that takes place as data moves up or down in the data capture architecture.
For example, the following are the steps of translation as data is read from a barcode and transferred to an application:
■ The barcode is analysed to determine the symbology type and is translated according to the symbology standard into a GS1 element string.
■ The GS1 element string is parsed according to the GS1 General Specifications into individual data elements and the GS1 Application Identifier (AI).
■ The data elements are parsed from their AI numbers, according to the GS1 General Specifications. These yield plain data element values.
The corresponding example for RFID has the following steps:
■ The binary data encoded into the EPC and user memory banks is read from the tag and transferred through the RFID Interrogator’s Low-Level Reader Protocol (LLRP) interface.
■ The binary data is decoded according to the EPC Tag Data Standard to yield an EPC Tag URI, which encapsulates the GS1 data elements that uniquely identify the object to which the RFID tag is affixed, along with RFID control information. For the user memory bank, which contains data supplemental to identification, the binary data is to yield OID/value pairs, each giving the value of one data element.
■ The EPC Tag URI is then decoded into an EPC URI according to Tag Data Standard. Optionally, the EPC URI may be translated into plain data element values. The OID/value pairs are also able to be translated to plain data element values.
GS1 standards for data capture include several standards that provide a consistent way to interface with hardware and infrastructure software. Because of the different operating model and capabilities of barcodes and RFID, there are separate standards and architecture dealing with each. This section discusses those differences, and the GS1 standards that apply to each.
5.4.1 Barcode data capture infrastructure standards
Barcode data capture infrastructure standards typically consist of rules for two operations:
■ Read all data elements from a single barcode
■ Print a barcode containing one or more data element
Both operations deal with the entire data content of a single barcode. In the interfaces to barcode equipment, this data content is commonly expressed as a GS1 concatenated element string with a symbology identifier, which is a string of characters having the following parts:
■ Symbology Identifier: A 3-character piece of control information that identifies which type of barcode symbol is involved.
■ Element strings: A series of GS1 element strings. Each GS1 element string consists of two to four digits that identify the data element, followed by the data content for that data element. In a concatenated element string, these are arranged in an arbitrary order, with a separator character employed to delimit GS1 element strings (except in the case of certain fixed-length data elements, which have no separator and are required to precede all other data elements).
The operation of printing a barcode is also centred on a GS1 concatenated element string, which specifies the data content of the printed barcode. In a typical printing application, however, there is usually much more information to be provided to the printer (including printing of non-GS1 data).
5.4.2 RFID data capture infrastructure standards
Radio Frequency Identification (RFID) allows data to be carried by an electronic device (RFID Tag), which communicates via radio frequency (RF) signals with a reading device called an RFID Interrogator (also called an “RFID Reader”).
RFID tags have additional capabilities than barcodes. Some of these are:
■ RFID tags can be read even when there is not a direct optical line of sight from the RFID Tag to the RFID Interrogator.
■ A single interrogator may read many tags simultaneously.
■ Data on RFID Tags is organised into multiple memory banks, each of which has separate access.
■ The data on RFID tags may be added to or changed.
■ Certain types of RFID tags may provide additional functionality besides data storage and retrieval; for example: encryption, authentication, access control, electronic disabling (“killing”), sensors, actuators, etc. The interfaces provide the ability to perform these operations as well.
RFID systems often employ an additional layer of software between the data capture application and individual RFID hardware devices. The two common interfaces between a data capture application and the RFID Interrogator with which it interacts are:
■ The Application Level Events (ALE) Interface: ALE is a GS1 standard interface between a data capture application and RFID Interrogators. ALE provides data capture applications with a high-level interface in which data from more than one RFID Interrogator may be aggregated together and in which data is filtered to avoid multiple reads, unwanted tags, etc. ALE also allows for multiple applications to simultaneously interact with the same RFID Interrogators. ALE is designed to let a data capture application focus on what data and operations it wants to use in interacting with RFID tags, without exposing the details of how this is accomplished in the interaction between Interrogator and Tag.
■ The Low Level Reader Protocol (LLRP) Interface: LLRP is a GS1 standard interface to a single RFID Interrogator device. It is a lower-level interface than ALE. It provides full control over the operation of the RFID Interrogator including low level details of the Interrogator-Tag interaction. Data at the LLRP level is represented in the same raw, encoded form that is used in the RFID Tag memory itself. LLRP allows a single client to have full control over a single reader.
When ALE and LLRP are used together, there is typically a layer of software between the LLRP and ALE interfaces. This software is called “filtering and collection” software. Filtering and collection software is responsible for receiving high-level instructions from one or more data capture applications that interface through ALE, determining how best to carry out those instructions by commanding individual RFID Interrogator devices, and then operating each Interrogator through LLRP. The filtering and collection software also translates between the raw, encoded data formats used in the RFID Tag memory to the application-friendly decoded formats used by data capture applications.
ALE and LLRP are part of the “data path” of an RFID data capture architecture – they are responsible for the communication of application data between RFID tags and the application layer. Complex RFID deployments involving many RFID Interrogators typically also have a “control path” through which the RFID hardware devices themselves may be configured, managed, and monitored for proper operation. This is especially necessary when RFID devices are not directly controlled by human operators. There are two GS1 standards that provide interfaces useful in constructing a control path for RFID infrastructure:
■ The Reader Management (RM) Interface: RM is a GS1 standard interface through which a monitoring application may obtain information about the status of an RFID Interrogator, including whether it is operational, how many tags are being read, and so on.
■ The RFID Discovery, Configuration, and Initialisation (DCI) Interface: DCI is a GS1 standard interface through which an RFID Interrogator may automatically make itself known to a network, obtain configuration information, and initialise itself so that it communicates with filtering and collection or application software.
6 Share – Business data and communication
This section discusses the architectural foundations underlying GS1 standards for business data sharing.
The GS1 standards for sharing business data enable to automate the interactions between two or more end users. The end users involved must have a common understanding of the structure and meaning of business data, and this leads to GS1 standards that define the content of business data. Moreover, the end users must have an agreed method of communicating data between themselves, and this leads to GS1 standards for communication of business data. The open nature of value networks implies that an end user may not always know in advance where to find relevant business data, and this leads to GS1 interface standards for data and service discovery across the value network. In an international environment, such standards must balance the need for the seamless flow of data across the world with the need to respect national sovereignty and local regulation. This leads to principles of world-wide federation that inform the design of GS1-provided services that aid in discovery.
These four topics are discussed in detail in the remainder of this section.
6.1 Content of standardised business data
6.2 Communication of business data
6.3 Data and service discovery
6.4 Worldwide federation
6.5 Layering of interface standards – Content vs. Syntax vs. Transport
GS1 standards for business data pertain to three categories:
■ Master data that provide descriptive attributes of entities identified by GS1 identification keys, including trade items, parties, and physical locations.
■ Transaction data that consists of transactions related to business processes across the value network.
■ Visibility event data provide details about the “what, when, where, why” activity in the value network.
6.1.1 Master data
Master data are attributes of an entity that are static or nearly so. For a trade item class, for example, master data might include the trade item’s dimensions, descriptive text, nutritional information in the case of a food product, and so on. For a legal entity, master data might include the name of the organisation, its postal address, geographic coordinates, contact information, and so on.
Master data provide the information necessary for applications to understand entities and to process them appropriately in business processes.
Data sharing in the GS1 system is built on an architectural pattern that combines data in recurring business documents with master data:
■ Master data associates the GS1 identification key with the attributes that describe the corresponding entity.
■ Recurring business documents with transaction data and visibility event data refer to entities by use of GS1 identification keys.
■ Applications that process the recurring business documents obtain a complete set of information by combining the GS1 identification keys referenced in business documents with the associated master data. In this way, the repetition of master data attributes in each recurring business document is avoided.
There are six methods supported in the GS1 system by which a data recipient may receive master data from a data source:
1. Synchronisation in advance: A data recipient obtains master data prior to processing any recurring business documents. This is referred to as “synchronisation” because the process of obtaining master data in this way is repeated periodically in order that the data recipient’s copy of master data is consistent (“synchronised”) with the master copy published by the data source.
2. Peer-to-peer communication in advance: A data source of master data can send master data directly to a data recipient in a specialised EDI message, such as Item Data Notification (GS1 XML) and Price Sales Catalogue – PRICAT (GS1 EANCOM).
3. Query on demand: A data recipient obtains master data for a given entity by issuing a query to a lookup service, where the query contains the GS1 identification key for the entity whose master data is desired. In this method, it is possible to defer obtaining master data associated with a given GS1 identification key until the data recipient is processing a business document containing that key.
4. Embedding in a business document: A business document itself may contain master data attributes in addition to a GS1 identification key. In this way, the consuming application does not need to obtain master data from another source.
5. Embedding in a physical data carrier: A physical data carrier (barcode or RFID tag) affixed to an entity may contain attributes that describe the entity. GS1 standards for capture may be used to extract these attributes and pass them to a business application.
6. Embedding in a web page: A set of master data may be published on a web page using the GS1 Web Vocabulary. GS1 Digital Link URIs can be used to point to such data.
The first three methods in this list follow the architectural pattern of pre-aligning master data as described above. Methods 4 and 5 are used when it is not possible or convenient to pre-align master data. Method 6 can be used for pre-alignment and non-pre-alignment situations.
The following subsections cover master data for trade items in detail and for other GS1 keys more generally.
6.1.1.1 Master data for trade items
Master data for trade items may apply to one or more trade items. Five different scopes exist for trade item master data, each corresponding to a different level of identification:
■ Global Model Number-level: Attributes that apply to all GTINs that are part of a “Model” or “type” of trade item.
■ GTIN-level: Attributes that apply to all instances of a given GTIN are GTIN-level master data attributes.
■ Consumer Product Variant-level: Attributes that apply to a specific variant of a given GTIN.
■ Batch/lot-level: Attributes that apply to all instances of a GTIN within a single batch or lot as defined by the manufacturer.
■ Instance-level: Attributes that apply to a single instance of a GTIN identified by GTIN plus serial number.
An example of GTIN-level master data attributes for a trade item are the product name and its physical dimensions (for a fixed-measure trade item). An example of a batch/lot-level master data attribute is the expiration date, which is typically identical for all instances within a given batch/lot but varies from one lot to the next. An example of an instance-level master data attribute is the harvest geo-coordinates of a tuna carcass.
In all three of the above examples, the master data attributes do not change over the life of the trade item instances concerned. It is this static nature of such attributes that makes them “master data.” The volume and rate of creation of master data is different at different scopes. GTIN-level master data is created infrequently, at the rate of new product introduction, instance-level master data is created every time a new trade item instance is manufactured, and batch/lot-level master data is somewhere in between.
The Global Product Classification (GPC) defines a code that locates a trade item within a taxonomy of all trade items; a trade item’s GPC code is therefore a very important master data attribute, both to describe the trade item and to identify what sets of category-specific master data attributes might be available for that trade item.
6.1.1.2 Master data associated with other entities
Besides trade items, the entities for which master data alignment is most important are locations and organisations. The GS1 identification key for locations and organisations is the GLN. Master data related to the GLN include for example its function, postal address, geo-coordinates, opening hours, etc. In case the GLN is used to identify an organisation, the master data may include other attributes such as a company registration number, associated bank account, etc. Peer-to-peer master data alignment related to locations or organisations can be done by implementing the GS1 EDI Party Information message (PARTIN).
Master data may exist for any of the types of entities that can be identified by GS1 identification keys. In practice, the communication of master data for entities other than those identified by GTIN or GLN is achieved during the sharing of business transactions or event data related to these entities.
6.1.2 Transaction data
Transaction data are business information required to support a collaborative business process shared bilaterally between organisations. Often these are functionally the same as their namesake paper documents, such as purchase order and invoice. Transaction data is consumed by software applications, not directly by humans. This means that the GS1 design principles include rules such as only exchanging coded rather than clear text information and that master data should be aligned before exchanging the transactional data.
GS1 standards for transaction data, collectively named GS1 EDI, are provided to automate business transactions commonly occurring across value networks. This includes business processes beginning with a buyer ordering goods from a supplier and progressing to the final receipt of cash by the supplier in exchange for those goods. GS1 standards for transaction data also support business processes such as demand forecasting, transport, traceability data, clinical trials, etc.
Transaction Data are always shared within the framework of a business agreement (contract) between two parties. Each document confirms the commitment to execute the agreement; for example, sending an electronic purchase order message implies that the sender wants to receive the ordered goods according to the conditions agreed in the contract and will pay for them.
The GS1 standards for transaction data include:
■ GS1 EANCOM
■ GS1 XML
■ GS1 UN/CEFACT XML
6.1.3 Visibility event data
Visibility Event Data are records of the completion of business process steps in which physical or digital entities are handled. Where Transaction Data confirm legal or financial interactions between trading partners, Visibility Event Data confirm the carrying out of a physical process or a comparable digital process. Examples of processes that may be the subject of Visibility Event Data include affixing of identification to a newly manufactured object (“commissioning”), shipping, receiving, movement from one location to another, picking, packing, transfer at point-of-sale, and destroying.
The same business process may simultaneously yield Visibility Event Data and Transaction Data as shown in the diagram below.
Figure 6-1-3 Relationship between Transaction Data and Visibility Event Data
Examples of three business processes that generate different kinds of data:
■ In some cases, a visibility event coincides with a business transaction, so that there may be a piece of Transaction Data and a piece of Visibility Event Data describing different aspects of the same occurrence. For example, when products are shipped from a loading dock, there may be a Despatch Advice confirming the sender’s intent to deliver specific products to the receiver and one or several “shipping” EPCIS events confirming the observation of products leaving the loading dock.
■ A visibility event may occur with no corresponding business transaction. For example, when a trade item moves from the “back room” storage of a retail store to the sales area where a consumer can purchase it. This is a highly relevant event for purposes of assessing availability of product to consumers, but it has no associated business transaction.
■ A business transaction may take place with no corresponding visibility event. For example, when a buyer sends an “order” message to a supplier, there is a legal interaction, but nothing occurring in the physical world where the ordered products reside.
Each Visibility Event has four data dimensions:
■ What: Identification of the physical or digital object(s) involved in the event, expressed using an identification key
■ When: The date and time when the event took place
■ Where: The physical location involved in the event, which may include:
□ The physical location where the event took place
□ The physical location where the objects are expected to be following the event
■ Why: Details about the business process context in which the observation took place, which may include:
□ An identification of the business process taking place at the time of the event
□ The business state of the objects following the event
□ Links to relevant Transaction Data (especially in those cases where a visibility event and a business transaction occur simultaneously)
Visibility Event Data is defined by the GS1 Electronic Product Code Information Services (EPCIS) standard.
This GS1 Lightweight Messaging standard provides a simple and lightweight messaging framework for value network participants to ask verification questions to each other. The standard defines how actionable information can be shared between parties. Messaging is based on various authentication checks on the product identifier and associated data.
GS1 standards offer several methods for communication of Business Data between end users. In summary, the methods are:
■ “Push” methods, where one party unilaterally transfers data to another in the absence of a prior request. Push methods may be further classified as:
□ Bilateral party-to-party push, where one party transfers data directly to another party
□ Publish/subscribe, where one party transfers data to a data pool, which in turn pushes the data to other parties who have previously expressed interest in that data by registering a subscription (“selective push”)
□ Broadcast, where a party publishes Business Data in a publicly accessible place such as a World Wide Web page, where it may be retrieved by any interested party
■ “Pull” or “query” methods, where one party makes a request for specific data to another party, who in turn responds with the desired data.
In principle, any of the above communication methods could be used for any of the categories of business data that are governed by GS1 business data standards. In practice, the type of data dictates the most appropriate communication methods and GS1 standards support the combinations that end users have found to be most useful. They are summarised in the table below:
Table 6‑1 Summary of the most useful communication methods per data type
Data Type | Example data | Data standard | Available communication methods | |||
Bilateral “Push” | Publish/ Subscribe | Broadcast | “Pull” (“Query”) | |||
Master Data | Trade item / catalogue item Batch/lot master data Instance-level master data (ILMD)
Location / party info | GDSN (supported by GS1 XML CIN and EANCOM PRICAT as noted below) | ü | ü |
|
|
EPCIS |
|
|
| ü (master data query, ILMD) | ||
GS1 Web Vocabulary |
|
| ü (via web pages) |
| ||
Transaction Data | Order Delivery Pay | GS1 EDI XML | ü |
|
|
|
Visibility Event Data | Observation Aggregation Transformation | EPCIS | ü (via AS2) | ü (standing queries) |
| ü |
GS1 standards for business data and communication provide the means for two end users to share business data reliably, once they have identified each other. GS1 standards for data and service discovery exist to help end users identify each other.
In general, there are four ways that one end user might identify sources of data owned or maintained by other end users:
■ Pre-arrangement: In many cases, one end user identifies another by means of some pre-arrangement that takes place outside the scope of any GS1 standard. For example, bilateral sharing of business transaction data via GS1 EDI typically takes place between end users who have identified each other in advance and agreed to trade with each other.
■ Originating Party Service Lookup: In some cases, an end user may wish to share data with the party that originates a given entity, such as the brand owner of a trade item. Originating Party Service Lookup refers to methods by which any value network party can find and initiate data sharing with the originating party.
■ Identifier resolution: The concept of Identifier resolution is the link between a GS1 identification key and a web tool that provides the option to access specific information resources related to the entity identified by the GS1 identification key.
■ Full Data Discovery: In some cases, an end user may wish to share data with all parties that have interacted with a given entity throughout its lifetime in the value network. For example, in “tracing” goods through the value network it is useful to obtain observations made by all parties that handled the goods in order to form a complete picture of what happened. Full Value network Data Discovery refers to finding the complete set of value network parties that have relevant data, along with the related problems of trust and access control.
Pre-arrangement requires no GS1 standards. In principle, it is possible to share data across an entire value network by exploiting pre-arrangement in a “1 up, 1 down” pattern. In this pattern, it is presumed that each party in a value network has pre-arranged data pathways established between its immediate predecessor (“1 up”) and immediate successor (“1 down”) with respect to the flow of goods. Such pathways therefore form a chain along which data can be shared from any point in the chain to any other. However, the ability to do so is limited by the willingness of all parties along the chain to cooperate, and whether they are all operational at the time data is to be shared.
Originating Party Service Lookup, Identifier Resolution and Data Discovery require additional services beyond the bilateral relationships between trading partners, and those services may be supported by GS1 standards. The following sections explain this in more detail.
6.3.1 Originator Party Service Lookup
Originating Party Service Lookup is facilitated by the GS1 Object Name Service (ONS) standard and associated GS1 service. ONS provides a means for an originating party to register one or more service descriptors to be associated with a class-level GS1 identification key. Each service descriptor specifies a type of service and an Internet Uniform Resource Locator (URL) that can be used to reach that service.
The ONS service operated by GS1 has not been adopted by a critical mass of end users and has been discontinued. The ONS standard is however still available for use by user communities.
The ONS functionalities might be supported by the forthcoming Resolvers specified by the GS1 Digital Link standard.
6.3.2 Identifier Resolution
A Resolver for GS1 Digital Link URIs connects a GS1-identified item to one or more online resources that are directly related to it. The item may be identified at any level of granularity, and the resources may be either human or machine readable. Examples include product information pages, instruction manuals, patient leaflets, clinical data, product data, service APIs, marketing experiences and more. By adhering to a common protocol based on existing GS1 identifiers and existing Web technologies, each conformant GS1 resolver is part of a coherent yet distributed network of information resources.
6.3.3 Data Discovery
Data Discovery is intended to solve the general problem of finding all data that resides within the value network regarding specified physical objects. It applies to finding all physical event data that is captured as an object moves through the value network.
There is not yet a GS1 standard nor GS1 services for Data Discovery; however, much exploratory work has taken place since the problem was first posed in 2006. Looking ahead, there is an opportunity for the GS1 Registry Platform to include registered links to sources of EPCIS data from across a value network. Such links would be registered at an appropriate level of key granularity and could be served up in response to a query to the GS1 Registry Platform and/or the GS1 Resolver.
It is anticipated that this work will be carried further as end users approach the point where full value network data sharing becomes a business requirement.
A fundamental architecture principle of the GS1 system is that each end user retains control over the data it originates. However, certain types of data are logically aggregated across many different end users. An example is master data in the Global Data Synchronisation Network, where each end user can synchronise master data for trade items identified by their Global Trade Identification Number (GTIN), regardless of the originator.
The most straightforward implementation of a global information resource of this kind is a single database maintained by some central authority. However, a single, centralised database has several drawbacks:
■ Scalability: A single database must be large enough to accommodate the aggregate volume of data and queries across the world.
■ Local Preferences: In different countries there may be different regulatory requirements as well as cultural preferences for critical services of this kind.
■ National Sovereignty: To the extent that each nation views services of this kind as an essential part of its business infrastructure, it may be uncomfortable with a centralised service hosted by another nation.
In contrast, a federated approach has the following properties:
■ Data distributed among multiple repositories, using the GS1 identification key as the basis for distribution.
In GDSN, this is realised through the existence of multiple certified GDSN Data Pools, each of which is the “home” repository for the master data associated with a subset of keys.
GS1 Resolvers can be set up by any party and are thus part of a federation.
■ Data may be replicated among repositories so that the failure of one repository does not affect users of others.
In GDSN, this is realised through synchronisation of data pools so that all data pools receive copies of the master data for all keys, regardless of where the data originated.
In the GS1 Registry Platform, this is realised through multiple redundant servers.
GS1 standards that define interfaces facilitate interoperability between different system components deployed by end users. They are typically specified in three layers. All standards in the Share layer, as well as the RFID infrastructure standards in the Capture layer, are designed in this way.
■ Abstract content: This is the primary layer of an interface specification. In this layer, the roles that interact via the interface are defined, along with their specific interactions. Abstract content is often specified in GS1 standards using the Unified Modelling Language (UML).
■ Concrete syntax: In this layer, the concrete syntax for the representation of data defined in the abstract content layer is specified. Many standards provide a single concrete syntax definition, but some standards may provide two or more alternative concrete syntaxes for the same abstract syntax. An example is the coexistence of GS1 XML and GS1 EANCOM syntax for GS1 EDI or the coexistence of JSON/JSON-LD and XML data bindings in the forthcoming new version of EPCIS (2.0).
■ Message transport: In this layer, the means for delivering a message having a concrete syntax from one side of the interface to another is specified. Message transport is the area where there is the most variety in the technical choices that can be negotiated between the parties. The layered structure ensures, however, that regardless of the choice of message transport the content of the messages may have the same syntax, and in all cases have the same meaning.
These layers are illustrated in the figure below (in this figure, the specific technologies mentioned are illustrative only; a given standard may specify a different set of options):
Figure 6‑5 Typical GS1 interface standard
7 GS1 Services
GS1 services are facilities coordinated by GS1 that provide benefit or assistance to other parties. Each GS1 service is available globally, with consistent functionality as viewed by end users around the world.
Both GS1 Member Organisations (MOs) and 3rd party service providers may also provide their own services to GS1 end users, which are not necessarily offered globally and are not coordinated across GS1. They are out of scope of this architecture document. However, local services of this kind are sometimes a proving ground for new ideas that eventually become GS1 services.
7.1 Functional scope of GS1 services
7.2 Current GS1 data services
7.3 GS1 data services strategy
Some GS1 services are training programmes and other types of customer support activities. Other GS1 services have a more direct connection to the GS1 System Architecture, the GS1 standards, and the information systems that end users construct using GS1 standards. These are called GS1 data services.
The role of GS1 data services is to provide the minimal backbone to make it possible for other parties to implement such services and for end users to discover such services and use them.
The responsibility for provisioning of the service and support of users is divided between the GS1 Global Office, GS1 Member Organisations, and 3rd party service providers. The goal of this division is to promote a federated approach to services where consistent functionality is available to end users on a global basis, but where GS1 Member Organisations and 3rd party service providers can cater to local markets, customs, and business models.
The main current GS1 data services are GEPIR and GDSN.
7.2.1 GEPIR
GEPIR (Global Electronic Party Information Registry) is a unique, internet-based service that gives access to basic contact information for companies that are members of GS1. Upon assignment of a GS1 company prefix to an organisation, the GS1 Member Organisation registers the organisation’s name and contact details in a server that complies with the GEPIR specifications. The backbone for the GEPIR network is the GEPIR Root Directory. The Root Directory is a series of XML files that provide information on the routing of queries in the network based on the GS1 Company Prefix allocation ranges assigned to individual GS1 Member Organisations.
GEPIR services are provided by GS1 Member Organisations and Global Office. They provide access to the GCP licensee through GS1 identification keys and by organisation name.
7.2.2 GDSN
The GS1 Global Data Synchronisation Network (GDSN) is a network of interoperable data pools enabling collaborating users to securely synchronise master data based on GS1 standards. GDSN supports accurate, real-time data sharing and trade item updates among subscribed trading partners.
Figure 7-2-2 GDSN choreography
1. Load Data: The seller (data source) registers product and company information in its data pool.
2. Register Data: A small subset of this data is sent to the GS1 Global Registry.
3. Subscription Request: The buyer (data recipient), through its data pool, subscribes to a seller's GLN, product category (GPC), target market, or GTIN to receive the corresponding product and company information. Using the GS1 Global Registry, the data pool containing the requested item and location information is identified and the subscription is forwarded to that data pool.
4. Publish Data: The seller’s data pool publishes the complete item and party information to the buyer via the buyer’s data pool.
5. Recipient Confirmation: The buyer sends a confirmation to the seller through the buyer’s data pool directly to the seller’s data pool. More than simply an acknowledgement, it informs the supplier of the action taken by the buyer on the item information.
In 2019, GS1 agreed a strategy on data services. The GS1 data services strategy focuses on the development of a Registry Platform consisting of scalable key registries that are accessed through a standard framework. The registries will store a minimal set of data attributes related to GS1 identification keys. The following statement known as the “Singapore resolution” was also agreed:
GS1 must establish NOW a system of Core Services to create, store, and check GS1 Company Prefix (GCP), Global Location Number (GLN), and Global Trade Item Number (GTIN). This system will require urgent prioritisation, focus, and coordination between Member Organisations and industry, based on technology tools, business process, and standards rules. Establishing and maintaining ubiquitous adoption of GCP, GLN, and GTIN is a pre-requisite to any more advanced use cases in product traceability, dynamic fulfilment, pedigree, content management, content quality, and authentication for industry.
The GS1 Data Services strategy is built on a series of important principles:
1. Be user-centric: The GS1 Data Services must be designed to support business processes and use cases, focused on trading partner needs and providers of business value.
2. GS1 identification keys and standards as the foundation: GS1 data services are based on the foundation of the GS1 identification keys and associated basic master data. The formats of data stored in and shared by the services are compliant with the GS1 standards for data exchange and validation.
3. Security: GS1 data services will be provided with appropriate physical, logical and commercial security (access control, authentication, non-repudiation and so on).
4. Data quality & integrity: Data quality will be core to the design of all GS1 data services and supporting programs.
5. Regulatory compliance: The aim is to provide a framework that GS1 Member Organisations can draw on to help with local/regional regulatory compliance.
6. Service availability: GS1 data services should be available globally (24*7*365), accessible and supportable to meet the needs of the future marketplaces.
7. Extensible and backward-compatible system: Extensibility and agility is a necessity for all GS1 data services in order adapt to new technologies, to enable more efficient business processes and to expand the user community
8 Glossary
Term | Definition |
Abstract Content (standards layer) | The layer of an Interface Standard that specifies the interactions that occur over the interface, including the abstract structure, meaning, and interaction patterns, but not including concrete syntax or transport |
AIDC | See Automatic Identification and Data Capture |
ALE | See Application Level Events |
Application Data (in physical data carriers) | Business data that are carried in Physical Data Carriers, defined in a data carrier-neutral way |
Application Level Events (ALE) | A GS1 standard interface between a Data Capture Application and one or more Radio-Frequency Identification (RFID) Interrogators (readers) |
Application standard | A type of GS1 standard that specifies a particular set of technical standards to which end user systems must conform in a particular business application |
Attribute (data modelling) | A piece of information associated with an entity. An attribute may be recognised if one can construct a sentence of the following form: “The [attribute name] of [entity] is [attribute value].” |
Automatic Identification and Data Capture (AIDC) | The reading and writing of information from Physical Data Carriers, e.g. barcodes and radio-frequency identification (RFID) tags |
Capture | A category of GS1 standards, encompassing the standards that are used to capture data that is carried directly on physical objects, bridging the world of physical things and the world of electronic information |
Carrier Data (in Physical Data Carriers) | Data contained in a Physical Data Carrier that describes the data carrier itself, as opposed to the object to which the data carrier is affixed |
Carrier internal representation | The representation of data as it exists within a Physical Data Carrier. In a barcode, this is the pattern of light and dark bars or squares. In a Radio-Frequency Identification (RFID) tag, this is the binary data stored in the digital memory of the RFID chip |
Class 1 Key | GS1 identification keys administered by GS1 and fully under its control |
Class 2 Key | GS1 identification keys administered by allocating a portion of GS1 numbering capacity to an external agency |
Class 3 Key | An identification key that is administered and controlled outside GS1, but which is supported in some part of the GS1 system. A class 3 key is not a “GS1 identification keys” |
Closed value network | A value network consisting of a fixed universe of trading partners, all of whom are known in advance |
Compound key (data modelling) | Two or more Attributes which together serve as a key, where no subset of those attributes taken by themselves would do so |
Concrete syntax (standards layer) | The layer of an Interface Standard which specifies a specific syntax that realises the abstract data structures defined in the Abstract Content layer |
Control data (in physical data carriers) | Data contained in a Physical Data Carrier that is used to by the Data Capture Application to control the interaction with the data carrier |
Data Capture Application | Software responsible for interacting directly with AIDC Data Carriers, and coordinating this interaction with the enclosing business process |
Data carrier | See Physical Data Carrier |
Data discovery | A future GS1 standardisation effort intended to provide a means for a value network party to locate all sources of data within the value network that meet specified criteria |
Data standard | A type of GS1 standard that defines the syntax and semantics of data |
DCI | See RFID Discovery, Configuration, and Initialization Interface |
Electronic Product Code Uniform Resource Identifier (EPC URI) | A uniform syntax for class 1, class 2, and class 3 keys that identify specific physical or digital objects, based on Internet Uniform Resource Identifier (URI) syntax |
Element string | See GS1 element string |
End user | An organisation that employs the GS1 system as a part of its business operations |
Entity (data modelling) | Something that is the subject of information in an information system |
EPC URI | See Electronic Product Code Uniform Resource Identifier |
Global Data Dictionary (GDD) | A compendium of the data elements defined across all GS1 standards. The GDD is not itself a GS1 standard, but rather is a tool which helps to ensure consistency across all GS1 standards |
Global Standards Management Process (GSMP) | The Global Standards Management Process (GSMP) supports standards development activity for the GS1 system. The GSMP uses a global consensus process to develop standards that are based on business needs and user-input |
GS1 element string | A syntax for representing one or more data elements, including GS1 identification keys and supplementary data, that is used in barcodes |
GS1 guideline | A document that provides information considered useful in implementing one or more GS1 standards |
GS1 identification key | A unique identifier for a class of objects (e.g. a trade item) or an instance of an object (e.g. a logistic unit) |
GS1 service | GS1 standards-based tool and/or capability (e.g., software, training) offered to Industry (by Global Office via GS1 Member Organisations or by Member Organisations themselves) to address a specific business need |
GS1 solution | GS1 offering to Industry (by Global Office via GS1 Member Organisations or by Member Organisations themselves) that combines GS1 standards, services, guidelines, and/or other activities to address a specific business need |
GS1 standard | Normative specification and rules agreed, per due process, by industry and GS1 Member Organisations to meet a business need of the GS1 community |
GS1 system | The sum of all the artefacts created by the GS1 community through GS1’s community development processes, including GS1 standards, GS1 guidelines, GS1 solutions, and GS1 services |
GS1 Web Vocabulary | A list of concepts, classes (types of thing) and properties or predicates (relationships, attributes), together with their definitions. |
GSMP | See Global Standards Management Process |
Identify | A category of GS1 standard, encompassing the standards that define unique identification codes which may be used by an information system to refer unambiguously to an entity |
Interface standard | A type of GS1 standard that defines an interaction between system components, often by defining the syntax and semantics of messages that are exchanged between system components |
Key (data modelling) | An attribute or group of attributes of an Entity that serves to uniquely identify that Entity, within some specified domain |
Low-Level Reader Protocol (LLRP) | A GS1 standard interface to a single Radio-Frequency Identification (RFID) device |
Master data | Attributes of an entity that are static (unchanging through the life of the entity) or nearly so |
Message Transport (standards layer) | The layer of an Interface Standard that specifies the means for delivering a message from one side of the interface to the other |
Object Name Service (ONS) | A GS1 standard for a service that provides a lightweight facility to identify services associated with a GS1 identification key that are registered by the party that originated the key |
OID/value pair | The combination of an Object Identifier as specified in ISO/IEC 9834 with the value of the OID for a specific object |
Physical data carrier | Generic term for a barcode or RFID Tag; a means of physically affixing machine-readable data to a physical object |
Profile | A type of standard whose normative content consists exclusively of references to other standards along with normative constraints upon their use |
Reader management (RM) | A GS1 standard interface through which a monitoring application may obtain information about the health and status of a Radio-Frequency Identification (RFID) Interrogator (reader) |
RFID Discovery, Configuration, and Initialization Interface | A GS1 standard interface through which a Radio-Frequency Identification (RFID) Interrogator (reader) may automatically make itself known to a network, obtain configuration information, and initialise itself so that it communicates with filtering and collection or application software |
Share | A category of GS1 standards, encompassing the standards that facilitate the sharing of data between business applications and trading partners |
Simple key (data modelling) | A single attribute that serves as a key |
Solution provider | An organisation that implements for end users systems that are based upon or implement the GS1 system |
Supplementary data | Attributes of entities, other than keys, defined by GS1 standards, that may be directly affixed to an entity using a GS1 Data Carrier |
Symbology identifier | A 3-character piece of Control Information used in barcode interface standards to identify which type of barcode symbol is read |
Technical standard | A type of GS1 standard that defines a set of behaviours for a system component. Technical Standards include Data Standards and Interface Standards |
Transaction data | Business documents that are shared bilaterally between trading partners, each document serving to automate a step in a business process involving a business transaction between parties |
Transfer encoding | The representation of data used in the interface between a Data Capture Application and the hardware device that interacts with the Data Carrier (barcode scanner or Radio-Frequency Identification (RFID) Interrogator) |
Value network | A set of parties who are involved in business relationships with one another |
Visibility event data | Records of the completion of business process steps in which physical or digital entities are handled |
A Summary of GS1 standards: Identify, Capture & Share
This informative annex provides a synopsis of the individual GS1 technical standards. Full details, and the access to the latest version of each, can be found on:
Normative References:
A.1.1 GTIN (Global Trade Item Number)
■ GS1 GTIN Management Standard
Abstract:
The GTIN identifies items that are traded and usually links to information about those items. Trading Partners use GTINs to communicate about items that they price, order or invoice and this supports the automation of business processes.
Allocation rules for the GTIN are specified in the GS1 GTIN Management Standard.
A.1.2 GLN (Global Location Number)
Normative References:
■ GS1 Global Location Number Allocation Rules
Abstract:
The Global Location Number (GLN) provides a unique and unambiguous identification of physical locations, digital locations, legal entities and functions within an organisation.
A.1.3 SSCC (Serial Shipping Container Code)
Normative References:
Abstract:
The SSCC supports the identification of logistic units, for example the identification of a pallet of goods, combined with the use of the Despatch Advice for automated goods receipt.
A.1.4 GIAI (Global Individual Asset Identifier)
Normative References:
Abstract:
GIAIs support a diverse range of business applications relating to individual assets (e.g., recording the life-cycle history of aircraft parts).
A.1.5 GRAI (Global Returnable Asset Identifier)
Normative References:
Abstract:
The GRAI supports the identification of Returnable Assets (such as a beer keg, a gas cylinder, a plastic pallet, or a crate). The GRAI is often used to identify a container of products identified with GTINs.
A.1.6 GSRN (Global Service Relationship Number)
Normative References:
Abstract:
The GSRN is used to identify the relationship between an organisation offering services and individual entities providing or benefitting from the services. For example, the GSRN can be used for patient identification enabling hospitals to store information about the medical characteristics of the individual together with details of treatment they have received.
A.1.6 GDTI (Global Document Type Identifier)
Normative References:
Abstract:
GDTIs are used to identify documents that cover any official or private papers that infer a right (e.g., proof of ownership) or obligation (e.g., notification of a call for military service) upon the bearer. The first part of the GDTI identifies the type of document and the optional serial number the individual instance.
A.1.7 GINC (Global Identification Number for Consignments)
Normative References:
Abstract:
GINCs are used to identify a logical grouping of goods (one or more physical entities) intended to be transported as a whole. The GINC is allocated by a freight forwarder (or a carrier acting as a freight forwarder). Typically, it encodes a House Way Bill Number.
A.1.8 GSIN (Global Shipment Identification Number)
Normative References:
Abstract:
GSIN is a globally unique number that identifies a logical grouping of logistic units (one or more physical entities) for the purpose of a transport shipment from that consignor (seller) to the consignee (buyer). The GSIN is a number assigned by a consignor (seller) of goods.
A1.9 GCN (Global Coupon Number)
Normative References:
Abstract:
The GCN supports the identification of coupons. A digital coupon is an electronic presentation, that is distributed and presented without manifesting as “paper” or in other hard-copy form, and that can be exchanged for a financial discount or for loyalty points when making a purchase.
A.1.10 CPID (Component/Part Identifier)
Normative References:
Abstract:
CPID enables companies to identify components and parts, typically where an Original Equipment Manufacturer (OEM) defines the specifications of a component that is part of its final product (such as an automobile).
A.1.11 GMN (Global Model Number)
Normative References:
Abstract:
The GMN enables users to uniquely identify the product model through the entire life cycle of the product: design - production – procurement – use – maintenance - disposal.
A.1.12.1 GS1 Application Identifiers
Normative References:
Abstract:
In the GS1 system the intention is that the minimum data is carried in physical data carriers (GS1 barcodes or GS1 RFID tags) attached to the object being identified: the identification key which can be used to find information about the identified object in a database. Ideally, the supplementary data encoded in physical data carriers will only encode information that cannot be looked up in a database by reference to the key. This could happen if data is needed when connection to a database is not available or when the key identifies a class of objects but the supplementary data relates to a batch or individual instance of the object. This supplementary data can be encoded into data carriers using GS1 Application Identifiers (AIs)
The list of AIs can be found on https://www.gs1.org/standards/barcodes/application-identifiers but the GS1 General Specifications remains the definitive source.
Normative References:
A.2.1.1 EAN/UPC
Normative References:
■ ISO/IEC 15420 : Information technology; automatic identification and data capture techniques; bar code symbology specifications; EAN/UPC
The EAN/UPC is a linear symbology that only encodes numbers. Its use is restricted to GS1 Applications. It has four main symbol types: EAN-13, UPC-A, EAN-8 and UPC-E. It is primarily used at the retail point-of-sale.
A.2.1.2 ITF-14
Normative References:
■ ISO/IEC 16390 : Information technology; automatic identification and data capture techniques; bar code symbology specifications; ITF
Abstract:
The ITF-14 is a linear symbology that only encodes numbers. Within the GS1 system it is restricted to encoding the GTIN as 14-digits with leading zeros if required. It is primarily used for cardboard cases where good print quality is hard to achieve.
Normative References:
■ ISO/IEC 15417 : Information technology; automatic identification and data capture techniques; bar code symbology specifications; Code-128 Symbology specifications
Abstract:
Code-128 is a linear symbology that encodes all the numbers and letters and several special characters. GS1-128 is a subset that uses the Function 1 Symbol Character (FNC1) in the first symbol character position following the Start Character to exclusively encode GS1 Application Identifiers.
A.2.1.4 GS1 DataBar
Normative References:
■ ISO/IEC 24724 : Information technology; automatic identification and data capture techniques; GS1 DataBar barcode symbology specification
Abstract:
GS1 DataBar is a family of linear symbologies used exclusively within the GS1 system. There are three groups of GS1 DataBar symbols:
1. comprises GS1 DataBar Omnidirectional, GS1 DataBar Truncated, GS1 DataBar Stacked and GS1 DataBar Stacked Omnidirectional and only encodes GTINs
2. GS1 DataBar Limited which encodes GTINs in a linear symbol with certain numbering restrictions.
3. comprises GS1 DataBar Expanded and GS1 DataBar Expanded Stacked. They can encode all the GS1 identification keys and any GS1 Application Identifier.
A.2.2.1 GS1 DataMatrix
Normative References:
■ ISO/IEC 16022 : Information technology; automatic identification and data capture techniques; Data Matrix bar code symbology specification
Abstract:
Data Matrix ISO version ECC 200 is a standalone, two-dimensional matrix symbology that is made up of square modules arranged within a perimeter finder pattern. It can encode all the numbers and letters and several special characters and uses Reed-Solomon error correction.
GS1 DataMatrix requires a leading FNC1 character at the start. This indicates that GS1 Application Identifier (AI) data is encoded.
A.2.2.2 GS1 Composite
Normative References:
■ ISO/IEC 24723 : Information technology; automatic identification and data capture techniques; EAN.UCC Composite bar code symbology specification
Abstract:
GS1 Composite integrates both a linear symbol and a 2 D Composite Component as a single symbology. There are three types of Composite Symbols A, B and C, each with different encoding rules. Properly defined encoders automatically select the appropriate type.
Normative References:
■ ISO/IEC 18004 : Information technology; automatic identification and data capture techniques; QR Code 2005 bar code symbology specification
Abstract:
GS1 QR Code is a standalone, two-dimensional matrix symbology that is made up of square modules arranged in an overall square pattern, including a unique finder pattern located at three corners of the symbol.
GS1 QR Code requires a leading FNC1 character at the start. QR Code 2005 is the only member of the QR Code family that supports GS1 system data structures, including Function 1 Symbol Character. ISO/IEC QR Code 2005 also contains specifications for Micro QR Code, but this symbology is not supported for the GS1 system. The FNC1 character indicates that GS1 Application Identifier (AI) data is encoded.
A.2.2.4 GS1 DotCode
Normative References:
■ AIM Rev 3.0, August 2014: Information technology; automatic identification and data capture techniques; bar code symbology specification - DotCode.
Abstract:
GS1 DotCode is a standalone, two-dimensional, symbology with the ability to encode GS1 identification keys while printing the barcode inline at high production speeds.
Normative references:
■ ISO/IEC 15962, 2nd Edition . Appendixes I, J, K, and L of the EPCglobal Tag Data Standard, which specify the encoding of the user memory bank of a Gen 2 RFID Tag, are reproduced in this ISO/IEC specification.
Abstract:
Defines the overall structure of the Electronic Product Code, including the mechanism for federating different coding schemes. For each GS1 Identification Key, defines rules for encoding and decoding from an RFID tag.
A.2.3.2 UHF Gen 2
Normative References:
Abstract:
The UHF Gen 2 Air Interface (often referred to simply as “Gen 2”) specifies the air interface for passive RFID Tags operating in the 860 MHz – 960 MHz radio frequency band. This standard is maintained in synchrony with ISO/IEC 18000-63.
A.2.3.3 HF Class 1
Abstract:
The HF Class 1 Air Interface specifies the air interface for passive RFID Tags operating in the 13.56MHz radio frequency band, with functionality comparable to UHF Class 1 Gen 2 tags.
A.2.3.4 Tag Data Translation
Normative references:
Abstract:
Provides in machine-readable form all of the rules that define how to translate between EPC encodings defined by the EPC Tag Data Standard.
A.2.3.5 Low-level Reader Protocol (LLRP)
Normative references:
■ EPC Low Level Reader Protocol (LLRP)
Abstract:
Provides means to command an RFID Interrogator to inventory tags (that is, to read the EPC codes carried on tags), read tags (that is, to read other data on the tags apart from the EPC code), write tags, manipulate tag user and identification data, and access other features such as kill, lock, etc.
A.2.3.6 Application Level Events (ALE)
Normative references:
■ EPC Application Level Events
Abstract:
A technical standard for the interface of EPC readers. It specifies how captured data can be obtained, filtered, consolidated for physical events. It also specifies how data can be processed from a variety of sources.
A.2.3.7 Reader Management (RM)
Normative references:
Abstract:
A technical standard for the configuration of an RFID Interrogator, such as its identity, number of antennas, and so forth. It also covers RFID Interrogator management functions including device discovery, identification and authentication, network connectivity management, firmware/software initialisation, configuration and updates, and managing reader power consumption.
A.2.3.8 Barcode / RFID interoperability guideline
Reference:
■ RFID Bar Code Interoperability, GS1 Guideline
Abstract:
This GS1 guideline provides information to end users and solution providers that use GS1 data carriers including barcodes and radio frequency identification (RFID) tags, specifically, data carriers that include serialised data. The guideline provides recommendations for best practices designed to lead to the highest degree of interoperability.
Normative References:
■ https://www.gs1.org/standards/edi/gs1-xml
■ W3C XML
Abstract:
W3C XML syntax is used in GS1 Business Message Standards (BMS) and several EPC standards (Reader Management, ALE, EPCIS). XML documents are constructed from elements, each of which has a tag followed by a value, so that the name of the data element which refers to a GS1 data definition is given explicitly. Each value is explicitly terminated by an end tag.
Normative References:
■ UN/EDIFACT syntax rules (ISO 9735)
Abstract:
EANCOM is a set of semantic rules based on the UN/EDIFACT syntax rules (ISO 9735); they are subsets of the United Nations Standard Messages (UNSM). Logically associated elements of data are associated into segments. The groupings of data elements are explicitly tagged and the individual values of data elements follow the segment tag in a known sequence with separator characters between. Adjacent separator characters show missing optional data and segments are explicitly terminated.
Normative References:
■ https://www.gs1.org/standards/edi/gs1-un-cefact-xml/2012
■ W3C XML
Abstract:
A GS1 profiled schema based on the UN/CEFACT XML standards for cross-industry Order, Order Response, Despatch Advice and Invoice.
A.3.1.4 Global Data Synchronisation Network (GDSN)
Normative References:
■ https://www.gs1.org/standards/gdsn
Abstract:
The Global Data Synchronisation Network (GDSN) enables trading partners to globally share trusted product data. The GDSN service is founded a suite of GS1 standards and guidelines including, but not limited to:
□ Business Message Standard (BMS) Catalogue Item Synchronisation
□ Business Message Standard (BMS) Basic Party Synchronisation
□ Business Message Standard (BMS) Price Synchronisation
□ Business Message Standard (BMS) Trade Item Authorisation
□ Business Message Standard (BMS) Shared Common Library
□ Trade Item Module Library (including approved product attributes and definitions)
□ Approved Code Lists
□ Validation Rules
□ GDSN Trade Item Implementation Guide
□ Packaging Label Guide
A.3.1.5 Global Product Classification
Normative References:
■ Product Classification (GPC) http://www.gs1.org/gpc
Abstract:
The Global Product Classification (GPC) gives trading partners a common language for grouping products in the same way, everywhere in the world.
The foundation of GPC is called a "Brick”. GPC Bricks define categories of similar products. Using the GPC Brick for classification ensures the correct recognition of the product category across the extended value network, from seller to buyer. Bricks can be further characterised by Brick Attributes.
A.3.1.6 GS1 Attribute Definitions for Business
Normative References:
■ https://www.gs1.org/standards/attribute-definitions-for-business
Abstract:
The GS1 Attribute Definitions for Business (ADB) provide additional clarity to existing technical standard definitions. Business-friendly names, definitions, examples and usage statements simplify meaning and usage of standard attributes for business users and communities.
Normative References:
■ https://www.gs1.org/standards/gs1-smartsearch
Abstract:
GS1 SmartSearch specifies how machine-readable structured data about a product or product offering can be embedded within an existing web page. GS1 SmartSearch focuses on structured data for use in B2C applications. GS1 SmartSearch is built around technologies developed for the so-called “semantic web,” including
■ Resource Description Format (RDF) as the language for expressing structured data
■ Schema.org and GS1 vocabularies to populate the structured data
■ JavaScript Object Notation for Linked Data (JSON-LD) as the machine-readable syntax for encoding the structured data into a format that can be easily embedded into a web page.
These technologies allow structured product data to be inserted directly into public-facing web pages, where it is available to any application that consumes those pages. This allows web page publishers to distribute product data directly to applications that can process that data. The GS1 Web Vocabulary is the primary output / manifestation of the GS1 SmartSearch standard.
Normative References:
Abstract:
GS1 Digital Link enables consistent representation of GS1 identification keys within web addresses to link to online information and services. It can be used with Linked Data technology and Web vocabularies such as schema.org and the GS1 Web Vocabulary in order to express machine-interpretable facts about products, assets, locations, organisations etc. at any level of granularity.
A.3.1.9.1 GS1 Product Image Specification
Normative References:
■ https://www.gs1.org/sites/default/files/docs/gdsn/Product_Image_Specification.pdf
Abstract:
The GS1 Product Image Specification Standard establishes rules for the storage of digital images associated to products and provides details on all aspects of digital imaging storage such as size and quality requirements.
A.3.1.9.2 GS1 Mobile Ready Hero Images
Normative References:
■ https://www.gs1.org/standards/Mobile-Ready-Hero-Image/
Abstract:
The Mobile Ready Hero Images Guideline aims to ensure that product images are enhanced to convey the key information to users of small screens in such a way as to help people find the product they need more easily, improve the consistency of presentation and increase the visual appeal of product images.
A.3.1.10 EPCIS and Core Business Vocabulary (CBV)
Normative References:
■ https://www.gs1.org/standards/epcis
■ ISO/IEC 19987:2017 Information technology — EPC Information Services (EPCIS) Standard
■ ISO/IEC 19988:2017 Information technology — Core Business Vocabulary Standard
Abstract:
The EPC Information Services (EPCIS) standard defines an abstract data model and concrete XML syntax for visibility event data, which is designed to provide information as to the whereabouts and condition of physical and digital objects. EPCIS 2.0 (expected to be ratified in 2020) introduces JSON / JSON-LD data bindings for event data, coexisting with the current XML data bindings. Visibility event data is complementary to master data and business transaction data.
A.3.1.11 Lightweight messaging
Normative References:
■ GS1 Lightweight Messaging Standard for Verification of Product Identifiers
Abstract:
The ‘GS1 Lightweight Messaging Standard for Verification of Product Identifiers' provides a simple and lightweight messaging framework for value network participants to ask verification questions and receive actionable information that immediately enables the requesting party to determine whether to accept, reject or quarantine a product instance, based on various authentication checks on the product identifier and associated data. It defines a verification request message and a corresponding response message.
A.3.1.12 GS1 Package Measurement Rules Standard
Normative References:
■ https://www.gs1.org/docs/gdsn/3.1/GS1_Package_Measurement_Rules.pdf
Abstract:
The GS1 Package Measurement Rules Standard provides the global rules for nominal measurement attributes of product packaging to facilitate communication of the height, width and depth for retail and non-retail products.
B Summary of GS1 application standards & solutions
This informative annex provides some examples of the standards and guidelines that are listed on https://www.gs1.org/standards/ under the category ‘Use’. While all GS1 standards and guidelines are used, those listed here bring together technical GS1 standards into combination to meet specific business requirements. Examples of such Application Standards include:
Normative References:
■ https://www.gs1.org/standards/traceability
Abstract:
GS1 provides the global framework to ensure that traceability systems are interoperable and scalable, where trading partners can easily collaborate and share information across the entire global value network.
Normative References:
■ https://www.gs1.org/standards/fighting-illicit-trade
Abstract:
Illicit trade and product counterfeiting are serious problems with negative consequences for authorities, brand owners, distributors, retailers and consumers. The GS1 Fighting Illicit Trade suite helps partners implement existing GS1 standards-based solutions.
Normative References:
■ https://www.gs1.org/industries/healthcare
Abstract:
Healthcare application standards, which provides a common set of data and data carriers for medical products and specific guidance for use of GS1 technical standards like EDI, GLN in Healthcare.
B.4 Fresh Foods
Normative References:
■ https://www.gs1.org/industries/retail/fresh-foods/implementation-guidelines
Abstract:
The identification, capturing and sharing of information for Fresh Foods (or, more specifically, products of nature like fish, fruit, vegetables, etc. which, by definition, are not produced to identical specifications) require application standards tailored to the individual business challenges.
B.5 Rail standards
Normative References:
■ https://www.gs1.org/industries/technical-industries/rail/rail-standards
Abstract:
The Identification of components and parts in the rail industry, Exchange of component/part lifecycle data in the rail industry and Vehicle Visibility Standard combine to meet the specific rail industry needs.
Change Log
Log of Changes
Release | Date of Change | Summary of Change |
1.0 | 14 February 2012 | Initial release |
2.0 | February 2013 | Update based upon recent standard changes |
3.0 | 14 April 2014 | Update based upon recent standard changes |
4.0 | May 2015 | Applied new GS1 branding and clarifications in the classes of keys (section 4.3) and approved following GSMP Community Review. |
5.0 | April 2016 | Updates based upon recent standard changes |
6.0 | Feb 2017 | Updates based upon recent standard changes |
7.0 | Feb 2018 | Updates based upon recent standard changes |
8.0 | Feb 2019 | Updates based upon recent standard changes |
9.0 | Feb 2020 | Major review based upon simplification effort, new GS1 services strategy & recent standard changes. |