1 Introduction
Global business partners require a consistent, reliable experience in exchanging and using organisation/party and location information, no matter where they operate. Business, governments, and consumers all expect accurate and more detailed information on where products come from, are now, and will be; along with who they are interacting with.
Establishing industry standards based on real-world organisation and location-based use cases enables more timely, accurate, and consistent exchange of foundational master data across the stakeholder groups. Having globally aligned, interoperable attribution creates an ecosystem in which organisation and location data can be readily shared in a scalable, interoperable way across different sectors and markets.
1.1 Purpose
A set of global attributes for the Global Location Number (GLN) whether mandatory or non-mandatory are a requirement to ensure the data being shared between stakeholders is complete, interoperable, and aligned whilst being able to be scaled to meet all business needs, supporting the deployment of future GLN solutions and services.
2 References
3 Global Location Number (GLN) Overview
The Global Location Number (GLN) provides a global supply chain solution by uniquely identifying parties and locations that are involved in business transactions.
1. Party identification
A party is defined as an entity that needs to be represented in a business-related transaction. A GLN identifying a party answers the question of “who” is involved within the use case leveraging GS1 standards. This may be a legal entity or function that defines who is transacting in a scenario.
A legal entity is any business, government body, department, charity, individual, or institution that has standing in the eyes of the law and has the capacity to enter into agreements or contracts.
A function is an organisational subdivision or department that is most commonly segmented based on the specific tasks being performed, as defined by the organisation.
Examples of a party:
■ Corporation (legal entity)
■ Subsidiary or a holding company (legal entity)
■ Government body (legal entity)
■ An individual acting as a business entity (legal entity)
■ Accounting department (function)
■ Human resources department (function)
2. Location identification
GLN identifying locations are used to answer the question of “where” something has been, is, or will be. A location can be either physical or digital in nature.
A physical location is a tangible place that may be represented by an address, coordinates, or other means. A physical location within another physical location (sub-location) can be allocated its own GLN.
A fixed physical location is expected to main in the same location for its entire lifecycle while a mobile physical location is expected to change its place.
A digital location is an electronic (non-physical) address that is used for communication between computer systems.
Examples of a location:
■ Corporate headquarters (fixed physical location)
■ Warehouse or distribution centre (fixed physical location)
■ Hospital cafeteria (fixed physical location)
■ Grocery store (fixed physical location)
■ Dock door (fixed physical location)
■ Mobile blood donation van (mobile physical location)
■ API entry point (digital location)
3.1 Examples of GLN use
GLN is incorporated throughout GS1 standards and the service and solutions that leverage the standards. This section includes examples of how GLN is used. Note that this is not an exhaustive list of how GLN may be used.
3.1.1 Location identification
A physical location is a site (an area, a structure or group of structures) or an area within a site where something was, is or will be located. Examples of physical locations include a store, a warehouse, or a berth in a port.
3.1.1.1 GS1 Logistic Label
The GS1 Logistic Label allows users to identify logistic units uniquely so that they can be tracked and traced throughout the supply chain. The only mandatory requirement is that each logistic unit must be identified with a unique identifier, the Serial Shipping Container Code (SSCC), though GLN is used to note the location and parties involved in the shipment. - https://www.gs1.org/standards/gs1-logistic-label-guideline/1-3
3.1.1.2 Scan4Transport
Scan4Transport is a global standard for encoding transport data on a logistics label. The standard supports the encoding of ship-to and return-to information (e.g., company name, addresses, handling instructions, etc) as well as GLNs. This is to support the needs of companies across the transport process to have access to the data they need in both on-line and off-line environments, especially when it is not possible to look-up reference keys such as a GLN in a system to enable first mile, sortation, and last mile activities. The B2C transport process often does not have a GLN for a residential address, subsequently the GS1 standards developed by the Scan4Transport work group, enables the transport industry to keep pace with the growing needs of their customers. - https://www.gs1.org/industries/transport-and-logistics/scan4transport
3.1.2 Identification of parties
A party is an organisation or a function thereof, which may or may not be associated with a physical location. The organisations and functions involved with supply chain transactions are known as parties, these include commercial parties to a transaction, third parties such as logistics service providers and regulatory and other public sector agencies.
3.1.2.1 GS1 EDI (Electronic Data Interchange)
GS1 EDI (Electronic Data Interchange) provides global standards for electronic business messaging that allow automation of business transactions commonly occurring across the entire supply chain. In EDI transactions organisations and functions involved in supply chain are identified. EDI covers master data alignment, order and delivery and financial settlement management, as well as transport and warehouse management. GLN is used to identify the parties and locations involved in the transactions. https://www.gs1.org/standards/edi
3.1.2.2 Global Data Synchronisation Network (GDSN)
The Global Data Synchronisation Network (GDSN) is the world's largest product data network. GDSN makes it possible for any company, in any market, to share high-quality product information seamlessly. GLN is used in GDSN to identify data source and data recipients, manufacturer, brand owners, and information providers. https://www.gs1.org/services/gdsn
3.1.2.3 Electronic Product Code Information Services (EPCIS)
EPCIS is a GS1 standard that enables trading partners to share information about the physical movement and status of products as they travel throughout the supply chain – from business to business and ultimately to consumers. The GLN can be used in Electronic Product Code Information Service (EPCIS). The ‘Where’ dimension of an EPCIS event (i.e., fields such as readPoint, bizLocation, source, destination) captures where the event physically took place and/or where things are following the event.
3.1.3 GS1 Web Vocabulary
The GS1 Web Vocabulary is designed to extend the work done by schema.org and makes use of similar concepts (Product, Offer, Organization, Place), extending them with many more detailed properties. The initial focus of the GS1 Web Vocabulary is consumer-facing properties for clothing, shoes, food beverage/tobacco and properties common to all trade items. - https://gs1.org/voc
3.1.4 GS1 Digital Link
The GS1 Digital Link standard extends the power and flexibility of GS1 identifiers by making them part of the web. That means that GS1 identifiers, such as the Global Trade Item Number (GTIN) and GLN, are now a gateway to consumer information that strengthens brand loyalty, improved supply chain traceability information, business partner APIs, patient safety information and more. - https://www.gs1.org/standards/gs1-digital-link
3.1.5 GLN in data carriers
The GLN can be encoded in either a barcode or EPC/RFID tag to automatically identify locations like storage places in a warehouse, the destination of a pallet, or the origin of a product.
3.1.6 GS1 Registry Platform (GRP)
The GS1 Registry Platform is a registry of GS1 keys, starting with the GS1 Company Prefix (GCP), Global Trade Item Number (GTIN), and Global Location Number (GLN). It includes the rules about data associated with the GS1 keys via the Global Data Dictionary (GDD). It is built on an infrastructure that supports API interfaces, analytics, and security. It provides a single mechanism for storage (“data in”) and query (“data out”) of basic key attributes for GS1 keys .
4 Global Location Number Data Model
There are at least three independent dimensions to the Global Location Number Data Model Standard, detailed in the following sections.
■ Abstract Data Model
■ Validation
■ Layering
4.1 Global Location Number data model dimensions
Figure 4‑1 Data model dimensions
4.1.1 Abstract data model
A Unified Modeling Language (UML) class diagram expresses the GLN data model at an abstract level, defining it in a way that is independent of the data format/syntax (e.g., XML vs JSON vs JSON-LD), relevant classes, properties/attributes and code lists and can be used to describe organisations/parties and physical locations. The UML class diagram defines the available terms but does not attempt to specify which are mandatory, conditional, optional or any cardinality constraints. See Figure 5‑1 UML Class Diagram.
Figure 4‑2 Abstract data model
An abstract data model defines data classes, attributes/properties, code lists / enumerations. An abstract data model:
■ includes definitions (and examples of usage)
■ specifies expected data types for values
■ supports hierarchical data structures and hierarchies of locations and organisations/parties
■ supports re-use of the data model at any level in the location or organisation/party
■ concerned with unambiguous semantic interpretation, not validation
■ often documented in UML class diagrams
4.1.2 Validation
One or more validation layers that are used to express constraints on the data model about which properties/attributes are mandatory/conditional, which are repeatable, cardinality constraints etc. Note that there might be multiple validation layers (e.g., a core global multi-sector validation layer and additional regional or sector-specific validation layers). Depending on the chosen data format, validation rules can be expressed using XSD, JSON Schema or Shape Constraint Language (SHACL).
It is worth noting that there will be different validation constraints where there are different regulatory requirements, country of use, different sector use and the different application use.
Figure 4‑3 Validation data model
A validation schema checks that:
■ mandatory data is present.
□ An example can be seen in Figure 4‑3 where the “locality (city)” field is a mandatory field and cannot be left blank, if this is used in webform the submission of the date would take place until all mandatory fields have been completed.
■ data is correctly formatted.
□ An example can be seen in Figure 4‑3 where a “country code” is required and this field definition must comply to an agreed format, in this instance ISO 3166.
Validation schema checks need to comply with the six types of cardinality constraints. Cardinality validation may be more restrictive than noted in section 5 to meet the needs of specific applications.
■ Mandatory one [1..1]: The attribute is mandatory. It cannot be repeated.
■ Mandatory many limited [1..n]: The attribute is mandatory. It can be repeated up to n times.
■ Mandatory many unlimited [1..*]: The attribute is mandatory. It can be repeated any number of times.
■ Optional one [0..1]: The attribute is optional. It cannot be repeated.
■ Optional many limited [0..n]: The attribute is optional. It can be repeated up to n times.
■ Optional many unlimited [0..*]: The attribute is optional. It can be repeated any number of times.
Figure 4‑4 An example of a conceptual validation
4.1.3 Layering
Layering of the data model and extensibility (represented by the onion model) as seen in Figure 4‑6, showing a global, multi-sector core as well as outer layers that may have different levels of maturity or may have narrower scope (e.g., region-specific, sector-specific) as seen in Figure 4‑7.
Figure 4‑5 Layering data model
Figure 4‑6 Data model layers
A layered 'onion' model defines core data and supports extensions by industry sector and/or geographic region and are typically implemented via use of multiple namespaces.
Figure 4‑7 Data model scope elements
4.1.4 Logical connections
There are some logical connections and intersections of these three independent dimensions as shown in the following three illustrations: Figure 4‑8, Figure 4‑9, and Figure 4‑10.
The validation schema reference the abstract data model and also depend on the contents of the layering. The schema can also go beyond what is defined in the abstract data model by adding validation constraints (e.g., mandatory properties, cardinality constraints etc).
Figure 4‑8 Connections between abstract data model and validation example
Since there can be multiple validation layers (e.g., core, global, multi-sector vs other validation layers for outer layers of the onion model), it is possible to be flexible about validating at each layer of the onion, even if for example, different regional or sector-specific layers have different requirements. Multiple validation layers are one way to support the onion model, to check that the data is correctly validated.
Figure 4‑9 Connections between validation and layering example
Use of multiple namespaces is the other way to support the flexibility of the onion model. It is expected to have a namespace for the core global multi-sector aspect of the data model. Anything outside of that (defined in the outer layers of the onion model) can be defined within its own namespace, so that there is no conflict between different definitions in the outer layers and no ambiguity about where a particular class, property/attribute or code list is defined. Each region or sector defining its own 'extensions' to the global multi-sector core can do so within their own namespace and can make cross-references to the global multi-sector core but express how it is extending that in its own way, for its own needs (which might be to meet the needs of some specific legislation in a particular region or sector). It is not a problem for the data to make use of multiple namespaces. XML and JSON-LD support this natively. JSON does not - but JSON-LD context resources can be used to hide some of the namespace complexity from anyone who wants to consume the JSON-LD data as if it is just JSON, while preserving support for multiple namespaces for those who need those details.
Figure 4‑10 Connections between abstract data model and layering example
5 GLN data model attributes
Attributes contained in the GLN Data Model Standard may be a single attribute (e.g., gs1:partyGLN or gs1:organizationName) or a class (e.g., gs1:Place) consisting of multiple attributes and/or sub-classes.
The Global Location Number Unified Modelling Language (UML) class diagram defines data classes, attributes/properties, and code list enumerations included in this data model. Classes are depicted as boxes, within which properties are indicated with text.
The tables throughout section 5 contain both classes and individual properties. The value in the cardinality column applies to the object described in the row. Both attributes and classes may be repeated and or be mandatory as indicated by the cardinality.
Example: gs1:PostalAddress is a class and the rule described in the cardinality column applies to the class as a whole. The cardinality column included in the gs1:PostalAddress table applies to the attributes only when the gs1:PostalAddress class is being used.
Other attributes may be in optional classes.
Example: The gs1:GeoCoordinates class is optional, but when the gs1:GeoCoordinates are provided the cardinality rules for the properties will apply.
The UML class diagram and information in section 5:
■ includes definitions and examples of usage
■ specifies expected data types for values
■ supports hierarchical data structures and hierarchies of locations and organisations/parties
■ supports reuse of the data model at any level in the location or organisation/party hierarchy
■ concerned with unambiguous semantic interpretation, not validation
5.1 GLN Type
5.2 Organisation
5.3 Place
5.4 Postal Address
5.5 Country
5.6 Contact point
5.7 Interval Specification
5.8 Certification
5.9 Creative Work
5.10 Product
gs1:GLN_TypeCode designates what a specific GLN is being used to identify. What a GLN identifies will dictate how a GLN can be shared, what GLN Management Rules apply and whether additional attributes may be required for an application.
GLN Type value may be any combination of LEGAL_ENTITY, FIXED_PHYSICAL_LOCATION, DIGITAL_LOCATION, FUNCTION or LEGAL_ENTITY, MOBLE_PHYSICAL_LOCATION, DIGITAL_LOCATION, FUNCTION.
Important: gs1:GLN_TypeCode value selections SHALL NOT contain both FIXED_PHYSICAL_LOCATION and MOBILE_PHYSICAL_LOCATION.
Table 5‑1 gs1:GLN_TypeCode code list table
gs1:Organization properties are associated to GLNs being used to identify an organisation/party (i.e., gs1:GLN_TypeCode = LEGAL_ENTITY and/or FUNCTION).
Code list values related to the following can be found https://www.gs1.org/docs/barcodes/GLN_DataModel_CodeValue_Nov2021.xlsx
■ gs1:GLN_TypeCode (also see section 5.1)
■ gs1: OrganizationID_Details
■ gs1: OrganizationClassificationDetails
■ gs1:OrganizationRoleType
■ gs1:BusinessEntityType
Note: The different spelling of organisation and organization is used in this document due to the alignment of the GS1 Web Vocabulary with https://schema.org/ which uses the spelling “organization”. In other GS1 documentation, for example the GS1 General Specifications the spelling used is “organisation”.
Table 5‑2 gs1:Organization table
5.2.1 Organisation identification details
Government bodies, trade organisations, and other parties issue identifiers that are associated to legal entities and/or functions. Linking these identifiers to GLN and one another supports consolidating records, mapping related, collaborative identifiers, enhances search ability and enables more efficient transitions between identifiers. gs1:OrganizationID_Details provides a method for connecting and sharing party identifiers.
Table 5‑3 gs1:OrgnaizationID_Details table
5.2.2 Organisation classification
Government bodies, trade organisations, and other parties have developed taxonomies that classify business sectors, activities, and other organisational classifications. Different countries may require specific classification system values to be associated to an organisation and shared for taxation and other purposes. gs1:OrganizationClassificationDetails provides a method for associating the necessary classification systems and appropriate values to an organisation.
Table 5‑4 gs1:OrganizationClassificationDetails table
5.2.3 Organisation status history
Over the lifetime of an organisation, it may go through periods of being active and inactive. gs1:OrganizationStatusHistory allows changes in status to be communicated in advance and tracked over time.
Note: Changes to organisation status is separate from when an organisation is officially formed or terminated and whether the GLN remains activated. To designate when an organisation formed or was formally terminated, see gs1:organizationFormationDate and/or gs1:organizationFormationDate.
Table 5‑5 gs1:OrganizationStatusHistory table
5.2.3.1 Status type
gs1:StatusType is used to designate if a organisation/party or location is active.
Table 5‑6 gs1:StatusType code list table
gs1:Place properties are associated to GLNs being used to identify a location (i.e., gs1:GLN_TypeCode = FIXED_PHYSICAL_LOCATION, MOBILE_PHYSICAL_LOCATION, DIGITAL_LOCATION).
Code list values related to the following can be found https://www.gs1.org/docs/barcodes/GLN_DataModel_CodeValue_Nov2020.xlsx.
■ gs1:GLN_TypeCode (also see section 5.1)
■ gs1:LocationType
■ gs1:LocationIDDetails
Table 5‑7 gs1:Place table
5.3.1 GeoCoordinates
A geographic coordinate system is a three-dimensional reference system that locates points on the earth's surface. The unit of measure is usually decimal degrees. A point has two coordinate values: latitude and longitude. The latitude is specified by degrees, starting from 0° and ending up with 90° to both sides of the equator, making latitude Northern and Southern. The equator is the plane with 0° latitude.
Important: If geodetic property is not expressed, then WGS84 is assumed to be the default.
Table 5‑8 gs1:GeoCoordinates table
5.3.2 GeoShape
A GeoShape is defined using several properties whose values are based on latitude/longitude pairs. Either whitespace or commas can be used to separate latitude and longitude. Whitespace should be used when writing a list of several such points.
Table 5‑9 gs1:GeoShape table
5.3.3 Location status history
Over the lifetime of a place/location, it may go through periods of being active and inactive. gs1:LocationStatusHistory allows changes in status to be communicated in advance and tracked over time.
Table 5‑10 gs1:LocationStatusHistory table
5.3.4 Location identification details
Government bodies, trade organisations, and other parties issue identifiers that are associated to locations. Linking these identifiers to GLN and one another supports consolidating records, mapping related, collaborative identifiers, enhances search ability and enables more efficient transitions between identifiers. gs1:LocationID_Details provides a method for connecting and sharing location identifiers.
Table 5‑11 gs1:LocationID_Details table
5.3.5 Logistic details
Sharing information on location capabilities and requirements can support proper planning and more efficient loading and unloading of transports. gs1:LogisticDetails provides options to communicate logistic details.
Table 5‑12 gs1:LogisticDetails table
5.3.5.1 Climate control details
The temperature and humidity levels in a storage area can determine what types of objects can be stored there and for how long. gs1:ClimateControlDetails is used to share these details.
Table 5‑13 gs1:ClimateControlDetails table
A postal address designates the location to which mail and other parcels are delivered. The fields required to form a valid address will vary based on property type, market, and other factors.
Table 5‑14 gs1:PostalAddress table
Country and country subdivisions are used as part of a postal address and other location references and designations. gs1:Country properties leverage ISO 3166 and ISO 3166-2 values.
Table 5‑15 gs1:Country table
Contact points provides information on an individual or department acting as point of contact for an organisation or location.
Table 5‑16 gs1:ContactPoint table
gs1:IntervalSpecification properties provide information on when something occurs and how long that occurrence is to remain in place.
Table 5‑17 gs1:IntervalSpecification table
gs1:CertificationDetails is used to share information about the type of certification issued by a certifying body.
Table 5‑18 gs1:CertificationDetails table
gs1:CreativeWork allows creative works, copyrights, patents, and other IP to be associated to an organisation.
Table 5‑19 gs1:CreativeWork table
Products may need to be associated to an organisation or place.
Table 5‑20 gs1:Product table
Contributors & change log
Contributors
Log of Changes
Useful links:
* PDF version of the GS1 GLN Data Model Solution Standard
* More information on the GS1 Global Location Numbers (GLN)