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

|
|
|
|
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 |
| ID |
Requirement |
Weight |
| REQ-12 |
Every
command needs a response and is handled according to the agreement
between the parties involved. In the inter-operable network,
acknowledgement messages are standardised and may contain the following
information: - Confirmation of message receipt- Success / Failure of
processing (syntax and content)- Reason for failure, with a code number
and text message unique assigned to each failure |
Primary |
| REQ-20 |
Synchronisation Lists must include every Catalogue Item (GTIN+GLN+TM) that needs to be synchronised. |
Primary |
| REQ-21 |
If
an Catalogue Item is "Confirmed of Synchronisation" then all Catalogue
items below in the Catalogue Item Hierarchy shall be included in the
Synchronisation list. |
Primary |
| REQ-22 |
Relationship dependent data will only be communicated for Synchronised, Review or Accept status in the Synchronisation List. |
Primary |
| REQ-23 |
Events
that can trigger notifications are: - Publication of new data / change
of publication - Change of published Catalogue Item / Party / Partner
Profile - Change of owner, rights - Subscription - Synchronisation List
- Confirmation/ Rejection - Request for Notification - Any successful
matching process |
Primary |
| REQ-24 |
Notifications
must NOT be sent in the following cases since data is not yet public
and validated information: - Data load (add, change, etc…) -
Data validation - Registration of new Catalogue Item |
Primary |
| REQ-26 |
Notification
to the data recipient will always include the entire hierarchy.
(Applies to add & update by adding a higher level) |
Primary |
| REQ-30 |
Only Catalogue Items are registered in the Global Registry. Not Catalogue Item Hierarchies. |
Primary |
| REQ-31 |
Validation acknowledgements are mandatory. |
Primary |
| REQ-32 |
Acknowledgement Reason codes must be unique. |
Primary |
| REQ-34 |
ItemLinks are not registered or held within the Global Registry. |
Primary |
| REQ-36 |
If the Catalogue Item was registered, updates impacting the Registry data must be reflected in the Global Registry. |
Primary |
| REQ-37 |
Registration
of Catalogue Item changes only needs to happen for changes that: -
Impact fields stored in the Global Registry. - Are authorised according
to the GTIN allocation rules. |
Primary |
| REQ-45 |
Data source is sending full Hierarchies to the Source Data Pool. |
Primary |
| REQ-62 |
Cancel Catalogue Item is achieved through the maintenance (using change function) of the cancel date. |
Secondary |
| REQ-63 |
Need cancel date in Catalogue Item data model. |
Secondary |
| REQ-64 |
Cancel date needs to be stored in the Global Registry. |
Secondary |
| REQ-65 |
Communicate that product is no longer available: maintain end availability date. |
Secondary |
| REQ-66 |
When product is available again: update start/end availability date. |
Secondary |
| REQ-92 |
“Single
Data Source” Principle: - there can only be one official source
of the data – the one that is registered - this source is
identified by the data source - this is the only valid source for data
synchronisation and related processes |
Primary |
| REQ-99 |
The
Global Registry functionality requirements can be summarised as
follows: - Enable data synchronisation - Validation, registration and
subscription functions - Enable global validation - Checking compliance
with basic EAN.UCC rules related to the format of a GTIN/GLN and
ensuring the uniqueness of the data that is being registered - Enable
global search functionality that does not require full duplication of
data in the Global Registry. |
Primary |
| REQ-100 |
The
Global Registry is involved in the following functions and/or business
cases as defined in the Item Synchronisation detailed requirements: -
Validation - Registration - Subscription - Global Search |
Primary |
| REQ-101 |
Registry
Validation includes: - EAN.UCC standards validation for GTIN and GLN
formats (i.e. check digit) - Uniqueness validation for Item
(GTIN/GLN/TM), Party (GLN) or data pool (GLN), ensuring there is only
one occurrence and data source for each data record as identified by
the appropriate fields. |
Primary |
| REQ-102 |
Registry validation is a part of the registration process. |
Primary |
| REQ-104 |
In
summary, the registry requirements for validation are: - EAN.UCC
standards validation for GTIN/GLN formats - Uniqueness validation for
Item, Party and data pool key - Store and maintain EAN.UCC standards -
Process validation command - Provide validation acknowledgement |
Primary |
| REQ-105 |
Registration
is the process, which references all Catalogue Items and Parties
published in all certified data pools and on which there is a need to
synchronise / retrieve information. This is supported by data storage
in accordance with the Registry data scope and rules. |
Primary |
| REQ-106 |
Registering
a Catalogue Item involves a check by the Global Registry for Item
uniqueness. The Item is identified by the following elements: GTIN,
GLN, Target Market. Each combination of this key data found in the
Global Registry must be unique. When an Item is registered, the
registry verifies that the combination of this data is unique to that
Item. |
Primary |
| REQ-107 |
The
registration process is triggered by the following business cases: 1.
Create Catalogue Item: After the physical load and validation of the
data, the registry record needs to be created before data can be
published. 2. Update Catalogue Item: When a registered Catalogue Item
is updated in its source data pool, updates impacting the Registry data
must be reflected in the Global Registry, before the updated data can
be propagated to the recipients. Registration of Catalogue Item changes
only needs to happen for changes that: Impacts fields stored in the
Global Registry. Are authorised according to the GTIN allocation rules.
3. Correct Catalogue Item: When a registered item is corrected in its
source data pool, corrections impacting the Registry data must be
reflected in the Global Registry before the updated data can be
propagated to the data recipients. 4. Delete Catalogue Item: Deletions
need to be reflected in the Global Registry: the discontinuation dates
starts the EAN.UCC standard retention period (48 months for CPG, 36
months for apparel) as soon as GTIN has been discontinued in ALL target
markets where it was active (needs to be stored in the Global
Registry). 5. Cancel Catalogue Item: Communicates a trade item was
never manufactured – this allows an earlier “reuse”
of the GTIN i.o. standard retention period. This is achieved through
the maintenance (using change function) of the cancel date. 6. Removing
an Catalogue Item from the supply chain: The permanent removal of a
Catalogue Item from the supply chain is achieved through the
maintenance of a discontinuation date. This date has to be reflected in
the Global Registry to kick off the EAN.UCC retention period. Temporary
removals are not reflected in the Global Registry and only handled
through the maintenance of the availability period in the data pools. |
Primary |
| REQ-108 |
Registry
requirements for registration are: - Registration can only happen after
successful validation. - Registration can only produce errors, no
warnings. - Successful Registration of a Catalogue Item is mandatory
prior to publication of any hierarchy containing that Catalogue Item. -
ItemStatus needs to be included in GTIN data model to reflect
validation and registration status. - Process registration command (for
create, update, correct, delete). - Provide registration
acknowledgement. |
Primary |
| REQ-118 |
Changes/corrections applied to the Global Registry are effective immediately. |
Primary |
| REQ-119 |
Future effective changes stored in the data pool are only reflected in the Global Registry when they become effective. |
Primary |
| REQ-159 |
Multiple
independent hierarchies can co-exist at the data-pool for an item for
example hierarchy 1 = case A – each A and hierarchy 2 = pallet A
– case A –each A. |
Primary |
| REQ-171 |
The
message identifier (CorrelationInformation:
requestingDocu-mentInstanceIdentifier) at the document header levelfor
the EAN.UCC response and the GDSN Exception must equal
theDocumentIdentification: instanceIdentifier of the originalmessage. |
Primary |
| REQ 185 |
The
deletion date is updated by the GS1 GR, adding either the cancellation
or discontinue timeframe to the cancel or discontinue dates
respectively. |
Primary |
| REQ 186 |
At the end of the time period, which differs per industry, the deletion date becomes current and the item is actually deleted |
Primary |
| REQ 187 |
The GS1 GR must receive the GPC code information in order7to calculate the deletion date properly |
Primary |
| REQ 188 |
The GS1 GR will maintain a cross-reference table for the GPC brick level codes and a corresponding GTIN Reuse Time |
Primary |
| REQ 189 |
The GS1 GR will maintain an additional field to establish the GTIN reuse timeframe based on each industry’s guidelines |
Primary |
| REQ 190 |
When
an item is discontinued in the GDSN, the waiting period for the GTIN
before it can be reused for an item has to be aligned with the specific
industry requirement:
- clothing, footwear and personal accessories apply a 30 month rule to the discontinue date
- Fast Moving Consumer Goods GTINs can be reused after a 48 month period to the discontinue date and
-12 month rule applies to the cancel date.
Note: Clothing, footwear and personal accessories are defined as being
all GPC bricks contained within the following GPC Segments:
| 63000000 |
Footwear |
| 67000000 |
Clothing |
| 64000000 |
Personal Accessories |
It is assumed for this BSD that all other established GPC Segments and
their associated Bricks will follow the 48 month period to the
discontinue date until the specific industry rule and associated GPCs
are established. |
Primary |
| REQ 191 |
When an item has a discontinue date, the state of the item does not get updated until that date becomes current. |
Primary |
| REQ 192 |
The Global Registry must support a Registry CatalogueItem State of “DELETED”. |
Primary |
|
|
|
|
|
|
|
|
|
7. Register Catalogue Item |
|
|
|
 |
|
|
|
|
|
|
|
| Use Case Name |
Register Catalogue Item |
| Traceability Identifier |
UC-18 |
| Use Case Description |
All Catalogue Items for trade must be registered in the Global Registry.Prior
to registration, the Catalogue Item data must pass a validation at the
Source Data Pool and a uniqueness check at the Registry.The Global Registry ensures that valid, unique Catalogue Item data are available worldwide.
This Use Case describes the Registration process that is performed by the Global Registry. |
| Use Cases Above |
UC-2: Load and Update Catalogue Item Data within a Source Data Pool |
| Use Cases Below |
None |
| Actors |
Source Data Pool (SDP)Global Registry |
| Performance Goals |
SDP: To have validated, registered Catalogue Item data.
Global Registry: To ensure valid, unique Catalogue Item data are registered. |
| Preconditions |
The Source Data Pool is a certified Data Pool.The Source Data Pool has a profile that resides in the registry.The
Source Data Pool has validated Catalogue Item data received from a Data
Source and has sent that Catalogue Item data and a Validation
Certificate to the Global Registry. |
| Postconditions |
The Catalogue Item data has been registered and retained by the Global Registry. |
| Scenario |
Begins when, the Global Registry receives validated Catalogue Item Data from a Source Data Pool.
1.The Global Registry ensures that the Source Data Pool is certified.2.The Global Registry validates the Validation Certificate (from validation engine) sent with the Catalogue Item data.3.The Global Registry verifies the uniqueness of the GTIN, GLN, TM combination.4.The Global Registry stores the Catalogue Item data.
Ends when, The Global Registry sends a registration acknowledgement to the SDP
|
| Alternative Scenario |
ad 1.Data Pool not certified:
1.1.The Global Registry sends an error message to the Source Data PoolEnds when, the Source Data Pool receives the error message
ad 2.Validation certificate does not pass validation:2.1.The Global
Registry sends a validation error message to the Source Data PoolEnds when, the Source Data Pool receives the validation error message
ad 3.The Catalogue Item already exists in the Registry:
3.1.Global Registry sends a registration error message to the
SDP3.2.The SDP receives the registration error message3.3.The SDP sends
a registration error message to the Data SourceEnds when, the Data Source receives the registration error message |
| Special Requirements |
- Validation: applying GDDstandard and GTIN allocation rules.
|
| Extension Points |
N/A |
| Requirements Covered |
| ID |
Requirement |
Weight |
| REQ-1 |
Party data must exist prior to a Catalogue Item is being registered. |
Secondary |
| REQ-2 |
Catalogue Item data must be validated prior to registration. |
Secondary |
| REQ-8 |
EAN.UCC standards validation for GTIN and GLN format. |
Primary |
| REQ-9 |
Uniqueness
validation for Item (GTIN/GLN/TM), Party (GLN) or data pool (GLN)
– only applies to the occurrence of the key, not to the
uniqueness of the information related to it. |
Primary |
| REQ-10 |
The
Catalogue Item is identified by the following elements: GTIN, GLN,
Target Market. Each combination of this key data found in the Global
Registry must be unique. |
Secondary |
| REQ-12 |
Every
command needs a response and is handled according to the agreement
between the parties involved. In the inter-operable network,
acknowledgement messages are standardised and may contain the following
information: - Confirmation of message receipt- Success / Failure of
processing (syntax and content)- Reason for failure, with a code number
and text message unique assigned to each failure |
Primary |
| REQ-20 |
Synchronisation Lists must include every Catalogue Item (GTIN+GLN+TM) that needs to be synchronised. |
Primary |
| REQ-23 |
Events
that can trigger notifications are: - Publication of new data / change
of publication - Change of published Catalogue Item / Party / Partner
Profile - Change of owner, rights - Subscription - Synchronisation List
- Confirmation/ Rejection - Request for Notification - Any successful
matching process |
Primary |
| REQ-24 |
Notifications
must NOT be sent in the following cases since data is not yet public
and validated information: - Data load (add, change, etc…) -
Data validation - Registration of new Catalogue Item |
Secondary |
| REQ-30 |
Only Catalogue Items are registered in the Global Registry. Not Catalogue Item Hierarchies. |
Secondary |
| REQ-31 |
Validation acknowledgements are mandatory. |
Secondary |
| REQ-32 |
Acknowledgement Reason codes must be unique. |
Primary |
| REQ-34 |
ItemLinks are not registered or held within the Global Registry. |
Secondary |
| REQ-36 |
If the Catalogue Item was registered, updates impacting the Registry data must be reflected in the Global Registry. |
Primary |
| REQ-37 |
Registration
of Catalogue Item changes only needs to happen for changes that: -
Impact fields stored in the Global Registry. - Are authorised according
to the GTIN allocation rules. |
Primary |
| REQ-42 |
If
the correction impacts the hierarchy, then it must be handled by
deleting the incorrect ItemLink and adding a new Item Link - Add/Delete
Scenario’s. |
Primary |
| REQ-92 |
“Single
Data Source” Principle: - there can only be one official source
of the data – the one that is registered - this source is
identified by the data source - this is the only valid source for data
synchronisation and related processes |
Primary |
| REQ-99 |
The
Global Registry functionality requirements can be summarised as
follows: - Enable data synchronisation - Validation, registration and
subscription functions - Enable global validation - Checking compliance
with basic EAN.UCC rules related to the format of a GTIN/GLN and
ensuring the uniqueness of the data that is being registered - Enable
global search functionality that does not require full duplication of
data in the Global Registry. |
Primary |
| REQ-100 |
The
Global Registry is involved in the following functions and/or business
cases as defined in the Item Synchronisation detailed requirements: -
Validation - Registration - Subscription - Global Search |
Primary |
| REQ-101 |
Registry
Validation includes: - EAN.UCC standards validation for GTIN and GLN
formats (i.e. check digit) - Uniqueness validation for Item
(GTIN/GLN/TM), Party (GLN) or data pool (GLN), ensuring there is only
one occurrence and data source for each data record as identified by
the appropriate fields. |
Primary |
| REQ-102 |
Registry validation is a part of the registration process. |
Secondary |
| REQ-104 |
In
summary, the registry requirements for validation are: - EAN.UCC
standards validation for GTIN/GLN formats - Uniqueness validation for
Item, Party and data pool key - Store and maintain EAN.UCC standards -
Process validation command - Provide validation acknowledgement |
Secondary |
| REQ-105 |
Registration
is the process, which references all Catalogue Items and Parties
published in all certified data pools and on which there is a need to
synchronise / retrieve information. This is supported by data storage
in accordance with the Registry data scope and rules. |
Secondary |
| REQ-106 |
Registering
a Catalogue Item involves a check by the Global Registry for Item
uniqueness. The Item is identified by the following elements: GTIN,
GLN, Target Market. Each combination of this key data found in the
Global Registry must be unique. When an Item is registered, the
registry verifies that the combination of this data is unique to that
Item. |
Secondary |
| REQ-107 |
The
registration process is triggered by the following business cases: 1.
Create Catalogue Item: After the physical load and validation of the
data, the registry record needs to be created before data can be
published. 2. Update Catalogue Item: When a registered Catalogue Item
is updated in its source data pool, updates impacting the Registry data
must be reflected in the Global Registry, before the updated data can
be propagated to the recipients. Registration of Catalogue Item changes
only needs to happen for changes that: Impacts fields stored in the
Global Registry. Are authorised according to the GTIN allocation rules.
3. Correct Catalogue Item: When a registered item is corrected in its
source data pool, corrections impacting the Registry data must be
reflected in the Global Registry before the updated data can be
propagated to the data recipients. 4. Delete Catalogue Item: Deletions
need to be reflected in the Global Registry: the discontinuation dates
starts the EAN.UCC standard retention period (48 months for CPG, 36
months for apparel) as soon as GTIN has been discontinued in ALL target
markets where it was active (needs to be stored in the Global
Registry). 5. Cancel Catalogue Item: Communicates a trade item was
never manufactured – this allows an earlier “reuse”
of the GTIN i.o. standard retention period. This is achieved through
the maintenance (using change function) of the cancel date. 6. Removing
a Catalogue Item from the supply chain: The permanent removal of a
Catalogue Item from the supply chain is achieved through the
maintenance of a discontinuation date. This date has to be reflected in
the Global Registry to kick off the EAN.UCC retention period. Temporary
removals are not reflected in the Global Registry and only handled
through the maintenance of the availability period in the data pools. |
Secondary |
| REQ-108 |
Registry
requirements for registration are: - Registration can only happen after
successful validation. - Registration can only produce errors, no
warnings. - Successful Registration of a Catalogue Item is mandatory
prior to publication of any hierarchy containing that Catalogue Item. -
ItemStatus needs to be included in GTIN data model to reflect
validation and registration status. - Process registration command (for
create, update, correct, delete). - Provide registration
acknowledgement. |
Secondary |
| REQ-117 |
Catalogue
Item: - GTIN - GLN of Data Source - Unique Item Identification - Target
Market - Country Code [3166-1] - Sub-division code [3166-2] - EAN.UCC
Classification [brick level] - Address of the source data pool (GLN
used to look up url in data pool profile) - Registration Date -
Deletion Date (default: 31.12.9999) - Cancel Date (default: 31.12.9999)
- Discontinued Date (default: 31.12.9999) - Date and Time of last
change (system date for every action on the Catalogue Item) - Item
Validation Information (including validation engine Version, validation
date Date & Certificate ID) – certificate ID only has to be
maintained at item creation time, periodic maintenance does not affect
the Global Registry but is ensured in the data notification (notified
certificate needs to be equal or higher than registry certificate) |
Secondary |
| REQ-121 |
Party:
- GLN - Start Availability Date of the Party - Deletion Date of the
Party - Registration Date - Source Data Pool Pointer [GLN used to
….] - GLN of Data Source (*Data Source is actually the
‘owner’ of the GLN data - Date and Time of last change -
Party Validation Information (including Version, Date & Certificate
ID) |
Secondary |
| REQ-171 |
The
message identifier (CorrelationInformation:
requestingDocu-mentInstanceIdentifier) at the document header levelfor
the EAN.UCC response and the GDSN Exception must equal
theDocumentIdentification: instanceIdentifier of the originalmessage. |
Primary |
|
|
|
|
|
 |
|
|
|
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 |
All Catalogue Items for trade must be registered in the Global Registry.Prior
to registration, the Catalogue Item data must pass a validation at the
Source Data Pool and a uniqueness check at the Registry.The Global Registry ensures that valid, unique Catalogue Item data are available worldwide.
In
the event that Catalogue Item data changes (see Change Catalogue Item
Hierarchy Use Case) in a Source Data Pool, the changes must be
reflected in the Global Registry. |
| Use Cases Above |
UC-10:Change Catalogue Item |
| Use Cases Below |
None |
| Actors |
Source Data Pool (SDP)Global Registry |
| Performance Goals |
SDP: To have validated, registered Catalogue Item data.
Global Registry: To ensure valid, unique Catalogue Item data are registered. |
| Preconditions |
The Source Data Pool is a certified Data Pool..The Source Data Pool has a profile that resides in the registry.The Source Data Pool has received a “Change Catalogue Item Hierarchy” message from the Data Source.The
Source Data Pool has validated Catalogue Item data received from a Data
Source and has sent that Catalogue Item data and a Validation
Certificate to the Global Registry. |
| Postconditions |
The Catalogue Item data changes have been applied and retained in the Global Registry. |
| Scenario |
Begins when, the Global Registry receives a validated Change Registered Catalogue Item message from a Source Data Pool.
1.The Global Registry ensures that the Source Data Pool is certified.2.The Global Registry validates the Validation Certificate (from validation engine) sent with the Catalogue Item data.3.The Global Registry ensures that the Catalogue Item data already exists in the Registry.4.The Global Registry stores the Catalogue Item data.
Ends when, The Global Registry sends a registration acknowledgement to the SDP
|
| Alternative Scenario |
ad 1.Data Pool not certified:
1.1.The Global Registry sends an error message to the Source Data PoolEnds when, the Source Data Pool receives the error message
ad 2.Validation certificate does not pass validation:2.1.The Global Registry sends a validation error message to the Source Data PoolEnds when, the Source Data Pool receives the validation error message
ad 3.The Catalogue Item does not exist in the Registry:
3.1.Global Registry sends a registration error message to the SDP3.2.The SDP receives the registration error message
Ends when, the Source Data Pool receives the registration error message
|
| Special Requirements |
- Validation: applying GDD standard and GTIN allocation rules.
|
| Extension Points |
N/A |
| Requirements Covered |
| ID |
Requirement |
Weight |
| REQ-4 |
Data Source must be able to change Catalogue Item data in the Source Data Pool. |
Secondary |
| REQ-8 |
EAN.UCC standards validation for GTIN and GLN format. |
Primary |
| REQ-9 |
Uniqueness
validation for Item (GTIN/GLN/TM), Party (GLN) or data pool (GLN)
– only applies to the occurrence of the key, not to the
uniqueness of the information related to it. |
Primary |
| REQ-10 |
The
Catalogue Item is identified by the following elements: GTIN, GLN,
Target Market. Each combination of this key data found in the Global
Registry must be unique. |
Primary |
| REQ-12 |
Every
command needs a response and is handled according to the agreement
between the parties involved. In the inter-operable network,
acknowledgement messages are standardised and may contain the following
information: - Confirmation of message receipt- Success / Failure of
processing (syntax and content)- Reason for failure, with a code number
and text message unique assigned to each failure |
Primary |
| REQ-20 |
Synchronisation Lists must include every Catalogue Item (GTIN+GLN+TM) that needs to be synchronised. |
Primary |
| REQ-23 |
Events
that can trigger notifications are: - Publication of new data / change
of publication - Change of published Catalogue Item / Party / Partner
Profile - Change of owner, rights - Subscription - Synchronisation List
- Confirmation/ Rejection - Request for Notification - Any successful
matching process |
Primary |
| REQ-24 |
Notifications
must NOT be sent in the following cases since data is not yet public
and validated information: - Data load (add, change, etc…) -
Data validation - Registration of new Catalogue Item |
Primary |
| REQ-30 |
Only Catalogue Items are registered in the Global Registry. Not Catalogue Item Hierarchies. |
Primary |
| REQ-31 |
Validation acknowledgements are mandatory. |
Primary |
| REQ-32 |
Acknowledgement Reason codes must be unique. |
Primary |
| REQ-34 |
ItemLinks are not registered or held within the Global Registry. |
Primary |
| REQ-35 |
Changes have to comply with validation rules. |
Secondary |
| REQ-36 |
If the Catalogue Item was registered, updates impacting the Registry data must be reflected in the Global Registry. |
Secondary |
| REQ-37 |
Registration
of Catalogue Item changes only needs to happen for changes that: -
Impact fields stored in the Global Registry. - Are authorised according
to the GTIN allocation rules. |
Secondary |
| REQ-38 |
The
change function implies a full refresh of all attributes of the
previously created Catalogue Item – this will be reflected in the
subsequent notification, including a full refresh of the changed record
of the full hierarchy. |
Primary |
| REQ-62 |
Cancel Catalogue Item is achieved through the maintenance (using change function) of the cancel date. |
Primary |
| REQ-64 |
Cancel date needs to be stored in the Global Registry. |
Primary |
| REQ-92 |
“Single
Data Source” Principle: - there can only be one official source
of the data – the one that is registered - this source is
identified by the data source - this is the only valid source for data
synchronisation and related processes |
Primary |
| REQ-99 |
The
Global Registry functionality requirements can be summarised as
follows: - Enable data synchronisation - Validation, registration and
subscription functions - Enable global validation - Checking compliance
with basic EAN.UCC rules related to the format of a GTIN/GLN and
ensuring the uniqueness of the data that is being registered - Enable
global search functionality that does not require full duplication of
data in the Global Registry. |
Primary |
| REQ-100 |
The
Global Registry is involved in the following functions and/or business
cases as defined in the Item Synchronisation detailed requirements: -
Validation - Registration - Subscription - Global Search |
Primary |
| REQ-101 |
Registry
Validation includes: - EAN.UCC standards validation for GTIN and GLN
formats (i.e. check digit) - Uniqueness validation for Item
(GTIN/GLN/TM), Party (GLN) or data pool (GLN), ensuring there is only
one occurrence and data source for each data record as identified by
the appropriate fields. |
Primary |
| REQ-102 |
Registry validation is a part of the registration process. |
Primary |
| REQ-104 |
In
summary, the registry requirements for validation are: - EAN.UCC
standards validation for GTIN/GLN formats - Uniqueness validation for
Item, Party and data pool key - Store and maintain EAN.UCC standards -
Process validation command - Provide validation acknowledgement |
Primary |
| REQ-105 |
Registration
is the process, which references all Catalogue Items and Parties
published in all certified data pools and on which there is a need to
synchronise / retrieve information. This is supported by data storage
in accordance with the Registry data scope and rules. |
Primary |
| REQ-106 |
Registering
a Catalogue Item involves a check by the Global Registry for Item
uniqueness. The Item is identified by the following elements: GTIN,
GLN, Target Market. Each combination of this key data found in the
Global Registry must be unique. When an Item is registered, the
registry verifies that the combination of this data is unique to that
Item. |
Primary |
| REQ-107 |
The
registration process is triggered by the following business cases: 1.
Create Catalogue Item: After the physical load and validation of the
data, the registry record needs to be created before data can be
published. 2. Update Catalogue Item: When a registered Catalogue Item
is updated in its source data pool, updates impacting the Registry data
must be reflected in the Global Registry, before the updated data can
be propagated to the recipients. Registration of Catalogue Item changes
only needs to happen for changes that: Impacts fields stored in the
Global Registry. Are authorised according to the GTIN allocation rules.
3. Correct Catalogue Item: When a registered item is corrected in its
source data pool, corrections impacting the Registry data must be
reflected in the Global Registry before the updated data can be
propagated to the data recipients. 4. Delete Catalogue Item: Deletions
need to be reflected in the Global Registry: the discontinuation dates
starts the EAN.UCC standard retention period (48 months for CPG, 36
months for apparel) as soon as GTIN has been discontinued in ALL target
markets where it was active (needs to be stored in the Global
Registry). 5. Cancel Catalogue Item: Communicates a trade item was
never manufactured – this allows an earlier “reuse”
of the GTIN i.o. standard retention period. This is achieved through
the maintenance (using change function) of the cancel date. 6. Removing
a Catalogue Item from the supply chain: The permanent removal of a
Catalogue Item from the supply chain is achieved through the
maintenance of a discontinuation date. This date has to be reflected in
the Global Registry to kick off the EAN.UCC retention period. Temporary
removals are not reflected in the Global Registry and only handled
through the maintenance of the availability period in the data pools. |
Primary |
| REQ-108 |
Registry
requirements for registration are: - Registration can only happen after
successful validation. - Registration can only produce errors, no
warnings. - Successful Registration of a Catalogue Item is mandatory
prior to publication of any hierarchy containing that Catalogue Item. -
ItemStatus needs to be included in GTIN data model to reflect
validation and registration status. - Process registration command (for
create, update, correct, delete). - Provide registration
acknowledgement. |
Primary |
| REQ-118 |
Changes/corrections applied to the Global Registry are effective immediately. |
Secondary |
| REQ-119 |
Future effective changes stored in the data pool are only reflected in the Global Registry when they become effective. |
Secondary |
| REQ-171 |
The
message identifier (CorrelationInformation:
requestingDocu-mentInstanceIdentifier) at the document header levelfor
the EAN.UCC response and the GDSN Exception must equal
theDocumentIdentification: instanceIdentifier of the originalmessage. |
Primary |
|
|
|
|
|

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

|
|
|
|
Figure 30 - Correct
Registered Catalogue Item Activity Diagram |
|
|
|
 |
|
|
|
Figure 31
- Correct Registered Catalogue Item Sequence Diagram |
|
|
|
|
|
|
|
TOP |
|
|
|
|
|
|
|
10. Delete
Registered Catalogue Item |
|
|
|
 |
|
|
|
Figure 32
- Delete Registered Catalogue Item Use Case Diagram |
|
|
|
|
|
|
|
| Use Case Name |
Delete Registered Catalogue Item |
| Traceability Identifier |
UC-21 |
| Use Case Description |
This
use case describes the processes that need to take place for Catalogue
Item registered in the Global Registry to be deleted. The process takes
place in the Global Registry based upon either a previously set Cancel
or Discontinue date. |
| Use Cases Above |
UC-46: Manage Catalogue Item Data in Global Registry |
| Use Cases Below |
None |
| Actors |
Global Registry |
| Performance Goals |
Global Registry: To ensure that GTIN allocation rules are followed.The
GS1 GR determines the GTIN reuse period for this industry type of trade
item, calculates the deletion date and updates the
registryCatalogueItemState to DELETED. |
| Preconditions |
The deletion of registered Catalogue Items is a consequence of 2 actions:
- Catalogue Item was discontinued by the DS, and the currentdate = calculated deletion date.
- Catalogue Item was cancelled by theDS because the DS decided to never manufacture an item that they have alreadyregistered.
So
these changes are reflected in the Global Registry data and will
trigger a clean up (internal process) when the retention limit is over. |
| Postconditions |
The Registered Catalogue Item has a state of DELETED in the global registry.The deleted GTIN can be added as a new catalogue item. |
| Scenario |
Scenario: Cancel date exists in the RCIBegins Global Registry Receives the Registry Catalogue Item (RCI) which contains either the cancelDate or discontinueDate from the SDP.Continues with...
| Step # |
Actor |
Activity Step |
| 1 |
GS1 GR |
Determines if there is a discontinue date or a cancel date in the RCI. |
| 2 |
GS1 GR |
If there is a cancel date, GS1 GR updates the registryCatalogueItem state to CANCELLED. |
| 3 |
GS1 GR |
The
GS1 GR starts a “reuse” clock that determines the waiting
period after which the GTIN can be re-registered using the same
catalogue item reference as the previously registered RCI. |
| 4 |
GS1 GR |
At
the point that the calculated deletion date is reached (current date =
item cancellation date), the GS1 GR sets the state to DELETED. After
the waiting period, the DS can re-register the GTIN with another
product using the same key. |
Ends when... The GTIN for the cancelled catalogue item (GTIN+GLN+TM) can be reused. |
| Alternative Scenario |
Scenario: Discontinue date exists in the RCI
Begins Global Registry Receives the Registry Catalogue Item (RCI) which contains either the correct cancelDate or discontinueDate from the SDP.Continues with...
| Step # |
Actor |
Activity Step |
| 1 |
GS1 GR |
Determines if there is a discontinue date or a cancel date in the RCI. |
| 2 |
GS1 GR |
If there is a discontinue date, GS1 GR updates the registryCatalogueItem state to DISCONTINUED. |
| 3 |
GS1 GR |
The
GS1 GR starts a “reuse” clock that determines the waiting
period after which the GTIN can be re-registered using the same
catalogue item reference as the previously registered RCI. |
| 4 |
GS1 GR |
When
the (current date = the calculated deletion date) the GS1 GR sets the
state to DELETED. After the waiting period, the DS can re-register the
GTIN with another product using the same key. |
Ends when... The GTIN for the cancelled catalogue item (GTIN+GLN+TM) can be reused. |
| Special Requirements |
|
| Extension Points |
N/A |
| Requirements Covered |
| ID |
Requirement |
Weight |
| REQ-6 |
Data Source must be able to delete Catalogue Item data in the Source Data Pool. |
Secondary |
| REQ-7 |
If
a Catalogue Item is deleted:- the links pointing down must be deleted-
all links above must be deleted- all Items above must be deleted |
Secondary |
| REQ-12 |
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-42 |
If
the correction impacts the hierarchy, then it must be handled by
deleting the incorrect ItemLink and adding a new Item Link - Add/Delete
Scenario’s. |
Primary |
| REQ-47 |
The
objective of the “Delete” Function is not to physically
remove data from the data pool, but to “Flag for deletion”,
authorising the deletion of the data. |
Secondary |
| REQ-48 |
The
deletion needs to be validated against a number of criteria, e.g. Item
is no longer published, item discontinued, retention limit (EAN/UCC
specifications)... |
Primary |
| REQ-49 |
Rules for archiving or physical deletes will be agreed with the data pools and in the scope of the certification process. |
Primary |
| REQ-50 |
Deletions need to be reflected in the registry (deletion flag + effective change date = deletion date in the Global Registry) |
Secondary |
| REQ-51 |
To protect data integrity within the data pool, the deletion of a child can only occur after the deletion of the parents. |
Secondary |
| REQ-52 |
Validation for deleted Items ensures the parents have been deleted before the deletion of the child is performed. |
Secondary |
| REQ-53 |
Validation is automatically triggered by the “Delete” command and does not require a specific message flow. |
Primary |
| REQ-54 |
Deletion
of a Catalogue Item must trigger the invalidation of any hierarchy
links involving that Item, whether that Item is the parent or the child
in the link. This is completed by the Refresh.ItemLink message.
Ackn.ItemLink will be repeated for every link that was refreshed or
invalidated. |
Secondary |
| REQ-55 |
Deletion
needs to be validated against : - Publication status - Availability
Status (end availability + discontinued Y/N) - Hierarchy : parents have
to be deleted before children |
Primary |
| REQ-57 |
A deletion cannot be corrected – only the discontinuation can be reversed. |
Secondary |
| REQ-58 |
Deletes are not synchronised across data pools. |
Secondary |
| REQ-59 |
ItemLinks can only be deleted: - as the correction of an error - as the result of a delete.Item |
Primary |
| REQ-60 |
The validity period of an ItemLink is defined by the validity period of the Parent Item and/or the Child Item. |
Primary |
| REQ-61 |
When
either parent or child expires, the related ItemLink(s) have to expire
as well. This is achieved through the Refresh.ItemLink function. |
Primary |
| REQ-92 |
“Single
Data Source” Principle : - there can only be one official source
of the data – the one that is registered - this source is
identified by the data source - this is the only valid source for data
synchronisation and related processes |
Primary |
| REQ-99 |
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. |
Primary |
| REQ-119 |
Future effective changes stored in the data pool are only reflected in the Global Registry when they become effective. |
Primary |
| REQ-171 |
The
message identifier (CorrelationInformation:
requestingDocu-mentInstanceIdentifier) at the document header level for
the EAN.UCC response and the GDSN Exception must equal theDocumentIdentification: instanceIdentifier of the originalmessage. |
Primary |
| REQ 185 |
The
deletion date is updated by the GS1 GR, adding either the cancellation
or discontinue timeframe to the cancel or discontinue dates
respectively. |
Primary |
| REQ 186 |
At the end of the time period, which differs per industry, the deletion date becomes current and the item is actually deleted |
Primary |
| REQ 187 |
The GS1 GR must receive the GPC code information in order7to calculate the deletion date properly |
Primary |
| REQ 188 |
The GS1 GR will maintain a cross-reference table for the GPC brick level codes and a corresponding GTIN Reuse Time |
Primary |
| REQ 189 |
The GS1 GR will maintain an additional field to establish the GTIN reuse timeframe based on each industry’s guidelines |
Primary |
| REQ 190 |
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 33 - Delete
Registered Catalogue Item Activity diagram |
|
|
|
|
|
|
|
TOP |
|
|
|
|
|
|
|
11. Manage
Catalogue Item Distribution Criteria |
|
|
|
 |
|
|
|
|
|
|
|
| Use Case Name |
Manage Catalogue Item Distribution Criteria |
| Traceability Identifier |
UC-23 |
| Use Case Description |
The
Manage Catalogue Item Distribution Criteria Use Case describes the
process that takes place to allow Data Sources and Data Recipients to
define the criteria or circumstances under which they will distribute
or receive Catalogue Item data. |
| Use Cases Above |
UC-1:Synchronise Catalogue Item Data |
| Use Cases Below |
UC-24:Publish Catalogue Item Data
UC-26:Confirm Catalogue Item Data
UC-27:Subscribe to Catalogue Item Data
UC-28:Remove Catalogue Item Subscription
UC-34:Stop Publishing Catalogue Item Data
UC-48:Request Catalogue Item Data |
| Actors |
Data Source
Source Data Pool (SDP)
Data Recipient
Recipient Data Pool (RDP)
Global Registry |
| Performance Goals |
Data Source: To
inform the Source Data Pool of the criteria under which Catalogue Item
Data may be distributed to Data Recipients (Publication).
SDP: To
obtain the necessary information that will allow the SDP to distribute
Catalogue Item Data to the appropriate Recipient Data Pool
(Publications, Subscriptions and Confirmations).
Data Recipient: To
inform the Recipient Data Pool of the criteria under which Catalogue
Item Data may be forwarded to the Data Recipient (Subscriptions,
Confirmations).
Recipient Data Pool: To
obtain the necessary information that will allow the RDP to forward
Catalogue Item Data to the appropriate Data Recipient (Subscriptions,
Confirmations).
Global Registry: To provide SDP with Subscriptions and the address of the RDP for a particular Data Recipient. |
| Preconditions |
The Data Source has determined that they would like to distribute Catalogue Item Data. The Data Recipient has determined that they would like to receive Catalogue Item Data. |
| Postconditions |
A
full set of criteria (Publications, Subscriptions and Confirmations) is
specified, enabling the ongoing process of distribution of Catalogue
Item data. The confirmation is not a pre-requisite to the distribution
of data. |
| Scenario |
- The Data Source Publishes Catalogue Item data.
- The Data Recipient Subscribes to Catalogue Item Data.
- The Data Recipient Confirms Catalogue Item Data.
- The Source Data Pool applies the Publications, Subscriptionsand Confirmations to create the Synchronisation List
|
| Alternative Scenario |
None at this summary level |
| Special Requirements |
|
| Extension Points |
N/A |
|
Requirements Covered
|
| ID |
Requirement |
Weight |
| REQ-12 |
Every
command needs a response and is handled according to the agreement
between the parties involved. In the inter-operable network,
acknowledgement messages are standardised and may contain the following
information: - Confirmation of message receipt- Success / Failure of
processing (syntax and content)- Reason for failure, with a code number
and text message unique assigned to each failure |
Primary |
| REQ-13 |
The
Data Source grants visibility of item, party and partner profiles
including party capabilities data to a given list of parties
(identified by their GLNs) or to all parties in a given Target Market. |
Secondary |
| REQ-20 |
Synchronisation Lists must include every Catalogue Item (GTIN+GLN+TM) that needs to be synchronised. |
Secondary |
| REQ-21 |
If
a Catalogue Item is "Confirmed of Synchronisation" then all Catalogue
items below in the Catalogue Item Hierarchy shall be included in the
Synchronisation list. |
Secondary |
| REQ-22 |
Relationship dependent data will only be communicated for Synchronised, Review or Accept status in the Synchronisation List. |
Secondary |
| REQ-23 |
Events
that can trigger notifications are: - Publication of new data / change
of publication - Change of published Catalogue Item / Party / Partner
Profile - Change of owner, rights - Subscription - Synchronisation List
- Confirmation/ Rejection - Request for Notification - Any successful
matching process |
Primary |
| REQ-24 |
Notifications
must NOT be sent in the following cases since data is not yet public
and validated information: - Data load (add, change, etc…) -
Data validation - Registration of new Catalogue Item |
Primary |
| REQ-25 |
The
Data Distribution, which is the movement of data from one entity to
another, must be handled through a specific notification type. |
Primary |
| REQ-26 |
Notification
to the data recipient will always include the entire hierarchy.
(applies to add & update by adding a higher level) |
Primary |
| REQ-27 |
In case of an ItemLink correction, the entire hierarchy will be indicated as corrected in the notification. |
Primary |
| REQ-32 |
Acknowledgement Reason codes must be unique. |
Secondary |
| REQ-92 |
“Single
Data Source” Principle : - there can only be one official source
of the data – the one that is registered - this source is
identified by the data source - this is the only valid source for data
synchronisation and related processes |
Primary |
| REQ-99 |
The
Global Registry functionality requirements can be summarised as
follows: - Enable data synchronisation - Validation, registration and
subscription functions - Enable global validation - Checking compliance
with basic EAN.UCC rules related to the format of a GTIN/GLN and
ensuring the uniqueness of the data that is being registered - Enable
global search functionality that does not require full duplication of
data in the Global Registry. |
Primary |
| REQ-100 |
The
Global Registry is involved in the following functions and/or business
cases as defined in the Item Synchronisation detailed requirements: -
Validation - Registration - Subscription - Global Search |
Primary |
| REQ-101 |
Registry
Validation includes : - EAN.UCC standards validation for GTIN and GLN
formats (i.e. check digit) - Uniqueness validation for Item
(GTIN/GLN/TM), Party (GLN) or data pool (GLN), ensuring there is only
one occurrence and data source for each data record as identified by
the appropriate fields. |
Primary |
| REQ-102 |
Registry validation is a part of the registration process. |
Primary |
| REQ-104 |
In
summary, the registry requirements for validation are: - EAN.UCC
standards validation for GTIN/GLN formats - Uniqueness validation for
Item, Party and data pool key - Store and maintain EAN.UCC standards -
Process validation command - Provide validation acknowledgement |
Primary |
| REQ-105 |
Registration
is the process, which references all Catalogue Items and Parties
published in all certified data pools and on which there is a need to
synchronise / retrieve information. This is supported by data storage
in accordance with the Registry data scope and rules. |
Primary |
| REQ-106 |
Registering
a Catalogue Item involves a check by the Global Registry for Item
uniqueness. The Item is identified by the following elements: GTIN,
GLN, Target Market. Each combination of this key data found in the
Global Registry must be unique. When an Item is registered, the
registry verifies that the combination of this data is unique to that
Item. |
Primary |
| REQ-107 |
The
registration process is triggered by the following business cases: 1.
Create Catalogue Item: After the physical load and validation of the
data, the registry record needs to be created before data can be
published. 2. Update Catalogue Item: When a registered Catalogue Item
is updated in its source data pool, updates impacting the Registry data
must be reflected in the Global Registry, before the updated data can
be propagated to the recipients. Registration of Catalogue Item changes
only needs to happen for changes that: Impacts fields stored in the
Global Registry. Are authorised according to the GTIN allocation rules.
3. Correct Catalogue Item: When a registered item is corrected in its
source data pool, corrections impacting the Registry data must be
reflected in the Global Registry before the updated data can be
propagated to the data recipients. 4. Delete Catalogue Item: Deletions
need to be reflected in the Global Registry: the discontinuation dates
starts the EAN.UCC standard retention period (48 months for CPG, 36
months for apparel) as soon as GTIN has been discontinued in ALL target
markets where it was active (needs to be stored in the Global
Registry). 5. Cancel Catalogue Item: Communicates a trade item was
never manufactured – this allows an earlier “reuse”
of the GTIN i.o. standard retention period. This is achieved through
the maintenance (using change function) of the cancel date. 6. Removing
a Catalogue Item from the supply chain: The permanent removal of a
Catalogue Item from the supply chain is achieved through the
maintenance of a discontinuation date. This date has to be reflected in
the Global Registry to kick off the EAN.UCC retention period. Temporary
removals are not reflected in the Global Registry and only handled
through the maintenance of the availability period in the data pools. |
Primary |
| REQ-108 |
Registry
requirements for registration are : - Registration can only happen
after successful validation. - Registration can only produce errors, no
warnings. - Successful Registration of a Catalogue Item is mandatory
prior to publication of any hierarchy containing that Catalogue Item. -
ItemStatus needs to be included in GTIN data model to reflect
validation and registration status. - Process registration command (for
create, update, correct, delete). - Provide registration
acknowledgement. |
Primary |
| REQ-109 |
A
Data Recipient requests that it receive a “notification”
when a specific event occurs that meets the Recipients criteria
(selective on sources, categories, etc). This is subject to the
recipient’s access to information as controlled by the data
source through its source data pool. |
Primary |
| REQ-119 |
Future effective changes stored in the data pool are only reflected in the Global Registry when they become effective. |
Primary |
| REQ-121 |
Party:
- GLN - Start Availability Date of the Party - Deletion Date of the
Party - Registration Date - Source Data Pool Pointer [GLN used to
….] - GLN of Data Source (*Data Source is actually the
‘owner’ of the GLN data - Date and Time of last change -
Party Validation Information (including Version, Date & Certificate
ID) |
Primary |
| REQ-128 |
Source Data Pools must send notifications based on matching publications and subscriptions. |
Secondary |
| REQ-159 |
Multiple
independent hierarchies can co-exist at the data-pool for an item for
example hierarchy 1 = case A – each A and hierarchy 2 = pallet A
– case A –each A. |
Primary |
| REQ-171 |
The
message identifier (CorrelationInformation:
requestingDocu-mentInstanceIdentifier) at the document header level for
the EAN.UCC response and the GDSN Exception must equal the
DocumentIdentification: instanceIdentifier of the original message. |
Primary |
|
|
|
|
|
|
|
|
|
TOP |
|
|
|
|
|
|
|
12. Publish
Catalogue Item Data |
|
|
|
 |
|
|
|
|
|
|
|
| Use Case Name |
Publish Catalogue Item Data |
| Traceability Identifier |
UC-24 |
| Use Case Description |
The
Publish Catalogue Item Data Use Case describes how a Data Source
provides the Source Data Pool with the criteria under which their
Catalogue Item Data may be distributed to Data Recipients. |
| Use Cases Above |
UC-23:Manage Catalogue Item Distribution Criteria |
| Use Cases Below |
None |
| Actors |
Data SourceSource Data Pool (SDP) |
| Performance Goals |
Data Source: To
inform the Source Data Pool of the criteria (Target Market, Recipient
GLN) under which their Catalogue Item Data may be distributed to Data
Recipients.SDP:To
posses the necessary information that will allow the SDP to distribute
Catalogue Item Data to the appropriate Recipient Data Pool. |
| Preconditions |
Each Catalogue Item has been loaded to the Source Data Pool and Registered in the Global Registry. |
| Postconditions |
Publication data is stored in the Source Data Pool. |
| Scenario |
Begins when, the Source Data Pool receives a Publication message from a Data Source.
1.The SDP validates the Publication (valid Target Market, GLN)2.The SDP creates or updates the Synchronisation List
Ends when, the Synchronisation List is created or updated.
|
| Alternative Scenario |
ad 1.Data Source has sent invalid data:
1.1.The SDP sends an error message to the Source Data Pool specifying what was invalid.
Ends when, the Data Source receives the error message |
| Special Requirements |
|
| Extension Points |
N/A |
| Requirements Covered |
| ID |
Requirement |
Weight |
| REQ-12 |
Every
command needs a response and is handled according to the agreement
between the parties involved. In the inter-operable network,
acknowledgement messages are standardised and may contain the following
information: - Confirmation of message receipt- Success / Failure of
processing (syntax and content)- Reason for failure, with a code number
and text message unique assigned to each failure |
Primary |
| REQ-13 |
The
Data Source grants visibility of item, party and partner profiles
including party capabilities data to a given list of parties
(identified by their GLNs) or to all parties in a given Target Market. |
Primary |
| REQ-20 |
Synchronisation Lists must include every Catalogue Item (GTIN+GLN+TM) that needs to be synchronised. |
Primary |
| REQ-21 |
If
a Catalogue Item is "Confirmed of Synchronisation" then all Catalogue
items below in the Catalogue Item Hierarchy shall be included in the
Synchronisation list. |
Primary |
| REQ-22 |
Relationship dependent data will only be communicated for Synchronised, Review or Accept status in the Synchronisation List. |
Primary |
| REQ-23 |
Events
that can trigger notifications are: - Publication of new data / change
of publication - Change of published Catalogue Item / Party / Partner
Profile - Change of owner, rights - Subscription - Synchronisation List
- Confirmation/ Rejection - Request for Notification - Any successful
matching process |
Primary |
| REQ-24 |
Notifications
must NOT be sent in the following cases since data is not yet public
and validated information: - Data load (add, change, etc…) -
Data validation - Registration of new Catalogue Item |
Primary |
| REQ-32 |
Acknowledgement Reason codes must be unique. |
Primary |
| REQ-66 |
When product is available again: update start/end availability date. |
Primary |
| REQ-82 |
Maintaining a publication is granting visibility and access to data. |
Secondary |
| REQ-83 |
Publications
are initiated by the Data Source in the source data pool, they do not
need to be synchronised in the Global Data Synchronisation Network
(GDSN). |
Secondary |
| REQ-84 |
The
Target Market where product is available is communicated in the product
key (GTIN+GLN+TM) – this can be different from the Target Market
for publication. |
Secondary |
| REQ-85 |
Data
is either published: - to a Target Market: any GLN in the Target Market
has access to the data (only applies to “public” Items) -
to specific GLN’s: only these GLN’s have access to the data
(only applies to “private” Items) |
Secondary |
| REQ-86 |
The purpose of the public/private flag is to provide information to the parties involved on the status of the Catalogue Item. |
Secondary |
| REQ-87 |
Notification is triggered by the matching process. |
Secondary |
| REQ-88 |
The
matching process is owned and developed by each source data pool in
order to trigger data distribution based on publication and
subscription data. |
Secondary |
| REQ-89 |
The
matching process can be triggered either by publication, subscription
or as a scheduled event. It is valid for all subscription types
(including synchronisation list) and all publication types. |
Secondary |
| REQ-91 |
For
a given publication (create/update) : - the matching process identifies
subscriptions with matching criteria (TM, GLN, category, GTIN…)
- for each matching subscription, a notification is created including
all dependent hierarchies - for a synchronisation list, the hierarchy
information included in the notification, will be limited to the GTIN's
maintained in the Synchronisation list. - The notification is sent to
the home data pool of the data recipient. |
Secondary |
| REQ-93 |
Although
the notification process will physically move the data from one data
pool to another, this data should not be stored permanently for the
purpose of synchronisation with any other user than the initial
subscriber. If stored, access should be limited to the initial data
recipient. |
Secondary |
| REQ-109 |
A
Data Recipient requests that it receive a “notification”
when a specific event occurs that meets the Recipients criteria
(selective on sources, categories, etc). This is subject to the
recipient’s access to information as controlled by the data
source through its source data pool. |
Primary |
| REQ-128 |
Source Data Pools must send notifications based on matching publications and subscriptions. |
Primary |
| REQ-138 |
Publication Who : Data Source = source GLN What : Item record, identified by GTIN+GLN+TMWhere : TM or GLN (= target GLN) |
Secondary |
| REQ-140 |
Publication
TM does not have to be equal to the GTIN TM (i.e. I can have a product
record defined for TM France, but publishing the data toBelgium only for information purposes). |
Secondary |
| REQ-144 |
Request
for publication (subscription) resets the reject flag if catalogue Item
has been previously rejected and reactivate the subscription. |
Secondary |
| REQ-145 |
The request for publication subscription is only executed once. |
Secondary |
| REQ-146 |
Subscriptions
are passed from global Registry to data pools just once. The Global
Registry passes along to the source data pool matching subscriptions in
the entirety, rather than replicating for each GTIN registered. |
Primary |
| REQ-147 |
Request
for notification publication (subscription) resets the reject flag if
the Catalogue Item has been previously rejected and reactivate the
subscription. |
Primary |
| REQ-148 |
The "Reload" attribute will contain a Boolean value (TRUE or FALSE). |
Primary |
| REQ-149 |
Upon
execution of an item data notification, the source data pool will pass
along the value of this attribute within the message for the recipient
to properly route the inbound message. After executing the item data
notification, the source data pool will |
Primary |
| REQ-150 |
The
team identified the need for an additional process to be known as
“Request for Notification”. The Request for Notification is
originated by the requesting data recipient, through the recipient data
pool, to the Global Registry and forwarded to the so |
Primary |
| REQ-151 |
The
team wanted to reiterate the fact that new subscriptions received by a
source data pool would be executed immediately a single time. |
Primary |
| REQ-152 |
The
ability to set up a subscription and not get an initial full load of
data. She wants to only receive the changes, adds, deletes and new
items that match her subscription. (This is the same as a regular
subscription with the exception of not getting |
Primary |
| REQ-154 |
The Global Registry shall send only once a subscription to a Source Data Pool. |
Primary |
| REQ-156 |
Subscription matches are performed at any level of the hierarchy. The data recipient is sent all hierarchies that match. |
Secondary |
| REQ-155 |
Data Sources will publish trade items at the highest level of the hierarchy |
Primary |
| REQ-158 |
Top
of hierarchy is assumed to be the largest available unit determined by
the data source. Defined as the GTIN of the highest published item in
the hierarchy. |
Primary |
| REQ-159 |
Multiple
independent hierarchies can co-exist at the data-pool for an item for
example hierarchy 1 = case A – each A and hierarchy 2 = pallet A
– case A –each A. |
Primary |
| REQ-166 |
A
Request for Catalogue Item Notification with the isReload set to false
will result in items being re-sent whether they were previously
rejected or not. The Sync List will be reset. This is only valid for
items that have previously been sent to the data recipient.
The CIN response will have the following values:
- documentStatus= Original
- isReload = False
- Command= Add
|
Primary |
| REQ-167 |
A
Request for Catalogue Item Notification with the isReload set to true
will result in only items not previously rejected being re-sent. The
Sync List is not reset.
The CIN response will have the following values:
- documentStatus= Copy
- isReload = True
- Command= Add
|
Primary |
| REQ-168 |
The
Document Status of the RFCIN command is ignored for the purposes of
determining its impact on the sync list and the status of the CIN that
is generated. |
Primary |
| REQ-171 |
The
message identifier (CorrelationInformation:
requestingDocu-mentInstanceIdentifier) at the document header levelfor
the EAN.UCC response and the GDSN Exception must equal
theDocumentIdentification: instanceIdentifier of the originalmessage. |
Primary |
|
|
|
|
|

|
|
|
|
Figure 34 - Publish
Catalogue Item Data Activity Diagram |
|
|
|
 |
|
|
|
Figure
35- Publish Catalogue Item Data Sequence Diagram |
|
|
|
|
|
|
|
TOP |
|
|
|
|
|
|
|
13. Stop Publishing
Catalogue Item Data |
|
|
|
 |
|
|
|
Figure 36 - Stop
Publishing Catalogue Item Data Use Case Diagram |
|
|
|
| Use Case Name |
Stop Publishing Catalogue Item Data |
| Traceability Identifier |
UC-34 |
| Use Case Description |
The
Stop Publishing Catalogue Item Data Use Case describes how a Data
Source informs the Source Data Pool to delete the criteria under which
their Catalogue Item Data may be distributed to Data Recipients.
The Source Data Pool will not be able to distribute the Catalogue Item Data prescribed by the criteria. |
| Use Cases Above |
UC-23:Manage Catalogue Item Distribution Criteria |
| Use Cases Below |
None |
| Actors |
Data SourceSource Data Pool (SDP) |
| Performance Goals |
Data Source: To inform the Source Data Pool to delete a Publication and stop distributing Catalogue Item Data.SDP: To
posses the necessary information that will allow the SDP to distribute
Catalogue Item Data to the appropriate Recipient Data Pool. |
| Preconditions |
The Publication exists in the Source Data Pool. |
| Postconditions |
The Source Data Pool is unable to distribute the Catalogue Item Data that was specified in the deleted Publication. |
| Scenario |
Begins when, the Source Data Pool receives a message to delete a publicationfrom a Data Source.
1.The SDP validates that the Publication exists2.The SDP removes the entry from the Synchronisation List3.The SDP deletes the Publication.4.The SDP sends a CIN (with a Document Command of Delete and a CIN CatalogueItem State which equals the current catalogue item state in the Global Registry )
to the recipient data pool and on to the data recipient informing them
that the publication has been stopped (break in synchronisation). Note
: None of the item dates are updated in this transaction.
Ends when,
the Data Recipient receives the CIN with a Document Command of Delete
and a CIN Catalogue Item State which equals the current catalogue item
state in the Global Registry.
|
| Alternative Scenario |
ad 1.The Publication does not exist at the Source Data Pool:
1.1. The SDP sends an error message to the Source Data Pool specifying that the Publication does not exist.
Ends when, the Data Source receives the error message |
| Special Requirements |
|
| Extension Points |
N/A |
| Requirements Covered |
| ID |
Requirement |
Weight |
| REQ-12 |
Every
command needs a response and is handled according to the agreement
between the parties involved. In the inter-operable network,
acknowledgement messages are standardised and may contain the following
information: - Confirmation of message receipt- Success / Failure of
processing (syntax and content)- Reason for failure, with a code number
and text message unique assigned to each failure |
Primary |
| REQ-13 |
The
Data Source grants visibility of item, party and partner profiles
including party capabilities data to a given list of parties
(identified by their GLNs) or to all parties in a given Target Market. |
Primary |
| REQ-16 |
Subscription remains valid until it is deleted. Hence, it can not be updated. |
Primary |
| REQ-20 |
Synchronisation Lists must include every Catalogue Item (GTIN+GLN+TM) that needs to be synchronised. |
Primary |
| REQ-21 |
If
a Catalogue Item is "Confirmed of Synchronisation" then all Catalogue
items below in the Catalogue Item Hierarchy shall be included in the
Synchronisation list. |
Primary |
| REQ-22 |
Relationship dependent data will only be communicated for Synchronised, Review or Accept status in the Synchronisation List. |
Primary |
| REQ-23 |
Events
that can trigger notifications are: - Publication of new data / change
of publication - Change of published Catalogue Item / Party / Partner
Profile - Change of owner, rights - Subscription - Synchronisation List
- Confirmation/ Rejection - Request for Notification - Any successful
matching process |
Primary |
| REQ-24 |
Notifications
must NOT be sent in the following cases since data is not yet public
and validated information: - Data load (add, change, etc…) -
Data validation - Registration of new Catalogue Item |
Primary |
| REQ-32 |
Acknowledgement Reason codes must be unique. |
Primary |
| REQ-65 |
Communicate that product is no longer available: maintain end availability date. |
Primary |
| REQ-66 |
When product is available again: update start/end availability date. |
Primary |
| REQ-82 |
Maintaining a publication is granting visibility and access to data. |
Primary |
| REQ-83 |
Publications
are initiated by the Data Source in the source data pool, they do not
need to be synchronised in the Global Data Synchronisation Network
(GDSN). |
Primary |
| REQ-84 |
The
Target Market where product is available is communicated in the product
key (GTIN+GLN+TM) – this can be different from the Target Market
for publication. |
Primary |
| REQ-85 |
Data
is either published: - to a Target Market: any GLN in the Target Market
has access to the data (only applies to “public” Items) -
to specific GLN’s: only these GLN’s have access to the data
(only applies to “private” Items) |
Primary |
| REQ-86 |
The purpose of the public/private flag is to provide information to the parties involved on the status of the Catalogue Item. |
Primary |
| REQ-87 |
Notification is triggered by the matching process. |
Primary |
| REQ-88 |
The
matching process is owned and developed by each source data pool in
order to trigger data distribution based on publication and
subscription data. |
Primary |
| REQ-89 |
The
matching process can be triggered either by publication, subscription
or as a scheduled event. It is valid for all subscription types
(including synchronisation list) and all publication types. |
Primary |
| REQ-91 |
For
a given publication (create/update) : - the matching process identifies
subscriptions with matching criteria (TM, GLN, category, GTIN…)
- for each matching subscription, a notification is created including
all dependent hierarchies - for a synchronisation list, the hierarchy
information included in the notification, will be limited to the GTIN's
maintained in the Synchronisation list. - The notification is sent to
the home data pool of the data recipient. |
Primary |
| REQ-93 |
Although
the notification process will physically move the data from one data
pool to another, this data should not be stored permanently for the
purpose of synchronisation with any other user than the initial
subscriber. If stored, access should be limited to the initial data
recipient. |
Primary |
| REQ-109 |
A
Data Recipient requests that it receive a “notification”
when a specific event occurs that meets the Recipients criteria
(selective on sources, categories, etc). This is subject to the
recipient’s access to information as controlled by the data
source through its source data pool. |
Primary |
| REQ-128 |
Source Data Pools must send notifications based on matching publications and subscriptions. |
Primary |
| REQ-138 |
Publication Who : Data Source = source GLN What : Item record, identified by GTIN+GLN+TMWhere : TM or GLN (= target GLN) |
Primary |
| REQ-140 |
Publication
TM does not have to be equal to the GTIN TM (i.e. I can have a product
record defined for TM France, but publishing the data toBelgium only for information purposes). |
Primary |
| REQ-144 |
Request
for publication (subscription) resets the reject flag if catalogue Item
has been previously rejected and reactivate the subscription. |
Primary |
| REQ-145 |
The request for publication subscription is only executed once. |
Primary |
| REQ-146 |
Subscriptions
are passed from global Registry to data pools just once. The Global
Registry passes along to the source data pool matching subscriptions in
the entirety, rather than replicating for each GTIN registered. |
Primary |
| REQ-147 |
Request
for notification publication (subscription) resets the reject flag if
the Catalogue Item has been previously rejected and reactivate the
subscription. |
Primary |
| REQ-148 |
The "Reload" attribute will contain a Boolean value (TRUE or FALSE). |
Primary |
| REQ-149 |
Upon
execution of an item data notification, the source data pool will pass
along the value of this attribute within the message for the recipient
to properly route the inbound message. After executing the item data
notification, the source data pool will |
Primary |
| REQ-150 |
The
team identified the need for an additional process to be known as
“Request for Notification”. The Request for Notification is
originated by the requesting data recipient, through the recipient data
pool, to the Global Registry and forwarded to the so |
Primary |
| REQ-151 |
The
team wanted to reiterate the fact that new subscriptions received by a
source data pool would be executed immediately a single time. |
Primary |
| REQ-152 |
The
ability to set up a subscription and not get an initial full load of
data. She wants to only receive the changes, adds, deletes and new
items that match her subscription. (This is the same as a regular
subscription with the exception of not getting |
Primary |
| REQ-154 |
The Global Registry shall send only once a subscription to a Source Data Pool. |
Primary |
| REQ-155 |
Data Sources will publish trade items at the highest level of the hierarchy. |
Primary |
| REQ-158 |
Top
of hierarchy is assumed to be the largest available unit determined by
the data source. Defined as the GTIN of the highest published item in
the hierarchy. |
Primary |
| REQ-159 |
Multiple
independent hierarchies can co-exist at the data-pool for an item for
example hierarchy 1 = case A – each A and hierarchy 2 = pallet A
– case A –each A. |
Primary |
| REQ-162 |
To
stop the publication of a hierarchy to data recipient, a CIN (with a
Document Command of Delete and a CIN Catalogue Item State
which equals the current catalogue item state in the Global Registry)
will be sent from the source data pool to the recipient data pool and
on to the data recipient. |
Primary |
| REQ-165 |
Publication deletes must be done at highest level of the published item hierarchy. |
Primary |
| REQ-171 |
The
message identifier (CorrelationInformation:
requestingDocu-mentInstanceIdentifier) at the document header levelfor
the EAN.UCC response and the GDSN Exception must equal
theDocumentIdentification: instanceIdentifier of the originalmessage. |
Primary |
|
|
|
|
|

|
|
|
|
Figure 37 - Stop
Publishing Catalogue Item Data Activity Diagram |
|
|
|
 |
|
|
|
Figure 38 - Stop
Publishing Catalogue Item Data Sequence Diagram |
|
|
|
|
|
|
|
TOP |
|
|
|
|
|
|
|
14. Subscribe to
Catalogue Item Data |
|
|
|
 |
|
|
|
Figure 39 -
Subscribe to Catalogue Item Data Use Case Diagram |
|
|
|
| Use Case Name |
Subscribe to Catalogue Item Data |
| Traceability Identifier |
UC-27 |
| Use Case Description |
The
Subscribe to Catalogue Item Data Use Case describes how a Data
Recipient informs the Recipient Data Pool with the criteria under which
Catalogue Item Data may be distributed to the Data Recipient.
Once the Subscription is created,
the Recipient Data Pool will forward it to the Global Registry which,
in turn, will forward it to appropriate Source Data Pools (see UC-35
Distribute Subscription Data). |
| Use Cases Above |
UC-23:Manage Catalogue Item Distribution Criteria |
| Use Cases Below |
None |
| Actors |
Data RecipientRecipient Data Pool (RDP) |
| Performance Goals |
Data Recipient:To inform the Recipient Data Pool of the criteria by which Catalogue Item Data may be forwarded to the Recipient.RDP:To posses the necessary information that will allow the RDP to send subscriptions to the Global Registry. |
| Preconditions |
None |
| Postconditions |
The Recipient Data Pool has a Subscription that can be shared with the Global Registry. |
| Scenario |
Begins when, the Recipient Data Pool receives a Subscription Publication message from a Data Recipient.
1.The RDP sends a message acknowledgement to the Data Recipient2.The RDP validates the Subscription criteria (GTIN, GLN of data owner, Target Market or Category).3.The RDP sends a Subscription Verification to the Data Recipient
Ends when, the Data Recipient acknowledges the Subscription Verification message.
|
| Alternative Scenario |
ad 1.The Subscription already exists:
1.1.The RDP sends an error message to the Data Recipient specifying that the Subscription exists.
Ends when, the Data Recipient receives the error message
Ad 2.The validation fails:2.1.The RDP sends an error message to the Data Recipient specifying the field in errorEnds when, the Data Recipient receives the error message
|
| Special Requirements |
If
the GLN is not found in the party registry, the subscription is still
persisted. The GLN must still pass all syntactic validations.
If the
GTIN is not found in the item registry, the subscription is still
persisted. The GTIN must still pass all syntactic validations.
If the Target Market is not found in the code list of valid target markets in the global registry, the subscription fails.
If the GPC is not found in the code list of valid GPCs in the global registry, the subscription fails.
If a subscription, after passing
these validations fails to match any items in the global registry, the
subscription is still persisted. |
| Extension Points |
N/A |
| Requirements Covered |
| ID |
Requirement |
Weight |
| REQ-12 |
Every
command needs a response and is handled according to the agreement
between the parties involved. In the inter-operable network,
acknowledgement messages are standardised and may contain the following
information: - Confirmation of message receipt- Success / Failure of
processing (syntax and content)- Reason for failure, with a code number
and text message unique assigned to each failure |
Primary |
| REQ-14 |
A
subscription must be able to be maintained on the following levels : -
GTIN - GLN of Data Source - Target Market - Lowest level of EAN.UCC
Classification or any combination of these 4 elements. |
Secondary |
| REQ-15 |
With
the set up of a subscription, a Data Recipient sets a profile to
receive ongoing updates of the matching data (including all
hierarchies, independently from the level subscribed on). |
Secondary |
| REQ-16 |
Subscription remains valid until it is deleted. Hence, it can not be updated. |
Primary |
| REQ-17 |
Subscriptions must be created by data recipients in their Recipients Data Pool and sent to the Global Registry. |
Secondary |
| REQ-19 |
The system must maintain detailed subscription lists. |
Secondary |
| REQ-20 |
Synchronisation Lists must include every Catalogue Item (GTIN+GLN+TM) that needs to be synchronised. |
Primary |
| REQ-21 |
If
a Catalogue Item is "Confirmed of Synchronisation" then all Catalogue
items below in the Catalogue Item Hierarchy shall be included in the
Synchronisation list. |
Primary |
| REQ-22 |
Relationship dependent data will only be communicated for Synchronised, Review or Accept status in the Synchronisation List. |
Primary |
| REQ-23 |
Events
that can trigger notifications are: - Publication of new data / change
of publication - Change of published Catalogue Item / Party / Partner
Profile - Change of owner, rights - Subscription - Synchronisation List
- Confirmation/ Rejection - Request for Notification - Any successful
matching process |
Primary |
| REQ-24 |
Notifications
must NOT be sent in the following cases since data is not yet public
and validated information: - Data load (add, change, etc…) -
Data validation - Registration of new Catalogue Item |
Primary |
| REQ-29 |
The confirmation process must take place in the home data pool of the data recipient. |
Primary |
| REQ-32 |
Acknowledgement Reason codes must be unique. |
Primary |
| REQ-69 |
Data recipient maintains subscription. |
Secondary |
| REQ-70 |
Data recipient will continue to receive updates until he rejects the data. |
Primary |
| REQ-72 |
Reject is optional: in the absence of confirmation & reject, the data recipient would still receive updates. |
Primary |
| REQ-73 |
Confirmed GTIN: - subscription: go to synchronisation list - synchronisation list: no action required |
Secondary |
| REQ-74 |
Only new products matching the initial subscription will be distributed to avoid resending data that was previously rejected. |
Primary |
| REQ-78 |
Subscription: for every matching GTIN, independently from its level, all hierarchies will be returned. |
Secondary |
| REQ-79 |
Synchronisation
list: - Includes every GTIN id (GTIN+GLN+TM) that needs to be
synchronised - Can be a result of the Confirmation process - All
GTIN’s equal or lower in the hierarchy than the GTIN confirmed
will be returned |
Primary |
| REQ-81 |
Synchronisation
List is only synchronised between the involved source and recipient
data pools for applicable data: synchronisation list is built based on
confirmation received by a source data pool and nothing else. |
Primary |
| REQ-88 |
The
matching process is owned and developed by each source data pool in
order to trigger data distribution based on publication and
subscription data. |
Primary |
| REQ-89 |
The
matching process can be triggered either by publication, subscription
or as a scheduled event. It is valid for all subscription types
(including synchronisation list) and all publication types. |
Primary |
| REQ-90 |
For
a given subscription (create/update): - the matching process identifies
Items published to the GLN or TM of the subscription owner. - for each
item, a notification is created including all dependent hierarchies. -
for a synchronisation list, the hierarchy information included in the
notification, will be limited to the GTIN's maintained in the
Synchronisation list. - The notification is sent to the home data pool
of the data recipient. |
Secondary |
| REQ-99 |
The
Global Registry functionality requirements can be summarised as
follows: - Enable data synchronisation - Validation, registration and
subscription functions - Enable global validation - Checking compliance
with basic EAN.UCC rules related to the format of a GTIN/GLN and
ensuring the uniqueness of the data that is being registered - Enable
global search functionality that does not require full duplication of
data in the Global Registry. |
Primary |
| REQ-100 |
The
Global Registry is involved in the following functions and/or business
cases as defined in the Item Synchronisation detailed requirements: -
Validation - Registration - Subscription - Global Search |
Primary |
| REQ-109 |
A
Data Recipient requests that it receive a “notification”
when a specific event occurs that meets the Recipients criteria
(selective on sources, categories, etc). This is subject to the
recipient’s access to information as controlled by the data
source through its source data pool. |
Primary |
| REQ-110 |
After
a Subscription is created, the Global Registry will then disseminate
relevant subscriptions to appropriate Source Data Pools (current and
future new data pools). |
Secondary |
| REQ-111 |
Registry
requirements for subscription are: - Receive and store subscriptions -
Provide subscription acknowledgement - Matching process of
subscriptions with Source Data Pools - Forward subscriptions |
Secondary |
| REQ-123 |
Recipient maintains a subscription, including the "Reload" flag. |
Secondary |
| REQ-124 |
The notification triggered by a subscription must also carry the "Reload" flag value. |
Secondary |
| REQ-126 |
If
a new Reload is needed, the Recipient must delete the previous Reload
Subscription, then create a new Subscription with the "Reload" flag set. |
Secondary |
| REQ-128 |
Source Data Pools must send notifications based on matching publications and subscriptions. |
Primary |
| REQ-129 |
GTIN
and Category are mutually exclusive subscription criteria as the
Category is uniquely defined for a given GTIN, independently from the
GLN and from the TM. |
Secondary |
| REQ-132 |
The
events that can trigger the distribution of a subscription are: -
new/updated registration: check existing subscriptions, if new data
pools are found : distribute subscriptions - new subscription: check
existing registrations, if new data pools are found: distribute
subscriptions - delete subscriptions: distribute “delete”
to source data pools where subscription had been sent |
Primary |
| REQ-133 |
Subscriptions cannot be updated, they are created or deleted. |
Primary |
| REQ-134 |
Subscriptions must be stored in the recipient’s data pool. |
Primary |
| REQ-135 |
For
every subscription, the Registry must store the GLN of the Source Data
Pool to which the subscription was sent and when it was sent. |
Primary |
| REQ-136 |
Ability
to identify new or updated registered Catalogue Items that match a
subscription and forward the subscription to the Source Data Pool. |
Primary |
| REQ-137 |
Match new subscriptions with registered Catalogue Items and forward the subscription to the Source Data Pool. |
Primary |
| REQ-139 |
SubscriptionWho : Data Recipient = target GLNWhat : Any combination of GTIN, GLN, TM and Category |
Primary |
| REQ-141 |
Deletion
of a Subscription stops New Catalogue Items from being sent to RDP,
but, doesn't stop Catalogue Items already in the Synchronisation List
from being updated. |
Primary |
| REQ-142 |
Request
for Notification is not retained in the Global Registry and acts like a
Subscription that is applied to the Synchronisation List, then deleted
(no New Catalogue Item data will be sent). |
Primary |
| REQ-143 |
"Reload" flag is passed through to Recipient. |
Primary |
| REQ-144 |
Request
for publication (subscription) resets the reject flag if catalogue Item
has been previously rejected and reactivate the subscription. |
Primary |
| REQ-145 |
The request for publication subscription is only executed once. |
Primary |
| REQ-146 |
Subscriptions
are passed from global Registry to data pools just once. The Global
Registry passes along to the source data pool matching subscriptions in
the entirety, rather than replicating for each GTIN registered. |
Primary |
| REQ-147 |
Request
for notification publication (subscription) resets the reject flag if
the Catalogue Item has been previously rejected and reactivate the
subscription. |
Primary |
| REQ-148 |
The "Reload" attribute will contain a Boolean value (TRUE or FALSE). |
Primary |
| REQ-149 |
Upon
execution of an item data notification, the source data pool will pass
along the value of this attribute within the message for the recipient
to properly route the inbound message. After executing the item data
notification, the source data pool will |
Primary |
| REQ-150 |
The
team identified the need for an additional process to be known as
“Request for Notification”. The Request for Notification is
originated by the requesting data recipient, through the recipient data
pool, to the Global Registry and forwarded to the so |
Primary |
| REQ-151 |
The
team wanted to reiterate the fact that new subscriptions received by a
source data pool would be executed immediately a single time. |
Primary |
| REQ-152 |
The
ability to set up a subscription and not get an initial full load of
data. She wants to only receive the changes, adds, deletes and new
items that match her subscription. (This is the same as a regular
subscription with the exception of not getting |
Primary |
| REQ-154 |
The Global Registry shall send only once a subscription to a Source Data Pool. |
Primary |
| REQ-156 |
Subscription matches are performed at any level of the hierarchy. The data recipient is sent all hierarchies that match. |
Primary |
| REQ-159 |
Multiple
independent hierarchies can co-exist at the data-pool for an item for
example hierarchy 1 = case A – each A and hierarchy 2 = pallet A
– case A –each A. |
Primary |
| REQ- 169 |
The
Global Registry shall retain and persist all Catalogue Item
Subscriptions that are received that contain a GTIN or GLN that is not
found in the Global Registry. |
Primary |
| REQ-171 |
The
message identifier (CorrelationInformation:
requestingDocu-mentInstanceIdentifier) at the document header levelfor
the EAN.UCC response and the GDSN Exception must equal
theDocumentIdentification: instanceIdentifier of the originalmessage. |
Primary |
|
|
|
|
|

|
|
|
|
Figure 40 -
Subscribe to Catalogue Item Data Activity Diagram |
|
|
|
 |
|
|
|
Figure 41
- Subscribe to Catalogue Item Data Sequence Diagram |
|
|
|
|
|
|
|
TOP |
|
|
|
|
|
|
|
15. Remove
Catalogue Item Subscription |
|
|
|
 |
|
|
|
Figure 42
- Remove Catalogue Item Subscription Use Case Diagram |
|
|
|
| Use Case Name |
Remove Catalogue Item Subscription |
| Traceability Identifier |
UC-28 |
| Use Case Description |
The
Remove Catalogue Item Subscription Use Case describes how a Data
Recipient informs the Recipient Data Pool to delete a subscription.
Once the Subscription is removed,
the Recipient Data Pool will forward the removal information to the
Global Registry which, in turn, will forward it to appropriate Source
Data Pools (see UC-35 Distribute Subscription Data).
The Source Data Pools will remove the subscription.Thereafter, the Source Data Pools will not send new Catalogue Item data to the Data Recipient (via their Recipient Data Pool).The removal of a subscription does not affect the Synchronisation list held by the Source Data pool.The Data Recipient will continue to receive changes, corrections and deletions based on the Synchronisation List. |
| Use Cases Above |
UC-23:Manage Catalogue Item Distribution Criteria |
| Use Cases Below |
None |
| Actors |
Data RecipientRecipient Data Pool (RDP) |
| Performance Goals |
Data Recipient: To inform the Recipient Data Pool of the removal of a subscription. Essentially (via the Distribute Subscription Use Case) stopping new Catalogue Item data from being forwarded.RDP: To
posses the necessary information that will allow the RDP and
appropriate Source Data Pools to distribute Catalogue Item Data to the
Recipient. |
| Preconditions |
The Data recipient has a Subscription held by the Recipient Data Pool. |
| Postconditions |
The
Subscription no longer exists in the Recipient Data Pool or (via the
Distribute Subscription Use Case) the Registry and Source Data Pools. |
| Scenario |
Begins when, the Recipient Data Pool receives a Delete Subscription message from a Data Recipient.
1.The RDP sends a message acknowledgement to the Data Recipient2.The RDP validates that the Subscription exists.3.The RDP sends a Subscription Verification to the Data Recipient
Ends when, the Data Recipient acknowledges the Subscription Verification message.
|
| Alternative Scenario |
ad 2.The Subscription does not exist:
2.1.The RDP sends an error message to the Data Recipient specifying that the Subscription does not exist.
Ends when, the Data Recipient receives the error message
|
| Special Requirements |
|
| Extension Points |
N/A |
| Requirements Covered |
| ID |
Requirement |
Weight |
| REQ-12 |
Every
command needs a response and is handled according to the agreement
between the parties involved. In the inter-operable network,
acknowledgement messages are standardised and may contain the following
information: - Confirmation of message receipt- Success / Failure of
processing (syntax and content)- Reason for failure, with a code number
and text message unique assigned to each failure |
Primary |
| REQ-14 |
A
subscription must be able to be maintained on the following levels : -
GTIN - GLN of Data Source - Target Market - Lowest level of EAN.UCC
Classification or any combination of these 4 elements. |
Primary |
| REQ-15 |
With
the set up of a subscription, a Data Recipient sets a profile to
receive ongoing updates of the matching data (including all
hierarchies, independently from the level subscribed on). |
Primary |
| REQ-16 |
Subscription remains valid until it is deleted. Hence, it can not be updated. |
Secondary |
| REQ-19 |
The system must maintain detailed subscription lists. |
Primary |
| REQ-20 |
Synchronisation Lists must include every Catalogue Item (GTIN+GLN+TM) that needs to be synchronised. |
Primary |
| REQ-21 |
If
a Catalogue Item is "Confirmed of Synchronisation" then all Catalogue
items below in the Catalogue Item Hierarchy shall be included in the
Synchronisation list. |
Primary |
| REQ-22 |
Relationship dependent data will only be communicated for Synchronised, Review or Accept status in the Synchronisation List. |
Primary |
| REQ-23 |
Events
that can trigger notifications are: - Publication of new data / change
of publication - Change of published Catalogue Item / Party / Partner
Profile - Change of owner, rights - Subscription - Synchronisation List
- Confirmation/ Rejection - Request for Notification - Any successful
matching process |
Primary |
| REQ-24 |
Notifications
must NOT be sent in the following cases since data is not yet public
and validated information: - Data load (add, change, etc…) -
Data validation - Registration of new Catalogue Item |
Primary |
| REQ-29 |
The confirmation process must take place in the home data pool of the data recipient. |
Primary |
| REQ-32 |
Acknowledgement Reason codes must be unique. |
Primary |
| REQ-70 |
Data recipient will continue to receive updates until he rejects the data. |
Secondary |
| REQ-72 |
Reject is optional: in the absence of confirmation & reject, the data recipient would still receive updates. |
Secondary |
| REQ-77 |
Filtering out rejected data is a source data pool responsibility. |
Primary |
| REQ-78 |
Subscription: for every matching GTIN, independently from its level, all hierarchies will be returned. |
Primary |
| REQ-79 |
Synchronisation
list: - Includes every GTIN id (GTIN+GLN+TM) that needs to be
synchronised - Can be a result of the Confirmation process - All
GTIN’s equal or lower in the hierarchy than the GTIN confirmed
will be returned |
Primary |
| REQ-80 |
Rejection
at the highestlevel of a hierarchy will trigger the rejection of all
GTIN’s in the hierarchy of the rejected GTIN. |
Primary |
| REQ-81 |
Synchronisation
List is only synchronised between the involved source and recipient
data pools for applicable data: synchronisation list is built based on
confirmation received by a source data pool and nothing else. |
Primary |
| REQ-88 |
The
matching process is owned and developed by each source data pool in
order to trigger data distribution based on publication and
subscription data. |
Primary |
| REQ-89 |
The
matching process can be triggered either by publication, subscription
or as a scheduled event. It is valid for all subscription types
(including synchronisation list) and all publication types. |
Primary |
| REQ-90 |
For
a given subscription (create/update): - the matching process identifies
Items published to the GLN or TM of the subscription owner. - for each
item, a notification is created including all dependent hierarchies. -
for a synchronisation list, the hierarchy information included in the
notification, will be limited to the GTIN's maintained in the
Synchronisation list. - The notification is sent to the home data pool
of the data recipient. |
Primary |
| REQ-98 |
Note : rejection should not remove data previously authorised, for instance in a different hierarchy. |
Primary |
| REQ-99 |
The
Global Registry functionality requirements can be summarised as
follows: - Enable data synchronisation - Validation, registration and
subscription functions - Enable global validation - Checking compliance
with basic EAN.UCC rules related to the format of a GTIN/GLN and
ensuring the uniqueness of the data that is being registered - Enable
global search functionality that does not require full duplication of
data in the Global Registry. |
Primary |
| REQ-100 |
The
Global Registry is involved in the following functions and/or business
cases as defined in the Item Synchronisation detailed requirements: -
Validation - Registration - Subscription - Global Search |
Primary |
| REQ-109 |
A
Data Recipient requests that it receive a “notification”
when a specific event occurs that meets the Recipients criteria
(selective on sources, categories, etc). This is subject to the
recipient’s access to information as controlled by the data
source through its source data pool. |
Primary |
| REQ-110 |
After
a Subscription is created, the Global Registry will then disseminate
relevant subscriptions to appropriate Source Data Pools (current and
future new data pools). |
Primary |
| REQ-111 |
Registry
requirements for subscription are: - Receive and store subscriptions -
Provide subscription acknowledgement - Matching process of
subscriptions with Source Data Pools - Forward subscriptions |
Primary |
| REQ-123 |
Recipient maintains a subscription, including the "Reload" flag. |
Primary |
| REQ-124 |
The notification triggered by a subscription must also carry the "Reload" flag value. |
Primary |
| REQ-126 |
If
a new Reload is needed, the Recipient must delete the previous Reload
Subscription, then create a new Subscription with the "Reload" flag set. |
Primary |
| REQ-128 |
Source Data Pools must send notifications based on matching publications and subscriptions. |
Primary |
| REQ-129 |
GTIN
and Category are mutually exclusive subscription criteria as the
Category is uniquely defined for a given GTIN, independently from the
GLN and from the TM. |
Primary |
| REQ-132 |
The
events that can trigger the distribution of a subscription are: -
new/updated registration: check existing subscriptions, if new data
pools are found : distribute subscriptions - new subscription: check
existing registrations, if new data pools are found: distribute
subscriptions - delete subscriptions: distribute “delete”
to source data pools where subscription had been sent |
Primary |
| REQ-133 |
Subscriptions cannot be updated, they are created or deleted. |
Secondary |
| REQ-134 |
Subscriptions must be stored in the recipient’s data pool. |
Primary |
| REQ-135 |
For
every subscription, the Registry must store the GLN of the Source Data
Pool to which the subscription was sent and when it was sent. |
Primary |
| REQ-136 |
Ability
to identify new or updated registered Catalogue Items that match a
subscription and forward the subscription to the Source Data Pool. |
Primary |
| REQ-137 |
Match new subscriptions with registered Catalogue Items and forward the subscription to the Source Data Pool. |
Primary |
| REQ-139 |
SubscriptionWho : Data Recipient = target GLNWhat : Any combination of GTIN, GLN, TM and Category |
Primary |
| REQ-141 |
Deletion
of a Subscription stops New Catalogue Items from being sent to RDP,
but, doesn't stop Catalogue Items already in the Synchronisation List
from being updated. |
Secondary |
| REQ-142 |
Request
for Notification is not retained in the Global Registry and acts like a
Subscription that is applied to the Synchronisation List, then deleted
(no New Catalogue Item data will be sent). |
Primary |
| REQ-143 |
"Reload" flag is passed through to Recipient. |
Primary |
| REQ-144 |
Request
for publication (subscription) resets the reject flag if catalogue Item
has been previously rejected and reactivate the subscription. |
Primary |
| REQ-145 |
The request for publication subscription is only executed once. |
Primary |
| REQ-146 |
Subscriptions
are passed from global Registry to data pools just once. The Global
Registry passes along to the source data pool matching subscriptions in
the entirety, rather than replicating for each GTIN registered. |
Primary |
| REQ-147 |
Request
for notification publication (subscription) resets the reject flag if
the Catalogue Item has been previously rejected and reactivate the
subscription. |
Primary |
| REQ-148 |
The "Reload" attribute will contain a Boolean value (TRUE or FALSE). |
Primary |
| REQ-149 |
Upon
execution of an item data notification, the source data pool will pass
along the value of this attribute within the message for the recipient
to properly route the inbound message. After executing the item data
notification, the source data pool will |
Primary |
| REQ-150 |
The
team identified the need for an additional process to be known as
“Request for Notification”. The Request for Notification is
originated by the requesting data recipient, through the recipient data
pool, to the Global Registry and forwarded to the so |
Primary |
| REQ-151 |
The
team wanted to reiterate the fact that new subscriptions received by a
source data pool would be executed immediately a single time. |
Primary |
| REQ-152 |
The
ability to set up a subscription and not get an initial full load of
data. She wants to only receive the changes, adds, deletes and new
items that match her subscription. (This is the same as a regular
subscription with the exception of not getting |
Primary |
| REQ-154 |
The Global Registry shall send only once a subscription to a Source Data Pool. |
Primary |
| REQ-156 |
Subscription matches are performed at any level of the hierarchy. The data recipient is sent all hierarchies that match. |
Primary |
| REQ-159 |
Multiple
independent hierarchies can co-exist at the data-pool for an item for
example hierarchy 1 = case A – each A and hierarchy 2 = pallet A
– case A –each A. |
Primary |
| REQ-171 |
The
message identifier (CorrelationInformation:
requestingDocu-mentInstanceIdentifier) at the document header levelfor
the EAN.UCC response and the GDSN Exception must equal
theDocumentIdentification: instanceIdentifier of the originalmessage. |
Primary |
|
|
|
|
|

|
|
|
|
Figure 43 - Remove
Catalogue Item Subscription Activity Diagram |
|
|
|
 |
|
|
|
Figure 44 - Remove
Subscription Sequence Diagram |
|
|
|
|
|
|
|
TOP |
|
|
|
|
|
|
|
16.
Confirm Catalogue Item Data |
|
|
|
 |
|
|
|
|
|
|
|
| Use Case Name |
Confirm Catalogue Item Subscription |
| Traceability Identifier |
UC-26 |
| Use Case Description |
The
Confirm Catalogue Item Data Use Case describes how a Data Recipient
informs the Source Data Pool of its intentions regarding the Catalogue
Item.
The four states that can be communicated are Accepted, Synchronised, Rejected, or Review.Only
a CIC communicated with the status of Rejected will stop the Source
Data Pool from sending updates to the Recipient Data Pool. In the absence of a confirmation, the Source Data Pool will continue to send updates to the Recipient Data Pool.
In the case that the
status of the “Catalogue Confirmation State List” is set to
either “Review” or “Rejected” the Catalogue
Item Confirmation (CIC) Message can include additional information
about the Confirmation back to the Supplier (Data Source). |
| Use Cases Above |
UC-23:Manage Catalogue Item Distribution Criteria |
| Use Cases Below |
None |
| Actors |
Data RecipientRecipient Data Pool (RDP)Source Data Pool (SDP) |
| Performance Goals |
Data Recipient:To inform the Source Data Pool of its intentions regarding the Catalogue Item
RDP:To
posses the necessary information that will allow the RDP and
appropriate Source Data Pools to distribute Catalogue Item Data to the
Recipient.SDP:To identify Data Recipients that are actively using Synchronised Item data. |
| Preconditions |
The Data recipient has received Catalogue Item data. |
| Postconditions |
The RDP and SDP are aware of the Data Recipient’s intentions regarding a specific Catalogue Item.In the case of a reject, the SDP knows not to continue sending updates on the particular Item.
In the event of a CIC
Status of Review or Rejected, the Data Source optionally receives the
confirmation code, description and the comment and understands what
action they need to take to resolve the current situation. |
| Scenario |
Begins when, the Data Recipient sends a Catalogue Item Confirmation to the RDP.
1.The RDP sends a message acknowledgement to the Data Recipient2.The RDP validates the Confirmation message.3.The RDP sends an acknowledgement to the Data Recipient.4.The RDP sends the Catalogue Item Confirmation to the SDP.
Ends when, the SDP receives the Catalogue Item Confirmation.
|
| Alternative Scenario |
ad 2.The Confirmation message is invalid:
2.1.The RDP sends an error message to the Data Recipient specifying the errors in the Confirmation message.
Ends when, the Data Recipient receives the error message
|
| Special Requirements |
None |
| Extension Points |
N/A |
| Requirements Covered |
| ID |
Requirement |
Weight |
| REQ-172 |
When
the status of the “Catalogue Confirmation State List” is
set to either “Review” or “Rejected”, there may
be additional information in the CIC message such as theconfirmation
code, description, and the comment and understands what action they
need to take to resolve the current situation. |
Primary |
| REQ-173 |
This Confirmation Code and Description are joined as a pair |
Primary |
| REQ-174 |
The
CIC message can include multiple Catalogue Item References (GTIN + GLN
+ Target Market) to establish the relationship between the information
communicated and the actual Catalogue Item being referenced. |
Primary |
|
|
|
|
|

|
|
|
|
Figure 45 - Confirm
Catalogue Item Data Activity Diagram |
|
|
|
 |
|
|
|
Figure 46
- Catalogue Item Data Sequence Diagram |
|
|
|
|
|
|
|
TOP |
|
|
|
|
|
|
|
17. Request
Catalogue
Item Data |
|
|
|
 |
|
|
|
Figure 47
- Request Catalogue Item Data Use Case Diagram |
|
|
|
|
|
|
|
| Use Case Name |
Request Catalogue Item Data |
| Traceability Identifier |
UC-48 |
| Use Case Description |
The
Request Catalogue Item Data Use Case describes how a Data Recipient
informs the Source Data Pool to resend certain Catalogue Item data.This Use Case makes use of the Request for Catalogue Item Notification message.
This request is identical to a
subscription with the difference being that the Global Registry will
not retain the message once all relevant Source Data Pools receive the
message.A special case of the Request is when the Data Recipient includes the “reload” flag in the message.This flag is attached to the resultant Catalogue Item Notification. |
| Use Cases Above |
UC-23:Manage Catalogue Item Distribution Criteria |
| Use Cases Below |
None |
| Actors |
Data RecipientRecipient Data Pool (RDP) |
| Performance Goals |
Data Recipient: To inform the Source Data Pool that it Would like certain Catalogue Item data to be resent.
RDP: To
posses the necessary information that will allow the RDP and
appropriate Source Data Pools to distribute Catalogue Item Data to the
Recipient. |
| Preconditions |
The Data recipient has received Catalogue Item data. |
| Postconditions |
The RDP is aware that certain Catalogue Item data is to be resent to the Data Recipient. |
| Scenario |
Begins when, the Data Recipient sends a RequestForCatalogueItemNotification to the RDP.
1.The RDP sends a message acknowledgement to the Data Recipient2.The RDP validates the request message.3.The RDP sends an acknowledgement to the Data Recipient.
Ends when, the Data Recipient receives the acknowledgement.
|
| Alternative Scenario |
ad 2.The request message is invalid:
2.1.The RDP sends an error message to the Data Recipient specifying the errors in the original message.
Ends when, the Data Recipient receives the error message
|
| Special Requirements |
|
| Extension Points |
N/A |
| Requirements Covered |
| REQ-166 |
A
Request for Catalogue Item Notification with the isReload set to false
will result in items being re-sent whether they were previously
rejected or not. The Sync List will be reset. This is only valid for
items that have previously been sent to the data recipient.
The CIN response will have the following values:
- documentStatus= Original
- isReload = False
- Command= Add
|
Primary |
| REQ-167 |
A
Request for Catalogue Item Notifcation with the isReload set to true
will result in only items not previously rejected being re-sent. The
Sync List is not reset.
The CIN response will have the following values:
- documentStatus= Copy
- isReload = True
- Command= Add
|
Primary |
| REQ-168 |
The
Document Status of the RFCIN command is ignored for the purposes of
determining its impact on the sync list and the status of the CIN that
is generated. |
Primary |
| REQ-171 |
The
message identifier (CorrelationInformation:
requestingDocu-mentInstanceIdentifier) at the document header levelfor
the EAN.UCC response and the GDSN Exception must equal
theDocumentIdentification: instanceIdentifier of the originalmessage. |
Primary |
|
|
|
|
|

|
|
|
|
Figure 48 -
Catalogue Item Data Activity Diagram |
|
|
|
 |
|
|
|
Figure 49 - Request
Catalogue Item Data Sequence Diagram |
|
|
|
|
|
|
|
TOP |
|
|
|
|
|
|
|
18. Distribute
Subscription Data |
|
|
|
 |
|
|
|
Figure 50 -
Distribute Subscription Data Use Case Diagram |
|
|
|
|
|
|
|
| Use Case Name |
Distribute Subscription Data |
| Traceability Identifier |
UC-35 |
| Use Case Description |
The
Distribute Subscription Data Use Case describes how new and Delete
Subscription messages are propagated throughout the Data
Synchronisation system. |
| Use Cases Above |
UC-23:Manage Catalogue Item Distribution Criteria |
| Use Cases Below |
None |
| Actors |
Data RecipientRecipient Data Pool (RDP)Global RegistrySource Data Pool (SDP)Data Source |
| Performance Goals |
Data Recipient: To share Subscriptions and removal of Subscriptions with the appropriate Source Data Pools and Data Sources.RDP: To
posses the necessary information that will allow the RDP and
appropriate Source Data Pools to distribute Catalogue Item Data to the
Recipient.
Global Registry: To propagate Subscriptions to appropriate Data Pools.SDP: To posses the necessary information that will allow the SDP to distribute Catalogue Item Data to the Recipient (via their RDP).Data Source: To keep track of current and potential customer’s usage of Catalogue Item Data. |
| Preconditions |
The Data recipient has either created or deleted a Subscription in their Recipient Data Pool. |
| Postconditions |
The Subscription or delete subscription message is propagated to the Registry and proper Source Data Pools and Data Sources. |
| Scenario |
Begins
when, the Recipient Data Pool receives a Subscription or Delete
Subscription message from a Data Recipient and has validated it.
1.The RDP sends the Add/Delete Subscription to the Global Registry.2.The Global Registry validates the message.3.The Global Registry matches the subscription to Catalogue Item data in the Registry.4.The Global Registry sends the Add/Delete Subscription to the matching SDP5.The SDP sends the Add/Delete Subscription to the appropriate Data Source
Ends when, the Data Source acknowledges the Subscription message.
|
| Alternative Scenario |
ad 1.A new Catalogue Item is added to the Registry:1.1The Global Registry matches the new Catalogue Item against existing Subscriptions.1.2The Global Registry Sends all matching Subscriptions to the SDP of the new Catalogue Item.1.3The SDP forwards the Subscription to the Data Source that Published the Catalogue Item.Ends when, the Data Source sends an acknowledgement of the Subscription
ad 2.The Subscription fails validation at the Registry:
2.1.The Global Registry sends an error message to the RDP.2.2.The RDP sends an error message to the Data Recipient.
Ends when, the Data Recipient receives the error message
|
| Special Requirements |
|
| Extension Points |
N/A |
|
Requirements Covered
|
| ID |
Requirement |
Weight |
| REQ-12 |
Every
command needs a response and is handled according to the agreement
between the parties involved. In the inter-operable network,
acknowledgement messages are standardised and may contain the following
information: - Confirmation of message receipt- Success / Failure of
processing (syntax and content)- Reason for failure, with a code number
and text message unique assigned to each failure |
Primary |
| REQ-14 |
A
subscription must be able to be maintained on the following levels : -
GTIN - GLN of Data Source - Target Market - Lowest level of EAN.UCC
Classification or any combination of these 4 elements. |
Primary |
| REQ-15 |
With
the set up of a subscription, a Data Recipient sets a profile to
receive ongoing updates of the matching data (including all
hierarchies, independently from the level subscribed on). |
Primary |
| REQ-17 |
Subscriptions must be created by data recipients in their Recipients Data Pool and sent to the Global Registry. |
Primary |
| REQ-18 |
A new Source Data Pool will get their relevant subscriptions as soon as they start registering their GTIN’s. |
Secondary |
| REQ-19 |
The system must maintain detailed subscription lists. |
Primary |
| REQ-20 |
Synchronisation Lists must include every Catalogue Item (GTIN+GLN+TM) that needs to be synchronised. |
Primary |
| REQ-21 |
If
a Catalogue Item is "Confirmed of Synchronisation" then all Catalogue
items below in the Catalogue Item Hierarchy shall be included in the
Synchronisation list. |
Primary |
| REQ-22 |
Relationship dependent data will only be communicated for Synchronised, Review or Accept status in the Synchronisation List. |
Primary |
| REQ-23 |
Events
that can trigger notifications are: - Publication of new data / change
of publication - Change of published Catalogue Item / Party / Partner
Profile - Change of owner, rights - Subscription - Synchronisation List
- Confirmation/ Rejection - Request for Notification - Any successful
matching process |
Primary |
| REQ-24 |
Notifications
must NOT be sent in the following cases since data is not yet public
and validated information: - Data load (add, change, etc…) -
Data validation - Registration of new Catalogue Item |
Primary |
| REQ-25 |
The
Data Distribution, which is the movement of data from one entity to
another, must be handled through a specific notification type. |
Primary |
| REQ-29 |
The confirmation process must take place in the home data pool of the data recipient. |
Primary |
| REQ-32 |
Acknowledgement Reason codes must be unique. |
Primary |
| REQ-69 |
Data recipient maintains subscription. |
Primary |
| REQ-70 |
Data recipient will continue to receive updates until he rejects the data. |
Primary |
| REQ-72 |
Reject is optional: in the absence of confirmation & reject, the data recipient would still receive updates. |
Primary |
| REQ-73 |
Confirmed GTIN: - subscription: go to synchronisation list - synchronisation list: no action required |
Primary |
| REQ-74 |
Only new products matching the initial subscription will be distributed to avoid resending data that was previously rejected. |
Secondary |
| REQ-78 |
Subscription: for every matching GTIN, independently from its level, all hierarchies will be returned. |
Primary |
| REQ-79 |
Synchronisation
list: - Includes every GTIN id (GTIN+GLN+TM) that needs to be
synchronised - Can be a result of the Confirmation process - All
GTIN’s equal or lower in the hierarchy than the GTIN confirmed
will be returned |
Primary |
| REQ-80 |
Rejection
at the highestlevel of a hierarchy will trigger the rejection of all
GTIN’s in the hierarchy of the rejected GTIN. |
Primary |
| REQ-81 |
Synchronisation
List is only synchronised between the involved source and recipient
data pools for applicable data: synchronisation list is built based on
confirmation received by a source data pool and nothing else. |
Primary |
| REQ-88 |
The
matching process is owned and developed by each source data pool in
order to trigger data distribution based on publication and
subscription data. |
Primary |
| REQ-89 |
The
matching process can be triggered either by publication, subscription
or as a scheduled event. It is valid for all subscription types
(including synchronisation list) and all publication types. |
Primary |
| REQ-90 |
For
a given subscription (create/update): - the matching process identifies
Items published to the GLN or TM of the subscription owner. - for each
item, a notification is created including all dependent hierarchies. -
for a synchronisation list, the hierarchy information included in the
notification, will be limited to the GTIN's maintained in the
Synchronisation list. - The notification is sent to the home data pool
of the data recipient. |
Primary |
| REQ-99 |
The
Global Registry functionality requirements can be summarised as
follows: - Enable data synchronisation - Validation, registration and
subscription functions - Enable global validation - Checking compliance
with basic EAN.UCC rules related to the format of a GTIN/GLN and
ensuring the uniqueness of the data that is being registered - Enable
global search functionality that does not require full duplication of
data in the Global Registry. |
Primary |
| REQ-100 |
The
Global Registry is involved in the following functions and/or business
cases as defined in the Item Synchronisation detailed requirements: -
Validation - Registration - Subscription - Global Search |
Primary |
| REQ-109 |
A
Data Recipient requests that it receive a “notification”
when a specific event occurs that meets the Recipients criteria
(selective on sources, categories, etc). This is subject to the
recipient’s access to information as controlled by the data
source through its source data pool. |
Primary |
| REQ-110 |
After
a Subscription is created, the Global Registry will then disseminate
relevant subscriptions to appropriate Source Data Pools (current and
future new data pools). |
Primary |
| REQ-111 |
Registry
requirements for subscription are: - Receive and store subscriptions -
Provide subscription acknowledgement - Matching process of
subscriptions with Source Data Pools - Forward subscriptions |
Primary |
| REQ-127 |
The Global Registry must distribute Subscriptions only to relevant Source Data Pools. |
Secondary |
| REQ-129 |
GTIN
and Category are mutually exclusive subscription criteria as the
Category is uniquely defined for a given GTIN, independently from the
GLN and from the TM. |
Primary |
| REQ-130 |
GTIN,
GLN (of Data Source), Target Market and Classification must be stored
in the Global Registry, and are linked to the Source Data Pool(s) where
the data can be found. For instance, if given a GTIN, the Global
Registry will be able to return all the data pools where data can be
found on that GTIN, independently from the GLN of the Data Source, the
Target Market or the Category. |
Secondary |
| REQ-131 |
The distribution of subscriptions is either a scheduled event or is triggered by another event. |
Secondary |
| REQ-132 |
The
events that can trigger the distribution of a subscription are: -
new/updated registration: check existing subscriptions, if new data
pools are found : distribute subscriptions - new subscription: check
existing registrations, if new data pools are found: distribute
subscriptions - delete subscriptions: distribute “delete”
to source data pools where subscription had been sent |
Secondary |
| REQ-133 |
Subscriptions cannot be updated, they are created or deleted. |
Primary |
| REQ-134 |
Subscriptions must be stored in the recipient’s data pool. |
Secondary |
| REQ-135 |
For
every subscription, the Registry must store the GLN of the Source Data
Pool to which the subscription was sent and when it was sent. |
Secondary |
| REQ-136 |
Ability
to identify new or updated registered Catalogue Items that match a
subscription and forward the subscription to the Source Data Pool. |
Secondary |
| REQ-137 |
Match new subscriptions with registered Catalogue Items and forward the subscription to the Source Data Pool. |
Secondary |
| REQ-139 |
SubscriptionWho : Data Recipient = target GLNWhat : Any combination of GTIN, GLN, TM and Category |
Secondary |
| REQ-141 |
Deletion
of a Subscription stops New Catalogue Items from being sent to RDP,
but, doesn't stop Catalogue Items already in the Synchronisation List
from being updated. |
Primary |
| REQ-142 |
Request
for Notification is not retained in the Global Registry and acts like a
Subscription that is applied to the Synchronisation List, then deleted
(no New Catalogue Item data will be sent). |
Secondary |
| REQ-143 |
"Reload" flag is passed through to Recipient. |
Primary |
| REQ-144 |
Request
for publication (subscription) resets the reject flag if catalogue Item
has been previously rejected and reactivate the subscription. |
Primary |
| REQ-145 |
The request for publication subscription is only executed once. |
Primary |
| REQ-146 |
Subscriptions
are passed from global Registry to data pools just once. The Global
Registry passes along to the source data pool matching subscriptions in
the entirety, rather than replicating for each GTIN registered. |
Secondary |
| REQ-147 |
Request
for notification publication (subscription) resets the reject flag if
the Catalogue Item has been previously rejected and reactivates the
subscription. |
Secondary |
| REQ-148 |
The "Reload" attribute will contain a Boolean value (TRUE or FALSE). |
Secondary |
| REQ-149 |
Upon
execution of an item data notification, the source data pool will pass
along the value of this attribute within the message for the recipient
to properly route the inbound message. After executing the item data
notification, the source data pool will |
Secondary |
| REQ-150 |
The
team identified the need for an additional process to be known as
“Request for Notification”. The Request for Notification is
originated by the requesting data recipient, through the recipient data
pool, to the Global Registry and forwarded to the so |
Secondary |
| REQ-151 |
The
team wanted to reiterate the fact that new subscriptions received by a
source data pool would be executed immediately a single time. |
Secondary |
| REQ-152 |
The
ability to set up a subscription and not get an initial full load of
data. She wants to only receive the changes, adds, deletes and new
items that match her subscription. (This is the same as a regular
subscription with the exception of not getting |
Secondary |
| REQ-154 |
The Global Registry shall send only once a subscription to a Source Data Pool. |
Secondary |
| REQ-156 |
Subscription matches are performed at any level of the hierarchy. The data recipient is sent all hierarchies that match. |
Primary |
| REQ-171 |
The
message identifier (CorrelationInformation:
requestingDocu-mentInstanceIdentifier) at the document header levelfor
the EAN.UCC response and the GDSN Exception must equal
theDocumentIdentification: instanceIdentifier of the originalmessage. |
Primary |
|
|
|
|
|

|
|
|
|
Figure 51 -
Distribute Subscription Data Activity Diagram |
|
|
|
 |
|
|
|
Figure 52 -
Distribute Subscription Data Sequence Diagram |
|
|
|
|
|
|
|
TOP |
|
|
|
|
|
|
|
19. Distribute
Confirmation Data |
|
|
|
 |
|
|
|
Figure 53 -
Distribute Confirmation Data Use Case Diagram |
|
|
|
| Use Case Name |
Distribute Confirmation Data |
| Traceability Identifier |
UC-43 |
| Use Case Description |
The
Distribute Confirmation Data Use Case describes how the Data Recipient
informs the Source Data pool of the status of an individual Catalogue
Item Data synchronisation that was the result of a Publication /
Subscription match.Valid values for the status
are: “no value” (continue to send updates),
“Accept” (Data Recipient signals that they are interested
in the Catalogue Item, continue to send updates),
“Synchronised”(Data Recipient signals
that they intend to keep their database synchronised, continue to send
updates) and “Reject” (Data Recipient signals that they are
not interested in the Catalogue Item, do not continue to send updates).
Confirmations are passed to the Source Data Pool from the Recipient Data Pool.
In the case that the
status of the “Catalogue Confirmation State List” is set to
either “Review” or “Rejected” the Catalogue
Item Confirmation (CIC) Message can include additional information
about the Confirmation back to the Supplier (Data Source).
|
| Use Cases Above |
UC-47: Distribute Data Recipient Requests for Catalogue Item Data |
| Use Cases Below |
None |
| Actors |
Data RecipientRecipient Data Pool (RDP)Source Data Pool (SDP) |
| Performance Goals |
Data Recipient: To
prohibit future synchronisations of specific Catalogue Item Data, or,
to notify the Source Data Pool of the Data Recipient’s intentions
regarding the Catalogue Item data.
RDP: To
posses the necessary information that will allow the RDP and
appropriate Source Data Pools to distribute Catalogue Item Data to the
Recipient.
SDP: To posses the necessary information that will allow the SDP to distribute Catalogue Item Data to the Recipient (via their RDP). |
| Preconditions |
The Data recipient has either created a Subscription in their Recipient Data Pool and has received Catalogue Item data. |
| Postconditions |
In the case of a “Rejection”, the Data Recipient no longer receives updates to the specific Catalogue Item.For
all other authorizations, the Source Data Pool is aware of the Data
Recipient’s intentions regarding the Catalogue Item data.
In
the event of a CIC Status of Review or Rejected, the Data Source
optionally receives the confirmation code, description, and the comment
and understands what action they need to take to resolve the current
situation.
|
| Scenario |
Begins when, the Data Recipient sends a Confirmation message to the Recipient Data Pool
1.The RDP sends the Confirmation to the SDP.2.The SDP validates the message.3.The SDP matches the Confirmation with the Recipient’s Synchronisation List.4. A “Reject” Confirmation will stop future publications of the whole hierarchy.5.For all other Confirmations, the SDP applies the change to the Data Recipient Synchronisation List.6.The SDP sends the Confirmation to the Data Source.7.The SDP sends a Confirmation Acknowledgement to the RDP.8.The RDP forwards the Confirmation Acknowledgement to the Data Recipient.
Ends when, the Data Recipient sends an acknowledgement of the Recipient Data Pool’s message.
|
| Alternative Scenario |
ad 2.The Confirmation message does not pass validation:2.1The SDP sends a Confirmation Error message to the RDP.2.2The RDP forwards the Confirmation Error message to the Data Recipient.Ends when, the Data Recipient sends an acknowledgement of the error message |
| Special Requirements |
|
| Extension Points |
N/A |
| Requirements Covered |
| ID |
Requirement |
Weight |
| REQ-12 |
Every
command needs a response and is handled according to the agreement
between the parties involved. In the inter-operable network,
acknowledgement messages are standardised and may contain the following
information: - Confirmation of message receipt- Success / Failure of
processing (syntax and content)- Reason for failure, with a code number
and text message unique assigned to each failure |
Primary |
| REQ-17 |
Subscriptions must be created by data recipients in their Recipients Data Pool and sent to the Global Registry. |
Primary |
| REQ-18 |
A new Source Data Pool will get their relevant subscriptions as soon as they start registering their GTIN’s. |
Primary |
| REQ-20 |
Synchronisation Lists must include every Catalogue Item (GTIN+GLN+TM) that needs to be synchronised. |
Primary |
| REQ-21 |
If
a Catalogue Item is "Confirmed of Synchronisation" then all Catalogue
items below in the Catalogue Item Hierarchy shall be included in the
Synchronisation list. |
Primary |
| REQ-22 |
Relationship dependent data will only be communicated for Synchronised, Review or Accept status in the Synchronisation List. |
Primary |
| REQ-23 |
Events
that can trigger notifications are: - Publication of new data / change
of publication - Change of published Catalogue Item / Party / Partner
Profile - Change of owner, rights - Subscription - Synchronisation List
- Confirmation/ Rejection - Request for Notification - Any successful
matching process |
Primary |
| REQ-24 |
Notifications
must NOT be sent in the following cases since data is not yet public
and validated information: - Data load (add, change, etc…) -
Data validation - Registration of new Catalogue Item |
Primary |
| REQ-25 |
The
Data Distribution, which is the movement of data from one entity to
another, must be handled through a specific notification type. |
Primary |
| REQ-29 |
The confirmation process must take place in the home data pool of the data recipient. |
Secondary |
| REQ-32 |
Acknowledgement Reason codes must be unique. |
Primary |
| REQ-75 |
Updates for confirmed products will be distributed based on the synchronisation list. |
Secondary |
| REQ-76 |
Confirmation
(accept or synchronised) will indicate the data recipient’s
commitment to synchronise the data in its internal systems. |
Secondary |
| REQ-77 |
Filtering out rejected data is a source data pool responsibility. |
Secondary |
| REQ-78 |
Subscription: for every matching GTIN, independently from its level, all hierarchies will be returned. |
Primary |
| REQ-79 |
Synchronisation
list: - Includes every GTIN id (GTIN+GLN+TM) that needs to be
synchronised - Can be a result of the Confirmation process - All
GTIN’s equal or lower in the hierarchy than the GTIN confirmed
will be returned |
Secondary |
| REQ-80 |
Rejection
at the highestlevel of a hierarchy will trigger the rejection of all
GTIN’s in the hierarchy of the rejected GTIN. |
Secondary |
| REQ-81 |
Synchronisation
List is only synchronised between the involved source and recipient
data pools for applicable data: synchronisation list is built based on
confirmation received by a source data pool and nothing else. |
Primary |
| REQ-88 |
The
matching process is owned and developed by each source data pool in
order to trigger data distribution based on publication and
subscription data. |
Primary |
| REQ-89 |
The
matching process can be triggered either by publication, subscription
or as a scheduled event. It is valid for all subscription types
(including synchronisation list) and all publication types. |
Primary |
| REQ-90 |
For
a given subscription (create/update): - the matching process identifies
Items published to the GLN or TM of the subscription owner. - for each
item, a notification is created including all dependent hierarchies. -
for a synchronisation list, the hierarchy information included in the
notification, will be limited to the GTIN's maintained in the
Synchronisation list. - The notification is sent to the home data pool
of the data recipient. |
Primary |
| REQ-94 |
Confirmation
is not mandatory and can provide 4 outcomes:1.Synchronised: data is
integrated, in synch2.Accept: Data has been received by the data
recipient, but no business decision has been made on the data.
3.Reject: data will no longer be synchronised or updates will no longer
be provided.4. Review: request to the data source to review their data
and take action (applies to adds & changes) because the data
recipient has received discrepant datawhich they cannot synchronise.
If no confirmation is sent, data updates will continue to be provided
until the data recipient accepts, rejects or updates the subscription,
or until the data source changes the publication. For a new Catalogue
Item the same confirmation can be used. |
Secondary |
| REQ-95 |
The list of authorised values for the confirmation message does not imply a sequence in which the message has to be used. |
Secondary |
| REQ-96 |
The
same “confirmation” message can be used to stop
synchronising a Catalogue Item. In that case, the “Reject”
status will be used. |
Secondary |
| REQ-97 |
“Synchronised”
status is sent once – parties are assumed to be in synch unless a
reject/review status is exchanged. |
Secondary |
| REQ-98 |
Note : rejection should not remove data previously authorised, for instance in a different hierarchy. |
Secondary |
| REQ-99 |
The
Global Registry functionality requirements can be summarised as
follows: - Enable data synchronisation - Validation, registration and
subscription functions - Enable global validation - Checking compliance
with basic EAN.UCC rules related to the format of a GTIN/GLN and
ensuring the uniqueness of the data that is being registered - Enable
global search functionality that does not require full duplication of
data in the Global Registry. |
Primary |
| REQ-100 |
The
Global Registry is involved in the following functions and/or business
cases as defined in the Item Synchronisation detailed requirements: -
Validation - Registration - Subscription - Global Search |
Primary |
| REQ-109 |
A
Data Recipient requests that it receive a “notification”
when a specific event occurs that meets the Recipients criteria
(selective on sources, categories, etc). This is subject to the
recipient’s access to information as controlled by the data
source through its source data pool. |
Primary |
| REQ-110 |
After
a Subscription is created, the Global Registry will then disseminate
relevant subscriptions to appropriate Source Data Pools (current and
future new data pools). |
Primary |
| REQ-111 |
Registry
requirements for subscription are: - Receive and store subscriptions -
Provide subscription acknowledgement - Matching process of
subscriptions with Source Data Pools - Forward subscriptions |
Primary |
| REQ-127 |
The Global Registry must distribute Subscriptions only to relevant Source Data Pools. |
Primary |
| REQ-129 |
GTIN
and Category are mutually exclusive subscription criteria as the
Category is uniquely defined for a given GTIN, independently from the
GLN and from the TM. |
Primary |
| REQ-130 |
GTIN,
GLN (of Data Source), Target Market and Classification must be stored
in the Global Registry, and are linked to the Source Data Pool(s) where
the data can be found. For instance, if given a GTIN, the Global
Registry will be able to return all the data pools where data can be
found on that GTIN, independently from the GLN of the Data Source, the
Target Market or the Category. |
Primary |
| REQ-131 |
The distribution of subscriptions is either a scheduled event or is triggered by another event. |
Primary |
| REQ-132 |
The
events that can trigger the distribution of a subscription are: -
new/updated registration: check existing subscriptions, if new data
pools are found : distribute subscriptions - new subscription: check
existing registrations, if new data pools are found: distribute
subscriptions - delete subscriptions: distribute “delete”
to source data pools where subscription had been sent |
Primary |
| REQ-133 |
Subscriptions cannot be updated, they are created or deleted. |
Primary |
| REQ-134 |
Subscriptions must be stored in the recipient’s data pool. |
Primary |
| REQ-135 |
For
every subscription, the Registry must store the GLN of the Source Data
Pool to which the subscription was sent and when it was sent. |
Primary |
| REQ-136 |
Ability
to identify new or updated registered Catalogue Items that match a
subscription and forward the subscription to the Source Data Pool. |
Primary |
| REQ-137 |
Match new subscriptions with registered Catalogue Items and forward the subscription to the Source Data Pool. |
Primary |
| REQ-139 |
SubscriptionWho : Data Recipient = target GLNWhat : Any combination of GTIN, GLN, TM and Category |
Primary |
| REQ-141 |
Deletion
of a Subscription stops New Catalogue Items from being sent to RDP,
but, doesn't stop Catalogue Items already in the Synchronisation List
from being updated. |
Primary |
| REQ-142 |
Request
for Notification is not retained in the Global Registry and acts like a
Subscription that is applied to the Synchronisation List, then deleted
(no New Catalogue Item data will be sent). |
Primary |
| REQ-143 |
"Reload" flag is passed through to Recipient. |
Primary |
| REQ-144 |
Request
for publication (subscription) resets the reject flag if catalogue Item
has been previously rejected and reactivate the subscription. |
Primary |
| REQ-145 |
The request for publication subscription is only executed once. |
Primary |
| REQ-146 |
Subscriptions
are passed from global Registry to data pools just once. The Global
Registry passes along to the source data pool matching subscriptions in
the entirety, rather than replicating for each GTIN registered. |
Primary |
| REQ-147 |
Request
for notification publication (subscription) resets the reject flag if
the Catalogue Item has been previously rejected and reactivates the
subscription. |
Primary |
| REQ-148 |
The "Reload" attribute will contain a Boolean value (TRUE or FALSE). |
Primary |
| REQ-149 |
Upon
execution of an item data notification, the source data pool will pass
along the value of this attribute within the message for the recipient
to properly route the inbound message. After executing the item data
notification, the source data pool will |
Primary |
| REQ-150 |
The
team identified the need for an additional process to be known as
“Request for Notification”. The Request for Notification is
originated by the requesting data recipient, through the recipient data
pool, to the Global Registry and forwarded to the so |
Primary |
| REQ-151 |
The
team wanted to reiterate the fact that new subscriptions received by a
source data pool would be executed immediately a single time. |
Primary |
| REQ-152 |
The
ability to set up a subscription and not get an initial full load of
data. She wants to only receive the changes, adds, deletes and new
items that match her subscription. (This is the same as a regular
subscription with the exception of not getting |
Primary |
| REQ-154 |
The Global Registry shall send only once a subscription to a Source Data Pool. |
Primary |
| REQ-156 |
Subscription matches are performed at any level of the hierarchy. The data recipient is sent all hierarchies that match. |
Primary |
| REQ-157 |
Confirmations will be done at the highest level of the published trade item hierarchy. |
Primary |
| REQ-158 |
Top
of hierarchy is assumed to be the largest available unit determined by
the data source. Defined as the GTIN of the highest published item in
the hierarchy. |
Primary |
| REQ-160 |
Catalogue
Item Confirmations (CIC) for the item at the top level of the hierarchy
with a status of reject will stop publications of the whole hierarchy. |
Primary |
| REQ-161 |
A
CIC with a status of Rejected, Accepted, Review or Synchronised sent
for an item below the highest level of the published item hierarchy
will result in a CIC failure. |
Primary |
| REQ-171 |
The
message identifier (CorrelationInformation:
requestingDocu-mentInstanceIdentifier) at the document header levelfor
the EAN.UCC response and the GDSN Exception must equal
theDocumentIdentification: instanceIdentifier of the originalmessage. |
Primary |
| Req 172 |
When
the status of the “Catalogue Confirmation State List” is
set to either “Review” or “Rejected”, there may
be additional information in the CIC message such as theconfirmation
code, description, and the comment and understands what action they
need to take to resolve the current situation. |
Primary |
| Req 173 |
This Confirmation Code and Description are joined as a pair |
Primary |
| Req 174 |
The
CIC message can include multiple Catalogue Item References (GTIN + GLN
+ Target Market) to establish the relationship between the information
communicated and the actual Catalogue Item being referenced |
Primary |
|
|
|
|
|
 |
|
|
|
Figure 54 -
Distribute Confirmation Data Activity Diagram |
|
|
|
 |
|
|
|
Figure 55 -
Distribute Catalogue Item Confirmation Sequence
Diagram |
|
|
|
|
|
|
|
TOP |
|
|
|
|
|
|
|
20. Distribute
Request for Catalogue Item
Notification |
|
|
|
 |
|
|
|
Figure 56 -
Distribute Request for Catalogue Item Notification Use
Case Diagram |
|
|
|
|
|
|
|
| Use Case Name |
Distribute Request for Catalogue Item Notification |
| Traceability Identifier |
UC-22 |
| Use Case Description |
The
Distribute Request for Catalogue Item Notification Use Case describes
how the message is passed from Data Recipient through to the Source
Data Pool and Data Source.
This Use Case makes use of the RequestForCatalogueItemNotification
message.This message is identical to the CatalogueItemSubscription with
the addition of a “reload” flag.This reload flag is later
attached to the resultant CatalogueItemNotification message to allow
the Data Recipient to process it differently than a normal
notification.The RequestForCatalogueItemNotification message is also
different from a Subscription in that it is not retained in the Global
Registry after the Source Data Pools have received it. |
| Use Cases Above |
UC-47: Distribute Data Recipient Requests for Catalogue Item Data |
| Use Cases Below |
None |
| Actors |
Data RecipientRecipient Data Pool (RDP)Global RegistrySource Data Pool (SDP)Data Source |
| Performance Goals |
Data Recipient: To request that previously sent Catalogue Item data be resent.
RDP: To posses the necessary information that will allow the RDP and
appropriate Source Data Pools to distribute Catalogue Item Data to the
Recipient.
Global Registry: To forward to appropriate Source Data Pools all requests from Data Recipients.
SDP: To posses the necessary information that will allow the SDP
to distribute Catalogue Item Data to the Recipient (via their RDP).
Data Source: To be aware of all usages of supplied data. |
| Preconditions |
The Data recipient has created a Subscription in their Recipient Data Pool and has received Catalogue Item data. |
| Postconditions |
The request is passed to the Global Registry, appropriate Source Data pools and the Data Source. |
| Scenario |
Begins when, the Data Recipient sends a Request message to the Recipient Data Pool
1.The RDP sends the Request to the Global Registry.2.The Global Registry matches the Request with a list of Source Data Pools.3.The Global Registry sends the request to the appropriate Source Data Pool.4.The Source Data Pool sends a copy of the request to the Data Source. |
| Alternative Scenario |
|
| Special Requirements |
|
| Extension Points |
N/A |
| Requirements Covered |
|
|
|
|
|

|
|
|
|
Figure 57 -
Distribute Request for Catalogue Item Notification Activity Diagram |
|
|
|
 |
|
|
|
Figure 58 -
Distribute Request for Catalogue Item Notification
Sequence Diagram |
|
|
|
|
|
|
|
TOP |
|
|
|
|
|
|
|
21. Create
Synchronisation List |
|
|
|
 |
|
|
|
Figure 59 - Create
Synchronisation List Use Case Diagram |
|
|
|
|
|
|
|
| Use Case Name |
Create Synchronisation List |
| Traceability Identifier |
UC-45 |
| Use Case Description |
The
Synchronisation list is the sole means by which a Source Data Pool
determines the Catalogue Item Data that is to be sent to a Data
Recipient (via the Recipient’s Recipient Data Pool).
The Synchronisation list is created based on Publications, Subscriptions and Confirmations.Each one of these pares down the matches between Catalogue Item and Recipient.The
delta, or net positive matches are placed into the Synchronisation
List, which is used by the “Distribute Catalogue Item Data from
SDP to RDP” (UC-37) and “Distribute Catalogue Item Data
from RDP to Data Recipient” (UC-38) Use Cases.
UC-37 will use the Synchronisation List to send Recipient bound Catalogue Item Data to the Recipient Data Pool.UC-38 will then pass all appropriate Catalogue Item data to the Recipient.
|
| Use Cases Above |
UC-23:Manage Catalogue Item Distribution Criteria |
| Use Cases Below |
None |
| Actors |
Source Data Pool (SDP) |
| Performance Goals |
SDP: To determine which Recipient should be sent what Catalogue Item Hierarchy data. |
| Preconditions |
Publications, Subscriptions and Confirmations exist in the Source Data Pool. |
| Postconditions |
The
Synchronisation List is created and able to be used to direct the
Source Data Pool in moving appropriate Catalogue Item data to Recipient
Data Pools. |
| Scenario |
Begins
when, the Source Data Pool receives an add or delete of a Publication,
an Add of a Subscription, Confirmation ,or a Add, Change, Correct of an
Catalogue Item Hierarchy message.
1.The SDP Identifies all GTIN's of publications to a target market2.The SDP Identifies all GTIN's of Subscriptions by Recipient's Target Market3.Subset all GTIN's that are in both lists4.Remove GTINs that have been rejected by the Recipient5.Add Source GLN, RDP GLN, Recipient GLN, Source GTIN and Source TM to the Synchronisation List
Ends when, Synchronisation Listed is complete.
|
| Alternative Scenario |
None |
| Special Requirements |
|
| Extension Points |
N/A |
| Requirements Covered |
|
|
|
|
|
 |
|
|
|
Figure 60 - Create
Synchronisation List Activity Diagram |
|
|
|
|
|
|
|
TOP |
|
|
|
|
|
|
|
22. Distribute
Catalogue Item Data from SDP to
RDP |
|
|
|
 |
|
|
|
Figure 61 -
Distribute
Catalogue Item Data from SDP to RDP Use Case Diagram
|
|
|
|
| Use Case Name |
Distribute Catalogue Item Data from SDP to RDP |
| Traceability Identifier |
UC-37 |
| Use Case Description |
Using the Distribution Criteria, the Catalogue Item Data are distributed from SDP to RDP. |
| Use Cases Above |
UC-29:Distribute Catalogue Item Data |
| Use Cases Below |
UC-xx:Filter Catalogue Item Data at SDPUC-xx:Send Catalogue Item Data to RDPUC-xx:Filter Catalogue Item Data at RDP |
| Actors |
Source Data Pool (SDP)Recipient Data Pool (RDP) |
| Performance Goals |
SDP: Distribute Catalogue Item Data to the RDP based on the Distribution Criteria.
RDP: To receive Catalogue Item Data that complies with the Distribution Criteria. |
| Preconditions |
Publications are available at the SDP.Subscriptions
are communicated to the SDP. The SDP has the updated Synchronisation
list based on the subscriptions and Confirmations received.The SDP knows which RDP needs to receive Catalogue Item Data for each Recipient. |
| Postconditions |
RDP has received Catalogue Item Data that comply with the Distribution Criteria. |
| Scenario |
Begins when, the SDP filters the Catalogue Item Data using the Synchronisation list.
- The SDP sends filtered Catalogue Item Data to the RDP.
- The RDP receives the Catalogue Item Data.
Ends when,
the RDP uses the Subscription and Confirmations of the recipient to
filter the Catalogue Item Data to identify any Catalogue Items that
should not have been sent. |
| Alternative Scenario |
None at this summary level |
| Special Requirements |
|
| Extension Points |
N/A |
| Requirements Covered |
| ID |
Requirement |
Weight |
| REQ-12 |
Every
command needs a response and is handled according to the agreement
between the parties involved. In the inter-operable network,
acknowledgement messages are standardised and may contain the following
information: - Confirmation of message receipt- Success / Failure of
processing (syntax and content)- Reason for failure, with a code number
and text message unique assigned to each failure |
Primary |
| REQ-13 |
The
Data Source grants visibility of item, party and partner profiles
including party capabilities data to a given list of parties
(identified by their GLNs) or to all parties in a given Target Market. |
Primary |
| REQ-20 |
Synchronisation Lists must include every Catalogue Item (GTIN+GLN+TM) that needs to be synchronised. |
Primary |
| REQ-21 |
If
a Catalogue Item is "Confirmed of Synchronisation" then all Catalogue
items below in the Catalogue Item Hierarchy shall be included in the
Synchronisation list. |
Primary |
| REQ-22 |
Relationship dependent data will only be communicated for Synchronised, Review or Accept status in the Synchronisation List. |
Primary |
| REQ-23 |
Events
that can trigger notifications are: - Publication of new data / change
of publication - Change of published Catalogue Item / Party / Partner
Profile - Change of owner, rights - Subscription - Synchronisation List
- Confirmation/ Rejection - Request for Notification - Any successful
matching process |
Primary |
| REQ-24 |
Notifications
must NOT be sent in the following cases since data is not yet public
and validated information: - Data load (add, change, etc…) -
Data validation - Registration of new Catalogue Item |
Primary |
| REQ-25 |
The
Data Distribution, which is the movement of data from one entity to
another, must be handled through a specific notification type. |
Secondary |
| REQ-26 |
Notification
to the data recipient will always include the entire hierarchy.
(applies to add & update by adding a higher level) |
Secondary |
| REQ-27 |
In case of an ItemLink correction, the entire hierarchy will be indicated as corrected in the notification. |
Primary |
| REQ-28 |
The updated hierarchy always fully replaces the current hierarchy. This action is called "Full Refresh". |
Primary |
| REQ-32 |
Acknowledgement Reason codes must be unique. |
Primary |
| REQ-58 |
Deletes are not synchronised across data pools. |
Primary |
| REQ-81 |
Synchronisation
List is only synchronised between the involved source and recipient
data pools for applicable data: synchronisation list is built based on
confirmation received by a source data pool and nothing else. |
Secondary |
| REQ-88 |
The
matching process is owned and developed by each source data pool in
order to trigger data distribution based on publication and
subscription data. |
Primary |
| REQ-89 |
The
matching process can be triggered either by publication, subscription
or as a scheduled event. It is valid for all subscription types
(including synchronisation list) and all publication types. |
Primary |
| REQ-93 |
Although
the notification process will physically move the data from one data
pool to another, this data should not be stored permanently for the
purpose of synchronisation with any other user than the initial
subscriber. If stored, access should be limited to the initial data
recipient. |
Primary |
| REQ-109 |
A
Data Recipient requests that it receive a “notification”
when a specific event occurs that meets the Recipients criteria
(selective on sources, categories, etc). This is subject to the
recipient’s access to information as controlled by the data
source through its source data pool. |
Primary |
| REQ-125 |
The Source Data Pool is responsible to reset the "Reload" flag once it sends all requested data. |
Secondary |
| REQ-126 |
If
a new Reload is needed, the Recipient must delete the previous Reload
Subscription, then create a new Subscription with the "Reload" flag set. |
Secondary |
| REQ-143 |
"Reload" flag is passed through to Recipient. |
Primary |
| REQ-159 |
Multiple
independent hierarchies can co-exist at the data-pool for an item for
example hierarchy 1 = case A – each A and hierarchy 2 = pallet A
– case A –each A. |
Primary |
| REQ-166 |
A
Request for Catalogue Item Notification with the isReload set to false
will result in items being re-sent whether they were previously
rejected or not. The Sync List will be reset. This is only valid for
items that have previously been sent to the data recipient.
The CIN response will have the following values:
- documentStatus= Original
- isReload = False
- Command= Add
|
Primary |
| REQ-167 |
A
Request for Catalogue Item Notifcation with the isReload set to true
will result in only items not previously rejected being re-sent. The
Sync List is not reset.
The CIN response will have the following values:
- documentStatus= Copy
- isReload = True
- Command= Add
|
Primary |
| REQ-168 |
The
Document Status of the RFCIN command is ignored for the purposes of
determining its impact on the sync list and the status of the CIN that
is generated. |
Primary |
| REQ-171 |
The
message identifier (CorrelationInformation:
requestingDocu-mentInstanceIdentifier) at the document header levelfor
the EAN.UCC response and the GDSN Exception must equal
theDocumentIdentification: instanceIdentifier of the originalmessage. |
Primary |
|
|
|
|
|

|
|
|
|
Figure 62 -
Distribute Catalogue Item Data from SDP to RDP
Activity Diagram |
|
|
|
 |
|
|
|
Figure 63 -
Distribute Catalogue Item Data from SDP to RDP
Sequence Diagram |
|
|
|
|
|
|
|
TOP |
|
|
|
|
|
|
|
23. Distribute
Catalogue Item Data
from RDP to Recipient |
|
|
|
 |
|
|
|
Figure 64 -
Distribute Catalogue Item Data from RDP to Recipient
Use Case Diagram |
|
|
|
|
|
|
|
| Use Case Name |
Distribute Catalogue Item Data from RDP to Recipient |
| Traceability Identifier |
UC-38 |
| Use Case Description |
Catalogue Item Data are distributed from RDP to the Data Recipient. |
| Use Cases Above |
UC-29:Distribute Catalogue Item Data |
| Use Cases Below |
UC-xx:Send Catalogue Item Data to Recipient |
| Actors |
Recipient Data Pool (RDP)Data Recipient |
| Performance Goals |
RDP: Distribute Catalogue Item Data to the Recipient based on the Subscriptions and Confirmations.Data Recipient: To receive Catalogue Item Data that complies with their Subscriptions and Confirmations. |
| Preconditions |
Publications, Subscriptions and Confirmations have been defined.The Catalogue Item Data are filtered by the RDP (see UC-37). |
| Postconditions |
Data Recipient has received Catalogue Item Data that comply with their Subscriptions and Confirmations. |
| Scenario |
Begins when, the RDP sends the filtered Catalogue Item Data to the Data recipient.
Ends when, the Data Recipient receives the Catalogue Item Data from its RDP. |
| Alternative Scenario |
None at this summary level |
| Special Requirements |
|
| Extension Points |
N/A |
| Requirements Covered |
| ID |
Requirement |
Weight |
| REQ-12 |
Every
command needs a response and is handled according to the agreement
between the parties involved. In the inter-operable network,
acknowledgement messages are standardised and may contain the following
information: - Confirmation of message receipt- Success / Failure of
processing (syntax and content)- Reason for failure, with a code number
and text message unique assigned to each failure |
Primary |
| REQ-20 |
Synchronisation Lists must include every Catalogue Item (GTIN+GLN+TM) that needs to be synchronised. |
Primary |
| REQ-21 |
If
a Catalogue Item is "Confirmed of Synchronisation" then all Catalogue
items below in the Catalogue Item Hierarchy shall be included in the
Synchronisation list. |
Primary |
| REQ-22 |
Relationship dependent data will only be communicated for Synchronised, Review or Accept status in the Synchronisation List. |
Primary |
| REQ-23 |
Events
that can trigger notifications are: - Publication of new data / change
of publication - Change of published Catalogue Item / Party / Partner
Profile - Change of owner, rights - Subscription - Synchronisation List
- Confirmation/ Rejection - Request for Notification - Any successful
matching process |
Primary |
| REQ-24 |
Notifications
must NOT be sent in the following cases since data is not yet public
and validated information: - Data load (add, change, etc…) -
Data validation - Registration of new Catalogue Item |
Primary |
| REQ-25 |
The
Data Distribution, which is the movement of data from one entity to
another, must be handled through a specific notification type. |
Primary |
| REQ-26 |
Notification
to the data recipient will always include the entire hierarchy.
(applies to add & update by adding a higher level) |
Primary |
| REQ-27 |
In case of an ItemLink correction, the entire hierarchy will be indicated as corrected in the notification. |
Primary |
| REQ-28 |
The updated hierarchy always fully replaces the current hierarchy. This action is called "Full Refresh". |
Primary |
| REQ-32 |
Acknowledgement Reason codes must be unique. |
Primary |
| REQ-109 |
A
Data Recipient requests that it receive a “notification”
when a specific event occurs that meets the Recipients criteria
(selective on sources, categories, etc). This is subject to the
recipient’s access to information as controlled by the data
source through its source data pool. |
Secondary |
| REQ-143 |
"Reload" flag is passed through to Recipient. |
Secondary |
| REQ-159 |
Multiple
independent hierarchies can co-exist at the data-pool for an item for
example hierarchy 1 = case A – each A and hierarchy 2 = pallet A
– case A –each A. |
Primary |
| REQ-171 |
The
message identifier (CorrelationInformation:
requestingDocu-mentInstanceIdentifier) at the document header levelfor
the EAN.UCC response and the GDSN Exception must equal
theDocumentIdentification: instanceIdentifier of the originalmessage. |
Primary |
|
|
|
|
|

|
|
|
|
Figure 65 -
Distribute Catalogue Item Data from RDP to Recipient
Activity Diagram |
|
|
|
 |
|
|
|
Figure 66
- Distribute Catalogue Item Data from RDP to Recipient
Sequence Diagram |
|
|
|
|
|
|
|
24. Distribute
Confirmation Data
for a previously rejected Catalogue Item Notification |
|
|
|
 |
|
|
|
Figure 72
- Distribute Catalogue Item Data from RDP to Recipient Use Case Diagram |
|
|
|
|
|
|
|
| Use Case ID |
UC-49
|
| Use Case Name |
Distribute Confirmation Data for a previously rejected Catalogue Item Notification
|
| Use Case Description |
A Data Recipient sends a CIC with a status of ACCEPTED, REVIEW, SYNCHRONISED after previously sending a CIC REJECTED.
|
| Use Case Above |
UC-47: Distribute Data Recipient Requests for Catalogue Item Data
|
| Use Case Below |
None
|
| Actors (Goal) |
Data Source: The
Supplier (Data Source) communicates the trade item information as
necessary – initial published information or a change to the
trade item information.
GS1 Global Registry (GR): The GS1 GR registers the trade item.
Data Recipient: The Retailer (Data Recipient) is the trading partner who receives the communication about the trade item and responds to it.
Recipient Data Pool (RDP): The
Data Pool that receives the communication of the trade item from the
Source Data Pool and delivers it to the Data Recipient and handles the
response.
Source Data Pool (SDP): The
Data Pool that communicates the trade item information from the Data
Source to the Recipient Data Pool and handles the response.
|
| Performance Goals |
|
| Preconditions |
The
participants are registered in the GDSN GS1 Global Registry. The Data
Recipient has previously received a CIN for the catalogue item and sent
a CIC REJECTED for the item.
|
| Post conditions |
Synchronization
is allowed on the GTIN/GLN/TM. The RDP, SDP, and DS are aware of the
Data Recipient’s intentions regarding a specific Catalogue Item.
Updates to the item will be sent to the Data Recipient.
|
| Scenario |
Begins when. The
Retailer (DR) decides to begin synchronization on a product and sends
the CIC (State other than REJECTED) to the Supplier through the RDP.
Continues with...
| Step # |
Actor |
Activity Step |
| 1 |
DR |
Sends the CIC (State other than REJECTED) to the RDP. |
| 2 |
RDP |
Receives the CIC (State other than REJECTED). |
| 3 |
RDP |
Sends the CIC (State other than REJECTED) to the SDP. |
| 4 |
SDP |
Receives the CIC (State other than REJECTED). |
| 5 |
SDP |
Sends the CIC (State other than REJECTED) to the DS. |
| 6 |
SDP |
Updates the synch list for that GTIN/GLN/TM, allowing synchronization on the Trade Item |
| 7 |
SDP |
May query DS to confirm that they have the most current Trade Item information. |
| 8 |
SDP |
Sends the most current Trade Item Information to RDP. |
| 9 |
RDP |
Receives the most current Trade Item Information. |
| | | |