Catalogue Item Synchronisation 2.1

XML Standards	>	Catalogue Item Messages

Message Description

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

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

Figure 3 - Manage Catalogue Item Distribution Criteria Use Case Diagram

Figure 4 - Distribute Data Recipient Requests 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: will have: parametric search wild card search drop down list for searching Target Market specificity (language & currency) Must be enabled for images Must have ability to drill down enough to EAN.UCC classification structures Ability to search by specific language will have the ability to search to the attribute level. will have a request for publication functionality search engine will be housed at the home data pool 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

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

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

Figure 8 - Load and Update Catalogue Item Data within a Source Data Pool Activity Diagram

TOP

4. Manage Catalogue Item Data in Global Registry

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

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

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

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

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

Figure 14 - Add Catalogue Item Hierarchy Activity Diagram

Figure 15 - Add Catalogue Item Hierarchy Sequence Diagram

TOP

2. Change Catalogue Item Hierarchy

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

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

Figure 9 - Change Catalogue Item Hierarchy Activity Diagram

Figure 10 - Change Catalogue Item Hierarchy Sequence Diagram

TOP

3. Correct Catalogue Item Hierarchy

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

Figure 17 - Correct Catalogue Item Hierarchy Data Activity Diagram

Figure 18 - Correct Catalogue Item Hierarchy Sequence Diagram

TOP

4. Discontinue Catalogue Item

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

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

Figure 20 - Discontinue Catalogue Item Activity Diagram

Figure 21 - Discontinue Catalogue Item Sequence Diagram

TOP

5. Delete Catalogue Item Hierarchy

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

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

Requirement

Weight

REQ-12

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

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

Primary

REQ-99

Primary

REQ-100

Primary

REQ-101

Primary

REQ-102

Registry validation is a part of the registration process.

Primary

REQ-104

Primary

REQ-105

Primary

REQ-106

Primary

REQ-107

Primary

REQ-108

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

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

63000000	Footwear
67000000	Clothing
64000000	Personal Accessories

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 Name

Register Catalogue Item

Traceability Identifier

UC-18

Use Case Description

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

Figure 24 - Register Catalogue Item Activity Diagram

Figure 25 - Register Catalogue Item Sequence Diagram

TOP

8. Change Registered Catalogue Item Diagram

Figure 26 - Change Registered Catalogue Item Use Case Diagram

Use Case Name

Change Registered Catalogue Item

Traceability Identifier

UC-19

Use Case Description

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

Figure 27 - Change Registered Catalogue Item Activity Diagram

Figure 28 - Change Registered Catalogue Item Sequence Diagram

TOP

9. Correct Registered Catalogue Item

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

Figure 30 - Correct Registered Catalogue Item Activity Diagram

Figure 31 - Correct Registered Catalogue Item Sequence Diagram

TOP

10. Delete Registered Catalogue Item

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:

Catalogue Item was discontinued by the DS, and the currentdate = calculated deletion date.
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	If there is a cancel date, GS1 GR updates the registryCatalogueItem state to CANCELLED.
3	GS1 GR	The GS1 GR starts a “reuse” clock that determines the waiting period after which the GTIN can be re-registered using the same catalogue item reference as the previously registered RCI.
4	GS1 GR	At the point that the calculated deletion date is reached (current date = item cancellation date), the GS1 GR sets the state to DELETED. After the waiting period, the DS can re-register the GTIN with another product using the same key.

Ends when... The GTIN for the cancelled catalogue item (GTIN+GLN+TM) can be reused.

Alternative Scenario

Scenario: Discontinue date exists in the RCI
Begins Global Registry Receives the Registry Catalogue Item (RCI) which contains either the correct 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	If there is a discontinue date, GS1 GR updates the registryCatalogueItem state to DISCONTINUED.
3	GS1 GR	The GS1 GR starts a “reuse” clock that determines the waiting period after which the GTIN can be re-registered using the same catalogue item reference as the previously registered RCI.
4	GS1 GR	When the (current date = the calculated deletion date) the GS1 GR sets the state to DELETED. After the waiting period, the DS can re-register the GTIN with another product using the same key.

Ends when... The GTIN for the cancelled catalogue item (GTIN+GLN+TM) can be reused.

Special Requirements

Extension Points

N/A

Requirements Covered

Requirement

Weight

REQ-6

Data Source must be able to delete Catalogue Item data in the Source Data Pool.

Secondary

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

Secondary

REQ-12

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

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-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-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.

Secondary

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)...

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-50

Deletions need to be reflected in the registry (deletion flag + effective change date = deletion date in the Global Registry)

Secondary

REQ-51

To protect data integrity within the data pool, the deletion of a child can only occur after the deletion of the parents.

Secondary

REQ-52

Validation for deleted Items ensures the parents have been deleted before the deletion of the child is performed.

Secondary

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.

Secondary

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.

Secondary

REQ-58

Deletes are not synchronised across data pools.

Secondary

REQ-59

ItemLinks can only be deleted: - as the correction of an error - as the result of a delete.Item

Primary

REQ-60

The validity period of an ItemLink is defined by the validity period of the Parent Item and/or the Child Item.

Primary

REQ-61

When either parent or child expires, the related ItemLink(s) have to expire as well. This is achieved through the Refresh.ItemLink function.

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

Primary

REQ-100

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

Primary

REQ-105

Primary

REQ-106

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.

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 level for 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

63000000	Footwear
67000000	Clothing
64000000	Personal Accessories

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

Figure 33 - Delete Registered Catalogue Item Activity diagram

TOP

11. Manage Catalogue Item Distribution Criteria

Use Case Name

Manage Catalogue Item Distribution Criteria

Traceability Identifier

UC-23

Use Case Description

The Manage Catalogue Item Distribution Criteria Use Case describes the process that takes place to allow Data Sources and Data Recipients to define the criteria or circumstances under which they will distribute or receive Catalogue Item data.

Use Cases Above

UC-1:Synchronise Catalogue Item Data

Use Cases Below

UC-24:Publish Catalogue Item Data
UC-26:Confirm Catalogue Item Data
UC-27:Subscribe to Catalogue Item Data
UC-28:Remove Catalogue Item Subscription
UC-34:Stop Publishing Catalogue Item Data
UC-48:Request Catalogue Item Data

Actors

Data Source
Source Data Pool (SDP)
Data Recipient
Recipient Data Pool (RDP)
Global Registry

Performance Goals

Data Source: To inform the Source Data Pool of the criteria under which Catalogue Item Data may be distributed to Data Recipients (Publication).
SDP: To obtain the necessary information that will allow the SDP to distribute Catalogue Item Data to the appropriate Recipient Data Pool (Publications, Subscriptions and Confirmations).
Data Recipient: To inform the Recipient Data Pool of the criteria under which Catalogue Item Data may be forwarded to the Data Recipient (Subscriptions, Confirmations).
Recipient Data Pool: To obtain the necessary information that will allow the RDP to forward Catalogue Item Data to the appropriate Data Recipient (Subscriptions, Confirmations).
Global Registry: To provide SDP with Subscriptions and the address of the RDP for a particular Data Recipient.

Preconditions

The Data Source has determined that they would like to distribute Catalogue Item Data. The Data Recipient has determined that they would like to receive Catalogue Item Data.

Postconditions

A full set of criteria (Publications, Subscriptions and Confirmations) is specified, enabling the ongoing process of distribution of Catalogue Item data. The confirmation is not a pre-requisite to the distribution of data.

Scenario

The Data Source Publishes Catalogue Item data.
The Data Recipient Subscribes to Catalogue Item Data.
The Data Recipient Confirms Catalogue Item Data.
The Source Data Pool applies the Publications, Subscriptionsand Confirmations to create the Synchronisation List

Alternative Scenario

None at this summary level

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 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-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-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 level for the EAN.UCC response and the GDSN Exception must equal the DocumentIdentification: instanceIdentifier of the original message.	Primary

TOP

12. Publish Catalogue Item Data

Use Case Name

Publish Catalogue Item Data

Traceability Identifier

UC-24

Use Case Description

The Publish Catalogue Item Data Use Case describes how a Data Source provides the Source Data Pool with the criteria under which their Catalogue Item Data may be distributed to Data Recipients.

Use Cases Above

UC-23:Manage Catalogue Item Distribution Criteria

Use Cases Below

None

Actors

Data SourceSource Data Pool (SDP)

Performance Goals

Data Source: To inform the Source Data Pool of the criteria (Target Market, Recipient GLN) under which their Catalogue Item Data may be distributed to Data Recipients.SDP:To posses the necessary information that will allow the SDP to distribute Catalogue Item Data to the appropriate Recipient Data Pool.

Preconditions

Each Catalogue Item has been loaded to the Source Data Pool and Registered in the Global Registry.

Postconditions

Publication data is stored in the Source Data Pool.

Scenario

Begins when, the Source Data Pool receives a Publication message from a Data Source.
1.The SDP validates the Publication (valid Target Market, GLN)2.The SDP creates or updates the Synchronisation List
Ends when, the Synchronisation List is created or updated.

Alternative Scenario

ad 1.Data Source has sent invalid data:
1.1.The SDP sends an error message to the Source Data Pool specifying what was invalid.
Ends when, the Data Source receives the error message

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.	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-32	Acknowledgement Reason codes must be unique.	Primary
REQ-66	When product is available again: update start/end availability date.	Primary
REQ-82	Maintaining a publication is granting visibility and access to data.	Secondary
REQ-83	Publications are initiated by the Data Source in the source data pool, they do not need to be synchronised in the Global Data Synchronisation Network (GDSN).	Secondary
REQ-84	The Target Market where product is available is communicated in the product key (GTIN+GLN+TM) – this can be different from the Target Market for publication.	Secondary
REQ-85	Data is either published: - to a Target Market: any GLN in the Target Market has access to the data (only applies to “public” Items) - to specific GLN’s: only these GLN’s have access to the data (only applies to “private” Items)	Secondary
REQ-86	The purpose of the public/private flag is to provide information to the parties involved on the status of the Catalogue Item.	Secondary
REQ-87	Notification is triggered by the matching process.	Secondary
REQ-88	The matching process is owned and developed by each source data pool in order to trigger data distribution based on publication and subscription data.	Secondary
REQ-89	The matching process can be triggered either by publication, subscription or as a scheduled event. It is valid for all subscription types (including synchronisation list) and all publication types.	Secondary
REQ-91	For a given publication (create/update) : - the matching process identifies subscriptions with matching criteria (TM, GLN, category, GTIN…) - for each matching subscription, a notification is created including all dependent hierarchies - for a synchronisation list, the hierarchy information included in the notification, will be limited to the GTIN's maintained in the Synchronisation list. - The notification is sent to the home data pool of the data recipient.	Secondary
REQ-93	Although the notification process will physically move the data from one data pool to another, this data should not be stored permanently for the purpose of synchronisation with any other user than the initial subscriber. If stored, access should be limited to the initial data recipient.	Secondary
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-128	Source Data Pools must send notifications based on matching publications and subscriptions.	Primary
REQ-138	Publication Who : Data Source = source GLN What : Item record, identified by GTIN+GLN+TMWhere : TM or GLN (= target GLN)	Secondary
REQ-140	Publication TM does not have to be equal to the GTIN TM (i.e. I can have a product record defined for TM France, but publishing the data toBelgium only for information purposes).	Secondary
REQ-144	Request for publication (subscription) resets the reject flag if catalogue Item has been previously rejected and reactivate the subscription.	Secondary
REQ-145	The request for publication subscription is only executed once.	Secondary
REQ-146	Subscriptions are passed from global Registry to data pools just once. The Global Registry passes along to the source data pool matching subscriptions in the entirety, rather than replicating for each GTIN registered.	Primary
REQ-147	Request for notification publication (subscription) resets the reject flag if the Catalogue Item has been previously rejected and reactivate the subscription.	Primary
REQ-148	The "Reload" attribute will contain a Boolean value (TRUE or FALSE).	Primary
REQ-149	Upon execution of an item data notification, the source data pool will pass along the value of this attribute within the message for the recipient to properly route the inbound message. After executing the item data notification, the source data pool will	Primary
REQ-150	The team identified the need for an additional process to be known as “Request for Notification”. The Request for Notification is originated by the requesting data recipient, through the recipient data pool, to the Global Registry and forwarded to the so	Primary
REQ-151	The team wanted to reiterate the fact that new subscriptions received by a source data pool would be executed immediately a single time.	Primary
REQ-152	The ability to set up a subscription and not get an initial full load of data. She wants to only receive the changes, adds, deletes and new items that match her subscription. (This is the same as a regular subscription with the exception of not getting	Primary
REQ-154	The Global Registry shall send only once a subscription to a Source Data Pool.	Primary
REQ-156	Subscription matches are performed at any level of the hierarchy. The data recipient is sent all hierarchies that match.	Secondary
REQ-155	Data Sources will publish trade items at the highest level of the hierarchy	Primary
REQ-158	Top of hierarchy is assumed to be the largest available unit determined by the data source. Defined as the GTIN of the highest published item in the hierarchy.	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-166	A Request for Catalogue Item Notification with the isReload set to false will result in items being re-sent whether they were previously rejected or not. The Sync List will be reset. This is only valid for items that have previously been sent to the data recipient. The CIN response will have the following values: documentStatus= Original isReload = False Command= Add	Primary
REQ-167	A Request for Catalogue Item Notification with the isReload set to true will result in only items not previously rejected being re-sent. The Sync List is not reset. The CIN response will have the following values: documentStatus= Copy isReload = True Command= Add	Primary
REQ-168	The Document Status of the RFCIN command is ignored for the purposes of determining its impact on the sync list and the status of the CIN that is generated.	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

Figure 34 - Publish Catalogue Item Data Activity Diagram

Figure 35- Publish Catalogue Item Data Sequence Diagram

TOP

13. Stop Publishing Catalogue Item Data

Figure 36 - Stop Publishing Catalogue Item Data Use Case Diagram

Use Case Name

Stop Publishing Catalogue Item Data

Traceability Identifier

UC-34

Use Case Description

The Stop Publishing Catalogue Item Data Use Case describes how a Data Source informs the Source Data Pool to delete the criteria under which their Catalogue Item Data may be distributed to Data Recipients.
The Source Data Pool will not be able to distribute the Catalogue Item Data prescribed by the criteria.

Use Cases Above

UC-23:Manage Catalogue Item Distribution Criteria

Use Cases Below

None

Actors

Data SourceSource Data Pool (SDP)

Performance Goals

Data Source: To inform the Source Data Pool to delete a Publication and stop distributing Catalogue Item Data.SDP: To posses the necessary information that will allow the SDP to distribute Catalogue Item Data to the appropriate Recipient Data Pool.

Preconditions

The Publication exists in the Source Data Pool.

Postconditions

The Source Data Pool is unable to distribute the Catalogue Item Data that was specified in the deleted Publication.

Scenario

Begins when, the Source Data Pool receives a message to delete a publicationfrom a Data Source.
1.The SDP validates that the Publication exists2.The SDP removes the entry from the Synchronisation List3.The SDP deletes the Publication.4.The SDP sends a CIN (with a Document Command of Delete and a CIN CatalogueItem State which equals the current catalogue item state in the Global Registry ) to the recipient data pool and on to the data recipient informing them that the publication has been stopped (break in synchronisation). Note : None of the item dates are updated in this transaction.
Ends when, the Data Recipient receives the CIN with a Document Command of Delete and a CIN Catalogue Item State which equals the current catalogue item state in the Global Registry.

Alternative Scenario

ad 1.The Publication does not exist at the Source Data Pool:
1.1. The SDP sends an error message to the Source Data Pool specifying that the Publication does not exist.
Ends when, the Data Source receives the error message

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.	Primary
REQ-16	Subscription remains valid until it is deleted. Hence, it can not be updated.	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-32	Acknowledgement Reason codes must be unique.	Primary
REQ-65	Communicate that product is no longer available: maintain end availability date.	Primary
REQ-66	When product is available again: update start/end availability date.	Primary
REQ-82	Maintaining a publication is granting visibility and access to data.	Primary
REQ-83	Publications are initiated by the Data Source in the source data pool, they do not need to be synchronised in the Global Data Synchronisation Network (GDSN).	Primary
REQ-84	The Target Market where product is available is communicated in the product key (GTIN+GLN+TM) – this can be different from the Target Market for publication.	Primary
REQ-85	Data is either published: - to a Target Market: any GLN in the Target Market has access to the data (only applies to “public” Items) - to specific GLN’s: only these GLN’s have access to the data (only applies to “private” Items)	Primary
REQ-86	The purpose of the public/private flag is to provide information to the parties involved on the status of the Catalogue Item.	Primary
REQ-87	Notification is triggered by the matching process.	Primary
REQ-88	The matching process is owned and developed by each source data pool in order to trigger data distribution based on publication and subscription data.	Primary
REQ-89	The matching process can be triggered either by publication, subscription or as a scheduled event. It is valid for all subscription types (including synchronisation list) and all publication types.	Primary
REQ-91	For a given publication (create/update) : - the matching process identifies subscriptions with matching criteria (TM, GLN, category, GTIN…) - for each matching subscription, a notification is created including all dependent hierarchies - for a synchronisation list, the hierarchy information included in the notification, will be limited to the GTIN's maintained in the Synchronisation list. - The notification is sent to the home data pool of the data recipient.	Primary
REQ-93	Although the notification process will physically move the data from one data pool to another, this data should not be stored permanently for the purpose of synchronisation with any other user than the initial subscriber. If stored, access should be limited to the initial data recipient.	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-128	Source Data Pools must send notifications based on matching publications and subscriptions.	Primary
REQ-138	Publication Who : Data Source = source GLN What : Item record, identified by GTIN+GLN+TMWhere : TM or GLN (= target GLN)	Primary
REQ-140	Publication TM does not have to be equal to the GTIN TM (i.e. I can have a product record defined for TM France, but publishing the data toBelgium only for information purposes).	Primary
REQ-144	Request for publication (subscription) resets the reject flag if catalogue Item has been previously rejected and reactivate the subscription.	Primary
REQ-145	The request for publication subscription is only executed once.	Primary
REQ-146	Subscriptions are passed from global Registry to data pools just once. The Global Registry passes along to the source data pool matching subscriptions in the entirety, rather than replicating for each GTIN registered.	Primary
REQ-147	Request for notification publication (subscription) resets the reject flag if the Catalogue Item has been previously rejected and reactivate the subscription.	Primary
REQ-148	The "Reload" attribute will contain a Boolean value (TRUE or FALSE).	Primary
REQ-149	Upon execution of an item data notification, the source data pool will pass along the value of this attribute within the message for the recipient to properly route the inbound message. After executing the item data notification, the source data pool will	Primary
REQ-150	The team identified the need for an additional process to be known as “Request for Notification”. The Request for Notification is originated by the requesting data recipient, through the recipient data pool, to the Global Registry and forwarded to the so	Primary
REQ-151	The team wanted to reiterate the fact that new subscriptions received by a source data pool would be executed immediately a single time.	Primary
REQ-152	The ability to set up a subscription and not get an initial full load of data. She wants to only receive the changes, adds, deletes and new items that match her subscription. (This is the same as a regular subscription with the exception of not getting	Primary
REQ-154	The Global Registry shall send only once a subscription to a Source Data Pool.	Primary
REQ-155	Data Sources will publish trade items at the highest level of the hierarchy.	Primary
REQ-158	Top of hierarchy is assumed to be the largest available unit determined by the data source. Defined as the GTIN of the highest published item in the hierarchy.	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-162	To stop the publication of a hierarchy to data recipient, a CIN (with a Document Command of Delete and a CIN Catalogue Item State which equals the current catalogue item state in the Global Registry) will be sent from the source data pool to the recipient data pool and on to the data recipient.	Primary
REQ-165	Publication deletes must be done at highest level of the published item hierarchy.	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

Figure 37 - Stop Publishing Catalogue Item Data Activity Diagram

Figure 38 - Stop Publishing Catalogue Item Data Sequence Diagram

TOP

14. Subscribe to Catalogue Item Data

Figure 39 - Subscribe to Catalogue Item Data Use Case Diagram

Use Case Name

Subscribe to Catalogue Item Data

Traceability Identifier

UC-27

Use Case Description

The Subscribe to Catalogue Item Data Use Case describes how a Data Recipient informs the Recipient Data Pool with the criteria under which Catalogue Item Data may be distributed to the Data Recipient.
Once the Subscription is created, the Recipient Data Pool will forward it to the Global Registry which, in turn, will forward it to appropriate Source Data Pools (see UC-35 Distribute Subscription Data).

Use Cases Above

UC-23:Manage Catalogue Item Distribution Criteria

Use Cases Below

None

Actors

Data RecipientRecipient Data Pool (RDP)

Performance Goals

Data Recipient:To inform the Recipient Data Pool of the criteria by which Catalogue Item Data may be forwarded to the Recipient.RDP:To posses the necessary information that will allow the RDP to send subscriptions to the Global Registry.

Preconditions

None

Postconditions

The Recipient Data Pool has a Subscription that can be shared with the Global Registry.

Scenario

Begins when, the Recipient Data Pool receives a Subscription Publication message from a Data Recipient.
1.The RDP sends a message acknowledgement to the Data Recipient2.The RDP validates the Subscription criteria (GTIN, GLN of data owner, Target Market or Category).3.The RDP sends a Subscription Verification to the Data Recipient
Ends when, the Data Recipient acknowledges the Subscription Verification message.

Alternative Scenario

ad 1.The Subscription already exists:
1.1.The RDP sends an error message to the Data Recipient specifying that the Subscription exists.
Ends when, the Data Recipient receives the error message
Ad 2.The validation fails:2.1.The RDP sends an error message to the Data Recipient specifying the field in errorEnds when, the Data Recipient receives the error message

Special Requirements

If the GLN is not found in the party registry, the subscription is still persisted. The GLN must still pass all syntactic validations.
If the GTIN is not found in the item registry, the subscription is still persisted. The GTIN must still pass all syntactic validations.
If the Target Market is not found in the code list of valid target markets in the global registry, the subscription fails.
If the GPC is not found in the code list of valid GPCs in the global registry, the subscription fails.
If a subscription, after passing these validations fails to match any items in the global registry, the subscription is still persisted.

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-14	A subscription must be able to be maintained on the following levels : - GTIN - GLN of Data Source - Target Market - Lowest level of EAN.UCC Classification or any combination of these 4 elements.	Secondary
REQ-15	With the set up of a subscription, a Data Recipient sets a profile to receive ongoing updates of the matching data (including all hierarchies, independently from the level subscribed on).	Secondary
REQ-16	Subscription remains valid until it is deleted. Hence, it can not be updated.	Primary
REQ-17	Subscriptions must be created by data recipients in their Recipients Data Pool and sent to the Global Registry.	Secondary
REQ-19	The system must maintain detailed subscription lists.	Secondary
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-29	The confirmation process must take place in the home data pool of the data recipient.	Primary
REQ-32	Acknowledgement Reason codes must be unique.	Primary
REQ-69	Data recipient maintains subscription.	Secondary
REQ-70	Data recipient will continue to receive updates until he rejects the data.	Primary
REQ-72	Reject is optional: in the absence of confirmation & reject, the data recipient would still receive updates.	Primary
REQ-73	Confirmed GTIN: - subscription: go to synchronisation list - synchronisation list: no action required	Secondary
REQ-74	Only new products matching the initial subscription will be distributed to avoid resending data that was previously rejected.	Primary
REQ-78	Subscription: for every matching GTIN, independently from its level, all hierarchies will be returned.	Secondary
REQ-79	Synchronisation list: - Includes every GTIN id (GTIN+GLN+TM) that needs to be synchronised - Can be a result of the Confirmation process - All GTIN’s equal or lower in the hierarchy than the GTIN confirmed will be returned	Primary
REQ-81	Synchronisation List is only synchronised between the involved source and recipient data pools for applicable data: synchronisation list is built based on confirmation received by a source data pool and nothing else.	Primary
REQ-88	The matching process is owned and developed by each source data pool in order to trigger data distribution based on publication and subscription data.	Primary
REQ-89	The matching process can be triggered either by publication, subscription or as a scheduled event. It is valid for all subscription types (including synchronisation list) and all publication types.	Primary
REQ-90	For a given subscription (create/update): - the matching process identifies Items published to the GLN or TM of the subscription owner. - for each item, a notification is created including all dependent hierarchies. - for a synchronisation list, the hierarchy information included in the notification, will be limited to the GTIN's maintained in the Synchronisation list. - The notification is sent to the home data pool of the data recipient.	Secondary
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-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-110	After a Subscription is created, the Global Registry will then disseminate relevant subscriptions to appropriate Source Data Pools (current and future new data pools).	Secondary
REQ-111	Registry requirements for subscription are: - Receive and store subscriptions - Provide subscription acknowledgement - Matching process of subscriptions with Source Data Pools - Forward subscriptions	Secondary
REQ-123	Recipient maintains a subscription, including the "Reload" flag.	Secondary
REQ-124	The notification triggered by a subscription must also carry the "Reload" flag value.	Secondary
REQ-126	If a new Reload is needed, the Recipient must delete the previous Reload Subscription, then create a new Subscription with the "Reload" flag set.	Secondary
REQ-128	Source Data Pools must send notifications based on matching publications and subscriptions.	Primary
REQ-129	GTIN and Category are mutually exclusive subscription criteria as the Category is uniquely defined for a given GTIN, independently from the GLN and from the TM.	Secondary
REQ-132	The events that can trigger the distribution of a subscription are: - new/updated registration: check existing subscriptions, if new data pools are found : distribute subscriptions - new subscription: check existing registrations, if new data pools are found: distribute subscriptions - delete subscriptions: distribute “delete” to source data pools where subscription had been sent	Primary
REQ-133	Subscriptions cannot be updated, they are created or deleted.	Primary
REQ-134	Subscriptions must be stored in the recipient’s data pool.	Primary
REQ-135	For every subscription, the Registry must store the GLN of the Source Data Pool to which the subscription was sent and when it was sent.	Primary
REQ-136	Ability to identify new or updated registered Catalogue Items that match a subscription and forward the subscription to the Source Data Pool.	Primary
REQ-137	Match new subscriptions with registered Catalogue Items and forward the subscription to the Source Data Pool.	Primary
REQ-139	SubscriptionWho : Data Recipient = target GLNWhat : Any combination of GTIN, GLN, TM and Category	Primary
REQ-141	Deletion of a Subscription stops New Catalogue Items from being sent to RDP, but, doesn't stop Catalogue Items already in the Synchronisation List from being updated.	Primary
REQ-142	Request for Notification is not retained in the Global Registry and acts like a Subscription that is applied to the Synchronisation List, then deleted (no New Catalogue Item data will be sent).	Primary
REQ-143	"Reload" flag is passed through to Recipient.	Primary
REQ-144	Request for publication (subscription) resets the reject flag if catalogue Item has been previously rejected and reactivate the subscription.	Primary
REQ-145	The request for publication subscription is only executed once.	Primary
REQ-146	Subscriptions are passed from global Registry to data pools just once. The Global Registry passes along to the source data pool matching subscriptions in the entirety, rather than replicating for each GTIN registered.	Primary
REQ-147	Request for notification publication (subscription) resets the reject flag if the Catalogue Item has been previously rejected and reactivate the subscription.	Primary
REQ-148	The "Reload" attribute will contain a Boolean value (TRUE or FALSE).	Primary
REQ-149	Upon execution of an item data notification, the source data pool will pass along the value of this attribute within the message for the recipient to properly route the inbound message. After executing the item data notification, the source data pool will	Primary
REQ-150	The team identified the need for an additional process to be known as “Request for Notification”. The Request for Notification is originated by the requesting data recipient, through the recipient data pool, to the Global Registry and forwarded to the so	Primary
REQ-151	The team wanted to reiterate the fact that new subscriptions received by a source data pool would be executed immediately a single time.	Primary
REQ-152	The ability to set up a subscription and not get an initial full load of data. She wants to only receive the changes, adds, deletes and new items that match her subscription. (This is the same as a regular subscription with the exception of not getting	Primary
REQ-154	The Global Registry shall send only once a subscription to a Source Data Pool.	Primary
REQ-156	Subscription matches are performed at any level of the hierarchy. The data recipient is sent all hierarchies that match.	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- 169	The Global Registry shall retain and persist all Catalogue Item Subscriptions that are received that contain a GTIN or GLN that is not found in the Global Registry.	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

Figure 40 - Subscribe to Catalogue Item Data Activity Diagram

Figure 41 - Subscribe to Catalogue Item Data Sequence Diagram

TOP

15. Remove Catalogue Item Subscription

Figure 42 - Remove Catalogue Item Subscription Use Case Diagram

Use Case Name

Remove Catalogue Item Subscription

Traceability Identifier

UC-28

Use Case Description

The Remove Catalogue Item Subscription Use Case describes how a Data Recipient informs the Recipient Data Pool to delete a subscription.
Once the Subscription is removed, the Recipient Data Pool will forward the removal information to the Global Registry which, in turn, will forward it to appropriate Source Data Pools (see UC-35 Distribute Subscription Data).
The Source Data Pools will remove the subscription.Thereafter, the Source Data Pools will not send new Catalogue Item data to the Data Recipient (via their Recipient Data Pool).The removal of a subscription does not affect the Synchronisation list held by the Source Data pool.The Data Recipient will continue to receive changes, corrections and deletions based on the Synchronisation List.

Use Cases Above

UC-23:Manage Catalogue Item Distribution Criteria

Use Cases Below

None

Actors

Data RecipientRecipient Data Pool (RDP)

Performance Goals

Data Recipient: To inform the Recipient Data Pool of the removal of a subscription. Essentially (via the Distribute Subscription Use Case) stopping new Catalogue Item data from being forwarded.RDP: To posses the necessary information that will allow the RDP and appropriate Source Data Pools to distribute Catalogue Item Data to the Recipient.

Preconditions

The Data recipient has a Subscription held by the Recipient Data Pool.

Postconditions

The Subscription no longer exists in the Recipient Data Pool or (via the Distribute Subscription Use Case) the Registry and Source Data Pools.

Scenario

Begins when, the Recipient Data Pool receives a Delete Subscription message from a Data Recipient.
1.The RDP sends a message acknowledgement to the Data Recipient2.The RDP validates that the Subscription exists.3.The RDP sends a Subscription Verification to the Data Recipient
Ends when, the Data Recipient acknowledges the Subscription Verification message.

Alternative Scenario

ad 2.The Subscription does not exist:
2.1.The RDP sends an error message to the Data Recipient specifying that the Subscription does not exist.
Ends when, the Data Recipient receives the error message

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-14	A subscription must be able to be maintained on the following levels : - GTIN - GLN of Data Source - Target Market - Lowest level of EAN.UCC Classification or any combination of these 4 elements.	Primary
REQ-15	With the set up of a subscription, a Data Recipient sets a profile to receive ongoing updates of the matching data (including all hierarchies, independently from the level subscribed on).	Primary
REQ-16	Subscription remains valid until it is deleted. Hence, it can not be updated.	Secondary
REQ-19	The system must maintain detailed subscription lists.	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-29	The confirmation process must take place in the home data pool of the data recipient.	Primary
REQ-32	Acknowledgement Reason codes must be unique.	Primary
REQ-70	Data recipient will continue to receive updates until he rejects the data.	Secondary
REQ-72	Reject is optional: in the absence of confirmation & reject, the data recipient would still receive updates.	Secondary
REQ-77	Filtering out rejected data is a source data pool responsibility.	Primary
REQ-78	Subscription: for every matching GTIN, independently from its level, all hierarchies will be returned.	Primary
REQ-79	Synchronisation list: - Includes every GTIN id (GTIN+GLN+TM) that needs to be synchronised - Can be a result of the Confirmation process - All GTIN’s equal or lower in the hierarchy than the GTIN confirmed will be returned	Primary
REQ-80	Rejection at the highestlevel of a hierarchy will trigger the rejection of all GTIN’s in the hierarchy of the rejected GTIN.	Primary
REQ-81	Synchronisation List is only synchronised between the involved source and recipient data pools for applicable data: synchronisation list is built based on confirmation received by a source data pool and nothing else.	Primary
REQ-88	The matching process is owned and developed by each source data pool in order to trigger data distribution based on publication and subscription data.	Primary
REQ-89	The matching process can be triggered either by publication, subscription or as a scheduled event. It is valid for all subscription types (including synchronisation list) and all publication types.	Primary
REQ-90	For a given subscription (create/update): - the matching process identifies Items published to the GLN or TM of the subscription owner. - for each item, a notification is created including all dependent hierarchies. - for a synchronisation list, the hierarchy information included in the notification, will be limited to the GTIN's maintained in the Synchronisation list. - The notification is sent to the home data pool of the data recipient.	Primary
REQ-98	Note : rejection should not remove data previously authorised, for instance in a different hierarchy.	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-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-110	After a Subscription is created, the Global Registry will then disseminate relevant subscriptions to appropriate Source Data Pools (current and future new data pools).	Primary
REQ-111	Registry requirements for subscription are: - Receive and store subscriptions - Provide subscription acknowledgement - Matching process of subscriptions with Source Data Pools - Forward subscriptions	Primary
REQ-123	Recipient maintains a subscription, including the "Reload" flag.	Primary
REQ-124	The notification triggered by a subscription must also carry the "Reload" flag value.	Primary
REQ-126	If a new Reload is needed, the Recipient must delete the previous Reload Subscription, then create a new Subscription with the "Reload" flag set.	Primary
REQ-128	Source Data Pools must send notifications based on matching publications and subscriptions.	Primary
REQ-129	GTIN and Category are mutually exclusive subscription criteria as the Category is uniquely defined for a given GTIN, independently from the GLN and from the TM.	Primary
REQ-132	The events that can trigger the distribution of a subscription are: - new/updated registration: check existing subscriptions, if new data pools are found : distribute subscriptions - new subscription: check existing registrations, if new data pools are found: distribute subscriptions - delete subscriptions: distribute “delete” to source data pools where subscription had been sent	Primary
REQ-133	Subscriptions cannot be updated, they are created or deleted.	Secondary
REQ-134	Subscriptions must be stored in the recipient’s data pool.	Primary
REQ-135	For every subscription, the Registry must store the GLN of the Source Data Pool to which the subscription was sent and when it was sent.	Primary
REQ-136	Ability to identify new or updated registered Catalogue Items that match a subscription and forward the subscription to the Source Data Pool.	Primary
REQ-137	Match new subscriptions with registered Catalogue Items and forward the subscription to the Source Data Pool.	Primary
REQ-139	SubscriptionWho : Data Recipient = target GLNWhat : Any combination of GTIN, GLN, TM and Category	Primary
REQ-141	Deletion of a Subscription stops New Catalogue Items from being sent to RDP, but, doesn't stop Catalogue Items already in the Synchronisation List from being updated.	Secondary
REQ-142	Request for Notification is not retained in the Global Registry and acts like a Subscription that is applied to the Synchronisation List, then deleted (no New Catalogue Item data will be sent).	Primary
REQ-143	"Reload" flag is passed through to Recipient.	Primary
REQ-144	Request for publication (subscription) resets the reject flag if catalogue Item has been previously rejected and reactivate the subscription.	Primary
REQ-145	The request for publication subscription is only executed once.	Primary
REQ-146	Subscriptions are passed from global Registry to data pools just once. The Global Registry passes along to the source data pool matching subscriptions in the entirety, rather than replicating for each GTIN registered.	Primary
REQ-147	Request for notification publication (subscription) resets the reject flag if the Catalogue Item has been previously rejected and reactivate the subscription.	Primary
REQ-148	The "Reload" attribute will contain a Boolean value (TRUE or FALSE).	Primary
REQ-149	Upon execution of an item data notification, the source data pool will pass along the value of this attribute within the message for the recipient to properly route the inbound message. After executing the item data notification, the source data pool will	Primary
REQ-150	The team identified the need for an additional process to be known as “Request for Notification”. The Request for Notification is originated by the requesting data recipient, through the recipient data pool, to the Global Registry and forwarded to the so	Primary
REQ-151	The team wanted to reiterate the fact that new subscriptions received by a source data pool would be executed immediately a single time.	Primary
REQ-152	The ability to set up a subscription and not get an initial full load of data. She wants to only receive the changes, adds, deletes and new items that match her subscription. (This is the same as a regular subscription with the exception of not getting	Primary
REQ-154	The Global Registry shall send only once a subscription to a Source Data Pool.	Primary
REQ-156	Subscription matches are performed at any level of the hierarchy. The data recipient is sent all hierarchies that match.	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

Figure 43 - Remove Catalogue Item Subscription Activity Diagram

Figure 44 - Remove Subscription Sequence Diagram

TOP

16. Confirm Catalogue Item Data

Use Case Name

Confirm Catalogue Item Subscription

Traceability Identifier

UC-26

Use Case Description

The Confirm Catalogue Item Data Use Case describes how a Data Recipient informs the Source Data Pool of its intentions regarding the Catalogue Item.
The four states that can be communicated are Accepted, Synchronised, Rejected, or Review.Only a CIC communicated with the status of Rejected will stop the Source Data Pool from sending updates to the Recipient Data Pool. In the absence of a confirmation, the Source Data Pool will continue to send updates to the Recipient Data Pool.
In the case that the status of the “Catalogue Confirmation State List” is set to either “Review” or “Rejected” the Catalogue Item Confirmation (CIC) Message can include additional information about the Confirmation back to the Supplier (Data Source).

Use Cases Above

UC-23:Manage Catalogue Item Distribution Criteria

Use Cases Below

None

Actors

Data RecipientRecipient Data Pool (RDP)Source Data Pool (SDP)

Performance Goals

Data Recipient:To inform the Source Data Pool of its intentions regarding the Catalogue Item
RDP:To posses the necessary information that will allow the RDP and appropriate Source Data Pools to distribute Catalogue Item Data to the Recipient.SDP:To identify Data Recipients that are actively using Synchronised Item data.

Preconditions

The Data recipient has received Catalogue Item data.

Postconditions

The RDP and SDP are aware of the Data Recipient’s intentions regarding a specific Catalogue Item.In the case of a reject, the SDP knows not to continue sending updates on the particular Item.
In the event of a CIC Status of Review or Rejected, the Data Source optionally receives the confirmation code, description and the comment and understands what action they need to take to resolve the current situation.

Scenario

Begins when, the Data Recipient sends a Catalogue Item Confirmation to the RDP.
1.The RDP sends a message acknowledgement to the Data Recipient2.The RDP validates the Confirmation message.3.The RDP sends an acknowledgement to the Data Recipient.4.The RDP sends the Catalogue Item Confirmation to the SDP.
Ends when, the SDP receives the Catalogue Item Confirmation.

Alternative Scenario

ad 2.The Confirmation message is invalid:
2.1.The RDP sends an error message to the Data Recipient specifying the errors in the Confirmation message.
Ends when, the Data Recipient receives the error message

Special Requirements

None

Extension Points

N/A

Requirements Covered

ID	Requirement	Weight
REQ-172	When the status of the “Catalogue Confirmation State List” is set to either “Review” or “Rejected”, there may be additional information in the CIC message such as theconfirmation code, description, and the comment and understands what action they need to take to resolve the current situation.	Primary
REQ-173	This Confirmation Code and Description are joined as a pair	Primary
REQ-174	The CIC message can include multiple Catalogue Item References (GTIN + GLN + Target Market) to establish the relationship between the information communicated and the actual Catalogue Item being referenced.	Primary

Figure 45 - Confirm Catalogue Item Data Activity Diagram

Figure 46 - Catalogue Item Data Sequence Diagram

TOP

17. Request Catalogue Item Data

Figure 47 - Request Catalogue Item Data Use Case Diagram

Use Case Name

Request Catalogue Item Data

Traceability Identifier

UC-48

Use Case Description

The Request Catalogue Item Data Use Case describes how a Data Recipient informs the Source Data Pool to resend certain Catalogue Item data.This Use Case makes use of the Request for Catalogue Item Notification message.
This request is identical to a subscription with the difference being that the Global Registry will not retain the message once all relevant Source Data Pools receive the message.A special case of the Request is when the Data Recipient includes the “reload” flag in the message.This flag is attached to the resultant Catalogue Item Notification.

Use Cases Above

UC-23:Manage Catalogue Item Distribution Criteria

Use Cases Below

None

Actors

Data RecipientRecipient Data Pool (RDP)

Performance Goals

Data Recipient: To inform the Source Data Pool that it Would like certain Catalogue Item data to be resent.
RDP: To posses the necessary information that will allow the RDP and appropriate Source Data Pools to distribute Catalogue Item Data to the Recipient.

Preconditions

The Data recipient has received Catalogue Item data.

Postconditions

The RDP is aware that certain Catalogue Item data is to be resent to the Data Recipient.

Scenario

Begins when, the Data Recipient sends a RequestForCatalogueItemNotification to the RDP.
1.The RDP sends a message acknowledgement to the Data Recipient2.The RDP validates the request message.3.The RDP sends an acknowledgement to the Data Recipient.
Ends when, the Data Recipient receives the acknowledgement.

Alternative Scenario

ad 2.The request message is invalid:
2.1.The RDP sends an error message to the Data Recipient specifying the errors in the original message.
Ends when, the Data Recipient receives the error message

Special Requirements

Extension Points

N/A

Requirements Covered

REQ-166	A Request for Catalogue Item Notification with the isReload set to false will result in items being re-sent whether they were previously rejected or not. The Sync List will be reset. This is only valid for items that have previously been sent to the data recipient. The CIN response will have the following values: documentStatus= Original isReload = False Command= Add	Primary
REQ-167	A Request for Catalogue Item Notifcation with the isReload set to true will result in only items not previously rejected being re-sent. The Sync List is not reset. The CIN response will have the following values: documentStatus= Copy isReload = True Command= Add	Primary
REQ-168	The Document Status of the RFCIN command is ignored for the purposes of determining its impact on the sync list and the status of the CIN that is generated.	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

Figure 48 - Catalogue Item Data Activity Diagram

Figure 49 - Request Catalogue Item Data Sequence Diagram

TOP

18. Distribute Subscription Data

Figure 50 - Distribute Subscription Data Use Case Diagram

Use Case Name

Distribute Subscription Data

Traceability Identifier

UC-35

Use Case Description

The Distribute Subscription Data Use Case describes how new and Delete Subscription messages are propagated throughout the Data Synchronisation system.

Use Cases Above

UC-23:Manage Catalogue Item Distribution Criteria

Use Cases Below

None

Actors

Data RecipientRecipient Data Pool (RDP)Global RegistrySource Data Pool (SDP)Data Source

Performance Goals

Data Recipient: To share Subscriptions and removal of Subscriptions with the appropriate Source Data Pools and Data Sources.RDP: To posses the necessary information that will allow the RDP and appropriate Source Data Pools to distribute Catalogue Item Data to the Recipient.
Global Registry: To propagate Subscriptions to appropriate Data Pools.SDP: To posses the necessary information that will allow the SDP to distribute Catalogue Item Data to the Recipient (via their RDP).Data Source: To keep track of current and potential customer’s usage of Catalogue Item Data.

Preconditions

The Data recipient has either created or deleted a Subscription in their Recipient Data Pool.

Postconditions

The Subscription or delete subscription message is propagated to the Registry and proper Source Data Pools and Data Sources.

Scenario

Begins when, the Recipient Data Pool receives a Subscription or Delete Subscription message from a Data Recipient and has validated it.
1.The RDP sends the Add/Delete Subscription to the Global Registry.2.The Global Registry validates the message.3.The Global Registry matches the subscription to Catalogue Item data in the Registry.4.The Global Registry sends the Add/Delete Subscription to the matching SDP5.The SDP sends the Add/Delete Subscription to the appropriate Data Source
Ends when, the Data Source acknowledges the Subscription message.

Alternative Scenario

ad 1.A new Catalogue Item is added to the Registry:1.1The Global Registry matches the new Catalogue Item against existing Subscriptions.1.2The Global Registry Sends all matching Subscriptions to the SDP of the new Catalogue Item.1.3The SDP forwards the Subscription to the Data Source that Published the Catalogue Item.Ends when, the Data Source sends an acknowledgement of the Subscription
ad 2.The Subscription fails validation at the Registry:
2.1.The Global Registry sends an error message to the RDP.2.2.The RDP sends an error message to the Data Recipient.
Ends when, the Data Recipient receives the error message

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-14	A subscription must be able to be maintained on the following levels : - GTIN - GLN of Data Source - Target Market - Lowest level of EAN.UCC Classification or any combination of these 4 elements.	Primary
REQ-15	With the set up of a subscription, a Data Recipient sets a profile to receive ongoing updates of the matching data (including all hierarchies, independently from the level subscribed on).	Primary
REQ-17	Subscriptions must be created by data recipients in their Recipients Data Pool and sent to the Global Registry.	Primary
REQ-18	A new Source Data Pool will get their relevant subscriptions as soon as they start registering their GTIN’s.	Secondary
REQ-19	The system must maintain detailed subscription lists.	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-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-29	The confirmation process must take place in the home data pool of the data recipient.	Primary
REQ-32	Acknowledgement Reason codes must be unique.	Primary
REQ-69	Data recipient maintains subscription.	Primary
REQ-70	Data recipient will continue to receive updates until he rejects the data.	Primary
REQ-72	Reject is optional: in the absence of confirmation & reject, the data recipient would still receive updates.	Primary
REQ-73	Confirmed GTIN: - subscription: go to synchronisation list - synchronisation list: no action required	Primary
REQ-74	Only new products matching the initial subscription will be distributed to avoid resending data that was previously rejected.	Secondary
REQ-78	Subscription: for every matching GTIN, independently from its level, all hierarchies will be returned.	Primary
REQ-79	Synchronisation list: - Includes every GTIN id (GTIN+GLN+TM) that needs to be synchronised - Can be a result of the Confirmation process - All GTIN’s equal or lower in the hierarchy than the GTIN confirmed will be returned	Primary
REQ-80	Rejection at the highestlevel of a hierarchy will trigger the rejection of all GTIN’s in the hierarchy of the rejected GTIN.	Primary
REQ-81	Synchronisation List is only synchronised between the involved source and recipient data pools for applicable data: synchronisation list is built based on confirmation received by a source data pool and nothing else.	Primary
REQ-88	The matching process is owned and developed by each source data pool in order to trigger data distribution based on publication and subscription data.	Primary
REQ-89	The matching process can be triggered either by publication, subscription or as a scheduled event. It is valid for all subscription types (including synchronisation list) and all publication types.	Primary
REQ-90	For a given subscription (create/update): - the matching process identifies Items published to the GLN or TM of the subscription owner. - for each item, a notification is created including all dependent hierarchies. - for a synchronisation list, the hierarchy information included in the notification, will be limited to the GTIN's maintained in the Synchronisation list. - The notification is sent to the home data pool of the data recipient.	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-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-110	After a Subscription is created, the Global Registry will then disseminate relevant subscriptions to appropriate Source Data Pools (current and future new data pools).	Primary
REQ-111	Registry requirements for subscription are: - Receive and store subscriptions - Provide subscription acknowledgement - Matching process of subscriptions with Source Data Pools - Forward subscriptions	Primary
REQ-127	The Global Registry must distribute Subscriptions only to relevant Source Data Pools.	Secondary
REQ-129	GTIN and Category are mutually exclusive subscription criteria as the Category is uniquely defined for a given GTIN, independently from the GLN and from the TM.	Primary
REQ-130	GTIN, GLN (of Data Source), Target Market and Classification must be stored in the Global Registry, and are linked to the Source Data Pool(s) where the data can be found. For instance, if given a GTIN, the Global Registry will be able to return all the data pools where data can be found on that GTIN, independently from the GLN of the Data Source, the Target Market or the Category.	Secondary
REQ-131	The distribution of subscriptions is either a scheduled event or is triggered by another event.	Secondary
REQ-132	The events that can trigger the distribution of a subscription are: - new/updated registration: check existing subscriptions, if new data pools are found : distribute subscriptions - new subscription: check existing registrations, if new data pools are found: distribute subscriptions - delete subscriptions: distribute “delete” to source data pools where subscription had been sent	Secondary
REQ-133	Subscriptions cannot be updated, they are created or deleted.	Primary
REQ-134	Subscriptions must be stored in the recipient’s data pool.	Secondary
REQ-135	For every subscription, the Registry must store the GLN of the Source Data Pool to which the subscription was sent and when it was sent.	Secondary
REQ-136	Ability to identify new or updated registered Catalogue Items that match a subscription and forward the subscription to the Source Data Pool.	Secondary
REQ-137	Match new subscriptions with registered Catalogue Items and forward the subscription to the Source Data Pool.	Secondary
REQ-139	SubscriptionWho : Data Recipient = target GLNWhat : Any combination of GTIN, GLN, TM and Category	Secondary
REQ-141	Deletion of a Subscription stops New Catalogue Items from being sent to RDP, but, doesn't stop Catalogue Items already in the Synchronisation List from being updated.	Primary
REQ-142	Request for Notification is not retained in the Global Registry and acts like a Subscription that is applied to the Synchronisation List, then deleted (no New Catalogue Item data will be sent).	Secondary
REQ-143	"Reload" flag is passed through to Recipient.	Primary
REQ-144	Request for publication (subscription) resets the reject flag if catalogue Item has been previously rejected and reactivate the subscription.	Primary
REQ-145	The request for publication subscription is only executed once.	Primary
REQ-146	Subscriptions are passed from global Registry to data pools just once. The Global Registry passes along to the source data pool matching subscriptions in the entirety, rather than replicating for each GTIN registered.	Secondary
REQ-147	Request for notification publication (subscription) resets the reject flag if the Catalogue Item has been previously rejected and reactivates the subscription.	Secondary
REQ-148	The "Reload" attribute will contain a Boolean value (TRUE or FALSE).	Secondary
REQ-149	Upon execution of an item data notification, the source data pool will pass along the value of this attribute within the message for the recipient to properly route the inbound message. After executing the item data notification, the source data pool will	Secondary
REQ-150	The team identified the need for an additional process to be known as “Request for Notification”. The Request for Notification is originated by the requesting data recipient, through the recipient data pool, to the Global Registry and forwarded to the so	Secondary
REQ-151	The team wanted to reiterate the fact that new subscriptions received by a source data pool would be executed immediately a single time.	Secondary
REQ-152	The ability to set up a subscription and not get an initial full load of data. She wants to only receive the changes, adds, deletes and new items that match her subscription. (This is the same as a regular subscription with the exception of not getting	Secondary
REQ-154	The Global Registry shall send only once a subscription to a Source Data Pool.	Secondary
REQ-156	Subscription matches are performed at any level of the hierarchy. The data recipient is sent all hierarchies that match.	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

Figure 51 - Distribute Subscription Data Activity Diagram

Figure 52 - Distribute Subscription Data Sequence Diagram

TOP

19. Distribute Confirmation Data

Figure 53 - Distribute Confirmation Data Use Case Diagram

Use Case Name

Distribute Confirmation Data

Traceability Identifier

UC-43

Use Case Description

The Distribute Confirmation Data Use Case describes how the Data Recipient informs the Source Data pool of the status of an individual Catalogue Item Data synchronisation that was the result of a Publication / Subscription match.Valid values for the status are: “no value” (continue to send updates), “Accept” (Data Recipient signals that they are interested in the Catalogue Item, continue to send updates), “Synchronised”(Data Recipient signals that they intend to keep their database synchronised, continue to send updates) and “Reject” (Data Recipient signals that they are not interested in the Catalogue Item, do not continue to send updates).
Confirmations are passed to the Source Data Pool from the Recipient Data Pool.
In the case that the status of the “Catalogue Confirmation State List” is set to either “Review” or “Rejected” the Catalogue Item Confirmation (CIC) Message can include additional information about the Confirmation back to the Supplier (Data Source).

Use Cases Above

UC-47: Distribute Data Recipient Requests for Catalogue Item Data

Use Cases Below

None

Actors

Data RecipientRecipient Data Pool (RDP)Source Data Pool (SDP)

Performance Goals

Data Recipient: To prohibit future synchronisations of specific Catalogue Item Data, or, to notify the Source Data Pool of the Data Recipient’s intentions regarding the Catalogue Item data.
RDP: To posses the necessary information that will allow the RDP and appropriate Source Data Pools to distribute Catalogue Item Data to the Recipient.
SDP: To posses the necessary information that will allow the SDP to distribute Catalogue Item Data to the Recipient (via their RDP).

Preconditions

The Data recipient has either created a Subscription in their Recipient Data Pool and has received Catalogue Item data.

Postconditions

In the case of a “Rejection”, the Data Recipient no longer receives updates to the specific Catalogue Item.For all other authorizations, the Source Data Pool is aware of the Data Recipient’s intentions regarding the Catalogue Item data.
In the event of a CIC Status of Review or Rejected, the Data Source optionally receives the confirmation code, description, and the comment and understands what action they need to take to resolve the current situation.

Scenario

Begins when, the Data Recipient sends a Confirmation message to the Recipient Data Pool
1.The RDP sends the Confirmation to the SDP.2.The SDP validates the message.3.The SDP matches the Confirmation with the Recipient’s Synchronisation List.4. A “Reject” Confirmation will stop future publications of the whole hierarchy.5.For all other Confirmations, the SDP applies the change to the Data Recipient Synchronisation List.6.The SDP sends the Confirmation to the Data Source.7.The SDP sends a Confirmation Acknowledgement to the RDP.8.The RDP forwards the Confirmation Acknowledgement to the Data Recipient.
Ends when, the Data Recipient sends an acknowledgement of the Recipient Data Pool’s message.

Alternative Scenario

ad 2.The Confirmation message does not pass validation:2.1The SDP sends a Confirmation Error message to the RDP.2.2The RDP forwards the Confirmation Error message to the Data Recipient.Ends when, the Data Recipient sends an acknowledgement of the error message

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-17	Subscriptions must be created by data recipients in their Recipients Data Pool and sent to the Global Registry.	Primary
REQ-18	A new Source Data Pool will get their relevant subscriptions as soon as they start registering their GTIN’s.	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-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-29	The confirmation process must take place in the home data pool of the data recipient.	Secondary
REQ-32	Acknowledgement Reason codes must be unique.	Primary
REQ-75	Updates for confirmed products will be distributed based on the synchronisation list.	Secondary
REQ-76	Confirmation (accept or synchronised) will indicate the data recipient’s commitment to synchronise the data in its internal systems.	Secondary
REQ-77	Filtering out rejected data is a source data pool responsibility.	Secondary
REQ-78	Subscription: for every matching GTIN, independently from its level, all hierarchies will be returned.	Primary
REQ-79	Synchronisation list: - Includes every GTIN id (GTIN+GLN+TM) that needs to be synchronised - Can be a result of the Confirmation process - All GTIN’s equal or lower in the hierarchy than the GTIN confirmed will be returned	Secondary
REQ-80	Rejection at the highestlevel of a hierarchy will trigger the rejection of all GTIN’s in the hierarchy of the rejected GTIN.	Secondary
REQ-81	Synchronisation List is only synchronised between the involved source and recipient data pools for applicable data: synchronisation list is built based on confirmation received by a source data pool and nothing else.	Primary
REQ-88	The matching process is owned and developed by each source data pool in order to trigger data distribution based on publication and subscription data.	Primary
REQ-89	The matching process can be triggered either by publication, subscription or as a scheduled event. It is valid for all subscription types (including synchronisation list) and all publication types.	Primary
REQ-90	For a given subscription (create/update): - the matching process identifies Items published to the GLN or TM of the subscription owner. - for each item, a notification is created including all dependent hierarchies. - for a synchronisation list, the hierarchy information included in the notification, will be limited to the GTIN's maintained in the Synchronisation list. - The notification is sent to the home data pool of the data recipient.	Primary
REQ-94	Confirmation is not mandatory and can provide 4 outcomes:1.Synchronised: data is integrated, in synch2.Accept: Data has been received by the data recipient, but no business decision has been made on the data. 3.Reject: data will no longer be synchronised or updates will no longer be provided.4. Review: request to the data source to review their data and take action (applies to adds & changes) because the data recipient has received discrepant datawhich they cannot synchronise. If no confirmation is sent, data updates will continue to be provided until the data recipient accepts, rejects or updates the subscription, or until the data source changes the publication. For a new Catalogue Item the same confirmation can be used.	Secondary
REQ-95	The list of authorised values for the confirmation message does not imply a sequence in which the message has to be used.	Secondary
REQ-96	The same “confirmation” message can be used to stop synchronising a Catalogue Item. In that case, the “Reject” status will be used.	Secondary
REQ-97	“Synchronised” status is sent once – parties are assumed to be in synch unless a reject/review status is exchanged.	Secondary
REQ-98	Note : rejection should not remove data previously authorised, for instance in a different hierarchy.	Secondary
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-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-110	After a Subscription is created, the Global Registry will then disseminate relevant subscriptions to appropriate Source Data Pools (current and future new data pools).	Primary
REQ-111	Registry requirements for subscription are: - Receive and store subscriptions - Provide subscription acknowledgement - Matching process of subscriptions with Source Data Pools - Forward subscriptions	Primary
REQ-127	The Global Registry must distribute Subscriptions only to relevant Source Data Pools.	Primary
REQ-129	GTIN and Category are mutually exclusive subscription criteria as the Category is uniquely defined for a given GTIN, independently from the GLN and from the TM.	Primary
REQ-130	GTIN, GLN (of Data Source), Target Market and Classification must be stored in the Global Registry, and are linked to the Source Data Pool(s) where the data can be found. For instance, if given a GTIN, the Global Registry will be able to return all the data pools where data can be found on that GTIN, independently from the GLN of the Data Source, the Target Market or the Category.	Primary
REQ-131	The distribution of subscriptions is either a scheduled event or is triggered by another event.	Primary
REQ-132	The events that can trigger the distribution of a subscription are: - new/updated registration: check existing subscriptions, if new data pools are found : distribute subscriptions - new subscription: check existing registrations, if new data pools are found: distribute subscriptions - delete subscriptions: distribute “delete” to source data pools where subscription had been sent	Primary
REQ-133	Subscriptions cannot be updated, they are created or deleted.	Primary
REQ-134	Subscriptions must be stored in the recipient’s data pool.	Primary
REQ-135	For every subscription, the Registry must store the GLN of the Source Data Pool to which the subscription was sent and when it was sent.	Primary
REQ-136	Ability to identify new or updated registered Catalogue Items that match a subscription and forward the subscription to the Source Data Pool.	Primary
REQ-137	Match new subscriptions with registered Catalogue Items and forward the subscription to the Source Data Pool.	Primary
REQ-139	SubscriptionWho : Data Recipient = target GLNWhat : Any combination of GTIN, GLN, TM and Category	Primary
REQ-141	Deletion of a Subscription stops New Catalogue Items from being sent to RDP, but, doesn't stop Catalogue Items already in the Synchronisation List from being updated.	Primary
REQ-142	Request for Notification is not retained in the Global Registry and acts like a Subscription that is applied to the Synchronisation List, then deleted (no New Catalogue Item data will be sent).	Primary
REQ-143	"Reload" flag is passed through to Recipient.	Primary
REQ-144	Request for publication (subscription) resets the reject flag if catalogue Item has been previously rejected and reactivate the subscription.	Primary
REQ-145	The request for publication subscription is only executed once.	Primary
REQ-146	Subscriptions are passed from global Registry to data pools just once. The Global Registry passes along to the source data pool matching subscriptions in the entirety, rather than replicating for each GTIN registered.	Primary
REQ-147	Request for notification publication (subscription) resets the reject flag if the Catalogue Item has been previously rejected and reactivates the subscription.	Primary
REQ-148	The "Reload" attribute will contain a Boolean value (TRUE or FALSE).	Primary
REQ-149	Upon execution of an item data notification, the source data pool will pass along the value of this attribute within the message for the recipient to properly route the inbound message. After executing the item data notification, the source data pool will	Primary
REQ-150	The team identified the need for an additional process to be known as “Request for Notification”. The Request for Notification is originated by the requesting data recipient, through the recipient data pool, to the Global Registry and forwarded to the so	Primary
REQ-151	The team wanted to reiterate the fact that new subscriptions received by a source data pool would be executed immediately a single time.	Primary
REQ-152	The ability to set up a subscription and not get an initial full load of data. She wants to only receive the changes, adds, deletes and new items that match her subscription. (This is the same as a regular subscription with the exception of not getting	Primary
REQ-154	The Global Registry shall send only once a subscription to a Source Data Pool.	Primary
REQ-156	Subscription matches are performed at any level of the hierarchy. The data recipient is sent all hierarchies that match.	Primary
REQ-157	Confirmations will be done at the highest level of the published trade item hierarchy.	Primary
REQ-158	Top of hierarchy is assumed to be the largest available unit determined by the data source. Defined as the GTIN of the highest published item in the hierarchy.	Primary
REQ-160	Catalogue Item Confirmations (CIC) for the item at the top level of the hierarchy with a status of reject will stop publications of the whole hierarchy.	Primary
REQ-161	A CIC with a status of Rejected, Accepted, Review or Synchronised sent for an item below the highest level of the published item hierarchy will result in a CIC failure.	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 172	When the status of the “Catalogue Confirmation State List” is set to either “Review” or “Rejected”, there may be additional information in the CIC message such as theconfirmation code, description, and the comment and understands what action they need to take to resolve the current situation.	Primary
Req 173	This Confirmation Code and Description are joined as a pair	Primary
Req 174	The CIC message can include multiple Catalogue Item References (GTIN + GLN + Target Market) to establish the relationship between the information communicated and the actual Catalogue Item being referenced	Primary

Figure 54 - Distribute Confirmation Data Activity Diagram

Figure 55 - Distribute Catalogue Item Confirmation Sequence Diagram

TOP

20. Distribute Request for Catalogue Item Notification

Figure 56 - Distribute Request for Catalogue Item Notification Use Case Diagram

Use Case Name	Distribute Request for Catalogue Item Notification
Traceability Identifier	UC-22
Use Case Description	The Distribute Request for Catalogue Item Notification Use Case describes how the message is passed from Data Recipient through to the Source Data Pool and Data Source. This Use Case makes use of the RequestForCatalogueItemNotification message.This message is identical to the CatalogueItemSubscription with the addition of a “reload” flag.This reload flag is later attached to the resultant CatalogueItemNotification message to allow the Data Recipient to process it differently than a normal notification.The RequestForCatalogueItemNotification message is also different from a Subscription in that it is not retained in the Global Registry after the Source Data Pools have received it.
Use Cases Above	UC-47: Distribute Data Recipient Requests for Catalogue Item Data
Use Cases Below	None
Actors	Data RecipientRecipient Data Pool (RDP)Global RegistrySource Data Pool (SDP)Data Source
Performance Goals	Data Recipient: To request that previously sent Catalogue Item data be resent. RDP: To posses the necessary information that will allow the RDP and appropriate Source Data Pools to distribute Catalogue Item Data to the Recipient. Global Registry: To forward to appropriate Source Data Pools all requests from Data Recipients. SDP: To posses the necessary information that will allow the SDP to distribute Catalogue Item Data to the Recipient (via their RDP). Data Source: To be aware of all usages of supplied data.
Preconditions	The Data recipient has created a Subscription in their Recipient Data Pool and has received Catalogue Item data.
Postconditions	The request is passed to the Global Registry, appropriate Source Data pools and the Data Source.
Scenario	Begins when, the Data Recipient sends a Request message to the Recipient Data Pool 1.The RDP sends the Request to the Global Registry.2.The Global Registry matches the Request with a list of Source Data Pools.3.The Global Registry sends the request to the appropriate Source Data Pool.4.The Source Data Pool sends a copy of the request to the Data Source.
Alternative Scenario
Special Requirements
Extension Points	N/A
Requirements Covered

Figure 57 - Distribute Request for Catalogue Item Notification Activity Diagram

Figure 58 - Distribute Request for Catalogue Item Notification Sequence Diagram

TOP

21. Create Synchronisation List

Figure 59 - Create Synchronisation List Use Case Diagram

Use Case Name	Create Synchronisation List
Traceability Identifier	UC-45
Use Case Description	The Synchronisation list is the sole means by which a Source Data Pool determines the Catalogue Item Data that is to be sent to a Data Recipient (via the Recipient’s Recipient Data Pool). The Synchronisation list is created based on Publications, Subscriptions and Confirmations.Each one of these pares down the matches between Catalogue Item and Recipient.The delta, or net positive matches are placed into the Synchronisation List, which is used by the “Distribute Catalogue Item Data from SDP to RDP” (UC-37) and “Distribute Catalogue Item Data from RDP to Data Recipient” (UC-38) Use Cases. UC-37 will use the Synchronisation List to send Recipient bound Catalogue Item Data to the Recipient Data Pool.UC-38 will then pass all appropriate Catalogue Item data to the Recipient.
Use Cases Above	UC-23:Manage Catalogue Item Distribution Criteria
Use Cases Below	None
Actors	Source Data Pool (SDP)
Performance Goals	SDP: To determine which Recipient should be sent what Catalogue Item Hierarchy data.
Preconditions	Publications, Subscriptions and Confirmations exist in the Source Data Pool.
Postconditions	The Synchronisation List is created and able to be used to direct the Source Data Pool in moving appropriate Catalogue Item data to Recipient Data Pools.
Scenario	Begins when, the Source Data Pool receives an add or delete of a Publication, an Add of a Subscription, Confirmation ,or a Add, Change, Correct of an Catalogue Item Hierarchy message. 1.The SDP Identifies all GTIN's of publications to a target market2.The SDP Identifies all GTIN's of Subscriptions by Recipient's Target Market3.Subset all GTIN's that are in both lists4.Remove GTINs that have been rejected by the Recipient5.Add Source GLN, RDP GLN, Recipient GLN, Source GTIN and Source TM to the Synchronisation List Ends when, Synchronisation Listed is complete.
Alternative Scenario	None
Special Requirements
Extension Points	N/A
Requirements Covered

Figure 60 - Create Synchronisation List Activity Diagram

TOP

22. Distribute Catalogue Item Data from SDP to RDP

Figure 61 - Distribute Catalogue Item Data from SDP to RDP Use Case Diagram

Use Case Name

Distribute Catalogue Item Data from SDP to RDP

Traceability Identifier

UC-37

Use Case Description

Using the Distribution Criteria, the Catalogue Item Data are distributed from SDP to RDP.

Use Cases Above

UC-29:Distribute Catalogue Item Data

Use Cases Below

UC-xx:Filter Catalogue Item Data at SDPUC-xx:Send Catalogue Item Data to RDPUC-xx:Filter Catalogue Item Data at RDP

Actors

Source Data Pool (SDP)Recipient Data Pool (RDP)

Performance Goals

SDP: Distribute Catalogue Item Data to the RDP based on the Distribution Criteria.
RDP: To receive Catalogue Item Data that complies with the Distribution Criteria.

Preconditions

Publications are available at the SDP.Subscriptions are communicated to the SDP. The SDP has the updated Synchronisation list based on the subscriptions and Confirmations received.The SDP knows which RDP needs to receive Catalogue Item Data for each Recipient.

Postconditions

RDP has received Catalogue Item Data that comply with the Distribution Criteria.

Scenario

Begins when, the SDP filters the Catalogue Item Data using the Synchronisation list.

The SDP sends filtered Catalogue Item Data to the RDP.
The RDP receives the Catalogue Item Data.

Ends when, the RDP uses the Subscription and Confirmations of the recipient to filter the Catalogue Item Data to identify any Catalogue Items that should not have been sent.

Alternative Scenario

None at this summary level

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.	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-25	The Data Distribution, which is the movement of data from one entity to another, must be handled through a specific notification type.	Secondary
REQ-26	Notification to the data recipient will always include the entire hierarchy. (applies to add & update by adding a higher level)	Secondary
REQ-27	In case of an ItemLink correction, the entire hierarchy will be indicated as corrected in the notification.	Primary
REQ-28	The updated hierarchy always fully replaces the current hierarchy. This action is called "Full Refresh".	Primary
REQ-32	Acknowledgement Reason codes must be unique.	Primary
REQ-58	Deletes are not synchronised across data pools.	Primary
REQ-81	Synchronisation List is only synchronised between the involved source and recipient data pools for applicable data: synchronisation list is built based on confirmation received by a source data pool and nothing else.	Secondary
REQ-88	The matching process is owned and developed by each source data pool in order to trigger data distribution based on publication and subscription data.	Primary
REQ-89	The matching process can be triggered either by publication, subscription or as a scheduled event. It is valid for all subscription types (including synchronisation list) and all publication types.	Primary
REQ-93	Although the notification process will physically move the data from one data pool to another, this data should not be stored permanently for the purpose of synchronisation with any other user than the initial subscriber. If stored, access should be limited to the initial data recipient.	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-125	The Source Data Pool is responsible to reset the "Reload" flag once it sends all requested data.	Secondary
REQ-126	If a new Reload is needed, the Recipient must delete the previous Reload Subscription, then create a new Subscription with the "Reload" flag set.	Secondary
REQ-143	"Reload" flag is passed through to Recipient.	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-166	A Request for Catalogue Item Notification with the isReload set to false will result in items being re-sent whether they were previously rejected or not. The Sync List will be reset. This is only valid for items that have previously been sent to the data recipient. The CIN response will have the following values: documentStatus= Original isReload = False Command= Add	Primary
REQ-167	A Request for Catalogue Item Notifcation with the isReload set to true will result in only items not previously rejected being re-sent. The Sync List is not reset. The CIN response will have the following values: documentStatus= Copy isReload = True Command= Add	Primary
REQ-168	The Document Status of the RFCIN command is ignored for the purposes of determining its impact on the sync list and the status of the CIN that is generated.	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

Figure 62 - Distribute Catalogue Item Data from SDP to RDP Activity Diagram

Figure 63 - Distribute Catalogue Item Data from SDP to RDP Sequence Diagram

TOP

23. Distribute Catalogue Item Data from RDP to Recipient

Figure 64 - Distribute Catalogue Item Data from RDP to Recipient Use Case Diagram

Use Case Name

Distribute Catalogue Item Data from RDP to Recipient

Traceability Identifier

UC-38

Use Case Description

Catalogue Item Data are distributed from RDP to the Data Recipient.

Use Cases Above

UC-29:Distribute Catalogue Item Data

Use Cases Below

UC-xx:Send Catalogue Item Data to Recipient

Actors

Recipient Data Pool (RDP)Data Recipient

Performance Goals

RDP: Distribute Catalogue Item Data to the Recipient based on the Subscriptions and Confirmations.Data Recipient: To receive Catalogue Item Data that complies with their Subscriptions and Confirmations.

Preconditions

Publications, Subscriptions and Confirmations have been defined.The Catalogue Item Data are filtered by the RDP (see UC-37).

Postconditions

Data Recipient has received Catalogue Item Data that comply with their Subscriptions and Confirmations.

Scenario

Begins when, the RDP sends the filtered Catalogue Item Data to the Data recipient.
Ends when, the Data Recipient receives the Catalogue Item Data from its RDP.

Alternative Scenario

None at this summary level

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-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-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-28	The updated hierarchy always fully replaces the current hierarchy. This action is called "Full Refresh".	Primary
REQ-32	Acknowledgement Reason codes must be unique.	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.	Secondary
REQ-143	"Reload" flag is passed through to Recipient.	Secondary
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

Figure 65 - Distribute Catalogue Item Data from RDP to Recipient Activity Diagram

Figure 66 - Distribute Catalogue Item Data from RDP to Recipient Sequence Diagram

24. Distribute Confirmation Data for a previously rejected Catalogue Item Notification

Figure 72 - Distribute Catalogue Item Data from RDP to Recipient Use Case Diagram

Use Case ID

UC-49

Use Case Name

Distribute Confirmation Data for a previously rejected Catalogue Item Notification

Use Case Description

A Data Recipient sends a CIC with a status of ACCEPTED, REVIEW, SYNCHRONISED after previously sending a CIC REJECTED.

Use Case Above

UC-47: Distribute Data Recipient Requests for Catalogue Item Data

Use Case Below

None

Actors (Goal)

Data Source: The Supplier (Data Source) communicates the trade item information as necessary – initial published information or a change to the trade item information.

GS1 Global Registry (GR): The GS1 GR registers the trade item.

Data Recipient: The Retailer (Data Recipient) is the trading partner who receives the communication about the trade item and responds to it.

Recipient Data Pool (RDP): The Data Pool that receives the communication of the trade item from the Source Data Pool and delivers it to the Data Recipient and handles the response.

Source Data Pool (SDP): The Data Pool that communicates the trade item information from the Data Source to the Recipient Data Pool and handles the response.

Performance Goals

Preconditions

The participants are registered in the GDSN GS1 Global Registry. The Data Recipient has previously received a CIN for the catalogue item and sent a CIC REJECTED for the item.

Post conditions

Synchronization is allowed on the GTIN/GLN/TM. The RDP, SDP, and DS are aware of the Data Recipient’s intentions regarding a specific Catalogue Item. Updates to the item will be sent to the Data Recipient.

Scenario

Begins when. The Retailer (DR) decides to begin synchronization on a product and sends the CIC (State other than REJECTED) to the Supplier through the RDP.

Continues with...

Step #	Actor	Activity Step
1	DR	Sends the CIC (State other than REJECTED) to the RDP.
2	RDP	Receives the CIC (State other than REJECTED).
3	RDP	Sends the CIC (State other than REJECTED) to the SDP.
4	SDP	Receives the CIC (State other than REJECTED).
5	SDP	Sends the CIC (State other than REJECTED) to the DS.
6	SDP	Updates the synch list for that GTIN/GLN/TM, allowing synchronization on the Trade Item
7	SDP	May query DS to confirm that they have the most current Trade Item information.
8	SDP	Sends the most current Trade Item Information to RDP.
9	RDP	Receives the most current Trade Item Information.