|
1
|
Party data must exist prior to a Catalogue Item is being
registered.
|
x
|
|
|
|
|
|
xx
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2
|
Catalogue Item data must be validated prior to
registration.
|
x
|
|
|
|
|
|
xx
|
|
|
|
|
|
|
|
|
|
|
|
|
|
x
|
|
|
|
3
|
Data Source must be able to add a Catalogue Item to the
Source Data Pool.
|
xx
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
4
|
Data Source must be able to change Catalogue Item data in
the Source Data Pool.
|
|
x
|
|
|
|
|
|
xx
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
5
|
Data Source must be able to correct Catalogue Item data in
the Source Data Pool.
|
|
|
x
|
|
|
|
|
|
xx
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
6
|
Data Source must be able to delete Catalogue Item data in
the Source Data Pool.
|
|
|
|
|
x
|
|
|
|
|
xx
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
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
|
|
|
|
|
x
|
|
|
|
|
xx
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
8
|
GS1 standards validation for GTIN and GLN format.
|
x
|
x
|
x
|
|
|
|
x
|
x
|
x
|
|
|
|
|
|
|
|
|
|
|
|
xx
|
|
|
|
9
|
Uniqueness validation for Catalogue 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.
|
x
|
x
|
x
|
|
|
|
x
|
x
|
x
|
|
|
|
|
|
|
|
|
|
|
|
xx
|
|
|
|
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.
|
x
|
x
|
x
|
|
|
|
xx
|
x
|
x
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
11
|
Corrections bypass the standard GTIN/GLN allocation rules.
|
|
|
x
|
|
|
|
|
|
xx
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
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
|
xx
|
x
|
x
|
x
|
x
|
x
|
x
|
x
|
x
|
x
|
x
|
x
|
x
|
x
|
x
|
x
|
x
|
x
|
x
|
x
|
x
|
|
x
|
|
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.
|
|
|
|
|
|
|
|
|
|
|
xx
|
x
|
x
|
|
|
|
|
x
|
|
|
|
|
|
|
14
|
A subscription must be able to be maintained on the
following levels :
-
GTIN
-
GLN of Data Source
-
Target Market
-
Lowest level of GS1 Classification
Or any combination of these 4 elements.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
xx
|
x
|
x
|
|
|
|
|
|
|
|
|
15
|
With the set up of a subscription, a Data Recipient sets a
profile to receive ongoing updates of the matching data (including all hierarchies,
independently from the level subscribed on).
|
|
|
|
|
|
|
|
|
|
|
|
|
|
xx
|
x
|
x
|
|
|
|
|
|
|
|
|
16
|
Subscription remains valid until it is deleted. Hence, it
cannot be updated.
|
|
|
|
|
|
|
|
|
|
|
|
|
x
|
x
|
xx
|
|
|
|
|
|
|
|
|
|
17
|
Subscriptions must be created by data recipients in their
Recipients Data Pool and sent to the Global Registry.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
xx
|
|
x
|
x
|
|
|
|
|
|
|
|
18
|
A new Source Data Pool will get their relevant
subscriptions as soon as they start registering their GTIN’s.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
xx
|
x
|
|
|
|
|
|
|
|
19
|
The system must maintain detailed subscription lists.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
xx
|
x
|
x
|
|
|
|
|
|
|
|
|
20
|
Synchronisation Lists must include every Catalogue Item
(GTIN+GLN+TM) that needs to be
synchronised.
|
x
|
x
|
x
|
x
|
x
|
x
|
x
|
x
|
x
|
x
|
xx
|
x
|
x
|
x
|
x
|
x
|
x
|
x
|
x
|
|
|
|
x
|
|
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.
|
|
|
x
|
x
|
x
|
x
|
|
|
x
|
x
|
xx
|
x
|
x
|
x
|
x
|
x
|
x
|
x
|
x
|
|
|
|
|
|
22
|
Relationship dependent data will only be communicated for
Synchronised, Review or Accept status in the Synchronisation List.
|
|
|
x
|
x
|
x
|
x
|
|
|
x
|
x
|
xx
|
x
|
x
|
x
|
x
|
x
|
x
|
x
|
x
|
|
|
|
|
|
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
|
|
|
x
|
x
|
x
|
x
|
x
|
x
|
x
|
x
|
x
|
x
|
x
|
x
|
x
|
x
|
x
|
x
|
x
|
|
x
|
|
x
|
|
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
|
x
|
x
|
x
|
x
|
x
|
x
|
xx
|
x
|
x
|
x
|
x
|
x
|
x
|
x
|
x
|
x
|
x
|
x
|
x
|
|
x
|
|
x
|
|
25
|
The Data Distribution, which is the movement of data from
one entity to another, must be handled through a specific notification type.
|
|
|
|
|
|
|
|
|
|
|
x
|
|
|
|
|
x
|
x
|
xx
|
x
|
|
|
|
|
|
26
|
Notification to the data recipient will always include the
entire hierarchy. (applies to add & update by adding a higher level)
|
x
|
|
x
|
x
|
x
|
x
|
|
|
|
|
x
|
|
|
|
|
|
|
xx
|
x
|
|
|
|
|
|
27
|
In case of an ItemLink correction, the entire hierarchy
will be indicated as corrected in the notification.
|
|
|
xx
|
|
|
|
|
|
|
|
x
|
|
|
|
|
|
|
x
|
x
|
|
|
|
|
|
28
|
The updated hierarchy always fully replaces the current
hierarchy. This action is called "Full Refresh".
|
x
|
|
xx
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
x
|
x
|
|
|
|
|
|
29
|
The confirmation process must take place in the home data
pool of the data recipient.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
x
|
x
|
x
|
xx
|
|
|
|
|
|
|
|
30
|
Only Catalogue Items are registered in the Global
Registry. Not Catalogue Item Hierarchies.
|
x
|
x
|
x
|
x
|
x
|
x
|
xx
|
x
|
x
|
x
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
31
|
Validation acknowledgements are mandatory.
|
x
|
x
|
x
|
x
|
x
|
x
|
xx
|
x
|
x
|
x
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
32
|
Acknowledgement Reason codes must be unique.
|
x
|
x
|
x
|
x
|
x
|
x
|
x
|
x
|
x
|
x
|
xx
|
x
|
x
|
x
|
x
|
x
|
x
|
x
|
x
|
|
|
|
x
|
|
33
|
ItemLinks are identified by the parent GTIN key + child
GTIN key + quantity contained.
|
xx
|
x
|
x
|
|
x
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
34
|
ItemLinks are not registered or held within the Global
Registry.
|
x
|
x
|
x
|
x
|
x
|
x
|
xx
|
x
|
x
|
x
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
35
|
Changes have to comply with validation rules.
|
|
xx
|
|
|
|
|
|
xx
|
|
|
|
|
|
|
|
|
|
|
|
|
x
|
|
|
|
36
|
If the Catalogue Item was registered, updates impacting
the Registry data must be reflected in the Global Registry.
|
|
x
|
x
|
x
|
x
|
x
|
x
|
xx
|
x
|
x
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
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.
Note: Authorised … the Data Recipient
indicates to the Data Source that the Data Recipient is taking some action in
the direction of full Synchronisation.
The status is informative and does not change any behavior on the part
of any actor in the Data Synchronisation environment.
|
|
x
|
x
|
x
|
x
|
x
|
x
|
xx
|
x
|
x
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
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.
|
|
xx
|
|
|
|
|
|
x
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
39
|
The ability to provide incremental updates is:
- optional – not required for data
pool certification
- functionality provided between the
recipient’s data pool and its users
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
xx
|
|
|
|
|
40
|
Incorrect core data (i.e. attributes that cannot be updated
according to allocation rules) can only be updated through a specific correction
functionality.
|
|
|
xx
|
|
|
|
|
|
x
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
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 (see data
distribution / notification)
- the correction
will also be reflected in the Global Registry if it impacts Registry data
|
|
|
xx
|
|
|
|
|
|
x
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
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.
|
|
|
xx
|
|
|
|
x
|
|
x
|
x
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
43
|
if the correction does not impact the hierarchy, then ItemLink attributes will be updated through
the correction command.
|
|
|
x
|
|
|
|
|
|
xx
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
44
|
Notification of the hierarchy must indicate it is a correction.
|
|
|
xx
|
|
|
|
|
|
x
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
45
|
Data source is sending full Hierarchies to the Source Data
Pool.
|
xx
|
x
|
x
|
x
|
x
|
x
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
46
|
New hierarchy replaces old hierarchy completely.
|
x
|
xx
|
x
|
x
|
x
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
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.
|
|
|
|
|
x
|
|
|
|
|
xx
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
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)...
|
|
|
|
|
xx
|
|
|
|
|
x
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
49
|
Rules for archiving or physical deletes will be agreed
with the data pools and in the scope of the certification process.
|
|
|
|
x
|
x
|
|
|
|
|
x
|
|
|
|
|
|
|
|
|
|
xx
|
|
|
|
|
50
|
Deletions need to be reflected in the registry (deletion
flag + effective change date = deletion date in the Global Registry)
|
|
|
|
|
x
|
|
|
|
|
xx
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
51
|
To protect data integrity within the data pool, the
deletion of a child can only occur after the deletion of the parents.
|
|
|
|
|
x
|
|
|
|
|
xx
|
|
|
|
|
|
|
|
|
|
|
x
|
|
|
|
52
|
Validation for deleted Items ensures the parents have been
deleted before the deletion of the child is performed.
|
|
|
|
|
x
|
|
|
|
|
xx
|
|
|
|
|
|
|
|
|
|
|
x
|
|
|
|
53
|
Validation is automatically triggered by the “Delete”
command and does not require a specific message flow.
|
|
|
|
|
x
|
|
|
|
|
x
|
|
|
|
|
|
|
|
|
|
|
xx
|
|
|
|
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.
|
|
|
|
|
x
|
|
|
|
|
xx
|
|
|
|
|
|
|
|
|
|
|
x
|
|
|
|
55
|
Deletion needs to be validated against :
- Publication status
- Availability Status (end
availability + discontinued Y/N)
- Hierarchy : parents have to be
deleted before children
|
|
|
|
|
x
|
|
|
|
|
x
|
|
|
|
|
|
|
|
|
|
|
xx
|
|
|
|
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).
|
|
|
|
xx
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
57
|
A deletion cannot be corrected – only the discontinuation
can be reversed.
|
|
|
x
|
x
|
x
|
|
|
|
x
|
xx
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
58
|
Deletes are not synchronised across data pools.
|
|
|
|
|
x
|
|
|
|
|
xx
|
|
|
|
|
|
|
|
x
|
|
|
|
|
|
|
59
|
ItemLinks can only be deleted:
- as the correction of an error
- as the result of a delete.Item
|
|
|
x
|
|
xx
|
|
|
|
|
x
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
60
|
The validity period of a ItemLink is defined by the
validity period of the Parent Item and/or the Child Item.
|
|
|
|
|
xx
|
|
|
|
|
x
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
61
|
When either parent or child expire, the related
ItemLink(s) have to expire as well.
|
|
|
|
|
xx
|
|
|
|
|
x
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
62
|
Cancel Catalogue Item is achieved through the maintenance
(using change function) of the cancel date.
|
|
|
|
|
|
xx
|
|
x
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
63
|
Need cancel date in Catalogue Item data model.
|
|
|
|
|
|
xx
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
64
|
Cancel date needs to be stored in the Global Registry.
|
|
|
|
|
|
xx
|
|
x
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
65
|
Communicate that product is no longer available: maintain
end availability date.
|
|
|
|
|
|
xx
|
|
|
|
|
|
|
x
|
|
|
|
|
|
|
|
|
|
|
|
66
|
When product is available again: update start/end availability
date.
|
|
|
|
|
|
xx
|
|
|
|
|
|
x
|
x
|
|
|
|
|
|
|
|
|
|
|
|
67
|
Communicate the product is no longer going to be
manufactured: discontinued = Y + effective change date = discontinued date in
the Global Registry.
|
|
|
|
xx
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
68
|
Communicate the product is no longer going to be
available: maintain end availability date.
|
|
|
|
xx
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
69
|
Data recipient maintains subscription.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
xx
|
|
x
|
|
|
|
|
|
|
|
|
70
|
Data recipient will continue to receive updates until he
rejects the data.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
x
|
xx
|
x
|
|
|
|
|
|
|
|
|
71
|
For a synchronisation list / subscription, the reject will
remove that GTIN from the synchronisation list.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
xx
|
x
|
|
|
|
|
|
|
|
|
72
|
Reject is optional: in the absence of confirmation &
reject, the data recipient would still receive updates.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
x
|
xx
|
x
|
|
|
|
|
|
|
|
|
73
|
Confirmed GTIN:
- subscription: go to synchronisation
list
- synchronisation list: no action
required
|
|
|
|
|
|
|
|
|
|
|
|
|
|
xx
|
|
x
|
|
|
|
|
|
|
|
|
74
|
Only new products matching the initial subscription will
be distributed to avoid resending data that was previously rejected.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
x
|
|
xx
|
|
|
|
|
|
|
|
|
75
|
Updates for confirmed products will be distributed based
on the synchronisation list.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
xx
|
|
|
|
|
|
|
|
76
|
Confirmation (accept or synchronised) will indicate the
data recipient’s commitment to synchronise the data in its internal systems.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
xx
|
|
|
|
|
|
|
|
77
|
Filtering out rejected data is a source data pool
responsibility.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
x
|
|
xx
|
|
|
|
|
|
|
|
78
|
Subscription: for every matching GTIN, independently from
its level, all hierarchies will be returned.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
xx
|
x
|
x
|
x
|
|
|
|
|
|
|
|
79
|
Synchronisation list:
- Includes every GTIN id
(GTIN+GLN+TM) that needs to be synchronised
- Can be a result of the Confirmation
process
- All GTIN’s equal or lower in the
hierarchy than the GTIN confirmed will be returned
|
|
|
|
|
|
|
|
|
|
|
|
|
|
x
|
x
|
x
|
xx
|
|
|
|
|
|
|
|
80
|
Rejection at the
highest level of a hierarchy will trigger the rejection of all GTIN’s in the
hierarchy of the rejected GTIN.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
x
|
x
|
xx
|
|
|
|
|
|
|
|
81
|
Synchronisation List is only synchronised between the
involved source and recipient data pools for applicable data: synchronisation
list is built based on confirmation received by a source data pool and
nothing else.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
x
|
x
|
x
|
x
|
xx
|
|
|
|
|
|
|
82
|
Maintaining a publication is granting visibility and
access to data.
|
|
|
|
|
|
|
|
|
|
|
|
xx
|
x
|
|
|
|
|
|
|
|
|
|
|
|
83
|
Publications are initiated by the Data Source in the
source data pool, they do not need to be synchronised in the Global Data Synchronisation
Network (GDSN).
|
|
|
|
|
|
|
|
|
|
|
|
xx
|
x
|
|
|
|
|
|
|
|
|
|
|
|
84
|
The Target Market where product is available is
communicated in the product key (GTIN+GLN+TM) – this can be different from
the Target Market for publication.
|
|
|
|
|
|
|
|
|
|
|
|
xx
|
x
|
|
|
|
|
|
|
|
|
|
|
|
85
|
Data is either published:
- to a Target Market: any GLN in the
Target Market has access to the data (only applies to “public” Items)
- to specific GLN’s: only these GLN’s
have access to the data (only applies to “private” Items)
|
|
|
|
|
|
|
|
|
|
|
|
xx
|
x
|
|
|
|
|
|
|
|
|
|
|
|
86
|
The purpose of the public/private flag is to provide
information to the parties involved on the status of the Catalogue Item.
|
|
|
|
|
|
|
|
|
|
|
|
xx
|
x
|
|
|
|
|
|
|
|
|
|
|
|
87
|
Notification is triggered by the matching process.
|
|
|
|
|
|
|
|
|
|
|
|
xx
|
x
|
|
|
|
|
|
|
|
|
|
|
|
88
|
The matching process is owned and developed by each source
data pool in order to trigger data distribution based on publication and
subscription data.
|
|
|
|
|
|
|
|
|
|
|
|
xx
|
x
|
x
|
x
|
x
|
x
|
x
|
|
|
|
|
|
|
89
|
The matching process can be triggered either by
publication, subscription or as a scheduled event. It is valid for all
subscription types (including synchronisation list) and all publication
types.
|
|
|
|
|
|
|
|
|
|
|
|
xx
|
x
|
x
|
x
|
x
|
x
|
x
|
|
|
|
|
|
|
90
|
For a given subscription (create/update):
- the matching process identifies
Items published to the GLN or TM of the subscription owner.
- for each item, a notification is
created including all dependent hierarchies.
- for a synchronisation list, the
hierarchy information included in the notification, will be limited to the
GTIN's maintained in the Synchronisation list.
- The notification
is sent to the home data pool of the data recipient.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
xx
|
x
|
x
|
x
|
|
|
|
|
|
|
|
91
|
For a given publication (create/update) :
- the matching process identifies
subscriptions with matching criteria (TM, GLN, category, GTIN…)
- for each matching subscription, a
notification is created including all dependent hierarchies
- for a synchronisation list, the
hierarchy information included in the notification, will be limited to the
GTIN's maintained in the Synchronisation list.
- The notification
is sent to the home data pool of the data recipient.
|
|
|
|
|
|
|
|
|
|
|
|
xx
|
x
|
|
|
|
|
|
|
|
|
|
|
|
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
|
x
|
x
|
x
|
x
|
x
|
x
|
x
|
x
|
x
|
x
|
x
|
|
|
|
|
|
|
|
|
|
|
|
|
|
93
|
Although the notification process will physically move the
data from one data pool to another, this data should not be stored permanently
for the purpose of synchronisation with any other user than the initial
subscriber.
If stored, access should be limited to the initial data recipient.
|
|
|
|
|
|
|
|
|
|
|
|
xx
|
x
|
|
|
|
|
x
|
|
|
|
|
|
|
94
|
Confirmation is not mandatory and can provide 4 outcomes:
1.
Synchronised: data is integrated, in synch
2. Accept: Data has been received
by the data recipient, but no business decision has been made on the data.
3. Reject: data will no longer be synchronised
or updates will no longer be provided
4.
Review: request to the data source to
review
their data and take action (applies to adds & changes) because the data recipient
has received discrepant data which they cannot synchronise.
If no confirmation is sent, data updates will continue to
be provided until the data recipient accepts, rejects or updates the subscription,
or until the data source changes the publication. For a new Catalogue Item
the same confirmation can be used.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
xx
|
|
|
|
|
|
|
|
95
|
The list of authorised values for the confirmation message
does not imply a sequence in which the message has to be used.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
xx
|
|
|
|
|
|
|
|
96
|
The same “confirmation” message can be used to stop
synchronising a Catalogue Item. In that case, the “Reject” status will be
used to remove the Catalogue Item of the synchronisation list.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
xx
|
|
|
|
|
|
|
|
97
|
“Synchronised” status is sent once – parties are assumed
to be in synch unless a reject/review status is exchanged.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
xx
|
|
|
|
|
|
|
|
98
|
Note : rejection should not remove data previously
authorised, for instance in a different hierarchy.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
x
|
|
xx
|
|
|
|
|
|
|
|
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.
|
x
|
x
|
x
|
x
|
x
|
x
|
x
|
x
|
x
|
x
|
x
|
|
|
x
|
x
|
x
|
x
|
|
|
x
|
x
|
x
|
|
|
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
|
x
|
x
|
x
|
x
|
x
|
x
|
x
|
x
|
x
|
x
|
x
|
|
|
x
|
x
|
x
|
x
|
|
|
x
|
x
|
xx
|
|
|
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.
|
x
|
x
|
x
|
x
|
x
|
x
|
x
|
x
|
x
|
x
|
x
|
|
|
|
|
|
|
|
|
x
|
xx
|
|
|
|
102
|
Registry validation is a part of the registration process.
|
x
|
x
|
x
|
x
|
x
|
x
|
xx
|
x
|
x
|
x
|
x
|
|
|
|
|
|
|
|
|
x
|
x
|
|
|
|
103
|
Data Pool Validation includes the validation according to
any other GS1 standard applicable to the synchronised data and not
included in the Global Registry validation scope.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
xx
|
|
|
|
|
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
|
x
|
x
|
x
|
x
|
x
|
x
|
xx
|
x
|
x
|
x
|
x
|
|
|
|
|
|
|
|
|
x
|
x
|
|
|
|
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.
|
x
|
x
|
x
|
x
|
x
|
x
|
xx
|
x
|
x
|
x
|
x
|
|
|
|
|
|
|
|
|
x
|
x
|
|
|
|
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.
|
x
|
x
|
x
|
x
|
x
|
x
|
xx
|
x
|
x
|
x
|
x
|
|
|
|
|
|
|
|
|
x
|
x
|
|
|
|
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.
|
x
|
x
|
x
|
x
|
x
|
x
|
xx
|
x
|
x
|
x
|
x
|
|
|
|
|
|
|
|
|
x
|
x
|
|
|
|
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.
|
x
|
x
|
x
|
x
|
x
|
x
|
xx
|
x
|
x
|
x
|
x
|
|
|
|
|
|
|
|
|
x
|
x
|
|
|
|
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.
|
|
|
|
|
|
|
|
|
|
|
x
|
x
|
x
|
x
|
x
|
x
|
x
|
x
|
xx
|
|
|
|
|
|
110
|
After a Subscription is created, the Global Registry will
then disseminate relevant subscriptions to appropriate Source Data Pools
(current and future new data pools).
|
|
|
|
|
|
|
|
|
|
|
|
|
|
xx
|
x
|
x
|
x
|
|
|
|
|
|
|
|
111
|
Registry requirements for subscription are:
- Receive and store subscriptions
- Provide subscription
acknowledgement
- Matching process of subscriptions
with Source Data Pools
- Forward subscriptions
|
|
|
|
|
|
|
|
|
|
|
|
|
|
xx
|
x
|
x
|
x
|
|
|
|
|
|
|
|
112
|
The data pool validation is the compliance checking of new
or changed data versus GS1 Global Data Standards, principles and rules,
including:
- GS1 Item and Party data model
validation
- Syntax checks (field formats…)
- Consistency checks (pick lists,
authorised values…)
- Legal checks
(local data requirements…)
- Quality checks
(measurements, hierarchy representation…)
This will be handled through a validation engine.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
x
|
xx
|
|
|
|
113
|
The Global Registry provider will be expected to store and
distribute what has been described as a “Validation Engine”. This software module will be executed by
the data pools to ensure common standards compliance.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
xx
|
x
|
|
|
|
114
|
Additionally, GS1 standards should be stored centrally
– potentially in the Global Registry by version.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
xx
|
x
|
|
|
|
115
|
We recommend the adoption of a solution for Global Search
based on the population of a meta data index in the Global Registry.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
xx
|
|
|
116
|
The Global Registry includes:
- item data
- party data
- data pool profiles
- attributes required to enable
Global Search with the use of meta data database (to be defined)
- global validation rules required
for validation engine (to be defined)
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
xx
|
|
|
|
117
|
Catalogue Item:
-
GTIN
- GLN of Data Source
- Unique Item Identification
- Target Market
- Country Code [3166-1]
- Sub-division code [3166-2]
- GS1 Classification [brick
level]
- Address of the source data pool
(GLN used to look up url in data pool profile)
- Registration
Date
- Deletion Date
(default : 31.12.9999)
- Cancel Date
(default : 31.12.9999)
- Discontinued
Date (default : 31.12.9999)
- Date and Time of
last change (system date for every action on the Catalogue Item)
- Item Validation
Information (including validation engine Version, validation date Date &
Certificate ID) – certificate ID only has to be maintained at item creation
time, periodic maintenance does not affect the Global Registry but is ensured
in the data notification (notified certificate needs to be equal or higher
than registry certificate)
|
|
|
|
|
|
|
xx
|
|
|
|
|
|
|
|
|
|
|
|
|
|
x
|
|
|
|
118
|
Changes/corrections applied to the Global Registry are
effective immediately.
|
|
x
|
x
|
x
|
x
|
x
|
|
xx
|
x
|
x
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
119
|
Future effective changes stored in the data pool are only
reflected in the Global Registry when they become effective.
|
|
x
|
x
|
x
|
x
|
x
|
|
xx
|
x
|
x
|
x
|
|
|
|
|
|
|
|
|
|
|
|
|
|
120
|
Global Search:
-
Additional Product ID
-
Item Description(s)
-
Product Type
-
Item Effective Date
-
Non-public indicator
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
xx
|
|
|
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)
|
|
|
|
|
|
|
xx
|
|
|
|
x
|
|
|
|
|
|
|
|
|
x
|
x
|
|
|
|
122
|
Data Pool Profile:
-
GLN of the data pool
-
Name of data pool
-
Address of the Data Pool (IP or URL)
-
Creation date of data pool provider [for audit of set-up predating
certification]
-
Start availability date of the Data Pool
-
End availability date of the Data Pool
- Certification Start Date
- Certification Expiration Date
- Certification Status
- Identification of the Certification Body
- Certification ID (with version)
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
xx
|
|
|
|
|
123
|
Recipient maintains a subscription, including the
"Reload" flag.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
xx
|
x
|
|
|
|
|
|
|
|
|
|
124
|
The notification triggered by a subscription must also
carry the "Reload" flag value.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
xx
|
x
|
|
|
|
|
|
|
|
|
|
125
|
The Source Data Pool is responsible to reset the "Reload"
flag once it sends all requested data.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
xx
|
|
|
|
|
|
|
126
|
If a new Reload is needed, the Recipient must delete the
previous Reload Subscription, then create a new Subscription with the "Reload"
flag set.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
xx
|
x
|
|
|
xx
|
|
|
|
|
|
|
127
|
The Global Registry must distribute Subscriptions only to
relevant Source Data Pools.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
xx
|
x
|
|
|
|
|
|
|
|
128
|
Source Data Pools must send notifications based on
matching publications and subscriptions.
|
|
|
|
|
|
|
|
|
|
|
xx
|
x
|
x
|
x
|
x
|
|
|
|
|
|
|
|
|
|
129
|
GTIN and Category are mutually exclusive subscription
criteria as the Category is uniquely defined for a given GTIN, independently
from the GLN and from the TM.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
xx
|
x
|
x
|
x
|
|
|
|
|
|
|
|
130
|
GTIN, GLN (of Data Source), Target Market and
Classification must be stored in the Global Registry, and are linked to the
Source Data Pool(s) where the data can be found.
For instance, if given a GTIN, the Global Registry will be able to return all
the data pools where data can be found on that GTIN, independently from the
GLN of the Data Source, the Target Market or the Category.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
xx
|
x
|
|
|
|
|
|
|
|
131
|
The distribution of subscriptions is either a scheduled event
or is triggered by an other event.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
xx
|
x
|
|
|
|
|
|
|
|
132
|
The events that can trigger the distribution of a
subscription are:
- new/updated registration: check
existing subscriptions, if new data pools are found : distribute
subscriptions
- new subscription: check existing
registrations, if new data pools are found: distribute subscriptions
- delete
subscriptions: distribute “delete” to source data pools where subscription
had been sent
|
|
|
|
|
|
|
|
|
|
|
|
|
|
x
|
x
|
xx
|
x
|
|
|
|
|
|
|
|
133
|
Subscriptions cannot be updated, they are created or
deleted.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
x
|
xx
|
x
|
x
|
|
|
|
|
|
|
|
134
|
Subscriptions must be stored in the recipient’s data pool.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
x
|
x
|
xx
|
x
|
|
|
|
|
|
|
|
135
|
For every subscription, the Registry must store the GLN of
the Source Data Pool to which the subscription was sent and when it was sent.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
x
|
x
|
xx
|
x
|
|
|
|
|
|
|
|
136
|
Ability to identify new or updated registered Catalogue
Items that match a subscription and forward the subscription to the Source
Data Pool.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
x
|
x
|
xx
|
x
|
|
|
|
|
|
|
|
137
|
Match new subscriptions with registered Catalogue Items
and forward the subscription to the Source Data Pool.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
x
|
x
|
xx
|
x
|
|
|
|
|
|
|
|
138
|
Publication
Who : Data Source = source GLN
What : Item record, identified by
GTIN+GLN+TM
Where : TM or GLN (= target GLN)
|
|
|
|
|
|
|
|
|
|
|
|
xx
|
x
|
|
|
|
|
|
|
|
|
|
|
|
139
|
Subscription
Who : Data Recipient = target GLN
What : Any combination of GTIN, GLN,
TM and Category
|
|
|
|
|
|
|
|
|
|
|
|
|
|
x
|
x
|
xx
|
x
|
|
|
|
|
|
|
|
140
|
Publication TM does not have to be equal to the GTIN TM
(i.e. I can have a product record defined for TM France, but publishing the
data to Belgium only for information purposes).
|
|
|
|
|
|
|
|
|
|
|
|
xx
|
x
|
|
|
|
|
|
|
|
|
|
|
|
141
|
Deletion of a Subscription stops New Catalogue Items from
being sent to RDP, but, doesn't stop Catalogue Items already in the Synchronisation
List from being updated.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
x
|
xx
|
x
|
x
|
|
|
|
|
|
|
|
142
|
Request for Notification is not retained in the Global
Registry and acts like a Subscription that is applied to the Synchronisation
List, then deleted (no New Catalogue Item data will be sent).
|
|
|
|
|
|
|
|
|
|
|
|
|
|
x
|
x
|
xx
|
x
|
|
|
|
|
|
|
|
143
|
"Reload" flag is passed through to Recipient.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
x
|
x
|
x
|
x
|
x
|
xx
|
|
|
|
|
|
144
|
Request for publication (subscription) resets the reject
flag if catalogue Item has been previously rejected and reactivate the subscription.
|
|
|
|
|
|
|
|
|
|
|
|
xx
|
x
|
x
|
x
|
x
|
x
|
|
|
|
|
|
|
|
145
|
The request for publication subscription is only executed
once.
|
|
|
|
|
|
|
|
|
|
|
|
xx
|
x
|
x
|
x
|
x
|
x
|
|
|
|
|
|
|
|
146
|
Subscriptions are passed from global Registry to data
pools just once. The Global Registry passes along to the source data pool
matching subscriptions in the entirety, rather than replicating for each GTIN
registered.
|
|
|
|
|
|
|
|
|
|
|
|
x
|
x
|
x
|
x
|
xx
|
x
|
|
|
|
|
|
|
|
147
|
Request for notification publication (subscription) resets
the reject flag if the Catalogue Item has been previously rejected and reactivate
the subscription.
|
|
|
|
|
|
|
|
|
|
|
|
x
|
x
|
x
|
x
|
xx
|
x
|
|
|
|
|
|
|
|
148
|
The "Reload" attribute will contain a Boolean
value (TRUE or FALSE).
|
|
|
|
|
|
|
|
|
|
|
|
x
|
x
|
x
|
x
|
xx
|
x
|
|
|
|
|
|
|
|
149
|
Upon execution of an item data notification, the source
data pool will pass along the value of this attribute within the message for
the recipient to properly route the inbound message
|
|
|
|
|
|
|
|
|
|
|
|
x
|
x
|
x
|
x
|
xx
|
x
|
|
|
|
|
|
|
|
150
|
The team identified the need for an additional process to
be known as “Request for Notification”. The Request for Notification is originated
by the requesting data recipient, through the recipient data pool, to the
Global Registry and forwarded to the Source Data Pool.
|
|
|
|
|
|
|
|
|
|
|
|
x
|
x
|
x
|
x
|
xx
|
x
|
|
|
|
|
|
|
|
151
|
The team wanted to reiterate the fact that new
subscriptions received by a source data pool would be executed immediately a
single time.
|
|
|
|
|
|
|
|
|
|
|
|
x
|
x
|
x
|
x
|
xx
|
x
|
|
|
|
|
|
|
|
152
|
The ability to set up a subscription and not get an
initial full load of data. She wants
to only receive the changes, adds, deletes and new items that match her
subscription. (This is the same as a
regular subscription with the exception of not getting the initial load.
|
|
|
|
|
|
|
|
|
|
|
|
x
|
x
|
x
|
x
|
xx
|
x
|
|
|
|
|
|
|
|
153
|
The Global Registry and the data pools should be able to
process current and previous versions of the Catalogue Item Synchronisation
messages. The Global Registry and the data pools should also be able to process
a new version within a certain time frame.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
xx
|
|
|
|
|
154
|
The Global Registry shall send only once a subscription to
a Source Data Pool.
|
|
|
|
|
|
|
|
|
|
|
|
x
|
x
|
x
|
x
|
xx
|
x
|
|
|
|
|
|
|
|
155
|
Data Sources will publish trade items at the highest level of the
hierarchy.
|
|
|
|
|
|
|
|
|
|
|
xx
|
x
|
|
|
|
|
|
|
|
|
|
|
|
|
156
|
Subscription matches are performed at any level of the hierarchy. The
data recipient is sent all hierarchies that match.
|
|
|
|
|
|
|
|
|
|
|
xx
|
x
|
x
|
x
|
x
|
|
|
|
|
|
|
|
|
|
157
|
Confirmations will be done at the highest level of the published trade
item hierarchy.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
xx
|
|
|
|
|
|
|
|
158
|
Top of hierarchy is assumed to be the largest available unit determined
by the data source. Defined as the GTIN of the highest published item in the
hierarchy.
|
|
|
|
|
|
|
