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