GDSN Interoperability Test Final Report - GS1
GDSN Interoperability Test Final Report - GS1
GDSN Interoperability Test Final Report - GS1
You also want an ePaper? Increase the reach of your titles
YUMPU automatically turns print PDFs into web optimized ePapers that Google loves.
<strong>GDSN</strong> <strong>Interoperability</strong> <strong>Test</strong><br />
<strong>Final</strong> <strong>Report</strong><br />
Third Quarter 2005 (3Q05)<br />
Nov. 15, 2005<br />
Prepared & Facilitated By:<br />
DRUMMOND GROUP INC.<br />
www.drummondgroup.com<br />
Copyright © Drummond Group Inc. 2005 <strong>GDSN</strong> 3Q05 <strong>Final</strong> <strong>Report</strong> page 1
Table of Contents<br />
Cover Letter.................................................................................................................................................. 3<br />
Disclaimer ..................................................................................................................................................... 4<br />
Interoperable Data Pools............................................................................................................................ 5<br />
Duplicate Data Pools................................................................................................................................... 7<br />
<strong>Test</strong> History................................................................................................................................................... 8<br />
Definitions ..................................................................................................................................................... 9<br />
<strong>GDSN</strong> 3Q05 <strong>Interoperability</strong> <strong>Test</strong> Summary ......................................................................................... 11<br />
DGI <strong>Interoperability</strong> <strong>Test</strong>ing ..................................................................................................................... 12<br />
DGI Duplicate Data Pool <strong>Test</strong>ing ............................................................................................................ 13<br />
<strong>Interoperability</strong> Caveats ............................................................................................................................ 15<br />
ContentOwner .................................................................................................................................... 15<br />
EANUCCResponse ........................................................................................................................... 15<br />
Schema Location ............................................................................................................................... 15<br />
Classification Definition..................................................................................................................... 15<br />
SBDH Type......................................................................................................................................... 15<br />
BusinessScope................................................................................................................................... 16<br />
Transaction Limit................................................................................................................................16<br />
PartyDump.......................................................................................................................................... 16<br />
Cancel and Discontinue Dates ........................................................................................................ 16<br />
<strong>Test</strong> Criteria ................................................................................................................................................ 17<br />
<strong>GDSN</strong> <strong>Test</strong> Task #1 .............................................................................................................................. 17<br />
<strong>GDSN</strong> <strong>Test</strong> Task #2 .............................................................................................................................. 19<br />
<strong>GDSN</strong> <strong>Test</strong> Task #3 .............................................................................................................................. 20<br />
<strong>GDSN</strong> <strong>Test</strong> Task #4 .............................................................................................................................. 21<br />
<strong>GDSN</strong> <strong>Test</strong> Task #5 .............................................................................................................................. 23<br />
<strong>GDSN</strong> <strong>Test</strong> Task #6 .............................................................................................................................. 25<br />
<strong>GDSN</strong> <strong>Test</strong> Task #7 .............................................................................................................................. 27<br />
<strong>GDSN</strong> <strong>Test</strong> Task #8 .............................................................................................................................. 30<br />
<strong>GDSN</strong> <strong>Test</strong> Task #9 .............................................................................................................................. 33<br />
<strong>GDSN</strong> <strong>Test</strong> Task #10 ............................................................................................................................ 35<br />
<strong>GDSN</strong> <strong>Test</strong> Task #11 ............................................................................................................................ 40<br />
<strong>GDSN</strong> <strong>Test</strong> Task #12 ............................................................................................................................ 42<br />
About Drummond Group Inc. ................................................................................................................... 44<br />
Copyright © Drummond Group Inc. 2005 <strong>GDSN</strong> 3Q05 <strong>Final</strong> <strong>Report</strong> page 2
Cover Letter<br />
DRUMMOND GROUP Inc. (DGI) is pleased to announce that the following<br />
participants in the <strong>GDSN</strong>-3Q05 <strong>Interoperability</strong> <strong>Test</strong> Event have<br />
completed all <strong>Test</strong> Event certification requirements (see <strong>Interoperability</strong><br />
<strong>Test</strong> Summary below). Full-matrix final run testing was executed Sept. 22-<br />
30, 2005, and the duplicate data pool testing was executed Oct. 10-21,<br />
2005.<br />
This is the second interoperability certification of data pools using the<br />
Global Registry within <strong>GDSN</strong>. This test covered the functionality of the<br />
2.0.2 version of <strong>GDSN</strong> standards which include item synchronization and<br />
basic party registration.<br />
To fully understand what was involved with completing this test, please<br />
read this document carefully.<br />
Sincerely,<br />
Rik Drummond<br />
CEO,<br />
Drummond Group Inc.<br />
Copyright © Drummond Group Inc. 2005 <strong>GDSN</strong> 3Q05 <strong>Final</strong> <strong>Report</strong> page 3
Disclaimer<br />
Drummond Group Inc. (DGI) conducts interoperability and conformance<br />
testing in a neutral test environment for various companies and<br />
organizations ("Participant"). At the end of the testing process, DGI may<br />
list the name of the Participant in the final test report along with an<br />
indication that the Participant passed the test. The fact that the name of<br />
the Participant appears in the final report is not an endorsement of the<br />
Participant or its data pool service, and DGI therefore makes no<br />
warranties, either express or implied, regarding any facet of the business<br />
conducted by the Participant.<br />
Copyright © Drummond Group Inc. 2005 <strong>GDSN</strong> 3Q05 <strong>Final</strong> <strong>Report</strong> page 4
Interoperable Data Pools<br />
The data pools participants completed the <strong>Interoperability</strong> <strong>Test</strong> Event<br />
using <strong>GDSN</strong> standard 2.0.2 BMS against the <strong>GS1</strong> Global Registry,<br />
Version 2.<br />
Big Hammer<br />
Data Services<br />
Click Commerce,<br />
Inc.<br />
http://www.rrgroup.com/<br />
Data Pool Name: Big Hammer Data Services<br />
Product Registry v1.1<br />
Commport<br />
Communications<br />
International, inc.<br />
http://www.clickcommerce.com<br />
Data Pool Name: Click Commerce Data Pool v3.0<br />
<strong>GS1</strong> Argentina<br />
http://www.commport.com/<br />
Data Pool Name: COMMPORT GLOBAL<br />
SYNCHRONIZATION Datapool Services (CGS) v2.0,<br />
release 1.1<br />
<strong>GS1</strong> Colombia<br />
http://www.gs1.org.ar/<br />
Data Pool Name: Data.Cod v1.1<br />
<strong>GS1</strong> France<br />
http://www.gs1co.org/<br />
http://www.gs1fr.org/<br />
Data Pool Name: CABASnet v3.0 Data Pool Name: Parangon v2.0<br />
GXS<br />
Inovis USA, Inc.<br />
http://www.gxs.com/<br />
http://www.inovis.com/<br />
Data Pool Name: Data Pool Manager v6.0 Data Pool Name: Inovis GDS Director v1.0<br />
Copyright © Drummond Group Inc. 2005 <strong>GDSN</strong> 3Q05 <strong>Final</strong> <strong>Report</strong> page 5
LOGIX3, LLC<br />
ParaRede TI<br />
http://www.logix3.com/<br />
http://www.pararede.com/<br />
Data Pool Name: VISZERA v1.0 Data Pool Name: Clarinet v3.0<br />
SINFOS GmbH<br />
Soft Solutions<br />
http://www.sinfos.de/<br />
http://www.softsolutions.fr/<br />
Data Pool Name: SINFOS <strong>GDSN</strong> v2.0 Data Pool Name: ibs DataSync v6.0<br />
Sterling<br />
Commerce<br />
WorldWide Retail<br />
Exchange<br />
http://www.sterlingcommerce.com/<br />
Data Pool Name: Sterling Data Pool Services v1.0<br />
1SYNC<br />
(formerly<br />
Transora)<br />
http://www.wwre.org/<br />
Data Pool Name: WWRE WorldSYNC DX Release<br />
v4.0<br />
1SYNC<br />
(formerly<br />
UCCnet)<br />
http://www.1sync.org/<br />
Data Pool Name: 1SYNC (formerly Transora)<br />
Item Management (IM) Release 5.2<br />
http://www.1sync.org/<br />
Data Pool Name: 1SYNC (formerly UCCnet)<br />
Data Pool Services Release 3.0<br />
Copyright © Drummond Group Inc. 2005 <strong>GDSN</strong> 3Q05 <strong>Final</strong> <strong>Report</strong> page 6
Duplicate Data Pools<br />
<strong>GS1</strong> Australia<br />
<strong>GS1</strong> Canada<br />
Data Pool Name: <strong>GS1</strong>net Australia Data Pool v6.0 Data Pool Name: <strong>GS1</strong> Canada Data Pool v6.0<br />
<strong>GS1</strong> Hong Kong<br />
<strong>GS1</strong> MEMA<br />
Data Pool Name: <strong>GS1</strong> HK Data Pool v6.0 Data Pool Name: MEMA Data Pool v6.0<br />
<strong>GS1</strong> Russia<br />
<strong>GS1</strong> Slovakia<br />
Data Pool Name: RusDP1 Data Pool v6.0 Data Pool Name: E-katalog Data Pool v6.0<br />
<strong>GS1</strong> Spain<br />
Data Pool Name: AECOC Data Pool v6.0<br />
<strong>GS1</strong> Taiwan<br />
Data Pool Name: <strong>GDSN</strong> Service (<strong>GS1</strong> Taiwan Data<br />
Pool) v6.0<br />
<strong>GS1</strong> UK<br />
Data Pool Name: <strong>GS1</strong> UK Data Pool v6.0 Data Pool Name: Sincronet v3.0<br />
<strong>GS1</strong> Venezuela<br />
Copyright © Drummond Group Inc. 2005 <strong>GDSN</strong> 3Q05 <strong>Final</strong> <strong>Report</strong> page 7
<strong>Test</strong> History<br />
This is the second <strong>GDSN</strong> <strong>Interoperability</strong> <strong>Test</strong> administered by DGI.<br />
<strong>GDSN</strong> 3Q05 <strong>Interoperability</strong> <strong>Test</strong>: June–September 2005<br />
<strong>GDSN</strong> 3Q05 Duplicate Data Pool <strong>Test</strong>: October 2005<br />
Previous test<br />
<strong>GDSN</strong> 3Q05 <strong>Interoperability</strong> <strong>Test</strong>: October–December 2004<br />
Copyright © Drummond Group Inc. 2005 <strong>GDSN</strong> 3Q05 <strong>Final</strong> <strong>Report</strong> page 8
Definitions<br />
Data Pool – Data Pool is both a company providing data<br />
synchronization within <strong>GDSN</strong> and the software itself which provides<br />
the functionality. For the purpose of a <strong>Test</strong> Round, Data Pool is<br />
described by a name, followed by a version, followed by a single<br />
digit release. The assumption is that version and release syntax is<br />
as: “VV.Rx…x,” where VV is the version numeral designator, R is<br />
the single digit release numeral designator and x is the sub-release<br />
multiple digit numeral designator. DGI assumes that any digits of<br />
less significance than the R place do not indicate code changes on<br />
the data pool-with-release tested in the <strong>Test</strong> Round. A Data Pool<br />
must identify its software as data pool name, followed by version<br />
digits followed by a decimal point followed by a single release<br />
designator digit before the <strong>Test</strong> Round is complete.<br />
Full-Matrix <strong>Test</strong>ing – This is a test process in which all participants<br />
test with one another over the same test scope. For example, in a<br />
test with 16 participants and 20 test cases, each participant tests<br />
with the other 15 participants as both originator and recipient of<br />
each of the 20 test cases for a total of 600 test instances. Fullmatrix<br />
testing emulates live supply-chain trading partner<br />
relationships.<br />
Duplicate Data Pool (DDP) – A copied instance of tested Data Pool<br />
software used by a <strong>GS1</strong> Member Organisation. A DDP does not<br />
participate in the Full–matrix <strong>Test</strong>ing.<br />
Duplicate Data Pool <strong>Test</strong> – A test to determine if a Data Pool<br />
software instance is the same as the original, tested Data Pool<br />
software.<br />
<strong>Interoperability</strong> <strong>Test</strong> Event – This is a test in which Data Pools<br />
successfully demonstrate interoperability amongst each other<br />
through full-matrix testing over the entire test criteria.<br />
<strong>Interoperability</strong> – A Data Pool is deemed interoperable with all other<br />
data pools and the Global Registry if and only if it demonstrates in a<br />
full-matrix manner exchange of data covering the test criteria of the<br />
<strong>Interoperability</strong> <strong>Test</strong> Event. A Data Pool is either interoperable or it<br />
is not interoperable. Waivers or exceptions are not given in<br />
demonstrating interoperability for the test criteria unless the entire<br />
Data Pool <strong>Test</strong> Group and DGI agree.<br />
Interoperable Data Pools – The group of data pools, from the Data<br />
Pool <strong>Test</strong> Group, which successfully completed the <strong>Test</strong> Criteria, in<br />
a full duplex manner with every other Data Pool <strong>Test</strong> Group<br />
Copyright © Drummond Group Inc. 2005 <strong>GDSN</strong> 3Q05 <strong>Final</strong> <strong>Report</strong> page 9
participant in an <strong>Interoperability</strong> <strong>Test</strong> Round without any errors in<br />
the <strong>Final</strong> <strong>Test</strong> Phase.<br />
Data Pool <strong>Test</strong> Group or <strong>Test</strong> Group – A group of data pools<br />
involved in an interoperability or conformant <strong>Test</strong> Event. Also, the<br />
<strong>GS1</strong> Global Registry is included in this group since its participation<br />
is mandatory.<br />
<strong>Test</strong> Instance– An executed test case. Every time a test case is<br />
executed it is considered a test instance.<br />
<strong>Test</strong> Case or <strong>Test</strong> Step – This is a specific action that a Data Pool<br />
must fulfill, in addition to the response of the expected action. It is<br />
the most basic step to determining <strong>GDSN</strong> conformance and<br />
interoperability.<br />
<strong>Test</strong> Task – A set of collective test cases, often 10-20, representing<br />
specific <strong>GDSN</strong> function.<br />
<strong>Test</strong> Criteria – A set of individual <strong>Test</strong> Tasks, based on the <strong>GDSN</strong><br />
standard specification, that is used to verify that a Data Pool is<br />
conformant to the specification(s) and interoperable amongst the<br />
<strong>Test</strong> Group.<br />
Copyright © Drummond Group Inc. 2005 <strong>GDSN</strong> 3Q05 <strong>Final</strong> <strong>Report</strong> page 10
<strong>GDSN</strong> 3Q05 <strong>Interoperability</strong> <strong>Test</strong> Summary<br />
This is the second <strong>Interoperability</strong> <strong>Test</strong> Event certifying <strong>GDSN</strong><br />
interoperability. The purpose of the test is to provide a venue for<br />
data pools to test and correct their <strong>GDSN</strong> software in a noncompetitive<br />
environment. To accomplish this, each data pool<br />
interacts with the <strong>GS1</strong> Global Registry and the other data pools in<br />
the <strong>Test</strong> Group sending and receiving specific <strong>GDSN</strong> messages<br />
and performing the necessary operations.<br />
<strong>Test</strong> cases which involve messages and expected operations are<br />
derived from “use cases” from within the 2.0.2 <strong>GDSN</strong> Standards<br />
and are approved by the <strong>GDSN</strong> Task Group. The test cases cover<br />
<strong>GDSN</strong> functionality of item registration, subscription, notification<br />
and confirmation, as well as item sync list capability.<br />
The <strong>Interoperability</strong> <strong>Test</strong> Event began June 26, 2005 and end<br />
September 30, 2005. Early in the process, the testing was focused<br />
on finding and correcting interoperability errors. In the final weeks<br />
of testing, code changes and debug settings were not allowed.<br />
During this time, the data pools tested with each other without error<br />
and demonstrated interoperability. Results of the test cases were<br />
reported and verified by each of the participating companies as<br />
demonstrated by the message transmissions, data pool logs and<br />
Global Registry reports. This final version of code from each data<br />
pool has been deemed interoperable. All data pools listed in the<br />
previous section, “Interoperable Data Pools,” were successful in the<br />
testing without exception and were interoperable over all the test<br />
cases.<br />
A Duplicate Data Pool test followed the <strong>Interoperability</strong> <strong>Test</strong> Event<br />
testing 10 Duplicate Data Pools. The Duplicate Data Pools are<br />
listed in the previous section, titled “Duplicate Data Pools,” and<br />
information about the Duplicate Data Pool test can be found in the<br />
section titled, "DGI Duplicate Data Pool <strong>Test</strong>ing.”<br />
No warranty of data pool interoperability is implied over and above<br />
the publishing of this test round’s final report. The 3Q05 <strong>GDSN</strong> test<br />
round was completed by all data pools during the specified time<br />
period of testing.<br />
Copyright © Drummond Group Inc. 2005 <strong>GDSN</strong> 3Q05 <strong>Final</strong> <strong>Report</strong> page 11
DGI <strong>Interoperability</strong> <strong>Test</strong>ing<br />
A Data Pool is deemed interoperable with the <strong>Test</strong> Group in the<br />
<strong>Interoperability</strong> <strong>Test</strong> Event if it completes the required test cases of<br />
the <strong>Test</strong> Criteria. A Data Pool is either interoperable or it is not<br />
interoperable with members of the <strong>Test</strong> Group passing the final run.<br />
Waivers or exceptions are not given in demonstrating<br />
interoperability for the <strong>Test</strong> Criteria unless the entire <strong>Test</strong> group and<br />
DGI agree.<br />
DGI engenders a neutral testing environment to facilitate<br />
interoperability and conformance testing. It is DGI’s purpose to<br />
facilitate interoperability among the largest group of Data Pools in<br />
the <strong>Test</strong> group in an objective manner.<br />
A DGI <strong>Interoperability</strong> <strong>Test</strong> Event has three progressively more<br />
stringent phases. The phases include:<br />
1. Debug Phase,<br />
2. Dry Run Phase<br />
3. <strong>Final</strong> Run Phase<br />
Each phase becomes more and more stringent with respect to<br />
testing requirements and pass/fail criteria.<br />
The Debug Phase is for the purpose of debugging Data Pools and<br />
enhancing stability in preparation of the Dry Run phase. Code<br />
changes and retesting of the test instances are frequent and<br />
necessary to create a stable and interoperable test group.<br />
The Dry Run Phase is composed of single or multiple practice<br />
periods. The Dry Run duplicates the subsequent <strong>Final</strong> Run phase.<br />
Data pools not demonstrating interoperability over the test cases<br />
with all members of the <strong>Test</strong> Group by the end of this phase may<br />
not participate in the <strong>Final</strong> Run Phase.<br />
The <strong>Final</strong> Run Phase is the Phase where Data Pools that have<br />
successfully completed the Debug and Dry Run Phases<br />
demonstrate interoperability in executing all test cases through fullmatrix<br />
testing. In this phase, no error in any test instances may<br />
occur without all parties involved being declared administratively<br />
failed until further investigation by DGI. Completion of this phase<br />
creates the certified interoperable data pools.<br />
Copyright © Drummond Group Inc. 2005 <strong>GDSN</strong> 3Q05 <strong>Final</strong> <strong>Report</strong> page 12
DGI Duplicate Data Pool <strong>Test</strong>ing<br />
After the completion of the <strong>Interoperability</strong> <strong>Test</strong> Event, the Duplicate<br />
Data Pool <strong>Test</strong> was executed. Some <strong>GS1</strong> Organisations choose to<br />
purchase Data Pool software and rebrand it for their use, similar to<br />
an OEM software situation.<br />
Duplicate Data Pool requirements from <strong>GDSN</strong> are:<br />
1. A letter must be provided by an officer of the Data Pool<br />
OEM stating that the Data Pool, with version number,<br />
licensed to the <strong>GS1</strong> Member Organisation or country is the<br />
same version that passed the most recent <strong>Interoperability</strong><br />
<strong>Test</strong>. The letter should also state that the OEM has<br />
responsibility for operations, maintenance and associated<br />
services of the Duplicated Data Pools software, and has<br />
authority over any code changes for the DDP being tested.<br />
2. The OEM’s Data Pool code base must have successfully<br />
passed the most recent <strong>GDSN</strong> interoperability test in order<br />
for a Duplicate Data Pool (DDP) to be eligible.<br />
The purpose of the Duplicate Data Pool <strong>Test</strong> was to verify this<br />
requirement. Within the test, each Duplicate Data Pool (DDP)<br />
tested in a pair-wise fashion with one other DDP. Each DDP<br />
executed the same test cases from the <strong>Test</strong> Criteria of the<br />
<strong>Interoperability</strong> <strong>Test</strong> Event. The message format was then<br />
compared to that of the original Data Pool from the <strong>Interoperability</strong><br />
<strong>Test</strong> Event to determine if they were the same. An executive from<br />
the original Data Pool provided a signed letter verifying the software<br />
provided to for the DDP was the same as the data pool software<br />
from the <strong>Interoperability</strong> <strong>Test</strong> Event.<br />
It is important to note that Duplicate Data Pools did not go through<br />
a full-matrix test with the other Data Pools from the <strong>Interoperability</strong><br />
<strong>Test</strong> Event. The software of the ten participating Duplicate Data<br />
Pools came from either GXS or ParaRede IT from the<br />
<strong>Interoperability</strong> <strong>Test</strong> Event. ParaRede was associated with <strong>GS1</strong><br />
Venezuela and GXS with <strong>GS1</strong> Australia, <strong>GS1</strong> Canada, <strong>GS1</strong> Hong<br />
Kong, <strong>GS1</strong> Russia, <strong>GS1</strong> Slovakia, <strong>GS1</strong> Spain, <strong>GS1</strong> Taiwan and<br />
<strong>GS1</strong> UK.<br />
NOTE:<br />
The <strong>GS1</strong> <strong>GDSN</strong>, Inc. Board-endorsed Duplicate Data Pool policy<br />
simplifies the process, reduces the number of required participants<br />
Copyright © Drummond Group Inc. 2005 <strong>GDSN</strong> 3Q05 <strong>Final</strong> <strong>Report</strong> page 13
for full-matrix certification testing, and makes more cost-effective<br />
the entry for multiple or duplicate installations of the same Original<br />
Manufacturer Data Pool code base. Additionally, this policy:<br />
• Provides a simplified, yet comprehensive certification process that<br />
does not require full-matrix certification for each duplicate<br />
installation of the same OEM’s data pool code base.<br />
• Provides a mechanism for <strong>GS1</strong> Member Organisations to offer<br />
<strong>GDSN</strong> certified data pool services to their customers without the<br />
expense and resource requirements of building a solution from the<br />
ground up.<br />
• Leverages the experience and knowledge of a previously <strong>GDSN</strong><br />
certified Data Pool to reduce time to market solution.<br />
Copyright © Drummond Group Inc. 2005 <strong>GDSN</strong> 3Q05 <strong>Final</strong> <strong>Report</strong> page 14
<strong>Interoperability</strong> Caveats<br />
During the <strong>Interoperability</strong> <strong>Test</strong> Event, issues of confusion were<br />
encountered that required discussion amongst the <strong>Test</strong> Group and<br />
<strong>GDSN</strong> Task Group. As these issues were resolved, they were<br />
considered consensus issues as both the whole <strong>Test</strong> Group and<br />
<strong>GDSN</strong> Task Group were in agreement with the final decision and<br />
future implementation.<br />
ContentOwner<br />
The contentOwner value at the message level is the GLN of the<br />
data pool. The contentOwner at the transaction, command and<br />
document levels is the data source/data recipient GLN.<br />
EANUCCResponse<br />
The EANUCCResponse indicates the processing success of<br />
transaction unit of work. The EANUCCResponse is not a<br />
transaction, command or document. It is an indicator of the<br />
acceptance of a processed transaction. An EANUCCResponse<br />
never contains a "Rejected" or "Modified" value. These are left over<br />
from an earlier work in the standard.<br />
The uniqueCreatorIdentification within the EANUCCResponse is<br />
copied from the uniqueCreatorIdentification of the transaction of the<br />
requesting message. The contentOwner within EANUCCResponse<br />
is also copied from the contentOwner of the transaction of the<br />
requesting message. The sender and receiver values are copied<br />
from the SBDH sender and receiver identifiers in the requesting<br />
message. Multiple EANUCCResponses can be contained within a<br />
single EAN.UCC Response message.<br />
Schema Location<br />
For all <strong>GDSN</strong> messages, schemaLocation is required. The fully<br />
qualified URL of http://www.gdsregistry.org/2.0/schemas/ will be<br />
used.<br />
Classification Definition<br />
The value for classificationDefinition can be the Brick definition or a<br />
data pool’s own version of the definition. The value should be<br />
accurate, but is not required. No validation is made on<br />
classificationDefinition apart from the schema imposed limit of 700<br />
characters.<br />
SBDH Type<br />
For non-response messages, the Type value in the SDBH will be<br />
the same value as the documentCommandOperand, e.g<br />
catalogueItemSubscription. For response messages,<br />
Copyright © Drummond Group Inc. 2005 <strong>GDSN</strong> 3Q05 <strong>Final</strong> <strong>Report</strong> page 15
EANUCCResponse, <strong>GDSN</strong>Exception,<br />
CatalogueItemRegistrationResponse and<br />
PartyRegistrationResponse, the Type value in the SDBH will be<br />
<strong>GDSN</strong>Response.<br />
BusinessScope<br />
The BusinessScope tag is required in all <strong>GDSN</strong> Response<br />
messages.<br />
Transaction Limit<br />
The number of transactions per message is limited at 100.<br />
PartyDump<br />
PartyDump is an exception to the Transaction Limit per message<br />
as it is not a <strong>GDSN</strong> message but file. Thus, it is not limited to the<br />
transactions per message limit of 100.<br />
Cancel and Discontinue Dates<br />
Source Data Pool can set valid cancel and discontinue dates to be<br />
yesterday's date and forward. This affects only the RCI message.<br />
Copyright © Drummond Group Inc. 2005 <strong>GDSN</strong> 3Q05 <strong>Final</strong> <strong>Report</strong> page 16
<strong>Test</strong> Criteria<br />
<strong>GDSN</strong> <strong>Test</strong> Task #1<br />
Overview: Basic PartySync<br />
<strong>GS1</strong> Use Case Covered: Party Sync: UC-1, UC-2, UC-4<br />
Purpose: This test task confirms basic party synchronization between Data Pools and the Global<br />
Registry<br />
Prerequisite Condition: SDP has created a DS trading partner and the RDP has recreated a DR<br />
trading partner and shared its information with the test group. Data Pool participants<br />
are required to supply the necessary GLNs.<br />
<strong>Test</strong>ing Procedure: For this test, all data pools will execute Party Registration on both Source<br />
and Recipient Data Pools.<br />
<strong>Test</strong> Step 1.1:<br />
Description: Both DS and DR trading partners of the Data Pool load their party data with<br />
the Data Pool. Data Pool then registers the party data with the GR with<br />
partyRegisteration message with .<br />
Confirm: GR sends back a valid PartyRegisterationResponse acknowledgment.<br />
Verify: Data Pool will email the Add-PartyRegistration messages to DGI-<strong>GDSN</strong>-<br />
Support<br />
<strong>Test</strong> Step 1.2:<br />
Description: After receiving the party data from all Data Pools participants, the GR will<br />
generate a batch message containing the all party data within the GR, including data<br />
pools and source/recipient trading partners.<br />
Confirm: Expected party information is present.<br />
Verify: Data Pool will email the batch party add messages to DGI-<strong>GDSN</strong>-Support.<br />
Verify: DGI will confirm correct party information is present in the Global Registry.<br />
<strong>Test</strong> Step 1.3:<br />
Description: Both Data Source and Data Recipient trading partners of the Data Pool will<br />
change their party data as mandated by DGI. The DS and DR changes their party<br />
information to a value specified by DGI. This results in a partyRegisteration message<br />
with generated by the<br />
SDP and RDP.<br />
Confirm: GR sends back a PartyRegisterationResponse acknowledgment for each<br />
message.<br />
Verify: Each participant will email the Change_by_Refresh-PartyRegistration messages<br />
to DGI-<strong>GDSN</strong>-Support<br />
<strong>Test</strong> Step 1.4:<br />
Copyright © Drummond Group Inc. 2005 <strong>GDSN</strong> 3Q05 <strong>Final</strong> <strong>Report</strong> page 17
Description: After receiving the changed party data from the Data Pools, the GR will<br />
generate a batch message containing the party data from each of the data pool trading<br />
partners to the Data Pool<br />
Confirm: DGI will confirm correct party information is present in the GR.<br />
Verify: Data Pool will email the batch party add messages to DGI-<strong>GDSN</strong>-Support.<br />
Copyright © Drummond Group Inc. 2005 <strong>GDSN</strong> 3Q05 <strong>Final</strong> <strong>Report</strong> page 18
<strong>GDSN</strong> <strong>Test</strong> Task #2<br />
Overview: SDP issues an RCI – Add<br />
<strong>GS1</strong> Use Case Covered: Catalogue Sync: UC-18<br />
Purpose: This test task confirms basic interoperability with the <strong>GS1</strong> Global Registry through item<br />
registration from each participating data pool acting as a SDP.<br />
Prerequisite Condition: <strong>Test</strong> Task 1 has been completed.<br />
<strong>Test</strong>ing Procedure: This test only involves the DS registering items through the SDP.<br />
<strong>Test</strong> Step 2.1:<br />
Description: SDP registers assigned items 1–16. SDP sends a RCI message with<br />
for items which are assigned to them. Items<br />
are not published. Item information will be provided by DGI at test time.<br />
Confirm: No RDP receives a CIN message.<br />
Confirm: GR sends CIRR with .<br />
Verify: Each participant will email the RCI messages to DGI-<strong>GDSN</strong>-Support<br />
<strong>Test</strong> Step 2.2:<br />
Description: <strong>GS1</strong> provides a report showing that items have been registered for each<br />
participating data pool.<br />
Confirm: GR confirms with DGI that items have been registered.<br />
Copyright © Drummond Group Inc. 2005 <strong>GDSN</strong> 3Q05 <strong>Final</strong> <strong>Report</strong> page 19
<strong>GDSN</strong> <strong>Test</strong> Task #3<br />
Overview: RDP issues Catalog Item Subscription - ADD<br />
<strong>GS1</strong> Use Cases Covered: Catalogue Sync: UC-27, UC-35<br />
Purpose: This test process confirms basic interoperability <strong>GS1</strong>, SDP and RDP, as well as between<br />
SDP and RDP themselves.<br />
Prerequisite Condition: Task 2 is complete.<br />
<strong>Test</strong>ing Procedure: This test process confirms basic interoperability with the <strong>GS1</strong> Global<br />
Registry through CIS-Add which triggers <strong>GDSN</strong> network messages across multiple<br />
data pools.<br />
<strong>Test</strong> Step 3.1:<br />
Description: Each RDP sends CIS with <br />
messages. The subscription criteria will be provided at a later date.<br />
Confirm: GR returns a EAN.UCC message with .<br />
Verify: RDP will email CIS–ADD message to DGI-<strong>GDSN</strong>-Support<br />
Verify: GR confirms with DGI that subscriptions have been received.<br />
<strong>Test</strong> Step 3.2:<br />
Description: All SDPs receive CIS from <strong>GS1</strong> from all other data pools acting as RDP.<br />
Confirm: SDP confirms CIS subscription matches expected criteria.<br />
Verify: SDP will email received CIS messages to DGI-<strong>GDSN</strong>-Support<br />
Verify: GR confirms CIS messages sent.<br />
<strong>Test</strong> Step 3.3:<br />
Description: All RDPs send CIS for GLN<br />
value which is not a registered data source. GLN value will be provided by DGI at test<br />
time.<br />
Confirm: GR returns a EAN.UCC message with .<br />
Verify: RDP will email CIS–Add message to DGI-<strong>GDSN</strong>-Support<br />
Verify: GR confirms to DGI that subscriptions were received.<br />
Copyright © Drummond Group Inc. 2005 <strong>GDSN</strong> 3Q05 <strong>Final</strong> <strong>Report</strong> page 20
<strong>GDSN</strong> <strong>Test</strong> Task #4<br />
Overview: SDP issues Catalog Item Notification and RDP issues Catalog Item Confirmation<br />
<strong>GS1</strong> Use Cases Covered: Catalogue Sync: UC-37, UC-43<br />
Purpose: This test process confirms item notification and confirmation messages between data<br />
pools.<br />
Prerequisite Condition: Task 3 has been completed and no items have been published.<br />
<strong>Test</strong> Step 4.1:<br />
Description: Data Source publishes items. Items to publish will be determined by DGI at<br />
test time.<br />
Confirm: CIN message must have and<br />
.<br />
Confirm: SDP receives EAN.UCC messages with for<br />
each CIN message sent.<br />
Verify: SDP will email CIN messages to DGI-<strong>GDSN</strong>-Support.<br />
<strong>Test</strong> Step 4.2:<br />
Description: All RDPs receive CINs for the items from <strong>Test</strong> Step 2.<br />
Confirm: RDP confirms CIN matches expected item data.<br />
Confirm: CIN message must have and<br />
.<br />
Confirm: RDP returns EAN.UCC messages with for<br />
each CIN message received.<br />
Verify: RDP will email CIN message to DGI-<strong>GDSN</strong>-Support.<br />
Copyright © Drummond Group Inc. 2005 <strong>GDSN</strong> 3Q05 <strong>Final</strong> <strong>Report</strong> page 21
<strong>Test</strong> Step 4.3:<br />
Description: All RDPs send CIC message for received CIN messages. The CIC state for<br />
each CIN message will be communicated to the participants by DGI at the test date. CIC<br />
states will include values of "ACCEPTED", "REJECTED", "SYCHRONISED" and<br />
"REVIEW". Only one CIC message will be sent for each CIN message.<br />
Confirm: RDP confirms CIC response matches expected state.<br />
Confirm: RDP receives EAN.UCC messages with for<br />
each CIC message sent.<br />
Verify: RDP emails each CIC message to DGI-<strong>GDSN</strong>-Support<br />
<strong>Test</strong> Step 4.4:<br />
Description: All SDPs receive CIC message in accordance with the <strong>Test</strong> Step 4.3.<br />
Confirm: CIC state matches expected value from <strong>Test</strong> Step 4.3. DGI will supply the<br />
expected synchronisation list for Data Pools to confirm.<br />
Confirm: SDP returns EAN.UCC messages with for<br />
each CIC message received.<br />
Verify: SDP emails each CIC message received from RDP to DGI-<strong>GDSN</strong>-Support.<br />
NOTE: "Null" and other values for the sync list entry besides the standard 4 values will<br />
be set before the CIC is returned. This default value can be essentially anything<br />
EXCEPT the values of "Accepted", "Review", "Synchronized" and "Rejected". This<br />
"default value" has not been defined by the <strong>GDSN</strong> Task Group other than it must not<br />
be one of the four defined values." This will not be checked for certification testing.<br />
Copyright © Drummond Group Inc. 2005 <strong>GDSN</strong> 3Q05 <strong>Final</strong> <strong>Report</strong> page 22
<strong>GDSN</strong> <strong>Test</strong> Task #5<br />
Overview: SDP Cancels a Catalog Item<br />
<strong>GS1</strong> Use Cases Covered: Catalogue Sync: UC-7, UC-20, UC-29<br />
Purpose: Each participant will create a "cancelDate" to an existing registered item that is unique<br />
in target market, GLN, GTIN.<br />
Prerequisite Condition: Task 4 is complete.<br />
<strong>Test</strong>ing Procedure: An item which has been synchronized will be canceled and the sync list<br />
trading partners will be updated.<br />
<strong>Test</strong> Step 5.1:<br />
Description: Each SDP will change an item by populating the "cancelDate" to the current<br />
date of test execution. SDP then sends the RCI to GR with . The item to use will be determined at test time by<br />
DGI.<br />
Confirm: GR returns a CIRR message with .<br />
Confirm: GR populates "cancelDate" and "deletionDate". The "deletionDate" must be 12<br />
months after the date of the "cancelDate" field. This is to insure GR is functioning<br />
properly and does not affect the data pools certification status. This is done by GR and<br />
not by the Data Pool.<br />
Verify: Each SDP will email the RCI message to DGI-<strong>GDSN</strong>-Support.<br />
<strong>Test</strong> Step 5.2:<br />
Description: Each SDP will send a CIN with with <br />
for the item to their sync list trading partners.<br />
Confirm: SDP receives EAN.UCC message with .<br />
Confirm: SDP sends the CIN for the cancelled item to RDPs according to the sync list<br />
and CIN contains a correctly populated "cancelDate".<br />
Verify: SDP emails CIN messages to DGI-<strong>GDSN</strong>-Support.<br />
Copyright © Drummond Group Inc. 2005 <strong>GDSN</strong> 3Q05 <strong>Final</strong> <strong>Report</strong> page 23
<strong>Test</strong> Step 5.3:<br />
Description: Recipient Data Pool will receive a CIN with with <br />
for the item if they have been added to the sync list.<br />
Confirm: RDP sends EAN.UCC message with .<br />
Confirm: RDP receives the CIN for the cancelled item from the respective SDP with the<br />
correct "cancelDate".<br />
Verify: RDP emails CIN messages to DGI-<strong>GDSN</strong>-Support.<br />
<strong>Test</strong> Step 5.4:<br />
Description: Each SDP participant will correct the "cancelDate" on the item from <strong>Test</strong><br />
Step 5.1 to the new value of 3/3/2006. RCI will have with <br />
Confirm: GR returns CIRR message with .<br />
Confirm: RCI message contains with<br />
.<br />
Verify: Each SDP will email the RCI-Correct message to DGI-<strong>GDSN</strong>-Support.<br />
<strong>Test</strong> Step 5.5:<br />
Description: Each data source/source data pool will send a CIN with<br />
and for the item to their sync list trading partners.<br />
Confirm: SDP receives EAN.UCC message with .<br />
Confirm: SDP sends the CIN for the corrected, cancelled item to RDPs according to the<br />
sync list. CIN contains a correctly populated "cancelDate".<br />
Confirm: GR populates "cancelDate".<br />
Verify: SDP emails CIN messages to DGI-<strong>GDSN</strong>-Support.<br />
<strong>Test</strong> Step 5.6:<br />
Description: RDP will receive a CIN with and for the item if<br />
they have been added to the sync list.<br />
Confirm: RDP sends EAN.UCC message with .<br />
Confirm: RDP receives the CIN for the corrected, cancelled item from the respective<br />
SDP, and CIN contains a correctly populated "cancelDate".<br />
Verify: RDP emails CIN messages to DGI-<strong>GDSN</strong>-Support.<br />
Copyright © Drummond Group Inc. 2005 <strong>GDSN</strong> 3Q05 <strong>Final</strong> <strong>Report</strong> page 24
<strong>GDSN</strong> <strong>Test</strong> Task #6<br />
Overview: SDP Discontinues a Catalog Item<br />
<strong>GS1</strong> Use Cases Covered: Catalogue Sync: UC-6, UC-20, UC-29<br />
Purpose: Each participant will create a discontinue date to an existing registered item that is<br />
unique in category code, GLN, GTIN.<br />
Prerequisite Condition: Task 4 is complete.<br />
<strong>Test</strong>ing Procedure: An item which has been synchronized will be discontinued and the sync list<br />
trading partners will be updated.<br />
<strong>Test</strong> Step 6.1:<br />
Description: Each SDP will change an item by populating the "discontinuedDate" to the<br />
current date of test execution. They will then send a RCI with<br />
to GR. The item to use<br />
will be determined at test time by DGI.<br />
Confirm: GR returns a CIRR message with .<br />
Confirm: GR populates "discontinuedDate" to today's date and populates "deletionDate"<br />
to 48 months later. This is to insure GR is functioning properly and does not affect the<br />
data pools certification status.<br />
Confirm: GR returns EAN.UCC response message.<br />
Verify: Each SDP will email the RCI message to DGI-<strong>GDSN</strong>-Support.<br />
<strong>Test</strong> Step 6.2:<br />
Description: Each DS/SDP will send a CIN with with for the item to their sync list trading partners.<br />
Confirm: SDP receives EAN.UCC message with .<br />
Confirm: SDP sends the CIN for the discontinued item to RDPs according to the sync<br />
list, and CIN contains a populated "discontinueDate" to todays' date.<br />
Verify: SDP emails CIN messages to DGI-<strong>GDSN</strong>-Support.<br />
Copyright © Drummond Group Inc. 2005 <strong>GDSN</strong> 3Q05 <strong>Final</strong> <strong>Report</strong> page 25
<strong>Test</strong> Step 6.3:<br />
Description: RDP will receive a CIN with with for the item if they have been added to the sync list.<br />
Confirm: RDP sends EAN.UCC message with .<br />
Confirm: RDP receives the CIN for the discontinued item from the respective SDP with<br />
the correct "discontinueDate" expected in test step 6.2<br />
Verify: RDP emails CIN messages to DGI-<strong>GDSN</strong>-Support.<br />
<strong>Test</strong> Step 6.4:<br />
Description: Each SDP participant will correct the "discontinueDate" on the item from<br />
<strong>Test</strong> Step 6.1 to the new value of 4/4/2006. RCI message for item is sent to GR with a<br />
with <br />
Confirm: GR returns a CIRR message with .<br />
Confirm: RCI message contains with<br />
.<br />
Verify: SDP will email the RCI message to DGI-<strong>GDSN</strong>-Support.<br />
<strong>Test</strong> Step 6.5:<br />
Description: SDP sends a CIN with <br />
and for the item to their sync list trading<br />
partners.<br />
Confirm: SDP receives EAN.UCC message with .<br />
Confirm: SDP sends the CIN for the corrected, discontinued item to RDPs according to<br />
the sync list CIN contains a correctly populated "discontinueDate", and GR populates<br />
"discontinueDate".<br />
Verify: SDP emails CIN messages to DGI-<strong>GDSN</strong>-Support.<br />
<strong>Test</strong> Step 6.6:<br />
Description: RDP receives a CIN with <br />
and for the item if they have been added<br />
to the sync list.<br />
Confirm: RDP sends EAN.UCC message with .<br />
Confirm: RDP receives the CIN for the corrected, discontinued item from the respective<br />
SDP, and CIN contains a correctly populated "discontinueDate".<br />
Verify: RDP emails CIN messages to DGI-<strong>GDSN</strong>-Support.<br />
Copyright © Drummond Group Inc. 2005 <strong>GDSN</strong> 3Q05 <strong>Final</strong> <strong>Report</strong> page 26
<strong>GDSN</strong> <strong>Test</strong> Task #7<br />
Overview: RDP issues RFCIN<br />
<strong>GS1</strong> Use Cases Covered: Catalogue Sync: UC-22<br />
Purpose: This test task confirms basic interoperability with the <strong>GS1</strong> Global Registry through an<br />
RFCIN with each participating data pool.<br />
Prerequisite Condition: New items are registered and CIS sent and received per the Task 7<br />
Matrix.<br />
<strong>Test</strong>ing Procedure:<br />
<strong>Test</strong> Step 7.1:<br />
Description: RDP sends RFCIN to GR with isReload flag set to "true" using criteria<br />
assigned by DGI.<br />
Confirm: GR returns a EAN.UCC message with .<br />
Verify: RDP emails RFCIN message to DGI-<strong>GDSN</strong>-Support.<br />
<strong>Test</strong> Step 7.2:<br />
Description: GR distributes RFCIN to all SDPs.<br />
Confirm: SDP confirm RFCIN subscription criteria is what is expected.<br />
Verify: SDP emails RFCIN messages received from GR to DGI-<strong>GDSN</strong>-Support.<br />
<strong>Test</strong> Step 7.3:<br />
Description: With "isReload=true" in RFCIN, sync lists entries are not reset and item<br />
information is resent to RDPs according to the sync list which resolves for items not<br />
previously rejected.<br />
Confirm: SDP confirm sync list is not reset, and CIN messages are sent to correct DRs<br />
with attributes of documentStatus value="COPY", isReload="true",<br />
commandType="ADD" are set in the CIN messages.<br />
Confirm: SDP receives EAN.UCC message to each CIN sent with<br />
.<br />
Verify: SDP email CINs sent as a result of the RFCIN message.<br />
Copyright © Drummond Group Inc. 2005 <strong>GDSN</strong> 3Q05 <strong>Final</strong> <strong>Report</strong> page 27
<strong>Test</strong> Step 7.4:<br />
Description: RDP receives CINs matching sync list and criteria used in 7.1.<br />
Confirm: CINs are received for items not previously rejected, and the CIN values<br />
DocumentStatus=copy, isReload=true, commandType=add are set.<br />
Confirm: RDP returns EAN.UCC message to each CIN message with<br />
.<br />
Verify: RDP emails CIN messages to DGI-<strong>GDSN</strong>-Support.<br />
<strong>Test</strong> Step 7.5:<br />
Description: Data Pool send RFCIN to GR with isReload flag set to "false" using criteria<br />
assigned by DGI at test time using criteria of GTIN and GLN.<br />
Confirm: GR returns a EAN.UCC response with .<br />
Verify: RDP will email RFCIN messages to DGI-<strong>GDSN</strong>-Support.<br />
<strong>Test</strong> Step 7.6:<br />
Description: GR distributes RFCIN to all SDPs.<br />
Confirm: SDP confirm RFCIN subscription criteria is what is expected.<br />
Verify: SDP emails RFCIN message received from GR to DGI-<strong>GDSN</strong>-Support.<br />
<strong>Test</strong> Step 7.7:<br />
Description: With "isReload=false" in RFCIN, sync lists are reset and SDP sends all<br />
matching item information to RDPs, including those which were previously rejected.<br />
Confirm: Sync list is reset, and CIN messages are sent to correct DRs for all items on the<br />
sync list, including those previously rejected. CIN messages with values<br />
documentStatus="Original", isReload="false", commandType="Add" set.<br />
Confirm: SDP receives EAN.UCC messages for CIN messages with<br />
.<br />
Verify: SDP emails CINs sent as a result of the RFCIN message.<br />
Copyright © Drummond Group Inc. 2005 <strong>GDSN</strong> 3Q05 <strong>Final</strong> <strong>Report</strong> page 28
<strong>Test</strong> Step 7.8:<br />
Description: RDP receives CINs matching criteria from Step 7.5.<br />
Confirm: CINs are received for all matching items, and CIN values<br />
documentStatus="Original", isReload="false", commandType="Add" are set.<br />
Confirm: RDP receives EAN.UCC messages for CIN messages with<br />
.<br />
Verify: RDP emails CIN messages to DGI-<strong>GDSN</strong>-Support.<br />
<strong>Test</strong> Step 7.9:<br />
Description: BrandName is CORRECTED on items from Task 7 Matrix. Updated CINs<br />
are generated.<br />
Confirm: CINs ARE generated because sync list has been reset.<br />
Confirm: SDP receives EAN.UCC messages for CIN messages with<br />
.<br />
Verify: SDP emails CIN messages to DGI-<strong>GDSN</strong>-Support.<br />
<strong>Test</strong> Step 7.10:<br />
Description: RDP receives CINs.<br />
Confirm: RDP receives EAN.UCC messages for CIN messages with<br />
.<br />
Verify: RDP emails CIN messages to DGI-<strong>GDSN</strong>-Support.<br />
Copyright © Drummond Group Inc. 2005 <strong>GDSN</strong> 3Q05 <strong>Final</strong> <strong>Report</strong> page 29
<strong>GDSN</strong> <strong>Test</strong> Task #8<br />
Overview: Basic Item Hierarchy<br />
<strong>GS1</strong> Use Case Covered: Catalogue Sync: UC-18,3,5,25<br />
Purpose: This test task confirms basic interoperability with the <strong>GS1</strong> Global Registry through item<br />
registration from each participating data pool acting as a SDP.<br />
Prerequisite Condition: <strong>Test</strong> Task 3 is completed.<br />
<strong>Test</strong>ing Procedure: This test only involves the DS registering items through the SDP.<br />
<strong>Test</strong> Step 8.1a<br />
Description: SDP registers items 17–25. SDP sends a RCI message with<br />
for items which are assigned to them. Items<br />
are not published. Item information will be provided by DGI at test time.<br />
Confirm: GR sends a CIRR message with .<br />
Confirm: No RDP receives a CIN message.<br />
Verify: Each participant will email the RCI messages to DGI-<strong>GDSN</strong>-Support<br />
<strong>Test</strong> Step 8.1b<br />
Description: Each RDP sends CIS with <br />
messages. The subscription criteria will be provided at a later date.<br />
Confirm: GR returns a EAN.UCC message with .<br />
Verify: RDP will email CIS–ADD message to DGI-<strong>GDSN</strong>-Support<br />
Verify: GR confirms with DGI that subscriptions have been received.<br />
<strong>Test</strong> Step 8.2<br />
Description: SDP creates Hierarchy 1 using the assigned items.<br />
Hierarchies:<br />
Hierarchy 1<br />
Hierarchy 1<br />
Item 18 Case<br />
↓↓↓<br />
Item 17 Each<br />
Item 18 (Case Unit) linked to Item 17 (Consumer Unit).<br />
Copyright © Drummond Group Inc. 2005 <strong>GDSN</strong> 3Q05 <strong>Final</strong> <strong>Report</strong> page 30
<strong>Test</strong> Step 8.3<br />
Description: DS publishes Item 18 to all DRs matching a subscription from <strong>Test</strong> Task 3.<br />
CIN is generated for Item 18 containing Hierarchy 1 information.<br />
Confirm: CIN message must have and<br />
.<br />
Confirm: SDP receives EAN.UCC messages for CIN messages with<br />
.<br />
Verify: SDP emails CIN messages to DGI-<strong>GDSN</strong>-Support.<br />
<strong>Test</strong> Step 8.4:<br />
Description: All RDPs receive CINs for the Item 18 from <strong>Test</strong> Step 8.3.<br />
Confirm: RDP confirms CIN messages contains Item Hierarchy 1.<br />
Confirm: CIN message must have and<br />
.<br />
Confirm: RDP sends EAN.UCC messages for CIN messages with<br />
.<br />
Verify: RDP emails CIN messages to DGI-<strong>GDSN</strong>-Support.<br />
Copyright © Drummond Group Inc. 2005 <strong>GDSN</strong> 3Q05 <strong>Final</strong> <strong>Report</strong> page 31
<strong>Test</strong> Step 8.5:<br />
Description: All RDPs send CIC message for received CIN messages. The CIC state for<br />
each CIN message will be "SYCHRONISED". Only one CIC message will be sent for<br />
each CIN message.<br />
Confirm: RDP confirms CIC response matches expected state.<br />
Confirm: RDP receives EAN.UCC messages for CIC messages with<br />
.<br />
Verify: RDP emails each CIC to DGI-<strong>GDSN</strong>-Support<br />
<strong>Test</strong> Step 8.6:<br />
Description: All SDPs receive CIC message in accordance with the <strong>Test</strong> Step 8.5.<br />
Confirm: CIC state matches expected value from <strong>Test</strong> Step 8.5.<br />
Confirm: SDP sends EAN.UCC messages for CIC messages with<br />
.<br />
Verify: SDP emails CIC received from RDP to DGI-<strong>GDSN</strong>-Support.<br />
Copyright © Drummond Group Inc. 2005 <strong>GDSN</strong> 3Q05 <strong>Final</strong> <strong>Report</strong> page 32
<strong>GDSN</strong> <strong>Test</strong> Task #9<br />
Overview: Multiple, independent hierarchies<br />
<strong>GS1</strong> Use Cases Covered: Catalogue Item Sync: UC-38<br />
Purpose: This test process confirms Data Pools ability to handle complex item hierarchy changes<br />
and modifications.<br />
Prerequisite Condition: <strong>Test</strong> Tasks 3 and 8 completed. Items have been added to SDP and<br />
registered with GR.<br />
<strong>Test</strong> Step 9.1<br />
Description: SDP creates Hierarchies 2 and 3 using the assigned items.<br />
Hierarchy 2 & 3<br />
Hierarchy 2 Hierarchy 3<br />
Pallet Item 21 Item 22 Pallet<br />
↓↓↓<br />
Case Item 20<br />
↓↓↓<br />
Each Item 19<br />
Item 20 (Case Unit) linked to Item 19 (Consumer Unit).<br />
Item 21 (Pallet Unit) linked to Item 20 (Case Unit).<br />
Item 22 (Pallet Unit) linked to Item 20 (Case Unit).<br />
<strong>Test</strong> Step 9.2<br />
Description: DS publishes Item 21 (Pallet) and Item 22 (Pallet) to all DRs. SDP issues<br />
CINs for full hierarchy (Pallet-Case-Each) for Pallet Items 21 and 22, which where<br />
previously subscribed to in <strong>Test</strong> Task 3, to all RDPs. Only two CINs commands are sent<br />
to each subscribing RDP which can be in a single physical message or two messages.<br />
Confirm: Each CIN command must be "ADD" and state must be "REGISTERED".<br />
Confirm: SDP receives and RDP sends EAN.UCC messages for CIN messages with<br />
.<br />
↓↓↓<br />
Verify: SDP emails sent CIN messages to DGI-<strong>GDSN</strong>-Support.<br />
<strong>Test</strong> Step 9.3<br />
Description: All RDPs receive CINs for the item hierarchies from <strong>Test</strong> Step 9.2.<br />
Confirm: RDP confirms CIN messages contains Item Hierarchy 2 and 3.<br />
Confirm: CIN message must have and<br />
.<br />
Confirm: RDP sends EAN.UCC messages for CIN messages with<br />
.<br />
Verify: RDP emails CIN messages to DGI-<strong>GDSN</strong>-Support.<br />
<strong>Test</strong> Step 9.4:<br />
Copyright © Drummond Group Inc. 2005 <strong>GDSN</strong> 3Q05 <strong>Final</strong> <strong>Report</strong> page 33
Description: All Recipient Data Pools send CIC message for received CIN messages.<br />
CIC of “REJECT” issued for received Item 21 (Pallet) and CIC of “SYCHRONISED”<br />
issued for Item 22 (Pallet).<br />
Confirm: RDP receives EAN.UCC messages for CIN messages with<br />
.<br />
Verify: RDP emails sent CIC messages to DGI-<strong>GDSN</strong>-Support<br />
<strong>Test</strong> Step 9.5:<br />
Description: All SDPs receive CIC messages in accordance with the <strong>Test</strong> Step 9.4<br />
Confirm: CIC state matches expected value from <strong>Test</strong> Step 9.4<br />
Confirm: SDP sends EAN.UCC messages for CIC messages with<br />
.<br />
Verify: SDP emails CIC messages received from RDP to DGI-<strong>GDSN</strong>-Support.<br />
<strong>Test</strong> Step 9.6:<br />
Description: SDP issues a Correct on Item 19 (Each) per DGI’s Instructions. A new CIN<br />
generated on Item 22 (Pallet) only.<br />
Confirm: CIN command must be "CORRECT" and state must be "REGISTERED".<br />
Confirm: CIN generated for Item 22 but NOT Item 21.<br />
Confirm: SDP receives EAN.UCC messages for CIN messages with<br />
.<br />
Verify: SDP emails CIN messages sent to DGI-<strong>GDSN</strong>-Support.<br />
<strong>Test</strong> Step 9.7:<br />
Description: RDP receives CIN on Item 22 only.<br />
Confirm: RDP sends EAN.UCC messages for CIN messages with<br />
.<br />
Verify: RDP will email CIN messages received to DGI-<strong>GDSN</strong>-Support.<br />
Copyright © Drummond Group Inc. 2005 <strong>GDSN</strong> 3Q05 <strong>Final</strong> <strong>Report</strong> page 34
<strong>GDSN</strong> <strong>Test</strong> Task #10<br />
Overview: Complex Hierarchies<br />
<strong>GS1</strong> Use Cases Covered: Catalogue Item Sync: UC-38<br />
Purpose: This test process confirms Data Pools ability to handle multiple, independent, item<br />
hierarchy.<br />
Prerequisite Condition: <strong>Test</strong> Tasks 3 and 8 completed and the following Hierarchy is created<br />
Description: SDP creates Hierarchy 4 using the assigned items.<br />
Hierarchy 4<br />
Hierarchy 4<br />
Item 25 Pallet<br />
↓↓↓<br />
Item 24 Case<br />
↓↓↓<br />
Item 23 Each<br />
Item 24 (Case Unit) linked to Item 23 (Consumer Unit).<br />
Item 25 (Pallet Unit) linked to Item 24 (Case Unit).<br />
<strong>Test</strong> Step 10.1:<br />
Description: Data Source publishes Item 25 (Pallet) matching subscription from <strong>Test</strong><br />
Task 3. SDP issues CIN for Item 25 (Pallet Level Item). Only one CIN sent to each<br />
subscribing RDP.<br />
Confirm: CIN command must be "ADD" and state must be "REGISTERED".<br />
Confirm: Each CIN must contain Item 25 (Pallet), Item 24 (Case) and Item 23 (Each).<br />
Confirm: SDP receives EAN.UCC messages for CIN messages with<br />
.<br />
Verify: SDP emails CIN message to DGI-<strong>GDSN</strong>-Support.<br />
<strong>Test</strong> Step 10.2:<br />
Description: RDP receive CIN for Hierarchy 4.<br />
Confirm: RDP confirms CIN hierarchy matches 10.1.<br />
Confirm: RDP sends EAN.UCC messages for CIN messages with<br />
.<br />
Verify: RDP emails each CIN message to DGI-<strong>GDSN</strong>-Support<br />
Copyright © Drummond Group Inc. 2005 <strong>GDSN</strong> 3Q05 <strong>Final</strong> <strong>Report</strong> page 35
<strong>Test</strong> Step 10.3:<br />
Description: RDP send CIC message for received CIN messages. CIC of<br />
“SYCHRONISED” issued for Item 25.<br />
Confirm: RDP receives EAN.UCC messages for CIN messages with<br />
.<br />
Verify: RDP emails each CIC message to DGI-<strong>GDSN</strong>-Support<br />
<strong>Test</strong> Step 10.4:<br />
Description: SDP receive CIC message of “SYCHRONISED” issued for Item 25.<br />
Confirm: SDP confirms CIC response matches expected state.<br />
Confirm: SDP sends EAN.UCC messages for CIN messages with<br />
.<br />
Verify: SDP emails each CIC message to DGI-<strong>GDSN</strong>-Support<br />
Copyright © Drummond Group Inc. 2005 <strong>GDSN</strong> 3Q05 <strong>Final</strong> <strong>Report</strong> page 36
<strong>Test</strong> Step 10.5:<br />
Description: DS publishes Item 24 (Case) matching subscription from <strong>Test</strong> Task 3. SDP<br />
issues CIN for Item 24 (Case). This creates a new item hierarchy, Hierarchy 5. Only one<br />
CIN for Hierarchy 5 is sent to each subscribing RDP.<br />
Hierarchy 4<br />
Hierarchy 4<br />
Item 25 Pallet<br />
↓↓↓<br />
Item 24 Case<br />
↓↓↓<br />
Item 23 Each<br />
Item 24 (Case Unit) linked to Item 23 (Consumer Unit).<br />
Item 25 (Pallet Unit) linked to Item 24 (Case Unit).<br />
Hierarchy 5<br />
Hierarchy 5<br />
Item 24 Case<br />
↓↓↓<br />
Item 23 Each<br />
Confirm: Each CIN command must be "ADD" and state must be "REGISTERED".<br />
Confirm: Each CIN must contain only Item 24 (Case) and Item 23 (Each).<br />
Confirm: SDP receives and RDP sends EAN.UCC messages for CIN messages with<br />
.<br />
Verify: SDP emails CIN messages sent to DGI-<strong>GDSN</strong>-Support.<br />
Verify: RDP emails CIN messages received to DGI-<strong>GDSN</strong>-Support.<br />
<strong>Test</strong> Step 10.6:<br />
Description: RDPs receive CIN from 10.6.<br />
Confirm: Each CIN command must be "ADD" and state must be "REGISTERED".<br />
Confirm: Each CIN must contain only Item 24 (Case) and Item 23 (Each).<br />
Confirm: RDP sends EAN.UCC messages for CIN messages with<br />
.<br />
Verify: RDP emails CIN messages sent to DGI-<strong>GDSN</strong>-Support.<br />
Copyright © Drummond Group Inc. 2005 <strong>GDSN</strong> 3Q05 <strong>Final</strong> <strong>Report</strong> page 37
<strong>Test</strong> Step 10.7:<br />
Description: All RDPs send CIC message for received CIN messages. CIC of<br />
“Synchronized” issued for Item 24 (Case).<br />
Confirm: SDP confirms CIC response matches expected state.<br />
Confirm: RDP receives EAN.UCC messages for CIC messages with<br />
.<br />
Verify: RDP emails CIC messages sent to DGI-<strong>GDSN</strong>-Support.<br />
<strong>Test</strong> Step 10.8:<br />
Description: SDPs receive CIC message for received CIN messages. CIC of<br />
“Synchronized” issued for Item 24 (Case).<br />
Confirm: SDP confirms CIC response matches expected state.<br />
Confirm: SDP sends EAN.UCC messages for CIC messages with<br />
.<br />
Verify: RDP emails CIC messages sent to DGI-<strong>GDSN</strong>-Support.<br />
<strong>Test</strong> Step 10.9:<br />
Description: SDP issues Correct on Item 23 (Each) per DGI’s Instructions. A CIN for<br />
Item 25 (Pallet level hierarchy, Hierarchy 4) and a CIN for Item 24 (Case level hierarchy,<br />
Hierarchy 5) is generated to RDPs according to synchronization list.<br />
Confirm: Each CIN command must be "CORRECT" and state must be "REGISTERED".<br />
Confirm: SDP receives EAN.UCC messages for CIN messages with<br />
.<br />
Verify: SDP emails each CIN message sent to DGI-<strong>GDSN</strong>-Support.<br />
<strong>Test</strong> Step 10.10:<br />
Description: RDP receives a CIN for Item 25 (Pallet level hierarchy, Hierarchy 4) and a<br />
CIN for Item 24 (Case level hierarchy, Hierarchy 5).<br />
Confirm: Each CIN command must be "CORRECT" and state must be "REGISTERED".<br />
Confirm: RDP sends EAN.UCC messages for CIN messages with<br />
.<br />
Verify: RDP emails each CIN message received to DGI-<strong>GDSN</strong>-Support.<br />
Copyright © Drummond Group Inc. 2005 <strong>GDSN</strong> 3Q05 <strong>Final</strong> <strong>Report</strong> page 38
<strong>Test</strong> Step 10.11:<br />
Description: RDP send CIC message for received CIN messages. CIC of<br />
“SYCHRONISED” issued for CIN of Item 25 (Pallet). CIC of “REJECT” issued for CIN<br />
Item 24 (Case).<br />
Confirm: RDP receives EAN.UCC messages for CIC messages with<br />
.<br />
Verify: RDP emails each CIC sent to DGI-<strong>GDSN</strong>-Support.<br />
<strong>Test</strong> Step 10.12:<br />
Description: SDP receives CIC of “SYCHRONISED” issued for CIN of Item 25 (Pallet).<br />
CIC of “REJECT” issued for CIN Item 24 (Case).<br />
Confirm: SDP confirms received CIC response matches expected state.<br />
Confirm: SDP sends EAN.UCC messages for CIC messages with<br />
.<br />
Verify: SDP emails each CIC received to DGI-<strong>GDSN</strong>-Support.<br />
<strong>Test</strong> Step 10.13:<br />
Description: SDP issues Correction on Item 23 (Each Level) per DGI’s Instructions. A<br />
new CIN is generated for Item 25 (Pallet level hierarchy, Hierarchy 4) only. Item 24<br />
(Case level hierarchy, Hierarchy 5) is not generated because it was previously<br />
REJECTED.<br />
Confirm: SDP receives EAN.UCC messages for CIN messages with<br />
.<br />
Verify: SDP will email each CIN message sent to DGI-<strong>GDSN</strong>-Support.<br />
<strong>Test</strong> Step 10.14:<br />
Description: RDP receives CIN for Item 25 (Pallet level hierarchy, Hierarchy 4) only.<br />
Confirm: RDP sends EAN.UCC messages for CIN messages with<br />
.<br />
Verify: RDP will email each CIN messages received to DGI-<strong>GDSN</strong>-Support.<br />
Copyright © Drummond Group Inc. 2005 <strong>GDSN</strong> 3Q05 <strong>Final</strong> <strong>Report</strong> page 39
<strong>GDSN</strong> <strong>Test</strong> Task #11<br />
Overview: RDP issues CIS Delete<br />
<strong>GS1</strong> Use Cases Covered: Catalogue Sync: UC-35<br />
Purpose: This test process confirms ability to delete item subscriptions between Global Registry<br />
and Data Pools.<br />
Prerequisite Condition: Task 4 has been completed.<br />
<strong>Test</strong>ing Procedure: For this test, each data pool will act as a SDP and RDP. This test task<br />
confirms basic interoperability with the <strong>GS1</strong> Global Registry through CIS Delete<br />
which triggers <strong>GDSN</strong> network messages across multiple data pools.<br />
<strong>Test</strong> Step 11.1:<br />
Description: All RDPs send CIS with to<br />
GR. GR will distribute CIS–Delete messages to SDPs. The subscription criteria will be<br />
supplied by DGI at test time.<br />
Confirm: GR returns a EAN.UCC message with .<br />
Confirm: GR confirms Subscriptions Delete messages received and delivered.<br />
Verify: RDP will Email CIS – Delete message to DGI-<strong>GDSN</strong>-Support.<br />
<strong>Test</strong> Step 11.2:<br />
Description: All SDPs receive CIS Delete from Global Registry.<br />
Confirm: CIS-Delete subscription criteria matches <strong>Test</strong> Step 11.1.<br />
Verify: SDP emails CIS–Delete messages received from GR to DGI-<strong>GDSN</strong>-Support<br />
Copyright © Drummond Group Inc. 2005 <strong>GDSN</strong> 3Q05 <strong>Final</strong> <strong>Report</strong> page 40
<strong>Test</strong> Step 11.3:<br />
Description: DS of the SDP adds a publication for a item which was previously<br />
unpublished and matched a subscription criteria recently deleted. Without a subscription<br />
criteria in place, no CIN message should be published to any data pool. The item to be<br />
used will be selected by DGI at test time.<br />
Confirm: No CIN message is sent or received.<br />
<strong>Test</strong> Step 11.4:<br />
Description: DS of the SDP does a CORRECT on an item in the sync list which is not<br />
previously rejected. CIN will be generated from the sync list.<br />
Confirm: CIN is sent according to the sync list, and each CIN command must be<br />
"CORRECT" and state must be "REGISTERED".<br />
Confirm: SDP receives and RDP sends EAN.UCC messages for CIN messages with<br />
.<br />
Verify: SDP emails each CIN message sent to DGI-<strong>GDSN</strong>-Support.<br />
Verify: RDP emails each CIN messages received to DGI-<strong>GDSN</strong>-Support.<br />
NOTE: This test step verifies the sync list functionality. While the item was added to the<br />
sync list after a publish on a subscription match, the subscription no longer is<br />
needed for the item to remain on the sync list. Even after the subscription is<br />
deleted, the item will continue to be published. This conforms with Business<br />
Rule# 141 in the CIS BMS.<br />
Copyright © Drummond Group Inc. 2005 <strong>GDSN</strong> 3Q05 <strong>Final</strong> <strong>Report</strong> page 41
<strong>GDSN</strong> <strong>Test</strong> Task #12<br />
Overview: Publication Delete<br />
<strong>GS1</strong> Use Cases Covered: Catalogue Sync: UC-34<br />
Purpose: This test process confirms ability to delete item publication and remove item from sync<br />
list.<br />
Prerequisite Condition: Task 4 has been completed.<br />
<strong>Test</strong>ing Procedure:<br />
<strong>Test</strong> Step 12.1:<br />
Description: DS issues a removes publication to some DR from the SDP. The publication<br />
and the DR will be selected by DGI at test time. The SDP generates a CIN with<br />
to the data recipient(s). The CIN has the<br />
same item state as in the GR. After removing the publication, the SDP will either<br />
physically or logically delete the entry from the sync list. By logically deleting this entry,<br />
SDP will mark the sync list entry as deleted and block future notifications generated on<br />
this item from the sync list.<br />
Confirm: SDP generates proper CIN–Delete message to RDP matching the sync list.<br />
Confirm: SDP receives EAN.UCC messages for CIN messages with<br />
.<br />
Verify: SDP emails CIN–Delete messages sent to DGI-<strong>GDSN</strong>-Support.<br />
<strong>Test</strong> Step 12.2:<br />
Description: RDP receives CIN with .<br />
RDP notifies its data recipient of Publication Delete for the item.<br />
Confirm: RDP sends a EAN.UCC message with .<br />
Confirm: RDP receives proper CIN–Delete message from DS/SDP for the item.<br />
Verify: RDP will email CIN–Delete messages received to DGI-<strong>GDSN</strong>-Support.<br />
Copyright © Drummond Group Inc. 2005 <strong>GDSN</strong> 3Q05 <strong>Final</strong> <strong>Report</strong> page 42
<strong>Test</strong> Step 12.3:<br />
Description: DS/SDP changes an item and issues a CIN with<br />
for the item from <strong>Test</strong> Step 12.1. DRs<br />
which have the publication deleted will not receive CIN but other DRs still within the<br />
sync list will receive CIN.<br />
Confirm: CIN sent ONLY to DR/RDP still on sync list .<br />
Confirm: SDP receives EAN.UCC messages for CIN messages with<br />
.<br />
Verify: SDP emails CIN messages sent to DGI-<strong>GDSN</strong>-Support.<br />
<strong>Test</strong> Step 12.4:<br />
Description: DRs/RDPs not removed from sync list receive CIN with<br />
for the item from <strong>Test</strong> Step 12.3.<br />
Confirm: RDP sends EAN.UCC messages for CIN messages with<br />
.<br />
Confirm: CIN received ONLY by DR/RDP still on sync list with<br />
.<br />
Verify: RDP emails CIN messages received to DGI-<strong>GDSN</strong>-Support.<br />
Copyright © Drummond Group Inc. 2005 <strong>GDSN</strong> 3Q05 <strong>Final</strong> <strong>Report</strong> page 43
About Drummond Group Inc.<br />
Drummond Group Inc. (DGI) is an independent, privately held company<br />
that works with software vendors, vertical industries and the standards<br />
community to drive adoption for standards by conducting interoperability<br />
and conformance testing, publishing related strategic research and<br />
developing vertical industry strategies. Founded in 1999, DGI represents<br />
best-of-breed in the industry on linking horizontal infrastructure<br />
technologies, standards and interoperability issues with the needs of<br />
vertical industries such as retail, grocery, health care, transportation,<br />
government and automotive. For more information, please visit<br />
www.drummondgroup.com or email: info@drummondgroup.com.<br />
Copyright © Drummond Group Inc. 2005 <strong>GDSN</strong> 3Q05 <strong>Final</strong> <strong>Report</strong> page 44