GS1 General Specifications introduction
The GS1 system, as explained in section GS1 Architecture Principles and GS1 System Architecture, aims to raise the efficiency of business processes and to provide cost savings through automation based on globally unique identification and digital information.
The GS1 system provides for the use of unambiguous identification keys to identify goods, services, assets, locations, organisations etc. worldwide. These identifiers can be represented in data carriers, such as barcodes or tags, to enable automatic data capture. They may also be used in electronic communications, improving speed and accuracy when sharing master data, transactional data and visibility event data.
The GS1 system is designed to overcome the limitations of using company-, organisation-, or sector-specific interfaces. It enables large scale deployment, flexibility in the selection of the most suitable system components and innovation − ultimately making trade more efficient and responsive to customers.
The GS1 system is designed for use in any industry or trade sector, and changes to the system are introduced in a way that does not disrupt existing users. This document defines:
-
technical standards for identification and Automatic Identification and Data Capture (AIDC)
-
application standards for the use of identification and AIDC within an intended environment (see the GS1 System Architecture section 3.1 for more information on GS1 standards). It supersedes all previous AIDC technical documents provided and/or published by GS1 or its predecessor organisations. Every organisation that claims conformity with GS1 standards is expected to conform fully to the GS1 General Specifications, including any related technical specifications normatively referenced such as, but not limited to, the GS1 Digital Link standard: URI syntax and GS1 EPC Tag Data Standard (TDS).
The GS1 system originated in the United States and was established in 1973 by the Uniform Product Code Council, subsequently known as the Uniform Code Council, Inc. (UCC). Following the success of this U.P.C. system, the European Article Numbering Association, subsequently known as EAN International, was established in 1977 to develop a compatible system for use outside North America. In February 2005, GS1 was officially launched as the successor to the organisations previously known as EAN and UCC, and the system became known under its current name: The GS1 system.
GS1 Architecture Principles and GS1 System Architecture The GS1 General Specifications combines technical and application standards, across all 4 layers of GS1 standards: Identify, Capture, Share and Use, as defined by the GS1 System Architecture. As such, the GS1 General Specifications is considered a foundational standard of GS1 as it supports the larger ecosystem of standards and services described within the GS1 System Architecture.
| GS1 system | |||
|---|---|---|---|
| Policy GS1 Architecture Principles | Architecture GS1 System Architecture | Standards layers (categories) GS1 standards Identify Capture Share Use | Based on GS1 standards GS1 guidelines e.g., AutoID in Rail GS1 solutions e.g., 2D migration programme GS1 services e.g., Verified by GS1 (VbG) |
Figure: How the GS1 Architecture Principles, GS1 System Architecture and GS1 system fit together
The GS1 Architecture Principles and GS1 System Architecture defines the policy and structural aspects of the GS1 system respectively, as depicted in the figure above. The full benefits of the GS1 system, which include GS1 standards (e.g., technical and application standards), GS1 guidelines (e.g., technical or industry implementation guidance), GS1 solutions (e.g., initiatives to develop standards and support implementation such as GS1 Traceability) and GS1 data services (e.g., GS1 Registry Platform (GRP)) can only be obtained when they respect the architecture and principles.
GS1 and other external international standards The core business of GS1 is the unique identification of value chain entities, for the purpose of exchanging information about those entities with trading partners and stakeholders. Organisations using GS1 standards to address their business requirements, especially for highly regulated sectors such as healthcare, also use standards from other standards development organisations (SDOs).
To ensure interoperability of GS1 standards with other external international standards systems, and across various sectors, GS1 participates in the standardisation processes of numerous international SDOs. As it pertains to the GS1 General Specifications, examples of international SDOs include ISO (International Organization for Standardization), ISO/IEC JTC1 (Joint Technical Committee 1 (information technology) of International Organization for Standardisation / International Electrotechnical Commission), ICCBBA (International Council for Commonality in Blood Banking Automation), W3C (World Wide Web Consortium), UN/CEFACT (United Nation Centre for Trade Facilitation and Electronic Business) and IETF (Internet Engineering Task Force). GS1 plays an important role by ensuring integration of GS1 standards within international standards portfolio, such as those referenced for identification in section 1.1.2 and for data carriers in section 5.1.2.
The mutual recognition between GS1 standards and other external international standards ensures greater understanding of the important role that industry standards play in the implementation of AIDC technologies. While GS1 standards may or may not be referenced directly by governmental regulations and laws, the reference to international standards such as those developed by ISO/IEC, guarantees the necessary references to GS1 standards are maintained. Therefore, it is important for the GS1 General Specifications to make reciprocal references to the international standards where GS1 standards are supported, and where appropriate, include direct references to the regulations and laws that are addressed by GS1 standards. This relationship between regulatory drivers, ISO/IEC standards and the GS1 General Specifications are shown in the figure below.
The GS1 System Architecture and the Architecture Principle for Third party standards, encourages the propagation of GS1 standards and other GS1 system components, through other standards bodies, to increase "...the impact, effectiveness, adoption and acceptance of the GS1 system globally". GS1's active participation in the development and maintenance of standards developed by other external international SDOs also provides early visibility and valuable opportunities to gain deeper understanding of emerging technologies, and their impact on existing and future GS1 standards.
Figure: GS1 and external international standards
Maintenance responsibility and management The GS1 Global Standards Management Process (GSMP) is the mechanism to approve the adoption of additions and changes to all GS1 standards and GS1 guidelines, including the GS1 General Specifications. The process is fully defined in the Global Standards Management Process Manual.
The standard is maintained in English and may be translated into other languages by local GS1 Member Organisations. Verbal forms used in normative statement In GS1 standards, normative statements are written using the verbal forms defined per the GS1 Style Guide. These include SHALL, SHALL NOT, SHOULD and SHOULD NOT. When these words are written in a normative statement, using the special meanings defined, they are written in all capitals to distinguish them from ordinary English use of the same words.
For a precise definition of these verbal forms, see the GS1 Style Guide. Briefly, their meanings are summarised as follows: SHALL means that all conforming implementations must do what the statement says, otherwise
-
the implementation is not conforming. No deviation is permitted.
-
SHOULD means that among several possibilities one is recommended as particularly suitable for a conforming implementation, without mentioning or excluding others. In other words, a conforming implementation is expected to do what the statement says, but might not if there is a good reason not to. It is similar to a MAY statement, but carries a stronger expectation that an implementation will usually do what the statement says.