|
CATALOGUE ITEM SYNCHRONISATION v. 2.0.2 |
|
|
|
|
|
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
EAN·UCC 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 EAN·UCC
system, the EAN·UCC 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
EAN·UCC “Keys”, specifically the Global
Trade Identification Number (GTIN) and
Global Location Number (GLN).
The EAN·UCC system provides the standards
to align data between trading partners; these are the foundation
standards. The EAN·UCC 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
1 - Load and Update Catalogue Item Data within a Source
Data Pool 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 GS1
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 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 |
|
| 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. GS1), 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-30:
Manage Data Pool Profile
UC-2: Load and Update Catalogue Item Data
within a Source Data Pool
UC-46: Manage Catalogue Item Data in Global
Registry
UC-23: Manage Catalogue Item Distribution
Criteria
UC-47: Distribute Data Recipient Requests
UC-29:
Distribute Catalogue Item Data |
| Actors:
|
Data
Source
Source 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. Manage Data
Pool Profile |
|
|
 |
|
|
Figure 7
- Manage Data Pool Profile Use Case Diagram |
|
|
|
|
|
| Use
Case Name: |
Manage
Data Pool Profile |
| Traceability
Identifier: |
UC-30 |
| Use
Case Description: |
The
maintenance and storage of certified
data pool information in the Global Registry, defining all the actors
in the
interoperable network and allowing any actor to retrieve information
about the
others. Additional requirements are
needed for the Data Pool Profile Use Case.
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: |
N/A
|
| Actors:
|
Source
Data Pool (SDP)
Global Registry
Recipient Data Pool (RDP) |
| Performance
Goals: |
SDP:
To be
able to obtain the address or URL of the
RDP.
RDP:
To make
available their address (URL) to SDPs.
Global Registry: To be able to
identify the Data Pools in the Synchronisation process. |
| 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 |
|
|
|
|
|
4. Load and
Update Catalogue Item
Data within a Source Data Pool |
|
|
 |
|
|
Figure 8 -
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 Hierarchy
UC-4:
Change Catalogue Item Hierarchy
UC-5:
Correct Catalogue Item Hierarchy
UC-25:
Delete Catalogue Item Hierarchy
UC-7: Cancel Catalogue Item |
| Actors:
|
Data
Source
Source 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 Data
4. 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 SDP
7. The SDP validates the Catalogue Item Hierarchy data
8. The SDP sends pertinent Catalogue Item Data updates to
the Global Registry
9. The Global Registry validates and updates the Catalogue
Item Data
10. The SDP stores the new Catalogue Item Hierarchy
data
11. 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 Source
Ends 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 SDP
3.2 / 9.2. The SDP receives the registration error
message and passes it to the Data Source
Ends 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 Hierarchy
data consists of Catalogue Item data and Item Link data (if
applicable).
|
Extension Points:
|
N/A
|
| Requirements
Covered: |
N/A |
|
|
|
|
|
|
Figure 9 - Load and
Update Catalogue Item Data within a Source
Data Pool Activity Diagram |
|
|
|
|
|
TOP |
|
|
|
|
|
5. Manage
Catalogue Item Data in
Global Registry |
|
|
 |
|
|
Figure 10 -
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 Item
UC-19: Change Registered Catalogue Item
UC-21: Delete Registered Catalogue Item
UC-17: Registry Validation
UC-32: Validate Data Pool
UC-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 data and Item Link data (if
applicable).
|
Extension Points:
|
N/A
|
| Requirements
Covered: |
N/A |
|
|
|
|
|
|
TOP |
|
|
|
|
|
6. Manage
Catalogue Item
Distribution Criteria |
|
|
 |
|
|
Figure 11 - Manage
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 Data
UC-34: Stop Publishing Catalogue Item Data
UC-27: Subscribe to Catalogue Item Data
UC-28: Remove Catalogue Item Subscription
UC-26:
Confirm Catalogue Item Data |
| Actors:
|
Data
Source
Source Data Pool (SDP)
Global Registry
Recipient 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
GS1 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 : - GS1 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: - GS1 standards validation
for GTIN/GLN formats - Uniqueness validation for Item, Party and data
pool key - Store and maintain GS1 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 GS1 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 GS1 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 |
|
|
|
|
|
7. Distribute Data
Recipient Requests for
Catalogue Item Data |
|
|
 |
|
|
Figure 12 -
Distribute Data Recipient Request 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-35:
Distribute Subscription Data
UC-43: Distribute Confirmation Data
UC-22:
Distribute Request for Notification |
| Actors:
|
Data
Source
Source Data Pool (SDP)
Global Registry
Recipient 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: |
N/A |
|
|
|
|
|
|
TOP |
|
|
|
|
|
8. Distribute
Catalogue Item Data |
|
|
 |
|
|
Figure 13 -
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 RDP
UC-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 comply 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 Catalogue Item Data.
- SDP sends
filtered Catalogue Item Data to the RDP.
- RDP use
Subscription and Confirmations to filter Catalogue Item 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:
|
N/A |
Extension Points:
|
N/A
|
| Requirements
Covered: |
See
Detail Use Cases |
|
|
|
|
|
|
TOP |
|
|
|
|
|
DETAIL USE CASES
|
|
|
|
|
|
1. Add Catalogue
Item Hierarchy |
|
|
 |
|
|
Figure 14 - Add
Catalogue Item Hierarchy Use Case |
|
|
|
|
|
| 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 |
| Use
Cases Above: |
UC-2:
Load and Update Catalogue Item Data within a
Source Data Pool |
| Use
Cases Below: |
|
| Actors:
|
Data
Source
Source
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 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
Source
4. The Data Source receives the validation
acknowledgement: Catalogue Item Hierarchy data loaded
5. The SDP loads the Catalogue Item Hierarchy data
6. The SDP sends the Registry Catalogue Item data of
Catalogue Items that are not registered yet to the Global
Registry
7. The Global Registry receives the Registry Item data
8. The Global Registry validates the Registry Item data
for uniqueness
9. The Global Registry registers the Registry Item data
10. The Global Registry sends a registration
acknowledgement to the SDP
11. The SDP receives the registration acknowledgement
12. The SDP storages the registration acknowledgement
12. 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 Source
Ends 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 SDP
7.2. The SDP receives the registration error
message dd Catalogue Item
Hierarchy Use Case
7.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 Hierarchy
data consists of Catalogue Item data and Item Link data (if
applicable).
|
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
|
GS1
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 GS1 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 : - GS1 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: - GS1 standards
validation for GTIN/GLN formats - Uniqueness validation for Item, Party
and data pool key - Store and maintain GS1 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 GS1 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 GS1 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
level for the GS1 response and the GDSN Exception must equal
the DocumentIdentification: instanceIdentifier of the
original message. |
Primary |
|
|
|
|
 |
|
|
Figure 15 - Add
Catalogue Item Hierarchy Activity Diagram |
|
|
 |
|
|
Figure 16
- Add Catalogue Item Hierarchy Sequence Diagram |
|
|
|
|
|
TOP |
|
|
|
|
|
2. Change
Catalogue Item Hierarchy |
|
|
 |
|
|
Figure 8
- Change Catalogue Item Hierarchy Use Case |
|
|
|
|
|
| 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 Item
UC-11: Change Item Link |
| Actors: |
Data Source
Source 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 Hierarcy 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 changed
3. The SDP sends a validation acknowledgement to
the Data Source
4. The Data Source receives the validation acknowledgement:
Catalogue Item Hierarchy data changed
5. The SDP
loads the changed Catalogue Item Hierarchy data
6. The SDP
sends the Registry Item data (to be changed) to the Global Registry
7. The Global Registry receives the Registry
Item data to be changed
8. The Global Registry validates the Registry
Item data
9. The Global Registry registers the changed
Registry Item data
10. The Global Registry sends a
registration acknowledgement to the SDP
12. The SDP receives the
registration acknowledgement
13. The SDP
storages the
registration acknowledgement
14. 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 Source
Ends 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 SDP
7.2. The SDP receives the registration error
message
7.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 Hierarchy data consists of Catalogue Item data and Item Link data
(if
applicable).
- Validation
is done against
existing 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
|
GS1
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
GS1 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 : - GS1 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: - GS1 standards
validation for GTIN/GLN formats - Uniqueness validation for Item, Party
and data pool key - Store and maintain GS1 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 GS1 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 GS1 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 GS1 response and the GDSN Exception must equal
the DocumentIdentification: 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 17 - Correct
Catalogue Item Hierarchy Use Case |
|
|
|
|
|
|
| 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 Source
Source 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 corrected
2.
The SDP validates Catalogue Item Hierarchy data to be corrected
3.
The SDP sends a validation acknowledgement to the Data Source
4.
The Data Source receives the validation acknowledgement: Catalogue
Item Hierarchy data corrected
5.
The SDP loads the corrected Catalogue Item Hierarchy data
6.
The SDP sends the Registry Item data (to be corrected) to the Global
Registry
7.
The Global Registry receives the Registry Item data to be corrected
8.
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 SDP
11. The SDP receives the registration
acknowledgement
12. The SDP stores the registration
acknowledgement
13. 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 Source
Ends 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 SDP
8.2. The SDP receives the registration error
message
8.3. The SDP sends a registration error message to
the Data Source
Ends when,
the Data Source receives the registration
error message
ad 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 Hierarchy data
consists of Catalogue Item data and Item Link data (if applicable).
- Validation
is done against
existing data, applying GDD standard and GTIN allocation rules.
- Catalogue
Item Hierarchy data
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
|
GS1
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 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-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
GS1 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 : - GS1 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: - GS1 standards
validation for GTIN/GLN formats - Uniqueness validation for Item, Party
and data pool key - Store and maintain GS1 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 GS1 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 GS1 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
level for the EAN.UCC response and the GDSN Exception must
equal the DocumentIdentification: instanceIdentifier of the
original message. |
Primary
|
|
|
|
|
|
|
 |
|
|
Figure 18 - Correct
Catalogue Item Hierarchy Data Activity Diagram |
|
|
 |
|
|
Figure 19
- Correct Catalogue Item Hierarchy Sequence Diagram
|
|
|
|
|
|
TOP |
|
|
|
|
|
4. Discontinue
Catalogue
Item |
|
|
 |
|
|
Figure 20
- Discontinue Catalogue Item Use Case |
|
|
|
|
|
| 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. After the discontinuation period
lapses (as defined by GTIN allocation rules), 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 Source
Source 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.
Global
Registry:
To discontinue Catalogue Item Data
upon request of a SDP. |
| 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
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 Data
4. The SDP
discontinues any Item Link involving
the Catalogue Item Data
5. The SDP sends the
Registry Item data to be
discontinued to the Global Registry
6. The Global
Registry receives the Registry Item
data to be discontinued
7. The Global
Registry validates the Registry
Item data
8. 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 SDP
10. The SDP receives the discontinue acknowledgement
11. 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 Source
Ends when,
the Data Source receives the
discontinue validation error message
ad 7.
Validation fails: Catalogue Item data not discontinued
7.1. Global Registry sends a discontinue
validation error message to the SDP
7.2. The SDP receives the discontinue validation
error message
7.3. The SDP sends a discontinue validation error
message to the Data Source
Ends when,
the Data Source receives the
discontinue validation error message |
Special Requirements:
|
- The
discontinuation date 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 registry).
- A
deletion cannot be corrected –
only the discontinuation can be reversed.
- Deletes
are not
synchronised 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 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 : - 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: -
standards validation for GTIN/GLN formats - Uniqueness validation for
Item, Party and data pool key - Store and maintain 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 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 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
level for the response and the GDSN Exception must
equal the DocumentIdentification: instanceIdentifier of the
original message. |
Primary
|
|
|
|
|
|
 |
|
|
Figure 21 -
Discontinue Catalogue Item Activity Diagram |
|
|
 |
|
|
Figure 22 -
Discontinue Catalogue Item Sequence Diagram |
|
|
|
|
|
TOP |
|
|
|
|
|
5. Delete Catalogue
Item Hierarchy |
|
|
 |
|
|
Figure 23 - Delete
Catalogue Item Hierarchy Use Case |
|
|
|
|
|
| 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 Source
Source 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 canceled
Catalogue Item Data.
Global Registry: To remove a discontinued or
canceled
Catalogue Item Data. |
| Preconditions: |
The
SDP has either
discontinued or canceled a Catalogue Item within the timeframe allowed
by 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 Canceled or
Discontinued
for a period described in the General Specification.
|
Alternative
Scenario:
|
None |
Special Requirements:
|
N/A |
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 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 : - 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: - standards
validation for GTIN/GLN formats - Uniqueness validation for Item, Party
and data pool key - Store and maintain 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 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 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 24 - 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.
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 Source
Source 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.
Global Registry: To ensure valid, unique Catalogue
Item
data are registered. |
| 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
receives Catalogue Item Hierarchy data to be changed
2. The SDP validates Catalogue Item Hierarchy
data to be changed
3. The SDP sends a validation acknowledgement to the Data
Source
4. The Data Source receives the validation acknowledgement:
Catalogue
Item Hierarchy data cancelled
5. The SDP loads the changed Catalogue Item Hierarchy data
6. The SDP sends the Registry Item data (to be changed) to
the Global
Registry
7. The Global Registry receives the Registry Item data to be
changed
8. 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 SDP
11. The SDP receives the registration acknowledgement
12. The SDP stores the registration acknowledgement
13. 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 Source
Ends 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 SDP
8.2. The SDP receives the registration error
message
8.3. The SDP sends a registration error message to
the Data Source
Ends 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 Hierarchy data consists
of Catalogue Item data and Item Link data (if applicable)
- Validation
is done against
existing data, applying GDD standard and GTIN allocation rules.
- Catalogue
Item Hierarchy
data 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 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 : - 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: -
standards validation for GTIN/GLN formats - Uniqueness validation for
Item, Party and data pool key - Store and maintain 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 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 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
level for the response and the GDSN Exception must
equal the DocumentIdentification: instanceIdentifier of the
original message. |
Primary
|
|
|
|
|
|
|
 |
|
|
Figure 25 -
Register Catalogue Item Activity Diagram
|
|
|
 |
|
|
Figure 26 -
Register Catalogue Item Sequence Diagram |
|
|
|
|
|
TOP |
|
|
|
|
|
7. Change
Registered Catalogue Item |
|
|
 |
|
|
Figure 27 - 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 Pool
Ends 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 Pool
Ends 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 SDP
3.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
|
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. |
PrimaryChange
Registered Catalogue Item Use Case Diagram |
|
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 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 : - 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: -
standards validation for GTIN/GLN formats - Uniqueness validation for
Item, Party and data pool key - Store and maintain 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 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 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
level for the response and the GDSN Exception must
equal the DocumentIdentification: instanceIdentifier of the
original message. |
Primary
|
|
|
|
|
|
|
 |
|
|
Figure 28 - Change
Registered Catalogue Item Activity Diagram |
|
|
|
|
|
Figure 29 - Change
Registered Catalogue Item Sequence Diagram |
|
|
|
|
|
TOP |
|
|
|
|
|
8. Correct
Registered Catalogue Item |
|
|
 |
|
|
Figure 30 - 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
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 Pool
Ends 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 SDP
3.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
Pool
Ends when, the Source Data Pool receives the
validation error message |
Special Requirements:
|
Validation: applying GDD
standards |
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
|
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 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 : - 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: -
standards validation for GTIN/GLN formats - Uniqueness validation for
Item, Party and data pool key - Store and maintain 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 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 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 the DocumentIdentification: instanceIdentifier of the
original message. |
Primary
|
|
|
|
|
|
|
|
 |
|
|
Figure 31 - Correct
Registered Catalogue Item Activity Diagram |
|
|
 |
|
|
Figure 32
- Correct Registered Catalogue Item Sequence Diagram
|
|
|
|
|
|
TOP |
|
|
|
|
|
9. Delete
Registered Catalogue Item |
|
|
 |
|
|
Figure 33
- Delete Registered Catalogue Item |
|
|
|
|
|
| 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. |
| Preconditions: |
The deletion of registered Catalogue Items
is a consequence of 2 actions:
- Catalogue Item was discontinued of
cancelled (through change)
-
Catalogue Item was flagged for deletion (through change). 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: |
|
| Scenario: |
|
Alternative
Scenario:
|
|
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 a ItemLink is defined by the validity period of the
Parent Item and/or the Child Item. |
Primary
|
|
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.
|
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 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 : - 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: -
standards validation for GTIN/GLN formats - Uniqueness validation for
Item, Party and data pool key - Store and maintain 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 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 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 the DocumentIdentification: instanceIdentifier of the
original message. |
Primary
|
|
|
|
|
|
|
|
 |
|
|
Figure 34 - 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,
Subscriptions and
Confirmations to create the Synchronisation List.Manage Catalogue Item Distribution Criteria
|
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 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 : - 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: -
standards validation for GTIN/GLN formats - Uniqueness validation for
Item, Party and data pool key - Store and maintain 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. |
| | | | | | | |
