XML Standards > Catalogue Item Messages
 

Message Description
Go To: www.gs1.org
 

CATALOGUE ITEM SYNCHRONISATION v. 2.1

Problem Statement

The business landscape has undergone a rapid and complicated transformation. Globalization, converging supply chains, and the rapid pace of technology have added new costs and complexity to the way business is conducted in every industry. These issues have added significant expense to the cost of doing business.
This makes standards, which bring order and efficiency to business processes more important and challenging than ever before.The success and growth of the GS1 System has been based, in part, on its strong legacy in Catalogue Item identification, linking together the physical flow of a Catalogue Item with the corresponding flow of electronic information. In order to maintain the value of this system, GS1 has embraced Simple eb (Simple e-Business), a business practice that streamlines and simplifies the flow of business trade information enabling more efficient and effective supply chains.As its name implies, Simple eb is focused on simplifying the underlying communication of information that is applicable across multiple business processes.

One of the premises of Simpl-eb is that EC constructs (data and data structures) that are common across multiple business processes must be aligned. Some of the Core Data must be synchronised so it need not be sent in each transaction and it has the same value in the trading partners systems; such data has been referred to as Master Data.

To put this in the context of the GS1 system, the GS1 Business Message Standards (XML), UCS EDI Standards, VICS EDI Standards, and EANCOM are electronic data carriers within the Simple eb framework.Simple eb is dependent on the alignment of core data and the Synchronisation of master data that is used in multiple business transactions.The most prevalent master data is Catalogue Item and party, which can be identified with GS1 “Keys”, specifically the Global Trade Identification Number (GTIN) and Global Location Number (GLN).

The GS1 system provides the standards to align data between trading partners; these are the foundation standards.The GS1 system also defines a process by which trading partners can exchange this aligned data between them and synchronise master data across an entire community; these are the foundation processes.
This foundation allows for the simplification (Simple-eb) of the basic trade processes of Plan, Order, Delivery, and Pay, which in turn form the basis for more complex processes such as CPFR, Micro-Merchandising, Scan-Based Trading (SBT), and any other future initiative.

Substantial effort has been made to develop a Global Data Synchronisation process because master data sharing between partners is both complex and fundamental to all supply chain processes.Integrity and timeliness of master data is critical to the flow of goods, services and information throughout the chain.Sharing data effectively and efficiently relies on access to common data definitions, data accuracy and agreement on the processes used to exchange data.

This process is termed Master Data Synchronisation.Throughout 2000-2002, with increased emphasis on global commerce, electronic trading communities and evolving Internet technology, it became obvious that global master data standards and processes were essential to support simple e-Business transactions.As a precursor to the establishment of standards, GCI, UCC and EAN developed business requirements in parallel to address "What standard processes are required to enable Global Data Synchronisation?”

In January 2002, GS1 instituted the GSMP to create and maintain global standards.The GSMP Data Synchronisation team was formed to align all business requirements associated with the Data Synchronisation process, including the Global Registry.


Objective

To supply the detail design of the catalogue Item synchronisation business transaction needed to meet the requirements of the referenced BRAD(s).

Audience

The audience of this standard is any participant in the global supply chain.This includes retailers, manufacturers, service providers and other third parties

Business Context


Industry: All
Geopolitical: All
Product: All
Process: GDSN
System Capabilities: EAN.UCC
Official Constraints: None



Business Transaction View




Business Rules
See table
TOP

Business Transaction Use Case Diagram

Use Case Diagram

Use Case Diagram
Use Case Diagram
Figure 2 - Manage Catalogue Item Data in Global Registry Use Case Diagram

Use Case Diagram

 Figure 3 - Manage Catalogue Item Distribution Criteria Use Case Diagram

Use Case Diagram
Figure 4 - Distribute Data Recipient Requests Use Case Diagram
Use Case Diagram
Figure 5 - Distribute Catalogue Item Data Use Case Diagram
TOP

SUMMARY USE CASES


1. Global Search

Use Case Name Global Search
Traceability Identifier UC-31
Use Case Description The Global Search feature of Data Synchronisation will be defined as directed by GSMP Change Request 02-000152.
Preliminarily, the Guiding Principles are:
  1. will have:
    1. parametric search
    2. wild card search
    3. drop down list for searching
    4. Target Market specificity (language & currency)
    5. Must be enabled for images
    6. Must have ability to drill down enough to EAN.UCC classification structures
    7. Ability to search by specific language
  2. will have the ability to search to the attribute level.
  3. will have a request for publication functionality
  4. search engine will be housed at the home data pool
  5. Global Search functionality will be facilitated by the GlobalRegistry
As a summary Use Case, specific processes will be further defined in the Detail Use Case section of this document.
Use Cases Above UC-1:Synchronise Catalogue Item Data
Use Cases Below

 
Actors Source Data Pool (SDP)Global Registry
Recipient Data Pool (RDP)Data Recipient
Performance Goals SDP: To ensure that Data Source provided Catalogue Item Data is searchable by Recipient Data Pools.
RDP: To find Catalogue Item Data that matches the Data Recipient’s search criteria.
Data Recipient:To find Catalogue Item Data available in the Target Markets served by the Data Recipient.
Global Registry: To ensure that Catalogue Item Data can be found by Recipient Data Pools.
Preconditions N/A
Postconditions N/A
Scenario N/A
Alternative Scenario N/A
Special Requirements N/A
Extension Points N/A
Requirements Covered N/A
TOP

2. Synchronise Catalogue Item Data
Use Case Diagram
Figure 6 - Synchronise Catalogue Item Data Use Case Diagram
Use Case Name Synchronise Catalogue Item Data
Traceability Identifier UC-1
Use Case Description The process of continuous harmonisation of information between all trading partners within the supply chain through the use of Align Data standards.
The salient points for synchronisation are: synchronisation is a process, it is auditable, must utilise industry standards (i.e. EAN.UCC), the data exchanged must be compliant with these standards, the recipient (i.e. the buyer) must acknowledge the integration of the data, and continuous updates must be applied.
As a summary Use Case, specific processes will be further defined in the Detail Use Case section of this document.
Use Cases Above None
Use Cases Below UC-2: Load and Update Catalogue Item Data within a Source Data PoolUC-46: Manage Catalogue Item Data in Global RegistryUC-23: Manage Catalogue Item Distribution CriteriaUC-47: Distribute Data Recipient RequestsUC-29: Distribute Catalogue Item DataUC-50: Distribute Catalogue Item Data for Initial Item Load
Actors Data SourceSource Data Pool (SDP)Global Registry
Recipient Data Pool (RDP)Data Recipient
Performance Goals Data Source: To have Catalogue Item Data available to Data Recipients.
SDP:To have Data Source provided Catalogue Item Data is searchable by Recipient Data Pools.
RDP:To find Catalogue Item Data that matches the Data Recipient’s search criteria.
Data Recipient: To find Catalogue Item Data available in the Target Markets served by the Data Recipient.
Global Registry:To ensure that Catalogue Item Data can be found by Recipient Data Pools.
Preconditions N/A
Postconditions N/A
Scenario N/A
Alternative Scenario N/A
Special Requirements N/A
Extension Points N/A
Requirements Covered N/A
TOP
3. Load and update Catalogue Item Data within a Source Data Pool
Use Case Diagram
Figure 7 - Load and update Catalogue Item Data within a Source Data Pool Use Case Diagram
Use Case Name Load and Update Catalogue Item Level Data within Source Data Pool
Traceability Identifier UC-2
Use Case Description This Use Case describes the processes that need to take place for Catalogue Item data to be transferred from the Data Source to the Source Data Pool, be validated and registered in the Global Registry.After this process, Catalogue Item data may be distributed to Recipients according to the distribution rules described in the Manage Catalogue Item Data Distribution Criteria Use Cases.
As a summary Use Case, specific processes will be further defined in the Detail Use Case section of this document.
Use Cases Above UC-1:Synchronise Catalogue Item Data
Use Cases Below UC-3:Add Catalogue Item HierarchyUC-4:Change Catalogue Item HierarchyUC-5:Correct Catalogue Item HierarchyUC-25:Delete Catalogue Item HierarchyUC-7:Cancel Catalogue Item
Actors Data SourceSource Data Pool (SDP)Global Registry
Performance Goals Data Source: To have validated, registered Catalogue Item Hierarchy data in their Source Data Pool.
SDP:To have validated, registered Catalogue Item Hierarchy data.
Global Registry: To ensure valid, unique Catalogue Item data are registered.
Preconditions Data Source has defined Catalogue Item data and Catalogue Item hierarchies using Item Links.
Postconditions Data Source knows that Catalogue Item data has been validated and registered and Item Links have been validated.
Scenario Begins when, the Data Source sends, to the SDP, Catalogue Item Hierarchy data.1. The SDP validates the Catalogue Item Hierarchy Data
 2. The SDP sends Catalogue Item Data to the Global Registry
 3. The Global Registry validates and registers the Catalogue Item Data4.The SDP stores the Catalogue Item Hierarchy data
5.The SDP notifies the Data Source of Registration
Ends when, the Data Source receives acknowledgement of the registration
6. Some time later, the Data Source updates the Catalogue Item Hierarchy data and sends it to SDP7.The SDP validates the Catalogue Item Hierarchy data8.The SDP sends pertinent Catalogue Item Data updates to the Global Registry9.The Global Registry validates and updates the Catalogue Item Data10. The SDP stores the new Catalogue Item Hierarchy data11. The SDP notifies the Data Source of Updates
Ends when, the Data Source receives acknowledgement of the registration
Alternative Scenario ad 1 & 7.Validation fails:
1.1. / 7.1. SDP sends an validation error message to the Data SourceEnds when, the Data Source receives the validation error message
ad 3 & 9.Validation fails at the Global Registry
3.1 / 9.1.Global Registry sends a registration error message to the SDP3.2 / 9.2.The SDP receives the registration error message and passes it to the Data SourceEnds when, the Data Source receives the registration error message
** SDP may not send Catalogue Item data to Registry for Uniqueness check w/o Registration.
Special Requirements
  • Data Source is using a(source) data pool.
  • Catalogue Item Hierarchydata consists of Catalogue Item data and Item Link data (ifapplicable).
Extension Points N/A
Requirements Covered
 
Activity Diagram
Figure 8 - Load and Update Catalogue Item Data within a Source Data Pool Activity Diagram
TOP
4. Manage Catalogue Item Data in Global Registry
Use Case Diagram
Figure 9 - Manage Catalogue Item Data in Global Registry Use Case Diagram
Use Case Name Manage Catalogue Item Data in Global Registry
Traceability Identifier UC-46
Use Case Description This use case describes the processes that need to take place for Catalogue Item Data to be registered in the Global Registry.
As a summary Use Case, specific processes will be further defined in the Detail Use Case section of this document.
Use Cases Above UC-1:Synchronise Catalogue Item Data
Use Cases Below UC-18: Register Catalogue ItemUC-19: Change Registered Catalogue ItemUC-21: Delete Registered Catalogue ItemUC-17: Registry ValidationUC-32: Validate Data PoolUC-33: Validate Catalogue Item Data for Registry
Actors Source Data Pool (SDP)Global Registry
Performance Goals SDP: To have validated, registered Catalogue Item Hierarchy data.
Global Registry: To ensure valid, unique Catalogue Item data are registered.
Preconditions Data Source has defined Catalogue Item data and Catalogue Item hierarchies using Item Links.
Postconditions Data Source knows that Catalogue Item data has been validated and registered and Item Links have been validated.
Scenario See detailed Use Cases for Scenarios
Alternative Scenario
 
Special Requirements
  • Data Source is using a (source) data pool.
  • Catalogue Item Hierarchy data consists of Catalogue Item dataand Item Link data (if applicable).
Extension Points N/A
Requirements Covered

TOP
5. Manage Catalogue Item Distribution Criteria
Use Case Diagram
Figure 10 - Catalogue Item Distribution Criteria Use Case Diagram
Use Case Name Manage Catalogue Item Distribution Criteria
Traceability Identifier UC-23
Use Case Description This Use Case describes the processes that need to take place for Publications, Subscriptions and Confirmations to be moved throughout the Synchronisation System.
As a summary Use Case, specific processes will be further defined in the Detail Use Case section of this document.
Use Cases Above UC-1:Synchronise Catalogue Item Data
Use Cases Below UC-24: Publish Catalogue Item DataUC-34: Stop Publishing Catalogue Item DataUC-27: Subscribe to Catalogue Item DataUC-28: Remove Catalogue Item SubscriptionUC-26: Confirm Catalogue Item Data
Actors Data SourceSource Data Pool (SDP)Global RegistryRecipient Data Pool (RDP)Data Recipient
Performance Goals Data Source: To have Catalogue Item publications available to the SDP for matching with Subscriptions.
SDP: To have the proper criteria (Publications, Subscriptions and Confirmations) to allow distribution of Catalogue Item data to Data Recipients (via their Recipient Data Pool).
Global Registry: To be able to distribute Catalogue Item Subscriptions to the proper Source Data Pools.
RDP: To ensure Catalogue Item Subscriptions match the data that is being sent by SDPs.
Data Recipients: To control the type and volume of Catalogue Item Data received.
Preconditions

Postconditions

Scenario See detailed Use Cases for Scenarios
Alternative Scenario

Special Requirements  
Extension Points N/A
Requirements Covered

ID

Requirement

Weight

REQ-12 Every command needs a response and is handled according to the agreement between the parties involved. In the inter-operable network, acknowledgement messages are standardised and may contain the following information: - Confirmation of message receipt- Success / Failure of processing (syntax and content)- Reason for failure, with a code number and text message unique assigned to each failure Primary
REQ-13 The Data Source grants visibility of item, party and partner profiles including party capabilities data to a given list of parties (identified by their GLNs) or to all parties in a given Target Market. Secondary
REQ-20 Synchronisation Lists must include every Catalogue Item (GTIN+GLN+TM) that needs to be synchronised. Secondary
REQ-21 If a Catalogue Item is "Confirmed of Synchronisation" then all Catalogue items below in the Catalogue Item Hierarchy shall be included in the Synchronisation list. Secondary
REQ-22 Relationship dependent data will only be communicated for Synchronised, Review or Accept status in the Synchronisation List. Secondary
REQ-23 Events that can trigger notifications are: - Publication of new data / change of publication - Change of published Catalogue Item / Party / Partner Profile - Change of owner, rights - Subscription - Synchronisation List - Confirmation/ Rejection - Request for Notification - Any successful matching process Primary
REQ-24 Notifications must NOT be sent in the following cases since data is not yet public and validated information: - Data load (add, change, etc…) - Data validation - Registration of new Catalogue Item Primary
REQ-25 The Data Distribution, which is the movement of data from one entity to another, must be handled through a specific notification type. Primary
REQ-26 Notification to the data recipient will always include the entire hierarchy. (applies to add & update by adding a higher level) Primary
REQ-27 In case of an ItemLink correction, the entire hierarchy will be indicated as corrected in the notification. Primary
REQ-32 Acknowledgement Reason codes must be unique. Secondary
REQ-92 “Single Data Source” Principle : - there can only be one official source of the data – the one that is registered - this source is identified by the data source - this is the only valid source for data synchronisation and related processes Primary
REQ-99 The Global Registry functionality requirements can be summarised as follows: - Enable data synchronisation - Validation, registration and subscription functions - Enable global validation - Checking compliance with basic EAN.UCC rules related to the format of a GTIN/GLN and ensuring the uniqueness of the data that is being registered - Enable global search functionality that does not require full duplication of data in the Global Registry. Primary
REQ-100 The Global Registry is involved in the following functions and/or business cases as defined in the Item Synchronisation detailed requirements: - Validation - Registration - Subscription - Global Search Primary
REQ-101 Registry Validation includes : - EAN.UCC standards validation for GTIN and GLN formats (i.e. check digit) - Uniqueness validation for Item (GTIN/GLN/TM), Party (GLN) or data pool (GLN), ensuring there is only one occurrence and data source for each data record as identified by the appropriate fields. Primary
REQ-102 Registry validation is a part of the registration process. Primary
REQ-104 In summary, the registry requirements for validation are: - EAN.UCC standards validation for GTIN/GLN formats - Uniqueness validation for Item, Party and data pool key - Store and maintain EAN.UCC standards - Process validation command - Provide validation acknowledgement Primary
REQ-105 Registration is the process, which references all Catalogue Items and Parties published in all certified data pools and on which there is a need to synchronise / retrieve information. This is supported by data storage in accordance with the Registry data scope and rules. Primary
REQ-106 Registering a Catalogue Item involves a check by the Global Registry for Item uniqueness. The Item is identified by the following elements: GTIN, GLN, Target Market. Each combination of this key data found in the Global Registry must be unique. When an Item is registered, the registry verifies that the combination of this data is unique to that Item. Primary
REQ-107 The registration process is triggered by the following business cases: 1. Create Catalogue Item: After the physical load and validation of the data, the registry record needs to be created before data can be published. 2. Update Catalogue Item: When a registered Catalogue Item is updated in its source data pool, updates impacting the Registry data must be reflected in the Global Registry, before the updated data can be propagated to the recipients. Registration of Catalogue Item changes only needs to happen for changes that: Impacts fields stored in the Global Registry. Are authorised according to the GTIN allocation rules. 3. Correct Catalogue Item: When a registered item is corrected in its source data pool, corrections impacting the Registry data must be reflected in the Global Registry before the updated data can be propagated to the data recipients. 4. Delete Catalogue Item: Deletions need to be reflected in the Global Registry: the discontinuation dates starts the EAN.UCC standard retention period (48 months for CPG, 36 months for apparel) as soon as GTIN has been discontinued in ALL target markets where it was active (needs to be stored in the Global Registry). 5. Cancel Catalogue Item: Communicates a trade item was never manufactured – this allows an earlier “reuse” of the GTIN i.o. standard retention period. This is achieved through the maintenance (using change function) of the cancel date. 6. Removing an Catalogue Item from the supply chain: The permanent removal of a Catalogue Item from the supply chain is achieved through the maintenance of a discontinuation date. This date has to be reflected in the Global Registry to kick off the EAN.UCC retention period. Temporary removals are not reflected in the Global Registry and only handled through the maintenance of the availability period in the data pools. Primary
REQ-108 Registry requirements for registration are : - Registration can only happen after successful validation. - Registration can only produce errors, no warnings. - Successful Registration of a Catalogue Item is mandatory prior to publication of any hierarchy containing that Catalogue Item. - ItemStatus needs to be included in GTIN data model to reflect validation and registration status. - Process registration command (for create, update, correct, delete). - Provide registration acknowledgement. Primary
REQ-109 A Data Recipient requests that it receive a “notification” when a specific event occurs that meets the Recipients criteria (selective on sources, categories, etc). This is subject to the recipient’s access to information as controlled by the data source through its source data pool. Primary
REQ-119 Future effective changes stored in the data pool are only reflected in the Global Registry when they become effective. Primary
REQ-121 Party: - GLN - Start Availability Date of the Party - Deletion Date of the Party - Registration Date - Source Data Pool Pointer [GLN used to ….] - GLN of Data Source (*Data Source is actually the ‘owner’ of the GLN data - Date and Time of last change - Party Validation Information (including Version, Date & Certificate ID) Primary
REQ-128 Source Data Pools must send notifications based on matching publications and subscriptions. Secondary
REQ-156 Subscription matches are performed at any level of the hierarchy. The data recipient is sent all hierarchies that match. Secondary

TOP
6. Distribute Data Receipient Requests for Catalogue Item Data
Use Case Diagram
Figure 11 - Distribute Data Receipient Requests for Catalogue Item Data Use Case Diagram
Use Case Name Distribute Data Recipient Requests for Catalogue Item Data
Traceability Identifier UC-47
Use Case Description This Use Case describes the processes that need to take place for Publications, Subscriptions and Confirmations to be moved throughout the Synchronisation System.
As a summary Use Case, specific processes will be further defined in the Detail Use Case section of this document.
Use Cases Above UC-1:Synchronise Catalogue Item Data
Use Cases Below UC-43: Distribute Confirmation DataUC-49Distribute Confirmation Data for a previously rejected Catalogue Item NotificationUC-22: Distribute Request for Notification
Actors Data SourceSource Data Pool (SDP)Global RegistryRecipient Data Pool (RDP)Data Recipient
Performance Goals Data Source: To obtain a copy of all subscriptions.
SDP: To have the proper criteria (Publications, Subscriptions and Confirmations) to allow distribution of Catalogue Item data to Data Recipients (via their Recipient Data Pool).
Global Registry: To be able to distribute Catalogue Item Subscriptions to the proper Source Data Pools.
RDP: To ensure Catalogue Item Subscriptions match the data that is being sent by SDPs.
Data Recipients: To control the type and volume of Catalogue Item Data received.
Preconditions

Postconditions
 
Scenario See detailed Use Cases for Scenarios
Alternative Scenario

Special Requirements  
Extension Points N/A
Requirements Covered

TOP
7. Distribute Catalogue Item Data
Use Case Diagram
Figure 12 - Distribute Catalogue Item Data Use Case Diagram
Use Case Name Distribute Catalogue Item Data
Traceability Identifier UC-29
Use Case Description Using the Distribution Criteria, the Catalogue Item Data are distributed from SDP to RDP and finally, to the Data Recipient.As a summary Use Case, specific processes will be further defined in the Detail Use Case section of this document.
Use Cases Above UC-1:Synchronise Catalogue Item Data
Use Cases Below UC-37:Distribute Catalogue Item Data from SDP to RDPUC-38:Distribute Catalogue Item Data from RDP to Data Recipient
Actors Source Data Pool (SDP)Recipient Data Pool (RDP)Data Recipient
Performance Goals SDP: Distribute Catalogue Item Data to the RDP based on the Distribution Criteria.
RDP: Distribute Catalogue Item Data to the Recipient based on the Distribution Criteria.Data Recipient: To receive Catalogue Item Data that complies with their Subscriptions and Confirmations.
Preconditions Publications, Subscriptions and Confirmations have been defined.The SDP knows which RDP needs to receive Catalogue Item Data for each Recipient.
Postconditions Data Recipient has received Catalogue Item Data that comply with their Subscriptions and Confirmations.
Scenario
  • SDP uses the Synchronisation List to filter the CatalogueItem Data.
  • SDP sends filtered Catalogue Item Data to the RDP.
  • RDP use Subscription and Confirmations to filter CatalogueItem Data.
  • RDP sends filtered Catalogue Item Data to the Data Recipient.
  • RDP sends appropriate Confirmations to the SDP.
Alternative Scenario None at this summary level
Special Requirements
Extension Points N/A
Requirements Covered See Detail Use Cases
TOP

DETAIL USE CASES

Use Case Diagram
Figure 1 - Add Catalogue Item Hierarchy Use Case Diagram
Use Case Name Add Catalogue Item Hierarchy
Traceability Identifier UC-3
Use Case Description The Add Catalogue Item Hierarchy use case describes what activities need to happen to validate and register Catalogue Item Hierarchy data.After the Catalogue Item Hierarchy data are validated and registered, they can then reside in the Source Data Pool for distribution.
Actors Data SourceSource Data Pool (SDP)Global Registry
Use Cases Above UC-2:Load and Update Catalogue Item Data within a Source Data Pool
Use Cases Below
 
Performance Goals Data Source: To have validated, registered Catalogue Item Hierarchy data in their Source Data Pool.
SDP: To have validated, registered Catalogue Item Hierarchy data.
Global Registry: To ensure valid, unique Catalogue Item data are registered.
Preconditions Data Source has defined Catalogue Item data and Catalogue Item hierarchies using Item Links.
Postconditions Data Source knows that Catalogue Item data has been validated and registered and Item Links have been validated.
Scenario Begins when, the Data Source sends, to the SDP, Catalogue Item Hierarchy data.
1. The SDP receives the Catalogue Item Hierarchy Data
2.The SDP validates the Catalogue Item Hierarchy data

3.The SDP sends a validation acknowledgement to the Data Source4.The Data Source receives the validation acknowledgement: Catalogue Item Hierarchy data loaded5.The SDP loads the Catalogue Item Hierarchy data6.The SDP sends the Registry Catalogue Item data of Catalogue Items that are not registered yet to the Global Registry7.The Global Registry receives the Registry Item data8.The Global Registry validates the Registry Item data for uniqueness9.The Global Registry registers the Registry Item data10.The Global Registry sends a registration acknowledgement to the SDP11. The SDP receives the registration acknowledgement12. The SDP storages the registration acknowledgement12. The SDP sends a registration acknowledgement to the Data Source
Ends when, the Data Source receives the registration acknowledgement: Catalogue Item data registered
Alternative Scenario ad 2.Validation fails: Catalogue Item Hierarchy data not loaded
2.1.SDP sends an validation error message to the Data SourceEnds when, the Data Source receives the validation error message
ad 7.Validation fails at the Global Registry: Catalogue Item data not registered
7.1.Global Registry sends a registration error message to the SDP7.2.The SDP receives the registration error message7.3.The SDP sends a registration error message to the Data Source

Ends when, the Data Source receives the registration error message
ad 3. & 11. The validation and registration acknowledgment messages can be combined
** SDP may not send Catalogue Item data to Registry for Uniqueness check w/o Registration.
Special Requirements
  • Data Source is using a(source) data pool.
  • Catalogue Item Hierarchydata consists of Catalogue Item data and Item Link data (ifapplicable).
Extension Points N/A
Requirements Covered  
ID Requirement Weight
REQ-1 Party data must exist prior to a Catalogue Item is being registered. Primary
REQ-2 Catalogue Item data must be validated prior to registration. Primary
REQ-3 Data Source must be able to add a Catalogue Item to the Source Data Pool. Secondary
REQ-8 EAN.UCC standards validation for GTIN and GLN format. Primary
REQ-9 Uniqueness validation for Item (GTIN/GLN/TM), Party (GLN) or data pool (GLN) – only applies to the occurrence of the key, not to the uniqueness of the information related to it. Primary
REQ-10 The Catalogue Item is identified by the following elements: GTIN, GLN, Target Market. Each combination of this key data found in the Global Registry must be unique. Primary
REQ-12 Every command needs a response and is handled according to the agreement between the parties involved. In the inter-operable network, acknowledgement messages are standardised and may contain the following information: - Confirmation of message receipt- Success / Failure of processing (syntax and content)- Reason for failure, with a code number and text message unique assigned to each failure Secondary
REQ-20 Synchronisation Lists must include every Catalogue Item (GTIN+GLN+TM) that needs to be synchronised. Primary
REQ-24 Notifications must NOT be sent in the following cases since data is not yet public and validated information: - Data load (add, change, etc…) - Data validation - Registration of new Catalogue Item Primary
REQ-26 Notification to the data recipient will always include the entire hierarchy. (Applies to add & update by adding a higher level) Primary
REQ-28 The updated hierarchy always fully replaces the current hierarchy. This action is called "Full Refresh". Primary
REQ-30 Only Catalogue Items are registered in the Global Registry. Not Catalogue Item Hierarchies. Primary
REQ-31 Validation acknowledgements are mandatory. Primary
REQ-32 Acknowledgement Reason codes must be unique. Primary
REQ-33 ItemLinks are identified by the parent GTIN key + child GTIN key + quantity contained. Secondary
REQ-34 ItemLinks are not registered or held within the Global Registry. Primary
REQ-45 Data source is sending full Hierarchies to the Source Data Pool. Secondary
REQ-46 New hierarchy replaces old hierarchy completely. Primary
REQ-92 “Single Data Source” Principle: - there can only be one official source of the data – the one that is registered - this source is identified by the data source - this is the only valid source for data synchronisation and related processes Primary
REQ-99 The Global Registry functionality requirements can be summarised as follows: - Enable data synchronisation - Validation, registration and subscription functions - Enable global validation - Checking compliance with basic EAN.UCC rules related to the format of a GTIN/GLN and ensuring the uniqueness of the data that is being registered - Enable global search functionality that does not require full duplication of data in the Global Registry. Primary
REQ-100 The Global Registry is involved in the following functions and/or business cases as defined in the Item Synchronisation detailed requirements: - Validation - Registration - Subscription - Global Search Primary
REQ-101 Registry Validation includes: - EAN.UCC standards validation for GTIN and GLN formats (i.e. check digit) - Uniqueness validation for Item (GTIN/GLN/TM), Party (GLN) or data pool (GLN), ensuring there is only one occurrence and data source for each data record as identified by the appropriate fields. Primary
REQ-102 Registry validation is a part of the registration process. Primary
REQ-104 In summary, the registry requirements for validation are: - EAN.UCC standards validation for GTIN/GLN formats - Uniqueness validation for Item, Party and data pool key - Store and maintain EAN.UCC standards - Process validation command - Provide validation acknowledgement Primary
REQ-105 Registration is the process, which references all Catalogue Items and Parties published in all certified data pools and on which there is a need to synchronise / retrieve information. This is supported by data storage in accordance with the Registry data scope and rules. Primary
REQ-106 Registering a Catalogue Item involves a check by the Global Registry for Item uniqueness. The Item is identified by the following elements: GTIN, GLN, Target Market. Each combination of this key data found in the Global Registry must be unique. When an Item is registered, the registry verifies that the combination of this data is unique to that Item. Primary
REQ-107 The registration process is triggered by the following business cases: 1. Create Catalogue Item: After the physical load and validation of the data, the registry record needs to be created before data can be published. 2. Update Catalogue Item: When a registered Catalogue Item is updated in its source data pool, updates impacting the Registry data must be reflected in the Global Registry, before the updated data can be propagated to the recipients. Registration of Catalogue Item changes only needs to happen for changes that: Impacts fields stored in the Global Registry. Are authorised according to the GTIN allocation rules. 3. Correct Catalogue Item: When a registered item is corrected in its source data pool, corrections impacting the Registry data must be reflected in the Global Registry before the updated data can be propagated to the data recipients. 4. Delete Catalogue Item: Deletions need to be reflected in the Global Registry: the discontinuation dates starts the EAN.UCC standard retention period (48 months for CPG, 36 months for apparel) as soon as GTIN has been discontinued in ALL target markets where it was active (needs to be stored in the Global Registry). 5. Cancel Catalogue Item: Communicates a trade item was never manufactured – this allows an earlier “reuse” of the GTIN i.o. standard retention period. This is achieved through the maintenance (using change function) of the cancel date. 6. Removing a Catalogue Item from the supply chain: The permanent removal of a Catalogue Item from the supply chain is achieved through the maintenance of a discontinuation date. This date has to be reflected in the Global Registry to kick off the EAN.UCC retention period. Temporary removals are not reflected in the Global Registry and only handled through the maintenance of the availability period in the data pools. Primary
REQ-108 Registry requirements for registration are: - Registration can only happen after successful validation. - Registration can only produce errors, no warnings. - Successful Registration of a Catalogue Item is mandatory prior to publication of any hierarchy containing that Catalogue Item. - ItemStatus needs to be included in GTIN data model to reflect validation and registration status. - Process registration command (for create, update, correct, delete). - Provide registration acknowledgement. Primary
REQ-159 Multiple independent hierarchies can co-exist at the data-pool for an item for example hierarchy 1 = case A – each A and hierarchy 2 = pallet A – case A –each A. Primary
REQ-171 The message identifier (CorrelationInformation: requestingDocu-mentInstanceIdentifier) at the document header levelfor the EAN.UCC response and the GDSN Exception must equal theDocumentIdentification: instanceIdentifier of the originalmessage. Primary

Activity Diagram
Figure 14 - Add Catalogue Item Hierarchy Activity Diagram
Sequence Diagram
Figure 15 - Add Catalogue Item Hierarchy Sequence Diagram
TOP
2. Change Catalogue Item Hierarchy
Use Case Diagram
Figure 8 - Change Catalogue Item Hierarchy Use Case Diagram
Use Case Name Change Catalogue Item Hierarchy
Traceability Identifier UC-4
Use Case Description The Change Catalogue Item Hierarchy use case describes what activities need to happen to change Catalogue Item Hierarchy data of a Catalogue Item already existing in a Source Data Pool, whether the Catalogue Item has been registered or not.
Use Cases Above UC-2:Load and Update Catalogue Item Data within a Source Data Pool
Use Cases Below UC-10:Change Catalogue ItemUC-11:Change Item Link
Actors Data SourceSource Data Pool (SDP)Global Registry
Performance Goals Data Source: To change Catalogue Item Hierarchy data in their Source Data Pool.
SDP: To have validated, registered updated Catalogue Item Hierarchy data.
Global Registry: To ensure valid, unique Catalogue Item data are registered, whether the Catalogue Item has been changed or not.
Preconditions Data Source has defined the changes to Catalogue Item data and Catalogue Item hierarchies (using Item Links) of a Catalogue Item already existing in a Source Data Pool.
Postconditions Data Source knows that updated Catalogue Item data has been validated and registered and updated Item Links have been validated.
Scenario Begins when, the Data Source sends, to the SDP, Catalogue Item Hierarchy data to be changed.
1.The SDP receives Catalogue Item Hierarchy data to be changed
2.The SDP validates Catalogue Item Hierarchy data to be changed3.The SDP sends a validation acknowledgement to the Data Source4.The Data Source receives the validation acknowledgement: Catalogue Item Hierarchy data changed5.The SDP loads the changed Catalogue Item Hierarchy data6.The SDP sends the Registry Item data (to be changed) to the Global Registry7.The Global Registry receives the Registry Item data to be changed8.The Global Registry validates the Registry Item data9.The Global Registry registers the changed Registry Item data
10. The Global Registry sends a registration acknowledgement to the SDP12. The SDP receives the registration acknowledgement13. The SDP storages the registration acknowledgement14. The SDP sends a registration acknowledgement to the Data Source
Ends when, the Data Source receives the registration acknowledgement: Catalogue Item data registered
Alternative Scenario ad 2.Validation fails: Catalogue Item Hierarchy data not loaded
2.1.SDP sends an validation error message to the Data SourceEnds when, the Data Source receives the validation error message
ad 7.Validation fails at the Global Registry: Catalogue Item data not registered
7.1.Global Registry sends a registration error message to the SDP7.2.The SDP receives the registration error message7.3.The SDP sends a registration error message to the Data Source

Ends when, the Data Source receives the registration error message
ad 3. & 11. The validation and registration acknowledgment messages can be combined
** SDP may not send Catalogue Item data to Registry for Uniqueness check w/o Registration.
Special Requirements
  • Data Source is using a(source) data pool.
  • Catalogue Item Hierarchydata consists of Catalogue Item data and Item Link data (if applicable).
  • Validation is done againstexisting data, applying GDD standard and GTIN allocation rules.
Extension Points N/A
Requirements Covered  
ID Requirement Weight
REQ-4 Data Source must be able to change Catalogue Item data in the Source Data Pool. Primary
REQ-8 EAN.UCC standards validation for GTIN and GLN format. Primary
REQ-9 Uniqueness validation for Item (GTIN/GLN/TM), Party (GLN) or data pool (GLN) – only applies to the occurrence of the key, not to the uniqueness of the information related to it. Primary
REQ-10 The Catalogue Item is identified by the following elements: GTIN, GLN, Target Market. Each combination of this key data found in the Global Registry must be unique. Primary
REQ-12 Every command needs a response and is handled according to the agreement between the parties involved. In the inter-operable network, acknowledgement messages are standardised and may contain the following information: - Confirmation of message receipt- Success / Failure of processing (syntax and content)- Reason for failure, with a code number and text message unique assigned to each failure Primary
REQ-20 Synchronisation Lists must include every Catalogue Item (GTIN+GLN+TM) that needs to be synchronised. Primary
REQ-24 Notifications must NOT be sent in the following cases since data is not yet public and validated information: - Data load (add, change, etc…) - Data validation - Registration of new Catalogue Item Primary
REQ-30 Only Catalogue Items are registered in the Global Registry. Not Catalogue Item Hierarchies. Primary
REQ-31 Validation acknowledgements are mandatory. Primary
REQ-32 Acknowledgement Reason codes must be unique. Primary
REQ-33 ItemLinks are identified by the parent GTIN key + child GTIN key + quantity contained. Primary
REQ-34 ItemLinks are not registered or held within the Global Registry. Primary
REQ-35 Changes have to comply with validation rules. Secondary
REQ-36 If the Catalogue Item was registered, updates impacting the Registry data must be reflected in the Global Registry. Primary
REQ-37 Registration of Catalogue Item changes only needs to happen for changes that: - Impact fields stored in the Global Registry. - Are authorised according to the GTIN allocation rules. Primary
REQ-38 The change function implies a full refresh of all attributes of the previously created Catalogue Item – this will be reflected in the subsequent notification, including a full refresh of the changed record of the full hierarchy. Secondary
REQ-45 Data source is sending full Hierarchies to the Source Data Pool. Primary
REQ-46 New hierarchy replaces old hierarchy completely. Secondary
REQ-92 “Single Data Source” Principle: - there can only be one official source of the data – the one that is registered - this source is identified by the data source - this is the only valid source for data synchronisation and related processes Primary
REQ-99 The Global Registry functionality requirements can be summarised as follows: - Enable data synchronisation - Validation, registration and subscription functions - Enable global validation - Checking compliance with basic EAN.UCC rules related to the format of a GTIN/GLN and ensuring the uniqueness of the data that is being registered - Enable global search functionality that does not require full duplication of data in the Global Registry. Primary
REQ-100 The Global Registry is involved in the following functions and/or business cases as defined in the Item Synchronisation detailed requirements: - Validation - Registration - Subscription - Global Search Primary
REQ-101 Registry Validation includes: - EAN.UCC standards validation for GTIN and GLN formats (i.e. check digit) - Uniqueness validation for Item (GTIN/GLN/TM), Party (GLN) or data pool (GLN), ensuring there is only one occurrence and data source for each data record as identified by the appropriate fields. Primary
REQ-102 Registry validation is a part of the registration process. Primary
REQ-104 In summary, the registry requirements for validation are: - EAN.UCC standards validation for GTIN/GLN formats - Uniqueness validation for Item, Party and data pool key - Store and maintain EAN.UCC standards - Process validation command - Provide validation acknowledgement Primary
REQ-105 Registration is the process, which references all Catalogue Items and Parties published in all certified data pools and on which there is a need to synchronise / retrieve information. This is supported by data storage in accordance with the Registry data scope and rules. Primary
REQ-106 Registering a Catalogue Item involves a check by the Global Registry for Item uniqueness. The Item is identified by the following elements: GTIN, GLN, Target Market. Each combination of this key data found in the Global Registry must be unique. When an Item is registered, the registry verifies that the combination of this data is unique to that Item. Primary
REQ-107 The registration process is triggered by the following business cases: 1. Create Catalogue Item: After the physical load and validation of the data, the registry record needs to be created before data can be published. 2. Update Catalogue Item: When a registered Catalogue Item is updated in its source data pool, updates impacting the Registry data must be reflected in the Global Registry, before the updated data can be propagated to the recipients. Registration of Catalogue Item changes only needs to happen for changes that: Impacts fields stored in the Global Registry. Are authorised according to the GTIN allocation rules. 3. Correct Catalogue Item: When a registered item is corrected in its source data pool, corrections impacting the Registry data must be reflected in the Global Registry before the updated data can be propagated to the data recipients. 4. Delete Catalogue Item: Deletions need to be reflected in theGlobal Registry: the discontinuation dates starts the EAN.UCC standard retention period (48 months for CPG, 36 months for apparel) as soon as GTIN has been discontinued in ALL target markets where it was active (needs to be stored in the Global Registry). 5. Cancel Catalogue Item: Communicates a trade item was never manufactured – this allows an earlier “reuse” of the GTIN i.o. standard retention period. This is achieved through the maintenance (using change function) of the cancel date. 6. Removing an Catalogue Item from the supply chain: The permanent removal of a Catalogue Item from the supply chain is achieved through the maintenance of a discontinuation date.This date has to be reflected in the Global Registry to kick off the EAN.UCC retention period. Temporary removals are not reflected in the Global Registry and only handled through the maintenance of the availability period in the data pools. Primary
REQ-108 Registry requirements for registration are: - Registration can only happen after successful validation. - Registration can only produce errors, no warnings. - Successful Registration of a Catalogue Item is mandatory prior to publication of any hierarchy containing that Catalogue Item. - ItemStatus needs to be included in GTIN data model to reflect validation and registration status. - Process registration command (for create, update, correct, delete). - Provide registration acknowledgement. Primary
REQ-118 Changes/corrections applied to the Global Registry are effective immediately. Primary
REQ-119 Future effective changes stored in the data pool are only reflected in the Global Registry when they become effective. Primary
REQ-171  The message identifier (CorrelationInformation: requestingDocu-mentInstanceIdentifier) at the document header levelfor the EAN.UCC response and the GDSN Exception must equal theDocumentIdentification: instanceIdentifier of the original message. Primary

Activity Diagram
Figure 9 - Change Catalogue Item Hierarchy Activity Diagram
Sequence Diagram
Figure 10 - Change Catalogue Item Hierarchy Sequence Diagram
TOP
3. Correct Catalogue Item Hierarchy
Use Case Diagram
Figure 16 - Correct Catalogue Item Hierarchy Use Case Diagram
Use Case Name Correct Catalogue Item Hierarchy
Traceability Identifier UC-5
Use Case Description The Correct Catalogue Item Hierarchy use case describes what activities need to happen to correct Catalogue Item Hierarchy data of a Catalogue Item already existing in a Source Data Pool, whether the Catalogue Item has been registered or not.A correction allows a Data Source to make changes to Catalogue Item data and hierarchy that would not be allowed by validation rules and as such is outside of normal processing.It is intended to provide a means for errors to be corrected and not as an alternative to the Change Catalogue Item Hierarchy process.A Data Source should expect that a Correct Catalogue Item Hierarchy message may be scrutinized more closely by the Data Recipient and possibly incur a delay in processing.
Use Cases Above UC-2:Load and Update Catalogue Item Data within a Source Data Pool
Use Cases Below
Actors Data SourceSource Data Pool (SDP)Global Registry
Performance Goals Data Source: To make corrections to errors in Catalogue Item Hierarchy data and have those corrections reflected in their Source Data Pool.SDP: To have validated, registered updated Catalogue Item Hierarchy data.
Global Registry: To ensure valid, unique Catalogue Item data are registered, whether the Catalogue Item has been corrected or not.
Preconditions Data Source has defined the corrections to Catalogue Item data and Catalogue Item hierarchies (using Item Links) of a Catalogue Item already existing in a Source Data Pool.
Postconditions Data Source knows that corrected Catalogue Item data has been validated and registered and corrected Item Links have been validated.
Scenario Begins ...when, the Data Source sends, to the SDP, Catalogue Item Hierarchy data to be corrected.
1.The SDP receives Catalogue Item Hierarchy data to be corrected2.The SDP validates Catalogue Item Hierarchy data to be corrected3.The SDP sends a validation acknowledgement to the Data Source4.The Data Source receives the validation acknowledgement: Catalogue Item Hierarchy data corrected5.The SDP loads the corrected Catalogue Item Hierarchy data6.The SDP sends the Registry Item data (to be corrected) to the Global Registry7.The Global Registry receives the Registry Item data to be corrected8.The Global Registry checks that the Catalogue Item exists in the Registry.9.The Global Registry registers the corrected Registry Item data
10. The Global Registry sends a registration acknowledgement to the SDP11. The SDP receives the registration acknowledgement12. The SDP stores the registration acknowledgement13. The SDP sends a registration acknowledgement to the Data Source
Ends ...when, the Data Source receives the registration acknowledgement: Catalogue Item data registered
Alternative Scenario ad 2.Validation fails: Catalogue Item Hierarchy data not loaded
2.1.SDP sends an validation error message to the Data SourceEnds when, the Data Source receives the validation error message
ad 8.The Catalogue Item is not found in the Registry: Catalogue Item data not registered
8.1.Global Registry sends a registration error message to the SDP8.2.The SDP receives the registration error message8.3.The SDP sends a registration error message to the Data SourceEnds when, the Data Source receives the registration error messagead 3. & 13. The validation and registration acknowledgment messages can be combined
** SDP may not send Catalogue Item data to Registry for Uniqueness check w/o Registration.
Special Requirements
  • Data Source is using a(source) data pool.
  • Catalogue Item Hierarchydata consists of Catalogue Item data and Item Link data (if applicable).
  • Validation is done againstexisting data, applying GDD standard and GTIN allocation rules.
  • Catalogue Item Hierarchydata bypasses the GTIN Allocation Rules
Extension Points N/A
Requirements Covered  
ID Requirement Weight
REQ-5 Data Source must be able to correct Catalogue Item data in the Source Data Pool. Primary
REQ-8 EAN.UCC standards validation for GTIN and GLN format. Primary
REQ-9 Uniqueness validation for Item (GTIN/GLN/TM), Party (GLN) or data pool (GLN) – only applies to the occurrence of the key, not to the uniqueness of the information related to it. Primary
REQ-10 The Catalogue Item is identified by the following elements: GTIN, GLN, Target Market. Each combination of this key data found in the Global Registry must be unique. Primary
REQ-11 Corrections bypass the standard GTIN/GLN allocation rules. Primary
REQ-12 Every command needs a response and is handled according to the agreement between the parties involved. In the inter-operable network, acknowledgement messages are standardised and may contain the following information: - Confirmation of message receipt- Success / Failure of processing (syntax and content)- Reason for failure, with a code number and text message unique assigned to each failure Primary
REQ-20 Synchronisation Lists must include every Catalogue Item (GTIN+GLN+TM) that needs to be synchronised. Primary
REQ-21 If a Catalogue Item is "Confirmed of Synchronisation" then all Catalogue items below in the Catalogue Item Hierarchy shall be included in the Synchronisation list. Primary
REQ-22 Relationship dependent data will only be communicated for Synchronised, Review or Accept status in the Synchronisation List. Primary
REQ-23 Events that can trigger notifications are: - Publication of new data / change of publication - Change of published Catalogue Item / Party / Partner Profile - Change of owner, rights - Subscription - Synchronisation List - Confirmation/ Rejection - Request for Notification - Any successful matching process Primary
REQ-24 Notifications must NOT be sent in the following cases since data is not yet public and validated information: - Data load (add, change, etc…) - Data validation - Registration of new Catalogue Item Primary
REQ-26 Notification to the data recipient will always include the entire hierarchy. (Applies to add & update by adding a higher level) Primary
REQ-27 In case of an ItemLink correction, the entire hierarchy will be indicated as corrected in the notification. Secondary
REQ-28 The updated hierarchy always fully replaces the current hierarchy. This action is called "Full Refresh". Secondary
REQ-30 Only Catalogue Items are registered in the Global Registry. Not Catalogue Item Hierarchies. Primary
REQ-31 Validation acknowledgements are mandatory. Primary
REQ-32 Acknowledgement Reason codes must be unique. Primary
REQ-33 ItemLinks are identified by the parent GTIN key + child GTIN key + quantity contained. Primary
REQ-34 ItemLinks are not registered or held within the Global Registry. Primary
REQ-36 If the Catalogue Item was registered, updates impacting the Registry data must be reflected in the Global Registry. Primary
REQ-37 Registration of Catalogue Item changes only needs to happen for changes that: - Impact fields stored in the Global Registry. - Are authorised according to the GTIN allocation rules. Primary
REQ-40 Incorrect core data (i.e. attributes that cannot be updated according to allocation rules) can only be updated through a specific correction functionality. Secondary
REQ-41 Correct Item Hierarchy must: - trigger syntactical and content validation - skip GTIN allocation rules validation - set a flag on the GTIN data record to inform the data recipient of the correction (see data distribution / notification) - the correction will also be reflected in the Global Registry if it impacts Registry data Secondary
REQ-42 If the correction impacts the hierarchy, then it must be handled by deleting the incorrect ItemLink and adding a new Item Link - Add/Delete Scenario’s. Secondary
REQ-43 If the correction does not impact the hierarchy, then ItemLink attributes will be updated through the correction command. Primary
REQ-44 Notification of the hierarchy must indicate it is a correction. Secondary
REQ-45 Data source is sending full Hierarchies to the Source Data Pool. Primary
REQ-46 New hierarchy replaces old hierarchy completely. Primary
REQ-57 A deletion cannot be corrected – only the discontinuation can be reversed. Primary
REQ-59 ItemLinks can only be deleted: - as the correction of an error - as the result of a delete Item. Primary
REQ-92 “Single Data Source” Principle: - there can only be one official source of the data – the one that is registered - this source is identified by the data source - this is the only valid source for data synchronisation and related processes Primary
REQ-99 The Global Registry functionality requirements can be summarised as follows: - Enable data synchronisation - Validation, registration and subscription functions - Enable global validation - Checking compliance with basic EAN.UCC rules related to the format of a GTIN/GLN and ensuring the uniqueness of the data that is being registered - Enable global search functionality that does not require full duplication of data in the Global Registry. Primary
REQ-100 The Global Registry is involved in the following functions and/or business cases as defined in the Item Synchronisation detailed requirements: - Validation - Registration - Subscription - Global Search Primary
REQ-101 Registry Validation includes: - EAN.UCC standards validation for GTIN and GLN formats (i.e. check digit) - Uniqueness validation for Item (GTIN/GLN/TM), Party (GLN) or data pool (GLN), ensuring there is only one occurrence and data source for each data record as identified by the appropriate fields. Primary
REQ-102 Registry validation is a part of the registration process. Primary
REQ-104 In summary, the registry requirements for validation are: - EAN.UCC standards validation for GTIN/GLN formats - Uniqueness validation for Item, Party and data pool key - Store and maintain EAN.UCC standards - Process validation command - Provide validation acknowledgement Primary
REQ-105 Registration is the process, which references all Catalogue Items and Parties published in all certified data pools and on which there is a need to synchronise / retrieve information. This is supported by data storage in accordance with the Registry data scope and rules. Primary
REQ-106 Registering a Catalogue Item involves a check by the Global Registry for Item uniqueness. The Item is identified by the following elements: GTIN, GLN, Target Market. Each combination of this key data found in the Global Registry must be unique. When an Item is registered, the registry verifies that the combination of this data is unique to that Item. Primary
REQ-107 The registration process is triggered by the following business cases: 1. Create Catalogue Item: After the physical load and validation of the data, the registry record needs to be created before data can be published. 2. Update Catalogue Item: When a registered Catalogue Item is updated in its source data pool, updates impacting the Registry data must be reflected in the Global Registry, before the updated data can be propagated to the recipients. Registration of Catalogue Item changes only needs to happen for changes that: Impacts fields stored in the Global Registry. Are authorised according to the GTIN allocation rules. 3. Correct Catalogue Item: When a registered item is corrected in its source data pool, corrections impacting the Registry data must be reflected in the Global Registry before the updated data can be propagated to the data recipients. 4. Delete Catalogue Item: Deletions need to be reflected in the Global Registry: the discontinuation dates starts the EAN.UCC standard retention period (48 months for CPG, 36 months for apparel) as soon as GTIN has been discontinued in ALL target markets where it was active (needs to be stored in the Global Registry). 5. Cancel Catalogue Item: Communicates a trade item was never manufactured – this allows an earlier “reuse” of the GTIN i.o. standard retention period. This is achieved through the maintenance (using change function) of the cancel date. 6. Removing an Catalogue Item from the supply chain: The permanent removal of a Catalogue Item from the supply chain is achieved through the maintenance of a discontinuation date. This date has to be reflected in the Global Registry to kick off the EAN.UCC retention period. Temporary removals are not reflected in the Global Registry and only handled through the maintenance of the availability period in the data pools. Primary
REQ-108 Registry requirements for registration are: - Registration can only happen after successful validation. - Registration can only produce errors, no warnings. - Successful Registration of a Catalogue Item is mandatory prior to publication of any hierarchy containing that Catalogue Item. - ItemStatus needs to be included in GTIN data model to reflect validation and registration status. - Process registration command (for create, update, correct, delete). - Provide registration acknowledgement. Primary
REQ-118 Changes/corrections applied to the Global Registry are effective immediately. Primary
REQ-119 Future effective changes stored in the data pool are only reflected in the Global Registry when they become effective. Primary
REQ-159 Multiple independent hierarchies can co-exist at the data-pool for an item for example hierarchy 1 = case A – each A and hierarchy 2 = pallet A – case A –each A. Primary
REQ-171 The message identifier (CorrelationInformation: requestingDocu-mentInstanceIdentifier) at the document header levelfor the EAN.UCC response and the GDSN Exception must equal theDocumentIdentification: instanceIdentifier of the originalmessage. Primary

Activity Diagram
Figure 17 - Correct Catalogue Item Hierarchy Data Activity Diagram
Sequence Diagram
Figure 18 - Correct Catalogue Item Hierarchy Sequence Diagram
TOP
4. Discontinue Catalogue Item
Use Case Diagram
Figure 19 - Discontinue Catalogue Item Use Case Diagram
Use Case Name Discontinue Catalogue Item
Traceability Identifier UC-6
Use Case Description This use case describes the process to flag a Catalogue Item for deletion, authorising the deletion of the Catalogue Item Data.When an item is discontinued in the GDSN, the waiting period for the GTIN before it can be reused for an item has to be aligned with the specific industry requirement (as defined by GS1 GTIN allocation rules). After the discontinuation period lapses, all parties are free to delete the Item from their databases.
This process is a special case of the Change Catalogue Item in that it uses the Change Catalogue Item process to set the discontinuation flag and date.
Use Cases Above UC-2:Load and Update Catalogue Item Data within a Source Data Pool
Use Cases Below UC-21:Delete Registered Catalogue Item
Actors Data SourceSource Data Pool (SDP)Global Registry
Performance Goals Data Source: To be able to discontinue Catalogue Item Data in the SDP (and in the Global Registry).

SDP: To discontinue Catalogue Item Data upon request of the Data Source. SDP sends the RCI to the GS1 GR, and after some time sends the updated CIN to all recipients currently synchronizing on the item with the discontinue information.GS1 Global Registry: To discontinue Catalogue Item Data upon request of a SDP. The GS1 GR determines the GTIN reuse period for this industry type of trade item, calculates the deletion date and updates the existing state as needed.
Preconditions The SDP has identified the Catalogue Item Data to be discontinued.
Postconditions The Data Source has received the discontinue acknowledgement: Catalogue Item data discontinued
Scenario Begins when, the Data Source sends the Catalogue Item Data to be discontinued to the SDP. 1.The SDP receives the Catalogue Item Data to be discontinued to the SDP.
2.The SDP validates the Catalogue Item Data against:
  • Publication status
  • Availability status (end availability + discontinued Y/N)
  • Hierarchy (parents have to be deleted before children)
3. The SDP discontinues the Catalogue Item Data4. The SDP discontinues any Item Link involving the Catalogue Item Data5. The SDP sends the Registry Item data to be discontinued to the Global Registry6. The Global Registry receives the Registry Item data to be discontinued7. The Global Registry validates the Registry Item data8. The Global Registry discontinues the Registry Item data (deletion flag + effective change date = deletion date in the Global Registry)9. The Global Registry sends a discontinue acknowledgement to the SDP10.The SDP receives the discontinue acknowledgement11.The SDP sends the discontinue acknowledgement to the Data Source
Ends when, the Data Source receives the discontinue acknowledgement: Catalogue Item data discontinued
Alternative Scenario ad 2.Validation fails: Catalogue Item data not discontinued
2.1.SDP sends a discontinue validation error message to the Data SourceEnds when, the Data Source receives the discontinue validation error message
ad 7.Validation fails: Catalogue Item data not discontinued7.1.Global Registry sends a discontinue validation error message to the SDP7.2.The SDP receives the discontinue validation error message7.3.The SDP sends a discontinue validation error message to the Data SourceEnds when, the Data Source receives the discontinue validation error message
Special Requirements
  • The discontinuation datestarts the standard retention period depending on the sector as soon asGTIN has been discontinued in ALL target markets where it was active(needs to be stored in the registry).
  • A deletion cannot be corrected – only the discontinuation can be reversed.
  • Deletes are notsynchronised across data pools.
Extension Points N/A
Requirements Covered
ID Requirement Weight
REQ-12 Every command needs a response and is handled according to the agreement between the parties involved. In the inter-operable network, acknowledgement messages are standardised and may contain the following information: - Confirmation of message receipt- Success / Failure of processing (syntax and content)- Reason for failure, with a code number and text message unique assigned to each failure Primary
REQ-20 Synchronisation Lists must include every Catalogue Item (GTIN+GLN+TM) that needs to be synchronised. Primary
REQ-21 If an Catalogue Item is "Confirmed of Synchronisation" then all Catalogue items below in the Catalogue Item Hierarchy shall be included in the Synchronisation list. Primary
REQ-22 Relationship dependent data will only be communicated for Synchronised, Review or Accept status in the Synchronisation List. Primary
REQ-23 Events that can trigger notifications are: - Publication of new data / change of publication - Change of published Catalogue Item / Party / Partner Profile - Change of owner, rights - Subscription - Synchronisation List - Confirmation/ Rejection - Request for Notification - Any successful matching process Primary
REQ-24 Notifications must NOT be sent in the following cases since data is not yet public and validated information: - Data load (add, change, etc…) - Data validation - Registration of new Catalogue Item Primary
REQ-26 Notification to the data recipient will always include the entire hierarchy. (Applies to add & update by adding a higher level) Primary
REQ-30 Only Catalogue Items are registered in the Global Registry. Not Catalogue Item Hierarchies. Primary
REQ-31 Validation acknowledgements are mandatory. Primary
REQ-32 Acknowledgement Reason codes must be unique. Primary
REQ-34 ItemLinks are not registered or held within the Global Registry. Primary
REQ-36 If the Catalogue Item was registered, updates impacting the Registry data must be reflected in the Global Registry. Primary
REQ-37 Registration of Catalogue Item changes only needs to happen for changes that: - Impact fields stored in the Global Registry. - Are authorised according to the GTIN allocation rules. Primary
REQ-45 Data source is sending full Hierarchies to the Source Data Pool. Primary
REQ-46 New hierarchy replaces old hierarchy completely. Primary
REQ-49 Rules for archiving or physical deletes will be agreed with the data pools and in the scope of the certification process. Primary
REQ-56 The discontinuation dates starts the standard retention period depending on the sector as soon as GTIN has been discontinued in ALL target markets where it was active (needs to be stored in the Global Registry). Secondary
REQ-57 A deletion cannot be corrected – only the discontinuation can be reversed. Primary
REQ-67 Communicate the product is no longer going to be manufactured: discontinued = Y + effective change date = discontinued date in the Global Registry. Secondary
REQ-68 Communicate the product is no longer going to be available: maintain end availability date. Secondary
REQ-92 “Single Data Source” Principle: - there can only be one official source of the data – the one that is registered - this source is identified by the data source - this is the only valid source for data synchronisation and related processes Primary
REQ-99 The Global Registry functionality requirements can be summarised as follows: - Enable data synchronisation - Validation, registration and subscription functions - Enable global validation - Checking compliance with basic EAN.UCC rules related to the format of a GTIN/GLN and ensuring the uniqueness of the data that is being registered - Enable global search functionality that does not require full duplication of data in the Global Registry. Primary
REQ-100 The Global Registry is involved in the following functions and/or business cases as defined in the Item Synchronisation detailed requirements: - Validation - Registration - Subscription - Global Search Primary
REQ-101 Registry Validation includes: - EAN.UCC standards validation for GTIN and GLN formats (i.e. check digit) - Uniqueness validation for Item (GTIN/GLN/TM), Party (GLN) or data pool (GLN), ensuring there is only one occurrence and data source for each data record as identified by the appropriate fields. Primary
REQ-102 Registry validation is a part of the registration process. Primary
REQ-104 In summary, the registry requirements for validation are: - EAN.UCC standards validation for GTIN/GLN formats - Uniqueness validation for Item, Party and data pool key - Store and maintain EAN.UCC standards - Process validation command - Provide validation acknowledgement Primary
REQ-105 Registration is the process, which references all Catalogue Items and Parties published in all certified data pools and on which there is a need to synchronise / retrieve information. This is supported by data storage in accordance with the Registry data scope and rules. Primary
REQ-106 Registering a Catalogue Item involves a check by the Global Registry for Item uniqueness. The Item is identified by the following elements: GTIN, GLN, Target Market. Each combination of this key data found in the Global Registry must be unique. When an Item is registered, the registry verifies that the combination of this data is unique to that Item. Primary
REQ-107 The registration process is triggered by the following business cases: 1. Create Catalogue Item: After the physical load and validation of the data, the registry record needs to be created before data can be published. 2. Update Catalogue Item: When a registered Catalogue Item is updated in its source data pool, updates impacting the Registry data must be reflected in the Global Registry, before the updated data can be propagated to the recipients. Registration of Catalogue Item changes only needs to happen for changes that: Impacts fields stored in the Global Registry. Are authorised according to the GTIN allocation rules. 3. Correct Catalogue Item: When a registered item is corrected in its source data pool, corrections impacting the Registry data must be reflected in the Global Registry before the updated data can be propagated to the data recipients. 4. Delete Catalogue Item: Deletions need to be reflected in the Global Registry: the discontinuation dates starts the EAN.UCC standard retention period (48 months for CPG, 36 months for apparel) as soon as GTIN has been discontinued in ALL target markets where it was active (needs to be stored in the Global Registry). 5. Cancel Catalogue Item: Communicates a trade item was never manufactured – this allows an earlier “reuse” of the GTIN i.o. standard retention period. This is achieved through the maintenance (using change function) of the cancel date. 6. Removing an Catalogue Item from the supply chain: The permanent removal of a Catalogue Item from the supply chain is achieved through the maintenance of a discontinuation date. This date has to be reflected in the Global Registry to kick off the EAN.UCC retention period. Temporary removals are not reflected in the Global Registry and only handled through the maintenance of the availability period in the data pools. Primary
REQ-108 Registry requirements for registration are: - Registration can only happen after successful validation. - Registration can only produce errors, no warnings. - Successful Registration of a Catalogue Item is mandatory prior to publication of any hierarchy containing that Catalogue Item. - ItemStatus needs to be included in GTIN data model to reflect validation and registration status. - Process registration command (for create, update, correct, delete). - Provide registration acknowledgement. Primary
REQ-118 Changes/corrections applied to the Global Registry are effective immediately. Primary
REQ-119 Future effective changes stored in the data pool are only reflected in the Global Registry when they become effective. Primary
REQ-159 Multiple independent hierarchies can co-exist at the data-pool for an item for example hierarchy 1 = case A – each A and hierarchy 2 = pallet A – case A –each A. Primary
REQ-171 The message identifier (CorrelationInformation: requestingDocu-mentInstanceIdentifier) at the document header levelfor the EAN.UCC response and the GDSN Exception must equal theDocumentIdentification: instanceIdentifier of the originalmessage. Primary
REQ 185 The deletion date is updated by the GS1 GR, adding either the cancellation or discontinue timeframe to the cancel or discontinue dates respectively. Primary
REQ 186 At the end of the time period, which differs per industry, the deletion date becomes current and the item is actually deleted Primary
REQ 187 The GS1 GR must receive the GPC code information in order7to calculate the deletion date properly Primary
REQ 188 The GS1 GR will maintain a cross-reference table for the GPC brick level codes and a corresponding GTIN Reuse Time Primary
REQ 189 The GS1 GR will maintain an additional field to establish the GTIN reuse timeframe based on each industry’s guidelines Primary
REQ 190 When an item is discontinued in the GDSN, the waiting period for the GTIN before it can be reused for an item has to be aligned with the specific industry requirement:
- clothing, footwear and personal accessories apply a 30 month rule to the discontinue date
- Fast Moving Consumer Goods GTINs can be reused after a 48 month period to the discontinue date and
-12 month rule applies to the cancel date.
Note: Clothing, footwear and personal accessories are defined as being all GPC bricks contained within the following GPC Segments:
63000000 Footwear
67000000 Clothing
64000000 Personal Accessories
It is assumed for this BSD that all other established GPC Segments and their associated Bricks will follow the 48 month period to the discontinue date until the specific industry rule and associated GPCs are established.
Primary
REQ 191 When an item has a discontinue date, the state of the item does not get updated until that date becomes current. Primary
REQ 192 The Global Registry must support a Registry CatalogueItem State of “DELETED”. Primary

Activity Diagram
Figure 20 - Discontinue Catalogue Item Activity Diagram
Sequence Diagram
Figure 21 - Discontinue Catalogue Item Sequence Diagram
TOP
5. Delete Catalogue Item Hierarchy
Use Case Diagram
Figure 22 - Delete Catalogue Item Hierarchy Use Case Diagram
Use Case Name Delete Catalogue Item Hierarchy
Traceability Identifier UC-25
Use Case Description This use case describes the process to remove a Catalogue Item from the Source Data Pool.
Use Cases Above UC-2:Load and Update Catalogue Item Data within a Source Data Pool
Use Cases Below None
Actors Data SourceSource Data Pool (SDP)Global Registry
Performance Goals Data Source: To be able to remove a discontinued or canceled Catalogue Item Data in the SDP (and in the Global Registry).
SDP: To be able to remove a discontinued or cancelled Catalogue Item Data.
Global Registry: To remove a discontinued or cancelled Catalogue Item Data.
Preconditions The SDP has either discontinued or cancelled a Catalogue Item within the timeframe allowed by EAN.UCC standards.
Postconditions The Catalogue Item has been removed from the SDP and Registry.
Scenario No scenario.
The SDP and Registry may remove (physically delete) a Catalogue Item that has been Cancelled or Discontinued for a period described in the EAN.UCC General Specification.
Alternative Scenario None
Special Requirements

Extension Points N/A
Requirements Covered
ID Requirement Weight
REQ-6 Data Source must be able to delete Catalogue Item data in the Source Data Pool. Primary
REQ-7 If a Catalogue Item is deleted:- the links pointing down must be deleted- all links above must be deleted- all Items above must be deleted Primary
REQ-12 Every command needs a response and is handled according to the agreement between the parties involved. In the inter-operable network, acknowledgement messages are standardised and may contain the following information: - Confirmation of message receipt- Success / Failure of processing (syntax and content)- Reason for failure, with a code number and text message unique assigned to each failure Primary
REQ-20 Synchronisation Lists must include every Catalogue Item (GTIN+GLN+TM) that needs to be synchronised. Primary
REQ-21 If an Catalogue Item is "Confirmed of Synchronisation" then all Catalogue items below in the Catalogue Item Hierarchy shall be included in the Synchronisation list. Primary
REQ-22 Relationship dependent data will only be communicated for Synchronised, Review or Accept status in the Synchronisation List. Primary
REQ-23 Events that can trigger notifications are: - Publication of new data / change of publication - Change of published Catalogue Item / Party / Partner Profile - Change of owner, rights - Subscription - Synchronisation List - Confirmation/ Rejection - Request for Notification - Any successful matching process Primary
REQ-24 Notifications must NOT be sent in the following cases since data is not yet public and validated information: - Data load (add, change, etc…) - Data validation - Registration of new Catalogue Item Primary
REQ-26 Notification to the data recipient will always include the entire hierarchy. (Applies to add & update by adding a higher level) Primary
REQ-30 Only Catalogue Items are registered in the Global Registry. Not Catalogue Item Hierarchies. Primary
REQ-31 Validation acknowledgements are mandatory. Primary
REQ-32 Acknowledgement Reason codes must be unique. Primary
REQ-33 ItemLinks are identified by the parent GTIN key + child GTIN key + quantity contained. Primary
REQ-34 ItemLinks are not registered or held within the Global Registry. Primary
REQ-36 If the Catalogue Item was registered, updates impacting the Registry data must be reflected in the Global Registry. Primary
REQ-37 Registration of Catalogue Item changes only needs to happen for changes that: - Impact fields stored in the Global Registry. - Are authorised according to the GTIN allocation rules. Primary
REQ-45 Data source is sending full Hierarchies to the Source Data Pool. Primary
REQ-46 New hierarchy replaces old hierarchy completely. Primary
REQ-47 The objective of the “Delete” Function is not to physically remove data from the data pool, but to “Flag for deletion”, authorising the deletion of the data. Primary
REQ-48 The deletion needs to be validated against a number of criteria, e.g. Item is no longer published, item discontinued, retention limit (EAN/UCC specifications)... Secondary
REQ-49 Rules for archiving or physical deletes will be agreed with the data pools and in the scope of the certification process. Primary
REQ-50 Deletions need to be reflected in the registry (deletion flag + effective change date = deletion date in the Global Registry) Primary
REQ-51 To protect data integrity within the data pool, the deletion of a child can only occur after the deletion of the parents. Primary
REQ-52 Validation for deleted Items ensures the parents have been deleted before the deletion of the child is performed. Primary
REQ-53 Validation is automatically triggered by the “Delete” command and does not require a specific message flow. Primary
REQ-54 Deletion of a Catalogue Item must trigger the invalidation of any hierarchy links involving that Item, whether that Item is the parent or the child in the link. This is completed by the Refresh.ItemLink message. Ackn.ItemLink will be repeated for every link that was refreshed or invalidated. Primary
REQ-55 Deletion needs to be validated against: - Publication status - Availability Status (end availability + discontinued Y/N) - Hierarchy: parents have to be deleted before children Primary
REQ-57 A deletion cannot be corrected – only the discontinuation can be reversed. Primary
REQ-58 Deletes are not synchronised across data pools. Primary
REQ-59 ItemLinks can only be deleted: - as the correction of an error - as the result of a delete.Item Secondary
REQ-60 The validity period of a ItemLink is defined by the validity period of the Parent Item and/or the Child Item. Secondary
REQ-61 When either parent or child expire, the related ItemLink(s) have to expire as well. This is achieved through the Refresh.ItemLink function. Secondary
REQ-92 “Single Data Source” Principle: - there can only be one official source of the data – the one that is registered - this source is identified by the data source - this is the only valid source for data synchronisation and related processes Primary
REQ-99 The Global Registry functionality requirements can be summarised as follows: - Enable data synchronisation - Validation, registration and subscription functions - Enable global validation - Checking compliance with basic EAN.UCC rules related to the format of a GTIN/GLN and ensuring the uniqueness of the data that is being registered - Enable global search functionality that does not require full duplication of data in the Global Registry. Primary
REQ-100 The Global Registry is involved in the following functions and/or business cases as defined in the Item Synchronisation detailed requirements: - Validation - Registration - Subscription - Global Search Primary
REQ-101 Registry Validation includes: - EAN.UCC standards validation for GTIN and GLN formats (i.e. check digit) - Uniqueness validation for Item (GTIN/GLN/TM), Party (GLN) or data pool (GLN), ensuring there is only one occurrence and data source for each data record as identified by the appropriate fields. Primary
REQ-102 Registry validation is a part of the registration process. Primary
REQ-104 In summary, the registry requirements for validation are: - EAN.UCC standards validation for GTIN/GLN formats - Uniqueness validation for Item, Party and data pool key - Store and maintain EAN.UCC standards - Process validation command - Provide validation acknowledgement Primary
REQ-105 Registration is the process, which references all Catalogue Items and Parties published in all certified data pools and on which there is a need to synchronise / retrieve information. This is supported by data storage in accordance with the Registry data scope and rules. Primary
REQ-106 Registering a Catalogue Item involves a check by the Global Registry for Item uniqueness. The Item is identified by the following elements: GTIN, GLN, Target Market. Each combination of this key data found in the Global Registry must be unique. When an Item is registered, the registry verifies that the combination of this data is unique to that Item. Primary
REQ-107 The registration process is triggered by the following business cases: 1. Create Catalogue Item: After the physical load and validation of the data, the registry record needs to be created before data can be published. 2. Update Catalogue Item: When a registered Catalogue Item is updated in its source data pool, updates impacting the Registry data must be reflected in the Global Registry, before the updated data can be propagated to the recipients. Registration of Catalogue Item changes only needs to happen for changes that: Impacts fields stored in the Global Registry. Are authorised according to the GTIN allocation rules. 3. Correct Catalogue Item: When a registered item is corrected in its source data pool, corrections impacting the Registry data must be reflected in the Global Registry before the updated data can be propagated to the data recipients. 4. Delete Catalogue Item: Deletions need to be reflected in the Global Registry: the discontinuation dates starts the EAN.UCC standard retention period (48 months for CPG, 36 months for apparel) as soon as GTIN has been discontinued in ALL target markets where it was active (needs to be stored in the Global Registry). 5. Cancel Catalogue Item: Communicates a trade item was never manufactured – this allows an earlier “reuse” of the GTIN i.o. standard retention period. This is achieved through the maintenance (using change function) of the cancel date. 6. Removing an Catalogue Item from the supply chain: The permanent removal of a Catalogue Item from the supply chain is achieved through the maintenance of a discontinuation date. This date has to be reflected in the Global Registry to kick off the EAN.UCC retention period. Temporary removals are not reflected in the Global Registry and only handled through the maintenance of the availability period in the data pools. Primary
REQ-108 Registry requirements for registration are: - Registration can only happen after successful validation. - Registration can only produce errors, no warnings. - Successful Registration of a Catalogue Item is mandatory prior to publication of any hierarchy containing that Catalogue Item. - ItemStatus needs to be included in GTIN data model to reflect validation and registration status. - Process registration command (for create, update, correct, delete). - Provide registration acknowledgement. Primary
REQ-118 Changes/corrections applied to the Global Registry are effective immediately. Primary
REQ-119 Future effective changes stored in the data pool are only reflected in the Global Registry when they become effective. Primary
REQ-159 Multiple independent hierarchies can co-exist at the data-pool for an item for example hierarchy 1 = case A – each A and hierarchy 2 = pallet A – case A –each A. Primary

TOP
6. Cancel Catalogue Item
Use Case Diagram
Figure 23 - Cancel Catalogue Item Use Case Diagram
Use Case Name Cancel Catalogue Item
Traceability Identifier UC-7
Use Case Description In certain cases, a manufacturer will register a Catalogue Item prior to deciding if it will ultimately be manufactured and sold.
The Cancel Catalogue Item use case describes the process to communicate that a trade item was never manufactured.This allows the reuse of the GTIN 12 months after cancellation instead of 48 months.When an item is cancelled in the GDSN, the waiting period for an item may have to be aligned with the specific industry requirement.
Note:This is a special usage of the Change Catalogue Item Hierarchy or Correct Catalogue Item Hierarchy use cases.
Use Cases Above UC-2:Load and Update Catalogue Item Data within a Source Data Pool
Use Cases Below UC-22:Cancel Registered Catalogue Item
Actors Data SourceSource Data Pool (SDP)Global Registry
Performance Goals Data Source: To be able to reuse the GTIN of a Catalogue Item that has not been manufactured as soon as possible.
SDP: To have validated, registered updated Catalogue Item Hierarchy data.Sends the RCI to the GS1 GR, and after some time sends the updated CIN to all recipients currently synchronizing on the item with the cancellation information.
GS1 Global Registry: To ensure valid, unique Catalogue Item data are registered.The GS1 GR determines the GTIN reuse period for this industry type of trade item, calculates the deletion date and the state remains unchanged.
Preconditions Data Source has registered a Catalogue Item that it now does not intend to manufacture.
Postconditions Catalogue Item retention period begins (after which, the GTIN can be reused).
Scenario Begins when, the Data Source sends, to the SDP, Catalogue Item Hierarchy data with a Catalogue Item that contains a cancel date.
1.The SDP receivesCatalogue Item Hierarchy data to be changed
2.The SDP validates Catalogue Item Hierarchy data to be changed3.The SDP sends a validation acknowledgement to the Data Source4.The Data Source receives the validation acknowledgement: Catalogue Item Hierarchy data cancelled5.The SDP loads the changed Catalogue Item Hierarchy data6.The SDP sends the Registry Item data (to be changed) to the Global Registry7.The Global Registry receives the Registry Item data to be changed8.The Global Registry checks that the Catalogue Item exists in the Registry.9.The Global Registry registers the changed Registry Item data
10. The Global Registry sends a registration acknowledgement to the SDP11. The SDP receives the registration acknowledgement12. The SDP stores the registration acknowledgement13. The SDP sends a registration acknowledgement to the Data Source
Ends when, the Data Source receives the registration acknowledgement: Catalogue Item data changed
Alternative Scenario ad 2.Validation fails: Catalogue Item Hierarchy data not loaded
2.1.SDP sends an validation error message to the Data SourceEnds when, the Data Source receives the validation error message
ad 8.The Catalogue Item is not found in the Registry: Catalogue Item data not registered
8.1.Global Registry sends a registration error message to the SDP8.2.The SDP receives the registration error message8.3.The SDP sends a registration error message to the Data SourceEnds when, the Data Source receives the registration error message
ad 3. & 13. The validation and registration acknowledgment messages can be combined
** The Catalogue Item Data is now not available for distribution.
Special Requirements
  • Data Source is using a(source) data pool.
  • Catalogue Item Hierarchydata consists of Catalogue Item data and Item Link data (if applicable).
  • Validation is done againstexisting data, applying GDD standard and GTIN allocation rules.
  • Catalogue Item Hierarchydata bypasses the GTIN Allocation Rules
Extension Points N/A

Requirements Covered
ID Requirement Weight
REQ-12 Every command needs a response and is handled according to the agreement between the parties involved. In the inter-operable network, acknowledgement messages are standardised and may contain the following information: - Confirmation of message receipt- Success / Failure of processing (syntax and content)- Reason for failure, with a code number and text message unique assigned to each failure Primary
REQ-20 Synchronisation Lists must include every Catalogue Item (GTIN+GLN+TM) that needs to be synchronised. Primary
REQ-21 If an Catalogue Item is "Confirmed of Synchronisation" then all Catalogue items below in the Catalogue Item Hierarchy shall be included in the Synchronisation list. Primary
REQ-22 Relationship dependent data will only be communicated for Synchronised, Review or Accept status in the Synchronisation List. Primary
REQ-23 Events that can trigger notifications are: - Publication of new data / change of publication - Change of published Catalogue Item / Party / Partner Profile - Change of owner, rights - Subscription - Synchronisation List - Confirmation/ Rejection - Request for Notification - Any successful matching process Primary
REQ-24 Notifications must NOT be sent in the following cases since data is not yet public and validated information: - Data load (add, change, etc…) - Data validation - Registration of new Catalogue Item Primary
REQ-26 Notification to the data recipient will always include the entire hierarchy. (Applies to add & update by adding a higher level) Primary
REQ-30 Only Catalogue Items are registered in the Global Registry. Not Catalogue Item Hierarchies. Primary
REQ-31 Validation acknowledgements are mandatory. Primary
REQ-32 Acknowledgement Reason codes must be unique. Primary
REQ-34 ItemLinks are not registered or held within the Global Registry. Primary
REQ-36 If the Catalogue Item was registered, updates impacting the Registry data must be reflected in the Global Registry. Primary
REQ-37 Registration of Catalogue Item changes only needs to happen for changes that: - Impact fields stored in the Global Registry. - Are authorised according to the GTIN allocation rules. Primary
REQ-45 Data source is sending full Hierarchies to the Source Data Pool. Primary
REQ-62 Cancel Catalogue Item is achieved through the maintenance (using change function) of the cancel date. Secondary
REQ-63 Need cancel date in Catalogue Item data model. Secondary
REQ-64 Cancel date needs to be stored in the Global Registry. Secondary
REQ-65 Communicate that product is no longer available: maintain end availability date. Secondary
REQ-66 When product is available again: update start/end availability date. Secondary
REQ-92 “Single Data Source” Principle: - there can only be one official source of the data – the one that is registered - this source is identified by the data source - this is the only valid source for data synchronisation and related processes Primary
REQ-99 The Global Registry functionality requirements can be summarised as follows: - Enable data synchronisation - Validation, registration and subscription functions - Enable global validation - Checking compliance with basic EAN.UCC rules related to the format of a GTIN/GLN and ensuring the uniqueness of the data that is being registered - Enable global search functionality that does not require full duplication of data in the Global Registry. Primary
REQ-100 The Global Registry is involved in the following functions and/or business cases as defined in the Item Synchronisation detailed requirements: - Validation - Registration - Subscription - Global Search Primary
REQ-101 Registry Validation includes: - EAN.UCC standards validation for GTIN and GLN formats (i.e. check digit) - Uniqueness validation for Item (GTIN/GLN/TM), Party (GLN) or data pool (GLN), ensuring there is only one occurrence and data source for each data record as identified by the appropriate fields. Primary
REQ-102 Registry validation is a part of the registration process. Primary
REQ-104 In summary, the registry requirements for validation are: - EAN.UCC standards validation for GTIN/GLN formats - Uniqueness validation for Item, Party and data pool key - Store and maintain EAN.UCC standards - Process validation command - Provide validation acknowledgement Primary
REQ-105 Registration is the process, which references all Catalogue Items and Parties published in all certified data pools and on which there is a need to synchronise / retrieve information. This is supported by data storage in accordance with the Registry data scope and rules. Primary
REQ-106 Registering a Catalogue Item involves a check by the Global Registry for Item uniqueness. The Item is identified by the following elements: GTIN, GLN, Target Market. Each combination of this key data found in the Global Registry must be unique. When an Item is registered, the registry verifies that the combination of this data is unique to that Item. Primary
REQ-107 The registration process is triggered by the following business cases: 1. Create Catalogue Item: After the physical load and validation of the data, the registry record needs to be created before data can be published. 2. Update Catalogue Item: When a registered Catalogue Item is updated in its source data pool, updates impacting the Registry data must be reflected in the Global Registry, before the updated data can be propagated to the recipients. Registration of Catalogue Item changes only needs to happen for changes that: Impacts fields stored in the Global Registry. Are authorised according to the GTIN allocation rules. 3. Correct Catalogue Item: When a registered item is corrected in its source data pool, corrections impacting the Registry data must be reflected in the Global Registry before the updated data can be propagated to the data recipients. 4. Delete Catalogue Item: Deletions need to be reflected in the Global Registry: the discontinuation dates starts the EAN.UCC standard retention period (48 months for CPG, 36 months for apparel) as soon as GTIN has been discontinued in ALL target markets where it was active (needs to be stored in the Global Registry). 5. Cancel Catalogue Item: Communicates a trade item was never manufactured – this allows an earlier “reuse” of the GTIN i.o. standard retention period. This is achieved through the maintenance (using change function) of the cancel date. 6. Removing an Catalogue Item from the supply chain: The permanent removal of a Catalogue Item from the supply chain is achieved through the maintenance of a discontinuation date. This date has to be reflected in the Global Registry to kick off the EAN.UCC retention period. Temporary removals are not reflected in the Global Registry and only handled through the maintenance of the availability period in the data pools. Primary
REQ-108 Registry requirements for registration are: - Registration can only happen after successful validation. - Registration can only produce errors, no warnings. - Successful Registration of a Catalogue Item is mandatory prior to publication of any hierarchy containing that Catalogue Item. - ItemStatus needs to be included in GTIN data model to reflect validation and registration status. - Process registration command (for create, update, correct, delete). - Provide registration acknowledgement. Primary
REQ-118 Changes/corrections applied to the Global Registry are effective immediately. Primary
REQ-119 Future effective changes stored in the data pool are only reflected in the Global Registry when they become effective. Primary
REQ-159 Multiple independent hierarchies can co-exist at the data-pool for an item for example hierarchy 1 = case A – each A and hierarchy 2 = pallet A – case A –each A. Primary
REQ-171 The message identifier (CorrelationInformation: requestingDocu-mentInstanceIdentifier) at the document header levelfor the EAN.UCC response and the GDSN Exception must equal theDocumentIdentification: instanceIdentifier of the originalmessage. Primary
REQ 185 The deletion date is updated by the GS1 GR, adding either the cancellation or discontinue timeframe to the cancel or discontinue dates respectively. Primary
REQ 186 At the end of the time period, which differs per industry, the deletion date becomes current and the item is actually deleted Primary
REQ 187 The GS1 GR must receive the GPC code information in order7to calculate the deletion date properly Primary
REQ 188 The GS1 GR will maintain a cross-reference table for the GPC brick level codes and a corresponding GTIN Reuse Time Primary
REQ 189 The GS1 GR will maintain an additional field to establish the GTIN reuse timeframe based on each industry’s guidelines Primary
REQ 190 When an item is discontinued in the GDSN, the waiting period for the GTIN before it can be reused for an item has to be aligned with the specific industry requirement:
- clothing, footwear and personal accessories apply a 30 month rule to the discontinue date
- Fast Moving Consumer Goods GTINs can be reused after a 48 month period to the discontinue date and
-12 month rule applies to the cancel date.
Note: Clothing, footwear and personal accessories are defined as being all GPC bricks contained within the following GPC Segments:
63000000 Footwear
67000000 Clothing
64000000 Personal Accessories
It is assumed for this BSD that all other established GPC Segments and their associated Bricks will follow the 48 month period to the discontinue date until the specific industry rule and associated GPCs are established.
Primary
REQ 191 When an item has a discontinue date, the state of the item does not get updated until that date becomes current. Primary
REQ 192 The Global Registry must support a Registry CatalogueItem State of “DELETED”. Primary

7. Register Catalogue Item
Use Case Diagram
Use Case Name Register Catalogue Item
Traceability Identifier UC-18
Use Case Description All Catalogue Items for trade must be registered in the Global Registry.Prior to registration, the Catalogue Item data must pass a validation at the Source Data Pool and a uniqueness check at the Registry.The Global Registry ensures that valid, unique Catalogue Item data are available worldwide.
This Use Case describes the Registration process that is performed by the Global Registry.
Use Cases Above UC-2: Load and Update Catalogue Item Data within a Source Data Pool
Use Cases Below None
Actors Source Data Pool (SDP)Global Registry
Performance Goals SDP: To have validated, registered Catalogue Item data.
Global Registry: To ensure valid, unique Catalogue Item data are registered.
Preconditions The Source Data Pool is a certified Data Pool.The Source Data Pool has a profile that resides in the registry.The Source Data Pool has validated Catalogue Item data received from a Data Source and has sent that Catalogue Item data and a Validation Certificate to the Global Registry.
Postconditions The Catalogue Item data has been registered and retained by the Global Registry.
Scenario Begins when, the Global Registry receives validated Catalogue Item Data from a Source Data Pool.
1.The Global Registry ensures that the Source Data Pool is certified.2.The Global Registry validates the Validation Certificate (from validation engine) sent with the Catalogue Item data.3.The Global Registry verifies the uniqueness of the GTIN, GLN, TM combination.4.The Global Registry stores the Catalogue Item data.
Ends when, The Global Registry sends a registration acknowledgement to the SDP
 
Alternative Scenario ad 1.Data Pool not certified:
1.1.The Global Registry sends an error message to the Source Data PoolEnds when, the Source Data Pool receives the error message
ad 2.Validation certificate does not pass validation:2.1.The Global Registry sends a validation error message to the Source Data PoolEnds when, the Source Data Pool receives the validation error message
ad 3.The Catalogue Item already exists in the Registry:
3.1.Global Registry sends a registration error message to the SDP3.2.The SDP receives the registration error message3.3.The SDP sends a registration error message to the Data SourceEnds when, the Data Source receives the registration error message
Special Requirements
  • Validation: applying GDDstandard and GTIN allocation rules.
Extension Points N/A
Requirements Covered
ID Requirement Weight
REQ-1 Party data must exist prior to a Catalogue Item is being registered. Secondary
REQ-2 Catalogue Item data must be validated prior to registration. Secondary
REQ-8 EAN.UCC standards validation for GTIN and GLN format. Primary
REQ-9 Uniqueness validation for Item (GTIN/GLN/TM), Party (GLN) or data pool (GLN) – only applies to the occurrence of the key, not to the uniqueness of the information related to it. Primary
REQ-10 The Catalogue Item is identified by the following elements: GTIN, GLN, Target Market. Each combination of this key data found in the Global Registry must be unique. Secondary
REQ-12 Every command needs a response and is handled according to the agreement between the parties involved. In the inter-operable network, acknowledgement messages are standardised and may contain the following information: - Confirmation of message receipt- Success / Failure of processing (syntax and content)- Reason for failure, with a code number and text message unique assigned to each failure Primary
REQ-20 Synchronisation Lists must include every Catalogue Item (GTIN+GLN+TM) that needs to be synchronised. Primary
REQ-23 Events that can trigger notifications are: - Publication of new data / change of publication - Change of published Catalogue Item / Party / Partner Profile - Change of owner, rights - Subscription - Synchronisation List - Confirmation/ Rejection - Request for Notification - Any successful matching process Primary
REQ-24 Notifications must NOT be sent in the following cases since data is not yet public and validated information: - Data load (add, change, etc…) - Data validation - Registration of new Catalogue Item Secondary
REQ-30 Only Catalogue Items are registered in the Global Registry. Not Catalogue Item Hierarchies. Secondary
REQ-31 Validation acknowledgements are mandatory. Secondary
REQ-32 Acknowledgement Reason codes must be unique. Primary
REQ-34 ItemLinks are not registered or held within the Global Registry. Secondary
REQ-36 If the Catalogue Item was registered, updates impacting the Registry data must be reflected in the Global Registry. Primary
REQ-37 Registration of Catalogue Item changes only needs to happen for changes that: - Impact fields stored in the Global Registry. - Are authorised according to the GTIN allocation rules. Primary
REQ-42 If the correction impacts the hierarchy, then it must be handled by deleting the incorrect ItemLink and adding a new Item Link - Add/Delete Scenario’s. Primary
REQ-92 “Single Data Source” Principle: - there can only be one official source of the data – the one that is registered - this source is identified by the data source - this is the only valid source for data synchronisation and related processes Primary
REQ-99 The Global Registry functionality requirements can be summarised as follows: - Enable data synchronisation - Validation, registration and subscription functions - Enable global validation - Checking compliance with basic EAN.UCC rules related to the format of a GTIN/GLN and ensuring the uniqueness of the data that is being registered - Enable global search functionality that does not require full duplication of data in the Global Registry. Primary
REQ-100 The Global Registry is involved in the following functions and/or business cases as defined in the Item Synchronisation detailed requirements: - Validation - Registration - Subscription - Global Search Primary
REQ-101 Registry Validation includes: - EAN.UCC standards validation for GTIN and GLN formats (i.e. check digit) - Uniqueness validation for Item (GTIN/GLN/TM), Party (GLN) or data pool (GLN), ensuring there is only one occurrence and data source for each data record as identified by the appropriate fields. Primary
REQ-102 Registry validation is a part of the registration process. Secondary
REQ-104 In summary, the registry requirements for validation are: - EAN.UCC standards validation for GTIN/GLN formats - Uniqueness validation for Item, Party and data pool key - Store and maintain EAN.UCC standards - Process validation command - Provide validation acknowledgement Secondary
REQ-105 Registration is the process, which references all Catalogue Items and Parties published in all certified data pools and on which there is a need to synchronise / retrieve information. This is supported by data storage in accordance with the Registry data scope and rules. Secondary
REQ-106 Registering a Catalogue Item involves a check by the Global Registry for Item uniqueness. The Item is identified by the following elements: GTIN, GLN, Target Market. Each combination of this key data found in the Global Registry must be unique. When an Item is registered, the registry verifies that the combination of this data is unique to that Item. Secondary
REQ-107 The registration process is triggered by the following business cases: 1. Create Catalogue Item: After the physical load and validation of the data, the registry record needs to be created before data can be published. 2. Update Catalogue Item: When a registered Catalogue Item is updated in its source data pool, updates impacting the Registry data must be reflected in the Global Registry, before the updated data can be propagated to the recipients. Registration of Catalogue Item changes only needs to happen for changes that: Impacts fields stored in the Global Registry. Are authorised according to the GTIN allocation rules. 3. Correct Catalogue Item: When a registered item is corrected in its source data pool, corrections impacting the Registry data must be reflected in the Global Registry before the updated data can be propagated to the data recipients. 4. Delete Catalogue Item: Deletions need to be reflected in the Global Registry: the discontinuation dates starts the EAN.UCC standard retention period (48 months for CPG, 36 months for apparel) as soon as GTIN has been discontinued in ALL target markets where it was active (needs to be stored in the Global Registry). 5. Cancel Catalogue Item: Communicates a trade item was never manufactured – this allows an earlier “reuse” of the GTIN i.o. standard retention period. This is achieved through the maintenance (using change function) of the cancel date. 6. Removing a Catalogue Item from the supply chain: The permanent removal of a Catalogue Item from the supply chain is achieved through the maintenance of a discontinuation date. This date has to be reflected in the Global Registry to kick off the EAN.UCC retention period. Temporary removals are not reflected in the Global Registry and only handled through the maintenance of the availability period in the data pools. Secondary
REQ-108 Registry requirements for registration are: - Registration can only happen after successful validation. - Registration can only produce errors, no warnings. - Successful Registration of a Catalogue Item is mandatory prior to publication of any hierarchy containing that Catalogue Item. - ItemStatus needs to be included in GTIN data model to reflect validation and registration status. - Process registration command (for create, update, correct, delete). - Provide registration acknowledgement. Secondary
REQ-117 Catalogue Item: - GTIN - GLN of Data Source - Unique Item Identification - Target Market - Country Code [3166-1] - Sub-division code [3166-2] - EAN.UCC Classification [brick level] - Address of the source data pool (GLN used to look up url in data pool profile) - Registration Date - Deletion Date (default: 31.12.9999) - Cancel Date (default: 31.12.9999) - Discontinued Date (default: 31.12.9999) - Date and Time of last change (system date for every action on the Catalogue Item) - Item Validation Information (including validation engine Version, validation date Date & Certificate ID) – certificate ID only has to be maintained at item creation time, periodic maintenance does not affect the Global Registry but is ensured in the data notification (notified certificate needs to be equal or higher than registry certificate) Secondary
REQ-121 Party: - GLN - Start Availability Date of the Party - Deletion Date of the Party - Registration Date - Source Data Pool Pointer [GLN used to ….] - GLN of Data Source (*Data Source is actually the ‘owner’ of the GLN data - Date and Time of last change - Party Validation Information (including Version, Date & Certificate ID) Secondary
REQ-171  The message identifier (CorrelationInformation: requestingDocu-mentInstanceIdentifier) at the document header levelfor the EAN.UCC response and the GDSN Exception must equal theDocumentIdentification: instanceIdentifier of the originalmessage. Primary

Activity Diagram
Figure 24 - Register Catalogue Item Activity Diagram
Sequence Diagram
Figure 25 - Register Catalogue Item Sequence Diagram
TOP
8. Change Registered Catalogue Item Diagram
Use Case Diagram
Figure 26 - Change Registered Catalogue Item Use Case Diagram
Use Case Name Change Registered Catalogue Item
Traceability Identifier UC-19
Use Case Description All Catalogue Items for trade must be registered in the Global Registry.Prior to registration, the Catalogue Item data must pass a validation at the Source Data Pool and a uniqueness check at the Registry.The Global Registry ensures that valid, unique Catalogue Item data are available worldwide.
In the event that Catalogue Item data changes (see Change Catalogue Item Hierarchy Use Case) in a Source Data Pool, the changes must be reflected in the Global Registry.
Use Cases Above UC-10:Change Catalogue Item
Use Cases Below None
Actors Source Data Pool (SDP)Global Registry
Performance Goals SDP: To have validated, registered Catalogue Item data.
Global Registry: To ensure valid, unique Catalogue Item data are registered.
Preconditions The Source Data Pool is a certified Data Pool..The Source Data Pool has a profile that resides in the registry.The Source Data Pool has received a “Change Catalogue Item Hierarchy” message from the Data Source.The Source Data Pool has validated Catalogue Item data received from a Data Source and has sent that Catalogue Item data and a Validation Certificate to the Global Registry.
Postconditions The Catalogue Item data changes have been applied and retained in the Global Registry.
Scenario Begins when, the Global Registry receives a validated Change Registered Catalogue Item message from a Source Data Pool.
1.The Global Registry ensures that the Source Data Pool is certified.2.The Global Registry validates the Validation Certificate (from validation engine) sent with the Catalogue Item data.3.The Global Registry ensures that the Catalogue Item data already exists in the Registry.4.The Global Registry stores the Catalogue Item data.
Ends when, The Global Registry sends a registration acknowledgement to the SDP
 
Alternative Scenario ad 1.Data Pool not certified:
1.1.The Global Registry sends an error message to the Source Data PoolEnds when, the Source Data Pool receives the error message
ad 2.Validation certificate does not pass validation:2.1.The Global Registry sends a validation error message to the Source Data PoolEnds when, the Source Data Pool receives the validation error message
ad 3.The Catalogue Item does not exist in the Registry:
3.1.Global Registry sends a registration error message to the SDP3.2.The SDP receives the registration error message
Ends when, the Source Data Pool receives the registration error message
 
Special Requirements
  • Validation: applying GDD standard and GTIN allocation rules.
Extension Points N/A
Requirements Covered  
ID Requirement Weight
REQ-4 Data Source must be able to change Catalogue Item data in the Source Data Pool. Secondary
REQ-8 EAN.UCC standards validation for GTIN and GLN format. Primary
REQ-9 Uniqueness validation for Item (GTIN/GLN/TM), Party (GLN) or data pool (GLN) – only applies to the occurrence of the key, not to the uniqueness of the information related to it. Primary
REQ-10 The Catalogue Item is identified by the following elements: GTIN, GLN, Target Market. Each combination of this key data found in the Global Registry must be unique. Primary
REQ-12 Every command needs a response and is handled according to the agreement between the parties involved. In the inter-operable network, acknowledgement messages are standardised and may contain the following information: - Confirmation of message receipt- Success / Failure of processing (syntax and content)- Reason for failure, with a code number and text message unique assigned to each failure Primary
REQ-20 Synchronisation Lists must include every Catalogue Item (GTIN+GLN+TM) that needs to be synchronised. Primary
REQ-23 Events that can trigger notifications are: - Publication of new data / change of publication - Change of published Catalogue Item / Party / Partner Profile - Change of owner, rights - Subscription - Synchronisation List - Confirmation/ Rejection - Request for Notification - Any successful matching process Primary
REQ-24 Notifications must NOT be sent in the following cases since data is not yet public and validated information: - Data load (add, change, etc…) - Data validation - Registration of new Catalogue Item Primary
REQ-30 Only Catalogue Items are registered in the Global Registry. Not Catalogue Item Hierarchies. Primary
REQ-31 Validation acknowledgements are mandatory. Primary
REQ-32 Acknowledgement Reason codes must be unique. Primary
REQ-34 ItemLinks are not registered or held within the Global Registry. Primary
REQ-35 Changes have to comply with validation rules. Secondary
REQ-36 If the Catalogue Item was registered, updates impacting the Registry data must be reflected in the Global Registry. Secondary
REQ-37 Registration of Catalogue Item changes only needs to happen for changes that: - Impact fields stored in the Global Registry. - Are authorised according to the GTIN allocation rules. Secondary
REQ-38 The change function implies a full refresh of all attributes of the previously created Catalogue Item – this will be reflected in the subsequent notification, including a full refresh of the changed record of the full hierarchy. Primary
REQ-62 Cancel Catalogue Item is achieved through the maintenance (using change function) of the cancel date. Primary
REQ-64 Cancel date needs to be stored in the Global Registry. Primary
REQ-92 “Single Data Source” Principle: - there can only be one official source of the data – the one that is registered - this source is identified by the data source - this is the only valid source for data synchronisation and related processes Primary
REQ-99 The Global Registry functionality requirements can be summarised as follows: - Enable data synchronisation - Validation, registration and subscription functions - Enable global validation - Checking compliance with basic EAN.UCC rules related to the format of a GTIN/GLN and ensuring the uniqueness of the data that is being registered - Enable global search functionality that does not require full duplication of data in the Global Registry. Primary
REQ-100 The Global Registry is involved in the following functions and/or business cases as defined in the Item Synchronisation detailed requirements: - Validation - Registration - Subscription - Global Search Primary
REQ-101 Registry Validation includes: - EAN.UCC standards validation for GTIN and GLN formats (i.e. check digit) - Uniqueness validation for Item (GTIN/GLN/TM), Party (GLN) or data pool (GLN), ensuring there is only one occurrence and data source for each data record as identified by the appropriate fields. Primary
REQ-102 Registry validation is a part of the registration process. Primary
REQ-104 In summary, the registry requirements for validation are: - EAN.UCC standards validation for GTIN/GLN formats - Uniqueness validation for Item, Party and data pool key - Store and maintain EAN.UCC standards - Process validation command - Provide validation acknowledgement Primary
REQ-105 Registration is the process, which references all Catalogue Items and Parties published in all certified data pools and on which there is a need to synchronise / retrieve information. This is supported by data storage in accordance with the Registry data scope and rules. Primary
REQ-106 Registering a Catalogue Item involves a check by the Global Registry for Item uniqueness. The Item is identified by the following elements: GTIN, GLN, Target Market. Each combination of this key data found in the Global Registry must be unique. When an Item is registered, the registry verifies that the combination of this data is unique to that Item. Primary
REQ-107 The registration process is triggered by the following business cases: 1. Create Catalogue Item: After the physical load and validation of the data, the registry record needs to be created before data can be published. 2. Update Catalogue Item: When a registered Catalogue Item is updated in its source data pool, updates impacting the Registry data must be reflected in the Global Registry, before the updated data can be propagated to the recipients. Registration of Catalogue Item changes only needs to happen for changes that: Impacts fields stored in the Global Registry. Are authorised according to the GTIN allocation rules. 3. Correct Catalogue Item: When a registered item is corrected in its source data pool, corrections impacting the Registry data must be reflected in the Global Registry before the updated data can be propagated to the data recipients. 4. Delete Catalogue Item: Deletions need to be reflected in the Global Registry: the discontinuation dates starts the EAN.UCC standard retention period (48 months for CPG, 36 months for apparel) as soon as GTIN has been discontinued in ALL target markets where it was active (needs to be stored in the Global Registry). 5. Cancel Catalogue Item: Communicates a trade item was never manufactured – this allows an earlier “reuse” of the GTIN i.o. standard retention period. This is achieved through the maintenance (using change function) of the cancel date. 6. Removing a Catalogue Item from the supply chain: The permanent removal of a Catalogue Item from the supply chain is achieved through the maintenance of a discontinuation date. This date has to be reflected in the Global Registry to kick off the EAN.UCC retention period. Temporary removals are not reflected in the Global Registry and only handled through the maintenance of the availability period in the data pools. Primary
REQ-108 Registry requirements for registration are: - Registration can only happen after successful validation. - Registration can only produce errors, no warnings. - Successful Registration of a Catalogue Item is mandatory prior to publication of any hierarchy containing that Catalogue Item. - ItemStatus needs to be included in GTIN data model to reflect validation and registration status. - Process registration command (for create, update, correct, delete). - Provide registration acknowledgement. Primary
REQ-118 Changes/corrections applied to the Global Registry are effective immediately. Secondary
REQ-119 Future effective changes stored in the data pool are only reflected in the Global Registry when they become effective. Secondary
REQ-171  The message identifier (CorrelationInformation: requestingDocu-mentInstanceIdentifier) at the document header levelfor the EAN.UCC response and the GDSN Exception must equal theDocumentIdentification: instanceIdentifier of the originalmessage. Primary

Activity Diagram
Figure 27 - Change Registered Catalogue Item Activity Diagram
Sequence Diagram
Figure 28 - Change Registered Catalogue Item Sequence Diagram
TOP
9. Correct Registered Catalogue Item
Use Case Diagram
Figure 29 - Correct Registered Catalogue Item Use Case Diagram
Use Case Name Correct Registered Catalogue Item
Traceability Identifier UC-20
Use Case Description All Catalogue Items for trade must be registered in the Global Registry.Prior to registration, the Catalogue Item data must pass a validation at the Source Data Pool and a uniqueness check at the Registry.The Global Registry ensures that valid, unique Catalogue Item data are available worldwide.
A correction allows a Data Source to make changes to Catalogue Item data that would not be allowed by validation rules and as such is outside of normal processing.It is intended to provide a means for errors to be corrected and not as an alternative to the Change Registered Catalogue Item process.
This process is triggered by the “Correct Hierarchy Data” Use Case.In the event that Catalogue Item Hierarchy data is corrected (see Correct Catalogue Item Hierarchy Use Case) in a Source Data Pool, the changes must be reflected in the Global Registry.

Use Cases Above

Use Cases Below None
Actors Source Data Pool (SDP)Global Registry
Performance Goals SDP:To correct errors in Catalogue Item data.To have validated, registered Catalogue Item Hierarchy data.
Global Registry: To ensure valid, unique Catalogue Item data are registered.
Preconditions The Source Data Pool is a certified Data Pool whose profile resides in the registry.The Source Data Pool has received a “Correct Catalogue Item Hierarchy” message from the Data Source.The Source Data Pool has validated Catalogue Item data received and has sent that Catalogue Item data to the Global Registry.
Postconditions The Catalogue Item data corrections have been applied and retained in the Global Registry.
Scenario Begins when, the Global Registry receives a validated Correct Registered Catalogue Item message from a Source Data Pool.
1.The Global Registry ensures that the Source Data Pool is certified.2.The Global Registry ensures that the Catalogue Item data already exists in the Registry.3.The Global Registry performs the Source Data Pool validation.4.The Global Registry removes the old Catalogue Item Data from the Registry.5.The Global Registry stores the Catalogue Item data.
Ends when, The Global Registry sends aregistration acknowledgement to the SDP 
Alternative Scenario ad 1.Data Pool not certified:
1.1.The Global Registry sends an error message to the Source Data PoolEnds when, the Source Data Pool receives the error message
ad 2.The Catalogue Item does not exist in the Registry:
3.1.Global Registry sends a registration error message to the SDP3.2.The SDP receives the registration error message
Ends when, the Source Data Pool receives the registration error message
ad 3.Catalogue Item data does not pass Data Pool validation:3.1.The Global Registry sends a validation error message to the Source Data PoolEnds when, the Source Data Pool receives the validation error message
Special Requirements
  • Validation: applying GDDstandards.
Extension Points N/A
Requirements Covered
ID Requirement Weight
REQ-5 Data Source must be able to correct Catalogue Item data in the Source Data Pool. Secondary
REQ-8 EAN.UCC standards validation for GTIN and GLN format. Primary
REQ-9 Uniqueness validation for Item (GTIN/GLN/TM), Party (GLN) or data pool (GLN) – only applies to the occurrence of the key, not to the uniqueness of the information related to it. Primary
REQ-10 The Catalogue Item is identified by the following elements: GTIN, GLN, Target Market. Each combination of this key data found in the Global Registry must be unique. Primary
REQ-11 Corrections bypass the standard GTIN/GLN allocation rules. Secondary
REQ-12 Every command needs a response and is handled according to the agreement between the parties involved. In the inter-operable network, acknowledgement messages are standardised and may contain the following information: - Confirmation of message receipt- Success / Failure of processing (syntax and content)- Reason for failure, with a code number and text message unique assigned to each failure Primary
REQ-20 Synchronisation Lists must include every Catalogue Item (GTIN+GLN+TM) that needs to be synchronised. Primary
REQ-21 If a Catalogue Item is "Confirmed of Synchronisation" then all Catalogue items below in the Catalogue Item Hierarchy shall be included in the Synchronisation list. Primary
REQ-22 Relationship dependent data will only be communicated for Synchronised, Review or Accept status in the Synchronisation List. Primary
REQ-23 Events that can trigger notifications are: - Publication of new data / change of publication - Change of published Catalogue Item / Party / Partner Profile - Change of owner, rights - Subscription - Synchronisation List - Confirmation/ Rejection - Request for Notification - Any successful matching process Primary
REQ-24 Notifications must NOT be sent in the following cases since data is not yet public and validated information: - Data load (add, change, etc…) - Data validation - Registration of new Catalogue Item Primary
REQ-30 Only Catalogue Items are registered in the Global Registry. Not Catalogue Item Hierarchies. Primary
REQ-31 Validation acknowledgements are mandatory. Primary
REQ-32 Acknowledgement Reason codes must be unique. Primary
REQ-34 ItemLinks are not registered or held within the Global Registry. Primary
REQ-36 If the Catalogue Item was registered, updates impacting the Registry data must be reflected in the Global Registry. Primary
REQ-37 Registration of Catalogue Item changes only needs to happen for changes that: - Impact fields stored in the Global Registry. - Are authorised according to the GTIN allocation rules. Primary
REQ-40 Incorrect core data (i.e. attributes that cannot be updated according to allocation rules) can only be updated through a specific correction functionality. Primary
REQ-41 Correct Item Hierarchy must: - trigger syntactical and content validation - skip GTIN allocation rules validation - set a flag on the GTIN data record to inform the data recipient of the correction (see data distribution / notification) - the correction will also be reflected in the Global Registry if it impacts Registry data Primary
REQ-42 If the correction impacts the hierarchy, then it must be handled by deleting the incorrect ItemLink and adding a new Item Link - Add/Delete Scenario’s. Primary
REQ-43 If the correction does not impact the hierarchy, then ItemLink attributes will be updated through the correction command. Secondary
REQ-44 Notification of the hierarchy must indicate it is a correction. Primary
REQ-57 A deletion cannot be corrected – only the discontinuation can be reversed. Primary
REQ-92 “Single Data Source” Principle: - there can only be one official source of the data – the one that is registered - this source is identified by the data source - this is the only valid source for data synchronisation and related processes Primary
REQ-99 The Global Registry functionality requirements can be summarised as follows: - Enable data synchronisation - Validation, registration and subscription functions - Enable global validation - Checking compliance with basic EAN.UCC rules related to the format of a GTIN/GLN and ensuring the uniqueness of the data that is being registered - Enable global search functionality that does not require full duplication of data in the Global Registry. Primary
REQ-100 The Global Registry is involved in the following functions and/or business cases as defined in the Item Synchronisation detailed requirements: - Validation - Registration - Subscription - Global Search Primary
REQ-101 Registry Validation includes: - EAN.UCC standards validation for GTIN and GLN formats (i.e. check digit) - Uniqueness validation for Item (GTIN/GLN/TM), Party (GLN) or data pool (GLN), ensuring there is only one occurrence and data source for each data record as identified by the appropriate fields. Primary
REQ-102 Registry validation is a part of the registration process. Primary
REQ-104 In summary, the registry requirements for validation are: - EAN.UCC standards validation for GTIN/GLN formats - Uniqueness validation for Item, Party and data pool key - Store and maintain EAN.UCC standards - Process validation command - Provide validation acknowledgement Primary
REQ-105 Registration is the process, which references all Catalogue Items and Parties published in all certified data pools and on which there is a need to synchronise / retrieve information. This is supported by data storage in accordance with the Registry data scope and rules. Primary
REQ-106 Registering a Catalogue Item involves a check by the Global Registry for Item uniqueness. The Item is identified by the following elements: GTIN, GLN, Target Market. Each combination of this key data found in the Global Registry must be unique. When an Item is registered, the registry verifies that the combination of this data is unique to that Item. Primary
REQ-107 The registration process is triggered by the following business cases: 1. Create Catalogue Item: After the physical load and validation of the data, the registry record needs to be created before data can be published. 2. Update Catalogue Item: When a registered Catalogue Item is updated in its source data pool, updates impacting the Registry data must be reflected in the Global Registry, before the updated data can be propagated to the recipients. Registration of Catalogue Item changes only needs to happen for changes that: Impacts fields stored in the Global Registry. Are authorised according to the GTIN allocation rules. 3. Correct Catalogue Item: When a registered item is corrected in its source data pool, corrections impacting the Registry data must be reflected in the Global Registry before the updated data can be propagated to the data recipients. 4. Delete Catalogue Item: Deletions need to be reflected in the Global Registry: the discontinuation dates starts the EAN.UCC standard retention period (48 months for CPG, 36 months for apparel) as soon as GTIN has been discontinued in ALL target markets where it was active (needs to be stored in the Global Registry). 5. Cancel Catalogue Item: Communicates a trade item was never manufactured – this allows an earlier “reuse” of the GTIN i.o. standard retention period. This is achieved through the maintenance (using change function) of the cancel date. 6. Removing an Catalogue Item from the supply chain: The permanent removal of a Catalogue Item from the supply chain is achieved through the maintenance of a discontinuation date. This date has to be reflected in the Global Registry to kick off the EAN.UCC retention period. Temporary removals are not reflected in the Global Registry and only handled through the maintenance of the availability period in the data pools. Primary
REQ-108 Registry requirements for registration are : - Registration can only happen after successful validation. - Registration can only produce errors, no warnings. - Successful Registration of a Catalogue Item is mandatory prior to publication of any hierarchy containing that Catalogue Item. - ItemStatus needs to be included in GTIN data model to reflect validation and registration status. - Process registration command (for create, update, correct, delete). - Provide registration acknowledgement. Primary
REQ-118 Changes/corrections applied to the Global Registry are effective immediately. Primary
REQ-119 Future effective changes stored in the data pool are only reflected in the Global Registry when they become effective. Primary
REQ-171  The message identifier (CorrelationInformation: requestingDocu-mentInstanceIdentifier) at the document header levelfor the EAN.UCC response and the GDSN Exception must equal theDocumentIdentification: instanceIdentifier of the originalmessage. Primary

Activity Diagram
Figure 30 - Correct Registered Catalogue Item Activity Diagram
Sequence Diagram
Figure 31 - Correct Registered Catalogue Item Sequence Diagram
TOP
10. Delete Registered Catalogue Item
Use Case Diagram
Figure 32 - Delete Registered Catalogue Item Use Case Diagram
Use Case Name Delete Registered Catalogue Item
Traceability Identifier UC-21
Use Case Description This use case describes the processes that need to take place for Catalogue Item registered in the Global Registry to be deleted. The process takes place in the Global Registry based upon either a previously set Cancel or Discontinue date.
Use Cases Above UC-46: Manage Catalogue Item Data in Global Registry
Use Cases Below None
Actors Global Registry
Performance Goals Global Registry: To ensure that GTIN allocation rules are followed.The GS1 GR determines the GTIN reuse period for this industry type of trade item, calculates the deletion date and updates the registryCatalogueItemState to DELETED.
Preconditions The deletion of registered Catalogue Items is a consequence of 2 actions:
 
  1. Catalogue Item was discontinued by the DS, and the currentdate = calculated deletion date.
  2. Catalogue Item was cancelled by theDS because the DS decided to never manufacture an item that they have alreadyregistered.
So these changes are reflected in the Global Registry data and will trigger a clean up (internal process) when the retention limit is over.
Postconditions The Registered Catalogue Item has a state of DELETED in the global registry.The deleted GTIN can be added as a new catalogue item.
Scenario Scenario: Cancel date exists in the RCIBegins Global Registry Receives the Registry Catalogue Item (RCI) which contains either the cancelDate or discontinueDate from the SDP.Continues with...
Step # Actor Activity Step
1 GS1 GR Determines if there is a discontinue date or a cancel date in the RCI.
2 GS1 GR