GDSN Interoperability Test Final Report - GS1

GDSN Interoperability Test 

Final Report 

Third Quarter 2005 (3Q05) 

Nov. 15, 2005 

Prepared & Facilitated By: 

DRUMMOND GROUP INC. 

www.drummondgroup.com 

Copyright © Drummond Group Inc. 2005 GDSN 3Q05 Final Report page 1

Table of Contents 

Cover Letter.................................................................................................................................................. 3 

Disclaimer ..................................................................................................................................................... 4 

Interoperable Data Pools............................................................................................................................ 5 

Duplicate Data Pools................................................................................................................................... 7 

Test History................................................................................................................................................... 8 

Definitions ..................................................................................................................................................... 9 

GDSN 3Q05 Interoperability Test Summary ......................................................................................... 11 

DGI Interoperability Testing ..................................................................................................................... 12 

DGI Duplicate Data Pool Testing ............................................................................................................ 13 

Interoperability Caveats ............................................................................................................................ 15 

ContentOwner .................................................................................................................................... 15 

EANUCCResponse ........................................................................................................................... 15 

Schema Location ............................................................................................................................... 15 

Classification Definition..................................................................................................................... 15 

SBDH Type......................................................................................................................................... 15 

BusinessScope................................................................................................................................... 16 

Transaction Limit................................................................................................................................16 

PartyDump.......................................................................................................................................... 16 

Cancel and Discontinue Dates ........................................................................................................ 16 

Test Criteria ................................................................................................................................................ 17 

GDSN Test Task #1 .............................................................................................................................. 17 









GDSN Test Task #10 ............................................................................................................................ 35 



About Drummond Group Inc. ................................................................................................................... 44 


Cover Letter 

DRUMMOND GROUP Inc. (DGI) is pleased to announce that the following 

participants in the GDSN-3Q05 Interoperability Test Event have 

completed all Test Event certification requirements (see Interoperability 

Test Summary below). Full-matrix final run testing was executed Sept. 22- 

30, 2005, and the duplicate data pool testing was executed Oct. 10-21, 

2005. 

This is the second interoperability certification of data pools using the 

Global Registry within GDSN. This test covered the functionality of the 

2.0.2 version of GDSN standards which include item synchronization and 

basic party registration. 

To fully understand what was involved with completing this test, please 

read this document carefully. 

Sincerely, 

Rik Drummond 

CEO, 

Drummond Group Inc. 


Disclaimer 

Drummond Group Inc. (DGI) conducts interoperability and conformance 

testing in a neutral test environment for various companies and 

organizations ("Participant"). At the end of the testing process, DGI may 

list the name of the Participant in the final test report along with an 

indication that the Participant passed the test. The fact that the name of 

the Participant appears in the final report is not an endorsement of the 

Participant or its data pool service, and DGI therefore makes no 

warranties, either express or implied, regarding any facet of the business 

conducted by the Participant. 


Interoperable Data Pools 

The data pools participants completed the Interoperability Test Event 

using GDSN standard 2.0.2 BMS against the GS1 Global Registry, 

Version 2. 

Big Hammer 

Data Services 

Click Commerce, 

Inc. 

http://www.rrgroup.com/ 

Data Pool Name: Big Hammer Data Services 

Product Registry v1.1 

Commport 

Communications 

International, inc. 

http://www.clickcommerce.com 

Data Pool Name: Click Commerce Data Pool v3.0 

GS1 Argentina 

http://www.commport.com/ 

Data Pool Name: COMMPORT GLOBAL 

SYNCHRONIZATION Datapool Services (CGS) v2.0, 

release 1.1 

GS1 Colombia 

http://www.gs1.org.ar/ 

Data Pool Name: Data.Cod v1.1 

GS1 France 

http://www.gs1co.org/ 

http://www.gs1fr.org/ 

Data Pool Name: CABASnet v3.0 Data Pool Name: Parangon v2.0 

GXS 

Inovis USA, Inc. 

http://www.gxs.com/ 

http://www.inovis.com/ 

Data Pool Name: Data Pool Manager v6.0 Data Pool Name: Inovis GDS Director v1.0 


LOGIX3, LLC 

ParaRede TI 

http://www.logix3.com/ 

http://www.pararede.com/ 

Data Pool Name: VISZERA v1.0 Data Pool Name: Clarinet v3.0 

SINFOS GmbH 

Soft Solutions 

http://www.sinfos.de/ 

http://www.softsolutions.fr/ 

Data Pool Name: SINFOS GDSN v2.0 Data Pool Name: ibs DataSync v6.0 

Sterling 

Commerce 

WorldWide Retail 

Exchange 

http://www.sterlingcommerce.com/ 

Data Pool Name: Sterling Data Pool Services v1.0 

1SYNC 

(formerly 

Transora) 

http://www.wwre.org/ 

Data Pool Name: WWRE WorldSYNC DX Release 

v4.0 

1SYNC 

(formerly 

UCCnet) 

http://www.1sync.org/ 

Data Pool Name: 1SYNC (formerly Transora) 

Item Management (IM) Release 5.2 

http://www.1sync.org/ 

Data Pool Name: 1SYNC (formerly UCCnet) 

Data Pool Services Release 3.0 


Duplicate Data Pools 

GS1 Australia 

GS1 Canada 

Data Pool Name: GS1net Australia Data Pool v6.0 Data Pool Name: GS1 Canada Data Pool v6.0 

GS1 Hong Kong 

GS1 MEMA 

Data Pool Name: GS1 HK Data Pool v6.0 Data Pool Name: MEMA Data Pool v6.0 

GS1 Russia 

GS1 Slovakia 

Data Pool Name: RusDP1 Data Pool v6.0 Data Pool Name: E-katalog Data Pool v6.0 

GS1 Spain 

Data Pool Name: AECOC Data Pool v6.0 

GS1 Taiwan 

Data Pool Name: GDSN Service (GS1 Taiwan Data 

Pool) v6.0 

GS1 UK 

Data Pool Name: GS1 UK Data Pool v6.0 Data Pool Name: Sincronet v3.0 

GS1 Venezuela 


Test History 

This is the second GDSN Interoperability Test administered by DGI. 

GDSN 3Q05 Interoperability Test: June–September 2005 

GDSN 3Q05 Duplicate Data Pool Test: October 2005 

Previous test 

GDSN 3Q05 Interoperability Test: October–December 2004 


Definitions 

Data Pool – Data Pool is both a company providing data 

synchronization within GDSN and the software itself which provides 

the functionality. For the purpose of a Test Round, Data Pool is 

described by a name, followed by a version, followed by a single 

digit release. The assumption is that version and release syntax is 

as: “VV.Rx…x,” where VV is the version numeral designator, R is 

the single digit release numeral designator and x is the sub-release 

multiple digit numeral designator. DGI assumes that any digits of 

less significance than the R place do not indicate code changes on 

the data pool-with-release tested in the Test Round. A Data Pool 

must identify its software as data pool name, followed by version 

digits followed by a decimal point followed by a single release 

designator digit before the Test Round is complete. 

Full-Matrix Testing – This is a test process in which all participants 

test with one another over the same test scope. For example, in a 

test with 16 participants and 20 test cases, each participant tests 

with the other 15 participants as both originator and recipient of 

each of the 20 test cases for a total of 600 test instances. Fullmatrix 

testing emulates live supply-chain trading partner 

relationships. 

Duplicate Data Pool (DDP) – A copied instance of tested Data Pool 

software used by a GS1 Member Organisation. A DDP does not 

participate in the Full–matrix Testing. 

Duplicate Data Pool Test – A test to determine if a Data Pool 

software instance is the same as the original, tested Data Pool 

software. 

Interoperability Test Event – This is a test in which Data Pools 

successfully demonstrate interoperability amongst each other 

through full-matrix testing over the entire test criteria. 

Interoperability – A Data Pool is deemed interoperable with all other 

data pools and the Global Registry if and only if it demonstrates in a 

full-matrix manner exchange of data covering the test criteria of the 

Interoperability Test Event. A Data Pool is either interoperable or it 

is not interoperable. Waivers or exceptions are not given in 

demonstrating interoperability for the test criteria unless the entire 

Data Pool Test Group and DGI agree. 

Interoperable Data Pools – The group of data pools, from the Data 

Pool Test Group, which successfully completed the Test Criteria, in 

a full duplex manner with every other Data Pool Test Group 


participant in an Interoperability Test Round without any errors in 

the Final Test Phase. 

Data Pool Test Group or Test Group – A group of data pools 

involved in an interoperability or conformant Test Event. Also, the 

GS1 Global Registry is included in this group since its participation 

is mandatory. 

Test Instance– An executed test case. Every time a test case is 

executed it is considered a test instance. 

Test Case or Test Step – This is a specific action that a Data Pool 

must fulfill, in addition to the response of the expected action. It is 

the most basic step to determining GDSN conformance and 

interoperability. 

Test Task – A set of collective test cases, often 10-20, representing 

specific GDSN function. 

Test Criteria – A set of individual Test Tasks, based on the GDSN 

standard specification, that is used to verify that a Data Pool is 

conformant to the specification(s) and interoperable amongst the 

Test Group. 


GDSN 3Q05 Interoperability Test Summary 

This is the second Interoperability Test Event certifying GDSN 

interoperability. The purpose of the test is to provide a venue for 

data pools to test and correct their GDSN software in a noncompetitive 

environment. To accomplish this, each data pool 

interacts with the GS1 Global Registry and the other data pools in 

the Test Group sending and receiving specific GDSN messages 

and performing the necessary operations. 

Test cases which involve messages and expected operations are 

derived from “use cases” from within the 2.0.2 GDSN Standards 

and are approved by the GDSN Task Group. The test cases cover 

GDSN functionality of item registration, subscription, notification 

and confirmation, as well as item sync list capability. 

The Interoperability Test Event began June 26, 2005 and end 

September 30, 2005. Early in the process, the testing was focused 

on finding and correcting interoperability errors. In the final weeks 

of testing, code changes and debug settings were not allowed. 

During this time, the data pools tested with each other without error 

and demonstrated interoperability. Results of the test cases were 

reported and verified by each of the participating companies as 

demonstrated by the message transmissions, data pool logs and 

Global Registry reports. This final version of code from each data 

pool has been deemed interoperable. All data pools listed in the 

previous section, “Interoperable Data Pools,” were successful in the 

testing without exception and were interoperable over all the test 

cases. 

A Duplicate Data Pool test followed the Interoperability Test Event 

testing 10 Duplicate Data Pools. The Duplicate Data Pools are 

listed in the previous section, titled “Duplicate Data Pools,” and 

information about the Duplicate Data Pool test can be found in the 

section titled, "DGI Duplicate Data Pool Testing.” 

No warranty of data pool interoperability is implied over and above 

the publishing of this test round’s final report. The 3Q05 GDSN test 

round was completed by all data pools during the specified time 

period of testing. 


DGI Interoperability Testing 

A Data Pool is deemed interoperable with the Test Group in the 

Interoperability Test Event if it completes the required test cases of 

the Test Criteria. A Data Pool is either interoperable or it is not 

interoperable with members of the Test Group passing the final run. 

Waivers or exceptions are not given in demonstrating 

interoperability for the Test Criteria unless the entire Test group and 

DGI agree. 

DGI engenders a neutral testing environment to facilitate 

interoperability and conformance testing. It is DGI’s purpose to 

facilitate interoperability among the largest group of Data Pools in 

the Test group in an objective manner. 

A DGI Interoperability Test Event has three progressively more 

stringent phases. The phases include: 

1. Debug Phase, 

2. Dry Run Phase 

3. Final Run Phase 

Each phase becomes more and more stringent with respect to 

testing requirements and pass/fail criteria. 

The Debug Phase is for the purpose of debugging Data Pools and 

enhancing stability in preparation of the Dry Run phase. Code 

changes and retesting of the test instances are frequent and 

necessary to create a stable and interoperable test group. 

The Dry Run Phase is composed of single or multiple practice 

periods. The Dry Run duplicates the subsequent Final Run phase. 

Data pools not demonstrating interoperability over the test cases 

with all members of the Test Group by the end of this phase may 

not participate in the Final Run Phase. 

The Final Run Phase is the Phase where Data Pools that have 

successfully completed the Debug and Dry Run Phases 

demonstrate interoperability in executing all test cases through fullmatrix 

testing. In this phase, no error in any test instances may 

occur without all parties involved being declared administratively 

failed until further investigation by DGI. Completion of this phase 

creates the certified interoperable data pools. 


DGI Duplicate Data Pool Testing 

After the completion of the Interoperability Test Event, the Duplicate 

Data Pool Test was executed. Some GS1 Organisations choose to 

purchase Data Pool software and rebrand it for their use, similar to 

an OEM software situation. 

Duplicate Data Pool requirements from GDSN are: 

1. A letter must be provided by an officer of the Data Pool 

OEM stating that the Data Pool, with version number, 

licensed to the GS1 Member Organisation or country is the 

same version that passed the most recent Interoperability 

Test. The letter should also state that the OEM has 

responsibility for operations, maintenance and associated 

services of the Duplicated Data Pools software, and has 

authority over any code changes for the DDP being tested. 

2. The OEM’s Data Pool code base must have successfully 

passed the most recent GDSN interoperability test in order 

for a Duplicate Data Pool (DDP) to be eligible. 

The purpose of the Duplicate Data Pool Test was to verify this 

requirement. Within the test, each Duplicate Data Pool (DDP) 

tested in a pair-wise fashion with one other DDP. Each DDP 

executed the same test cases from the Test Criteria of the 

Interoperability Test Event. The message format was then 

compared to that of the original Data Pool from the Interoperability 

Test Event to determine if they were the same. An executive from 

the original Data Pool provided a signed letter verifying the software 

provided to for the DDP was the same as the data pool software 

from the Interoperability Test Event. 

It is important to note that Duplicate Data Pools did not go through 

a full-matrix test with the other Data Pools from the Interoperability 

Test Event. The software of the ten participating Duplicate Data 

Pools came from either GXS or ParaRede IT from the 

Interoperability Test Event. ParaRede was associated with GS1 

Venezuela and GXS with GS1 Australia, GS1 Canada, GS1 Hong 

Kong, GS1 Russia, GS1 Slovakia, GS1 Spain, GS1 Taiwan and 

GS1 UK. 

NOTE: 

The GS1 GDSN, Inc. Board-endorsed Duplicate Data Pool policy 

simplifies the process, reduces the number of required participants 


for full-matrix certification testing, and makes more cost-effective 

the entry for multiple or duplicate installations of the same Original 

Manufacturer Data Pool code base. Additionally, this policy: 

• Provides a simplified, yet comprehensive certification process that 

does not require full-matrix certification for each duplicate 

installation of the same OEM’s data pool code base. 

• Provides a mechanism for GS1 Member Organisations to offer 

GDSN certified data pool services to their customers without the 

expense and resource requirements of building a solution from the 

ground up. 

• Leverages the experience and knowledge of a previously GDSN 

certified Data Pool to reduce time to market solution. 


Interoperability Caveats 

During the Interoperability Test Event, issues of confusion were 

encountered that required discussion amongst the Test Group and 

GDSN Task Group. As these issues were resolved, they were 

considered consensus issues as both the whole Test Group and 

GDSN Task Group were in agreement with the final decision and 

future implementation. 

ContentOwner 

The contentOwner value at the message level is the GLN of the 

data pool. The contentOwner at the transaction, command and 

document levels is the data source/data recipient GLN. 

EANUCCResponse 

The EANUCCResponse indicates the processing success of 

transaction unit of work. The EANUCCResponse is not a 

transaction, command or document. It is an indicator of the 

acceptance of a processed transaction. An EANUCCResponse 

never contains a "Rejected" or "Modified" value. These are left over 

from an earlier work in the standard. 

The uniqueCreatorIdentification within the EANUCCResponse is 

copied from the uniqueCreatorIdentification of the transaction of the 

requesting message. The contentOwner within EANUCCResponse 

is also copied from the contentOwner of the transaction of the 

requesting message. The sender and receiver values are copied 

from the SBDH sender and receiver identifiers in the requesting 

message. Multiple EANUCCResponses can be contained within a 

single EAN.UCC Response message. 

Schema Location 

For all GDSN messages, schemaLocation is required. The fully 

qualified URL of http://www.gdsregistry.org/2.0/schemas/ will be 

used. 

Classification Definition 

The value for classificationDefinition can be the Brick definition or a 

data pool’s own version of the definition. The value should be 

accurate, but is not required. No validation is made on 

classificationDefinition apart from the schema imposed limit of 700 

characters. 

SBDH Type 

For non-response messages, the Type value in the SDBH will be 

the same value as the documentCommandOperand, e.g 

catalogueItemSubscription. For response messages, 


EANUCCResponse, GDSNException, 

CatalogueItemRegistrationResponse and 

PartyRegistrationResponse, the Type value in the SDBH will be 

GDSNResponse. 

BusinessScope 

The BusinessScope tag is required in all GDSN Response 

messages. 

Transaction Limit 

The number of transactions per message is limited at 100. 

PartyDump 

PartyDump is an exception to the Transaction Limit per message 

as it is not a GDSN message but file. Thus, it is not limited to the 

transactions per message limit of 100. 

Cancel and Discontinue Dates 

Source Data Pool can set valid cancel and discontinue dates to be 

yesterday's date and forward. This affects only the RCI message. 


Test Criteria 

GDSN Test Task #1 

Overview: Basic PartySync 

GS1 Use Case Covered: Party Sync: UC-1, UC-2, UC-4 

Purpose: This test task confirms basic party synchronization between Data Pools and the Global 

Registry 

Prerequisite Condition: SDP has created a DS trading partner and the RDP has recreated a DR 

trading partner and shared its information with the test group. Data Pool participants 

are required to supply the necessary GLNs. 

Testing Procedure: For this test, all data pools will execute Party Registration on both Source 

and Recipient Data Pools. 

Test Step 1.1: 

Description: Both DS and DR trading partners of the Data Pool load their party data with 

the Data Pool. Data Pool then registers the party data with the GR with 

partyRegisteration message with . 

Confirm: GR sends back a valid PartyRegisterationResponse acknowledgment. 

Verify: Data Pool will email the Add-PartyRegistration messages to DGI-GDSN- 

Support 


Description: After receiving the party data from all Data Pools participants, the GR will 

generate a batch message containing the all party data within the GR, including data 

pools and source/recipient trading partners. 

Confirm: Expected party information is present. 

Verify: Data Pool will email the batch party add messages to DGI-GDSN-Support. 

Verify: DGI will confirm correct party information is present in the Global Registry. 


Description: Both Data Source and Data Recipient trading partners of the Data Pool will 

change their party data as mandated by DGI. The DS and DR changes their party 

information to a value specified by DGI. This results in a partyRegisteration message 

with generated by the 

SDP and RDP. 

Confirm: GR sends back a PartyRegisterationResponse acknowledgment for each 

message. 

Verify: Each participant will email the Change_by_Refresh-PartyRegistration messages 

to DGI-GDSN-Support 



Description: After receiving the changed party data from the Data Pools, the GR will 

generate a batch message containing the party data from each of the data pool trading 

partners to the Data Pool 

Confirm: DGI will confirm correct party information is present in the GR. 

Verify: Data Pool will email the batch party add messages to DGI-GDSN-Support. 



Overview: SDP issues an RCI – Add 

GS1 Use Case Covered: Catalogue Sync: UC-18 

Purpose: This test task confirms basic interoperability with the GS1 Global Registry through item 

registration from each participating data pool acting as a SDP. 

Prerequisite Condition: Test Task 1 has been completed. 

Testing Procedure: This test only involves the DS registering items through the SDP. 


Description: SDP registers assigned items 1–16. SDP sends a RCI message with 

for items which are assigned to them. Items 

are not published. Item information will be provided by DGI at test time. 

Confirm: No RDP receives a CIN message. 

Confirm: GR sends CIRR with . 

Verify: Each participant will email the RCI messages to DGI-GDSN-Support 


Description: GS1 provides a report showing that items have been registered for each 

participating data pool. 

Confirm: GR confirms with DGI that items have been registered. 



Overview: RDP issues Catalog Item Subscription - ADD 

GS1 Use Cases Covered: Catalogue Sync: UC-27, UC-35 

Purpose: This test process confirms basic interoperability GS1, SDP and RDP, as well as between 

SDP and RDP themselves. 

Prerequisite Condition: Task 2 is complete. 

Testing Procedure: This test process confirms basic interoperability with the GS1 Global 

Registry through CIS-Add which triggers GDSN network messages across multiple 

data pools. 


Description: Each RDP sends CIS with 

messages. The subscription criteria will be provided at a later date. 

Confirm: GR returns a EAN.UCC message with . 

Verify: RDP will email CIS–ADD message to DGI-GDSN-Support 

Verify: GR confirms with DGI that subscriptions have been received. 


Description: All SDPs receive CIS from GS1 from all other data pools acting as RDP. 

Confirm: SDP confirms CIS subscription matches expected criteria. 

Verify: SDP will email received CIS messages to DGI-GDSN-Support 

Verify: GR confirms CIS messages sent. 


Description: All RDPs send CIS for GLN 

value which is not a registered data source. GLN value will be provided by DGI at test 

time. 


Verify: RDP will email CIS–Add message to DGI-GDSN-Support 

Verify: GR confirms to DGI that subscriptions were received. 



Overview: SDP issues Catalog Item Notification and RDP issues Catalog Item Confirmation 

GS1 Use Cases Covered: Catalogue Sync: UC-37, UC-43 

Purpose: This test process confirms item notification and confirmation messages between data 

pools. 

Prerequisite Condition: Task 3 has been completed and no items have been published. 


Description: Data Source publishes items. Items to publish will be determined by DGI at 

test time. 

Confirm: CIN message must have and 

. 

Confirm: SDP receives EAN.UCC messages with for 

each CIN message sent. 

Verify: SDP will email CIN messages to DGI-GDSN-Support. 


Description: All RDPs receive CINs for the items from Test Step 2. 

Confirm: RDP confirms CIN matches expected item data. 


. 

Confirm: RDP returns EAN.UCC messages with for 

each CIN message received. 

Verify: RDP will email CIN message to DGI-GDSN-Support. 



Description: All RDPs send CIC message for received CIN messages. The CIC state for 

each CIN message will be communicated to the participants by DGI at the test date. CIC 

states will include values of "ACCEPTED", "REJECTED", "SYCHRONISED" and 

"REVIEW". Only one CIC message will be sent for each CIN message. 

Confirm: RDP confirms CIC response matches expected state. 

Confirm: RDP receives EAN.UCC messages with for 

each CIC message sent. 

Verify: RDP emails each CIC message to DGI-GDSN-Support 


Description: All SDPs receive CIC message in accordance with the Test Step 4.3. 

Confirm: CIC state matches expected value from Test Step 4.3. DGI will supply the 

expected synchronisation list for Data Pools to confirm. 

Confirm: SDP returns EAN.UCC messages with for 

each CIC message received. 

Verify: SDP emails each CIC message received from RDP to DGI-GDSN-Support. 

NOTE: "Null" and other values for the sync list entry besides the standard 4 values will 

be set before the CIC is returned. This default value can be essentially anything 

EXCEPT the values of "Accepted", "Review", "Synchronized" and "Rejected". This 

"default value" has not been defined by the GDSN Task Group other than it must not 

be one of the four defined values." This will not be checked for certification testing. 



Overview: SDP Cancels a Catalog Item 

GS1 Use Cases Covered: Catalogue Sync: UC-7, UC-20, UC-29 

Purpose: Each participant will create a "cancelDate" to an existing registered item that is unique 

in target market, GLN, GTIN. 


Testing Procedure: An item which has been synchronized will be canceled and the sync list 

trading partners will be updated. 


Description: Each SDP will change an item by populating the "cancelDate" to the current 

date of test execution. SDP then sends the RCI to GR with . The item to use will be determined at test time by 

DGI. 

Confirm: GR returns a CIRR message with . 

Confirm: GR populates "cancelDate" and "deletionDate". The "deletionDate" must be 12 

months after the date of the "cancelDate" field. This is to insure GR is functioning 

properly and does not affect the data pools certification status. This is done by GR and 

not by the Data Pool. 

Verify: Each SDP will email the RCI message to DGI-GDSN-Support. 


Description: Each SDP will send a CIN with with 

for the item to their sync list trading partners. 

Confirm: SDP receives EAN.UCC message with . 

Confirm: SDP sends the CIN for the cancelled item to RDPs according to the sync list 

and CIN contains a correctly populated "cancelDate". 

Verify: SDP emails CIN messages to DGI-GDSN-Support. 



Description: Recipient Data Pool will receive a CIN with with 

for the item if they have been added to the sync list. 

Confirm: RDP sends EAN.UCC message with . 

Confirm: RDP receives the CIN for the cancelled item from the respective SDP with the 

correct "cancelDate". 

Verify: RDP emails CIN messages to DGI-GDSN-Support. 


Description: Each SDP participant will correct the "cancelDate" on the item from Test 

Step 5.1 to the new value of 3/3/2006. RCI will have with 

Confirm: GR returns CIRR message with . 

Confirm: RCI message contains with 

. 

Verify: Each SDP will email the RCI-Correct message to DGI-GDSN-Support. 


Description: Each data source/source data pool will send a CIN with 

and for the item to their sync list trading partners. 


Confirm: SDP sends the CIN for the corrected, cancelled item to RDPs according to the 

sync list. CIN contains a correctly populated "cancelDate". 

Confirm: GR populates "cancelDate". 



Description: RDP will receive a CIN with and for the item if 

they have been added to the sync list. 


Confirm: RDP receives the CIN for the corrected, cancelled item from the respective 

SDP, and CIN contains a correctly populated "cancelDate". 




Overview: SDP Discontinues a Catalog Item 

GS1 Use Cases Covered: Catalogue Sync: UC-6, UC-20, UC-29 

Purpose: Each participant will create a discontinue date to an existing registered item that is 

unique in category code, GLN, GTIN. 


Testing Procedure: An item which has been synchronized will be discontinued and the sync list 

trading partners will be updated. 


Description: Each SDP will change an item by populating the "discontinuedDate" to the 

current date of test execution. They will then send a RCI with 

to GR. The item to use 

will be determined at test time by DGI. 


Confirm: GR populates "discontinuedDate" to today's date and populates "deletionDate" 

to 48 months later. This is to insure GR is functioning properly and does not affect the 

data pools certification status. 

Confirm: GR returns EAN.UCC response message. 

Verify: Each SDP will email the RCI message to DGI-GDSN-Support. 


Description: Each DS/SDP will send a CIN with with for the item to their sync list trading partners. 


Confirm: SDP sends the CIN for the discontinued item to RDPs according to the sync 

list, and CIN contains a populated "discontinueDate" to todays' date. 




Description: RDP will receive a CIN with with for the item if they have been added to the sync list. 


Confirm: RDP receives the CIN for the discontinued item from the respective SDP with 

the correct "discontinueDate" expected in test step 6.2 



Description: Each SDP participant will correct the "discontinueDate" on the item from 

Test Step 6.1 to the new value of 4/4/2006. RCI message for item is sent to GR with a 

with 


Confirm: RCI message contains with 

. 

Verify: SDP will email the RCI message to DGI-GDSN-Support. 


Description: SDP sends a CIN with 

and for the item to their sync list trading 

partners. 


Confirm: SDP sends the CIN for the corrected, discontinued item to RDPs according to 

the sync list CIN contains a correctly populated "discontinueDate", and GR populates 

"discontinueDate". 



Description: RDP receives a CIN with 

and for the item if they have been added 

to the sync list. 


Confirm: RDP receives the CIN for the corrected, discontinued item from the respective 

SDP, and CIN contains a correctly populated "discontinueDate". 




Overview: RDP issues RFCIN 

GS1 Use Cases Covered: Catalogue Sync: UC-22 

Purpose: This test task confirms basic interoperability with the GS1 Global Registry through an 

RFCIN with each participating data pool. 

Prerequisite Condition: New items are registered and CIS sent and received per the Task 7 

Matrix. 

Testing Procedure: 


Description: RDP sends RFCIN to GR with isReload flag set to "true" using criteria 

assigned by DGI. 


Verify: RDP emails RFCIN message to DGI-GDSN-Support. 


Description: GR distributes RFCIN to all SDPs. 

Confirm: SDP confirm RFCIN subscription criteria is what is expected. 

Verify: SDP emails RFCIN messages received from GR to DGI-GDSN-Support. 


Description: With "isReload=true" in RFCIN, sync lists entries are not reset and item 

information is resent to RDPs according to the sync list which resolves for items not 

previously rejected. 

Confirm: SDP confirm sync list is not reset, and CIN messages are sent to correct DRs 

with attributes of documentStatus value="COPY", isReload="true", 

commandType="ADD" are set in the CIN messages. 

Confirm: SDP receives EAN.UCC message to each CIN sent with 

. 

Verify: SDP email CINs sent as a result of the RFCIN message. 



Description: RDP receives CINs matching sync list and criteria used in 7.1. 

Confirm: CINs are received for items not previously rejected, and the CIN values 

DocumentStatus=copy, isReload=true, commandType=add are set. 

Confirm: RDP returns EAN.UCC message to each CIN message with 

. 



Description: Data Pool send RFCIN to GR with isReload flag set to "false" using criteria 

assigned by DGI at test time using criteria of GTIN and GLN. 

Confirm: GR returns a EAN.UCC response with . 

Verify: RDP will email RFCIN messages to DGI-GDSN-Support. 


Description: GR distributes RFCIN to all SDPs. 

Confirm: SDP confirm RFCIN subscription criteria is what is expected. 

Verify: SDP emails RFCIN message received from GR to DGI-GDSN-Support. 


Description: With "isReload=false" in RFCIN, sync lists are reset and SDP sends all 

matching item information to RDPs, including those which were previously rejected. 

Confirm: Sync list is reset, and CIN messages are sent to correct DRs for all items on the 

sync list, including those previously rejected. CIN messages with values 

documentStatus="Original", isReload="false", commandType="Add" set. 

Confirm: SDP receives EAN.UCC messages for CIN messages with 

. 

Verify: SDP emails CINs sent as a result of the RFCIN message. 



Description: RDP receives CINs matching criteria from Step 7.5. 

Confirm: CINs are received for all matching items, and CIN values 

documentStatus="Original", isReload="false", commandType="Add" are set. 

Confirm: RDP receives EAN.UCC messages for CIN messages with 

. 



Description: BrandName is CORRECTED on items from Task 7 Matrix. Updated CINs 

are generated. 

Confirm: CINs ARE generated because sync list has been reset. 


. 



Description: RDP receives CINs. 


. 




Overview: Basic Item Hierarchy 

GS1 Use Case Covered: Catalogue Sync: UC-18,3,5,25 

Purpose: This test task confirms basic interoperability with the GS1 Global Registry through item 

registration from each participating data pool acting as a SDP. 

Prerequisite Condition: Test Task 3 is completed. 

Testing Procedure: This test only involves the DS registering items through the SDP. 

Test Step 8.1a 

Description: SDP registers items 17–25. SDP sends a RCI message with 

for items which are assigned to them. Items 

are not published. Item information will be provided by DGI at test time. 

Confirm: GR sends a CIRR message with . 

Confirm: No RDP receives a CIN message. 

Verify: Each participant will email the RCI messages to DGI-GDSN-Support 

Test Step 8.1b 

Description: Each RDP sends CIS with 

messages. The subscription criteria will be provided at a later date. 


Verify: RDP will email CIS–ADD message to DGI-GDSN-Support 

Verify: GR confirms with DGI that subscriptions have been received. 

Test Step 8.2 

Description: SDP creates Hierarchy 1 using the assigned items. 

Hierarchies: 

Hierarchy 1 

Hierarchy 1 

Item 18 Case 

↓↓↓ 

Item 17 Each 

Item 18 (Case Unit) linked to Item 17 (Consumer Unit). 



Description: DS publishes Item 18 to all DRs matching a subscription from Test Task 3. 

CIN is generated for Item 18 containing Hierarchy 1 information. 


. 


. 



Description: All RDPs receive CINs for the Item 18 from Test Step 8.3. 

Confirm: RDP confirms CIN messages contains Item Hierarchy 1. 


. 

Confirm: RDP sends EAN.UCC messages for CIN messages with 

. 




Description: All RDPs send CIC message for received CIN messages. The CIC state for 

each CIN message will be "SYCHRONISED". Only one CIC message will be sent for 

each CIN message. 

Confirm: RDP confirms CIC response matches expected state. 

Confirm: RDP receives EAN.UCC messages for CIC messages with 

. 

Verify: RDP emails each CIC to DGI-GDSN-Support 


Description: All SDPs receive CIC message in accordance with the Test Step 8.5. 

Confirm: CIC state matches expected value from Test Step 8.5. 

Confirm: SDP sends EAN.UCC messages for CIC messages with 

. 

Verify: SDP emails CIC received from RDP to DGI-GDSN-Support. 



Overview: Multiple, independent hierarchies 

GS1 Use Cases Covered: Catalogue Item Sync: UC-38 

Purpose: This test process confirms Data Pools ability to handle complex item hierarchy changes 

and modifications. 

Prerequisite Condition: Test Tasks 3 and 8 completed. Items have been added to SDP and 

registered with GR. 


Description: SDP creates Hierarchies 2 and 3 using the assigned items. 

Hierarchy 2 & 3 

Hierarchy 2 Hierarchy 3 

Pallet Item 21 Item 22 Pallet 

↓↓↓ 

Case Item 20 

↓↓↓ 

Each Item 19 


Item 21 (Pallet Unit) linked to Item 20 (Case Unit). 



Description: DS publishes Item 21 (Pallet) and Item 22 (Pallet) to all DRs. SDP issues 

CINs for full hierarchy (Pallet-Case-Each) for Pallet Items 21 and 22, which where 

previously subscribed to in Test Task 3, to all RDPs. Only two CINs commands are sent 

to each subscribing RDP which can be in a single physical message or two messages. 

Confirm: Each CIN command must be "ADD" and state must be "REGISTERED". 

Confirm: SDP receives and RDP sends EAN.UCC messages for CIN messages with 

. 

↓↓↓ 

Verify: SDP emails sent CIN messages to DGI-GDSN-Support. 


Description: All RDPs receive CINs for the item hierarchies from Test Step 9.2. 

Confirm: RDP confirms CIN messages contains Item Hierarchy 2 and 3. 


. 


. 




Description: All Recipient Data Pools send CIC message for received CIN messages. 

CIC of “REJECT” issued for received Item 21 (Pallet) and CIC of “SYCHRONISED” 

issued for Item 22 (Pallet). 


. 

Verify: RDP emails sent CIC messages to DGI-GDSN-Support 


Description: All SDPs receive CIC messages in accordance with the Test Step 9.4 

Confirm: CIC state matches expected value from Test Step 9.4 


. 

Verify: SDP emails CIC messages received from RDP to DGI-GDSN-Support. 


Description: SDP issues a Correct on Item 19 (Each) per DGI’s Instructions. A new CIN 

generated on Item 22 (Pallet) only. 

Confirm: CIN command must be "CORRECT" and state must be "REGISTERED". 

Confirm: CIN generated for Item 22 but NOT Item 21. 


. 

Verify: SDP emails CIN messages sent to DGI-GDSN-Support. 


Description: RDP receives CIN on Item 22 only. 


. 

Verify: RDP will email CIN messages received to DGI-GDSN-Support. 



Overview: Complex Hierarchies 

GS1 Use Cases Covered: Catalogue Item Sync: UC-38 

Purpose: This test process confirms Data Pools ability to handle multiple, independent, item 

hierarchy. 

Prerequisite Condition: Test Tasks 3 and 8 completed and the following Hierarchy is created 

Description: SDP creates Hierarchy 4 using the assigned items. 

Hierarchy 4 

Hierarchy 4 

Item 25 Pallet 

↓↓↓ 

Item 24 Case 

↓↓↓ 

Item 23 Each 




Description: Data Source publishes Item 25 (Pallet) matching subscription from Test 

Task 3. SDP issues CIN for Item 25 (Pallet Level Item). Only one CIN sent to each 

subscribing RDP. 

Confirm: CIN command must be "ADD" and state must be "REGISTERED". 

Confirm: Each CIN must contain Item 25 (Pallet), Item 24 (Case) and Item 23 (Each). 


. 

Verify: SDP emails CIN message to DGI-GDSN-Support. 


Description: RDP receive CIN for Hierarchy 4. 

Confirm: RDP confirms CIN hierarchy matches 10.1. 


. 

Verify: RDP emails each CIN message to DGI-GDSN-Support 



Description: RDP send CIC message for received CIN messages. CIC of 

“SYCHRONISED” issued for Item 25. 


. 

Verify: RDP emails each CIC message to DGI-GDSN-Support 


Description: SDP receive CIC message of “SYCHRONISED” issued for Item 25. 

Confirm: SDP confirms CIC response matches expected state. 

Confirm: SDP sends EAN.UCC messages for CIN messages with 

. 

Verify: SDP emails each CIC message to DGI-GDSN-Support 



Description: DS publishes Item 24 (Case) matching subscription from Test Task 3. SDP 

issues CIN for Item 24 (Case). This creates a new item hierarchy, Hierarchy 5. Only one 

CIN for Hierarchy 5 is sent to each subscribing RDP. 

Hierarchy 4 

Hierarchy 4 

Item 25 Pallet 

↓↓↓ 

Item 24 Case 

↓↓↓ 

Item 23 Each 



Hierarchy 5 

Hierarchy 5 

Item 24 Case 

↓↓↓ 

Item 23 Each 


Confirm: Each CIN must contain only Item 24 (Case) and Item 23 (Each). 


. 


Verify: RDP emails CIN messages received to DGI-GDSN-Support. 


Description: RDPs receive CIN from 10.6. 


Confirm: Each CIN must contain only Item 24 (Case) and Item 23 (Each). 


. 

Verify: RDP emails CIN messages sent to DGI-GDSN-Support. 



Description: All RDPs send CIC message for received CIN messages. CIC of 

“Synchronized” issued for Item 24 (Case). 



. 

Verify: RDP emails CIC messages sent to DGI-GDSN-Support. 


Description: SDPs receive CIC message for received CIN messages. CIC of 

“Synchronized” issued for Item 24 (Case). 



. 

Verify: RDP emails CIC messages sent to DGI-GDSN-Support. 


Description: SDP issues Correct on Item 23 (Each) per DGI’s Instructions. A CIN for 

Item 25 (Pallet level hierarchy, Hierarchy 4) and a CIN for Item 24 (Case level hierarchy, 

Hierarchy 5) is generated to RDPs according to synchronization list. 

Confirm: Each CIN command must be "CORRECT" and state must be "REGISTERED". 


. 

Verify: SDP emails each CIN message sent to DGI-GDSN-Support. 


Description: RDP receives a CIN for Item 25 (Pallet level hierarchy, Hierarchy 4) and a 

CIN for Item 24 (Case level hierarchy, Hierarchy 5). 

Confirm: Each CIN command must be "CORRECT" and state must be "REGISTERED". 


. 

Verify: RDP emails each CIN message received to DGI-GDSN-Support. 



Description: RDP send CIC message for received CIN messages. CIC of 

“SYCHRONISED” issued for CIN of Item 25 (Pallet). CIC of “REJECT” issued for CIN 

Item 24 (Case). 


. 

Verify: RDP emails each CIC sent to DGI-GDSN-Support. 


Description: SDP receives CIC of “SYCHRONISED” issued for CIN of Item 25 (Pallet). 

CIC of “REJECT” issued for CIN Item 24 (Case). 

Confirm: SDP confirms received CIC response matches expected state. 


. 

Verify: SDP emails each CIC received to DGI-GDSN-Support. 


Description: SDP issues Correction on Item 23 (Each Level) per DGI’s Instructions. A 

new CIN is generated for Item 25 (Pallet level hierarchy, Hierarchy 4) only. Item 24 

(Case level hierarchy, Hierarchy 5) is not generated because it was previously 

REJECTED. 


. 

Verify: SDP will email each CIN message sent to DGI-GDSN-Support. 


Description: RDP receives CIN for Item 25 (Pallet level hierarchy, Hierarchy 4) only. 


. 

Verify: RDP will email each CIN messages received to DGI-GDSN-Support. 



Overview: RDP issues CIS Delete 


Purpose: This test process confirms ability to delete item subscriptions between Global Registry 

and Data Pools. 

Prerequisite Condition: Task 4 has been completed. 

Testing Procedure: For this test, each data pool will act as a SDP and RDP. This test task 

confirms basic interoperability with the GS1 Global Registry through CIS Delete 

which triggers GDSN network messages across multiple data pools. 


Description: All RDPs send CIS with to 

GR. GR will distribute CIS–Delete messages to SDPs. The subscription criteria will be 

supplied by DGI at test time. 


Confirm: GR confirms Subscriptions Delete messages received and delivered. 

Verify: RDP will Email CIS – Delete message to DGI-GDSN-Support. 


Description: All SDPs receive CIS Delete from Global Registry. 

Confirm: CIS-Delete subscription criteria matches Test Step 11.1. 

Verify: SDP emails CIS–Delete messages received from GR to DGI-GDSN-Support 



Description: DS of the SDP adds a publication for a item which was previously 

unpublished and matched a subscription criteria recently deleted. Without a subscription 

criteria in place, no CIN message should be published to any data pool. The item to be 

used will be selected by DGI at test time. 

Confirm: No CIN message is sent or received. 


Description: DS of the SDP does a CORRECT on an item in the sync list which is not 

previously rejected. CIN will be generated from the sync list. 

Confirm: CIN is sent according to the sync list, and each CIN command must be 

"CORRECT" and state must be "REGISTERED". 


. 

Verify: SDP emails each CIN message sent to DGI-GDSN-Support. 

Verify: RDP emails each CIN messages received to DGI-GDSN-Support. 

NOTE: This test step verifies the sync list functionality. While the item was added to the 

sync list after a publish on a subscription match, the subscription no longer is 

needed for the item to remain on the sync list. Even after the subscription is 

deleted, the item will continue to be published. This conforms with Business 

Rule# 141 in the CIS BMS. 



Overview: Publication Delete 


Purpose: This test process confirms ability to delete item publication and remove item from sync 

list. 

Prerequisite Condition: Task 4 has been completed. 

Testing Procedure: 


Description: DS issues a removes publication to some DR from the SDP. The publication 

and the DR will be selected by DGI at test time. The SDP generates a CIN with 

to the data recipient(s). The CIN has the 

same item state as in the GR. After removing the publication, the SDP will either 

physically or logically delete the entry from the sync list. By logically deleting this entry, 

SDP will mark the sync list entry as deleted and block future notifications generated on 

this item from the sync list. 

Confirm: SDP generates proper CIN–Delete message to RDP matching the sync list. 


. 

Verify: SDP emails CIN–Delete messages sent to DGI-GDSN-Support. 


Description: RDP receives CIN with . 

RDP notifies its data recipient of Publication Delete for the item. 

Confirm: RDP sends a EAN.UCC message with . 

Confirm: RDP receives proper CIN–Delete message from DS/SDP for the item. 

Verify: RDP will email CIN–Delete messages received to DGI-GDSN-Support. 



Description: DS/SDP changes an item and issues a CIN with 

for the item from Test Step 12.1. DRs 

which have the publication deleted will not receive CIN but other DRs still within the 

sync list will receive CIN. 

Confirm: CIN sent ONLY to DR/RDP still on sync list . 


. 



Description: DRs/RDPs not removed from sync list receive CIN with 

for the item from Test Step 12.3. 


. 

Confirm: CIN received ONLY by DR/RDP still on sync list with 

. 

Verify: RDP emails CIN messages received to DGI-GDSN-Support. 


About Drummond Group Inc. 

Drummond Group Inc. (DGI) is an independent, privately held company 

that works with software vendors, vertical industries and the standards 

community to drive adoption for standards by conducting interoperability 

and conformance testing, publishing related strategic research and 

developing vertical industry strategies. Founded in 1999, DGI represents 

best-of-breed in the industry on linking horizontal infrastructure 

technologies, standards and interoperability issues with the needs of 

vertical industries such as retail, grocery, health care, transportation, 

government and automotive. For more information, please visit 

www.drummondgroup.com or email: info@drummondgroup.com.

GDSN Interoperability Test Final Report - GS1

Create successful ePaper yourself

Delete template?

Save as template?