AS2 Testing Draft - GS1



Drummond Group Inc.

Global Data Synchronization Network (GDSN)

CERTIFICATION TEST PLAN

VERSION 1.4

3Q05 INTEROPERABILITY TEST EVENT

Test Criteria, Rules and Methodology

Prepared and facilitated by:

Drummond Group Inc.



Copyright © Drummond Group Inc. 2005

All rights, domestic and international, reserved. This document, in whole or in part, may not be distributed to any entity other than those formally enrolled in this specific test event.

Contents

Test Plan Amendments 1

Introduction 2

Overview 2

Purpose 2

Test History 2

Disclaimer on Test Procedure 2

Disclaimer on Test Criteria 2

No Warranty Implied by This Process from GS1 GDSN or Drummond Group Inc. 3

Antitrust Statement 3

Standard Basis for Test Criteria 3

Binding Arbitration 3

Test Event Time Line 3

DGI Interoperability and Compliance Process 5

Definitions 5

Certification of Data Pools 6

Test Process Description 6

Test Process Check Points 7

Test Pace 7

Test Procedure for Data Pool to GS1 8

Test Criteria Dispute Resolution Involving GS1 8

Test Procedure for Data Pool to Data Pool 8

Test Criteria Dispute Resolution for Data Pool to Data Pool 8

Test Participation Rules and Expectations 10

Test Overview 10

Test Etiquette 10

Test Data 11

Test-Criteria 12

GDSN Test Tasks Description 12

Definitions of Acronyms 12

GDSN AS2 Messaging Requirements 13

GDSN Test Task Conformance Requirements 13

GDSN Test Task #1 14

GDSN Test Task #2 16

GDSN Test Task #3 17

GDSN Test Task #4 18

GDSN Test Task #5 20

GDSN Test Task #6 23

GDSN Test Task #7 25

GDSN Test Task #8 27

GDSN Test Task #9 30

GDSN Test Task #10 32

GDSN Test Task #11 36

GDSN Test Task #12 38

About Drummond Group 40

Test Plan Amendments

|Date of Change |Document Version |Reason for Change |Summary of Change |

|5/26/06 |1.1 |Various corrections on test process |Numerous changes from original 1.0 draft. |

| | |and test criteria | |

|6/7/05 |1.2 |Clarity on item hierarchy |Separate out tests into different Test Tasks for clarity. |

| | | |Modified test steps involving item hierarchy for clarity. |

| | | | |

| | | | |

| | | | |

Introduction

Overview

Drummond Group Inc. (DGI) has been contracted by GS1 GDSN to develop and perform certification tests for members of the Global Data Synchronization Network (GDSN). The GDSN is a network of interoperable Data Pools and the GS1 Global Registry for communicating master data (Catalogue Item and Party) between trading partners. This certification program will confirm the interoperability and capability of participating Data Pools and the GS1 Global Registry.

Purpose

The DGI Interoperability Test will confirm that all participating Data Pools are fully capable of mandated GS1 functionality and mandated interoperable functionality.

Test History

The GDSN certification test has been developed from the initial GDSN Beta Test program. The GDSN Beta Test program was not an all-inclusive test. The GDSN Beta Test program executed limited Use Cases and Test Instances and only pair wise Data Pool testing was executed. The GDSN Beta Test was not a full matrix interoperability test.

DGI then performed the first GS1 fully interoperable certification program with an initial group of Data Pools for the 4Q04 certification test round. This test round and all subsequent certification events was performed in accordance with GS1 certification requirements as set by GDSN Task Group on certification.

Full Matrix Interoperability Test Events include:

• GDSN 4Q04 Interoperability Certification Event October-December 2004

Disclaimer on Test Procedure

This document is often refined with each test certification event to increase clarity and exactness. In the event there is clarity, conceptual or process inaccuracies in this document DGI will make every effort to correct. However, final interpretation of the document is solely DGI’s responsibility.

Disclaimer on Test Criteria

The test criteria section is based on GDSN business standards approved by the GDSN Task Force. The versions of the GDSN standards documents the "Test-Criteria" are listed in the section Standard Basis for Test Criteria. The "Test-Criteria" is developed from and references the use cases and business rules found in these documents. Data pools should always refer to the GDSN standards for messaging and implementation requirements. The GDSN standards are assumed to be correct if the "Test-Criteria" in the test plan is found to be different. The “Test-Criteria” listed here should not be inferred to be the minimal implementation requirements for your software. The “Test-Criteria” is a representative set of Use Cases for GDSN Interoperability, as agreed to by the GDSN Task Group.  However, DGI does not claim, nor intends, that the test criteria spelled out here are a complete and exhaustive set of test criteria. It is the Data Pools responsibility to ensure complete and accurate implementation of their software in accordance to the GDSN Business standards.

No Warranty Implied by This Process from GS1 GDSN or Drummond Group Inc.

DGI will define the tests, manage the testing, and record and publish the testing results. DGI can only attest to the interoperability of the specific group of Data Pools-with-version-with -release for a specific test round period. Any subsequent code updates by any of the Data Pools after the completion of this interoperability test may create interoperability problems.

NEITHER DGI NOR GS1 GDSN provide to participants any warranties, either express or implied, including, but not limited to, warranties of fitness for a particular purpose and warranties of merchantability.

Antitrust Statement

During testing with other Data Pools, participants may hear or obtain information about other Data Pools, but they are not allowed to convey this information to individuals who are not involved in this interoperability test event, including individuals within your own company. The test criteria or any test instance information may not be used in any way to affect the marketplace selection of Data Pools involved in this test group.

Legally, you may not share marketing, pricing or strategy information in any manner with other members of the test group. Sharing this type of information may constitute an antitrust issue.

Standard Basis for Test Criteria

This test is designed to test the interoperability of the Data Pools and GS1 Registry over the GDSN standards. The documentation name and version of the GDSN standards governing the test criteria is listed below. Additionally, XML messaging is governed by the current GDSN 2.0.2 schema.

• BMS For Align/GDSN/Catalogue Item Synchronization, vs 2.0.4

• BMS For Align Basic Party Synchronization, vs. 0.0.2

• BRD For Validation Rules For GDSN, vs. 0.0.6

• GDSN TG Operations Manual, vs. 1.2

• BMS for Align Trade Item, vs. 9.0.3

Binding Arbitration

DGI endeavors to be vendor and association-neutral and is the only neutral party involved in the test event. DGI is the sole arbitrator of any issues for this Test Event. There is no further recourse for test event participants on a DGI decision. A decision by DGI is final and binding to all members of the Data Pool test group.

Test Event Time Line

1. Conference call with signed data pools – May 13

2. Review of this test plan and Test Criteria with data pools – May 11-16

3. Registration Deadline – April 22

4. Terms of Agreement DUE – April 29

5. First draft of Test Plan and released to participants – May 20

6. New Data Pool Testing Begins – June 27

7. Certified Data Pool Testing Begins – July 18

8. Final Run Starts – Sept 14

9. Final Run Ends; Test Ends – Sept 30

10. Final report posted, marketing and press releases issued – TBA

DGI Interoperability and Compliance Process

Definitions

Administratively failed – a Data Pool is deemed to have failed the entire Interoperability Test Event unless this is reversed by an in-depth investigation by DGI.

Administrative failure– the test status of a Data Pool which has administratively failed the entire Interoperability Test Event.

Interoperability – A Data Pool is deemed interoperable with all other Data Pools and the GS1 Registry in the Interoperability Test Event if and only if it demonstrates in a full-matrix manner the pair wise exchange of data covering the Test Criteria between all Data Pools in the Interoperability Test Event. A Data Pool is either totally interoperable or it is not interoperable.

Interoperable Data Pools – A group of Data Pools, from the Test group, which successfully completed the Test Criteria, in a full duplex manner with every other Test group participant in an interoperability Test Event without any errors in the final test Phase.

Test Group – A group of Data Pools involved in interoperability Test Event.

Data Pool, Product, or Data Pool-with-version-with-release – are interchangeable and are defined for the purpose of a Test Event as a Data Pool 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 designators. DGI assumes that any digits of less significance than the R place do not indicate code changes on the Data Pool-with-version-with-release tested in the Test Event. A Data Pool must list its software code version submitted for testing as a Data Pool, followed by version digits followed by a decimal point followed by a single release designator digit before the Test Event is complete.

Tests or test cases – The Test Criteria is a set of individual tests, often 10 to 50, which the test group exchange among themselves to verify conformance and interoperability. Tests are made up of one or more test instances.

Test criteria – A set of individual tests, based on one or more standard specifications, that are used to verify that a Data Pool is conformant to the specification(s) or that a set of Data Pools are interoperable under the Test Criteria.

Test instance – In one of the test phases one member of the test group sends a test to one other party in the test group. This single exchange at a point in time is a test instance.

Test instance result – The result of single exchange of data between two Test group participants.

Test Event – A Test group tested over a written set of Test Criteria in a specified time period for either interoperability or conformance.

Test Event Phases or Test Phases – A Test Event is split into Phases. The Phases help debug and confirm the participating Data Pools and finally verify that the Data Pools are interoperable.

Certification of Data Pools

This process only tests Data Pools-with-version-with-release. A certification is given for a specific Data Pool-with-version-with-release only. As the Data Pool version or release changes, the interoperability certification is not inherited from the Data Pool-with-version-with-release which participated and completed a previous interoperability test. This means that the interoperability certification is not perpetual. Any code changes to Data Pools after interoperability certification may create interoperability problems.

The number of Data Pools listed as certified depends on the number of Data Pools passing the test event. A Data Pool using a software package that has been previously certified must certify their own application of this software, if the Data Pool wants to be listed as a separate and distinct Data Pool. A GDSN Data Pool is any entity that calls themselves a GDSN Data Pool, markets themselves as a GDSN Data Pool, and has a unique GLN assigned to the Data Pool. Certified Data Pools will be permitted to operate within the GDSN.

A Data Pool passing the test must be listed as follows in the DGI Final Test Report:

Data Pool name-with-version-with-release

Test Results and the DGI Final Test Report with the specifics from this test will be listed on the GS1 GDSN website. All data pool participants will have a chance to review the final report before publication.

Test Process Description

A Data Pool is deemed interoperable with the test group in the Interoperability Test Event if and only if it demonstrates in a full-matrix manner the pair wise exchange of test cases in the Test Criteria during the Final Run Phase of the Interoperability Test Event. A Data Pool is either totally 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 provides 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 as is possible in an objective manner.

A DGI Interoperability Test Event has four phases. The phases are:

1. New Data Pool Conformance Testing Phase

2. Certified Data Pool Conformance Testing Phase

3. Data Pool Interoperability Testing

4. Final Run Phase

The New Data Pool Debug Testing Phase and the Certified Data Pool Debug Testing Phase is focused primarily on data pools testing with the GS1 Global Registry but will involve some data pool to data pool testing as time permits. The New Data Pool Conformance testing is for data pools who did not participant in the previous GDSN Certification Event, and the Certified Data Pool Conformance testing is for the data pools who have been certified previously. New Data Pool Conformance testing begins earlier than the Certified Data Pool Debug Conformance as certified data pools will not need as much time given their previous certification.

Data Pool Interoperability Testing Phase is focused on the interoperability of both the new and previously certified data pools over data pool-to-data pool messaging, which includes item notification, item confirmation and synchronization lists. It builds upon the GS1 Global Registry testing done in the earlier phases. It is full-matrix, which requires a data pool to complete the necessary test tasks with all other participating data pools. Data pools are expected to participate both as a source data pool and recipient data pool unless stating their intention otherwise before the start of certification testing. Through both the Conformance and Interoperability phases, code changes and retesting of the test tasks may be frequent and necessary to create a stable and interoperable test group.

The Final Run Phase is the Phase where Data Pools that demonstrate complete interoperability, based on the Test Criteria among the complete Test group, are issued the certification. The test tasks performed in the earlier Conformance and Interoperability phases are re-executed. In this phase, no error in any test instances may happen without both parties involved being declared administratively failed until further investigation by DGI. NO CODE CHANGES ARE ALLOWED FOR ANY REASON WITHIN THE FINAL RUN. Code changes automatically move the Data Pool to a status of administrative failure. Any subsequent code updates by any of the Data Pools after the completion of this interoperability test may create interoperability problems.

Test Process Check Points

Check Points are well defined places in the DGI Interoperability Process where formal decisions are conducted as to the ability of a product in the Product Test Group to proceed to the next phase of the test round. A product may not proceed to the subsequent phase for the following reason:

1. Not completing all test criteria before the start of the Final Run Test Phase precludes participation in the Final Run Test Phase of an interoperability test round.

Test Pace

The testing process proceeds at the pace of 75 percent or more of the test group. As 75 percent complete a test step or test phase, the next test step or test phase is initiated. Up to a week notice is given for the start of the next step or phase once 75 percent of the test group has completed the previous step or phase. Data pool participants who fall behind in the testing will first be notified of their status and informed of the need to come up to pace. If they continue to stay behind the other data pool participants and delay testing, they will be removed from the test event.

Test Procedure for Data Pool to GS1

Data pools are required to complete the required test tasks involving the GS1 Global Registry as found in the Test Criteria section. DGI will inspect and verify the test results through information reported by the Data Pool and the GS1 Registry. Also, DGI will schedule and coordinate testing among the Data Pools.

Test Criteria Dispute Resolution Involving GS1

In testing with the GS1 Global Registry, it is assumed the Global Registry is correct in its message handling and processing. If a problem occurs with the GS1 Global Registry, it is the responsibility of the data pool to resolve the problem or demonstrate that the GS1 Global Registry is in error. If an error occurs during the Final Run, the Data Pool is not allowed to make code changes for test case correction and will be moved to a status of administrative failure unless the problem is clearly due to a failure of the GS1 Global Registry.

Test Procedure for Data Pool to Data Pool

Data pools are required to complete the required test tasks involving testing with other data pools as found in the Test Criteria section. Data Pools are required to validate the inbound messages received from the other Data Pool participants according to the criteria of the test tasks. If problems are found with messages of the other Data Pools, the Data Pool participant must notify DGI and the test group of the problem. DGI will inspect and verify the test results through information reported by the Data Pools. Also, DGI will schedule and coordinate testing among the Data Pools.

Test Criteria Dispute Resolution for Data Pool to Data Pool

When an error dispute occurs and a test task can not be completed per the test description and criteria, one or both of the Data Pools involved must take steps to resolve the problem. If the error occurs between a previously certified Data Pool and new Data Pool, the certified Data Pool is assumed to be correct until the new Data Pool can clearly prove otherwise. If the error fault is unclear, it is the responsibility of the new Data Pool to make the necessary changes to be interoperable with the previously certified Data Pool.

If the error is between two previously certified Data Pools or two new Data Pools, both are equally responsible for identifying the error and resolving it.

If the problem is due to the transmitted message being obviously outside of the GDSN standard(s) and the test criteria, the Data Pool that sent the message is responsible for the error and must make the necessary changes to complete the test instance.

If there is a need to interpret a standard or set of standards to achieve interoperability, DGI will consult with the Task Force for resolution of the issue, but DGI has the right to make a final decision to facilitate interoperability of the entire test group.

If an error dispute occurs during the Final Run, the Data Pools involved with the dispute are not allowed to make code changes for test instance correction and will be moved to a status of administrative failure. DGI will investigate the error, and if it is determined one Data Pool is not responsible for the error per the rules described above, that Data Pool will be moved from the status of administrative failure.

Test Participation Rules and Expectations

Test Overview

This section of the document explains the specific technical and resource requirements for this Test Event, GDSN 3Q05 Interoperability.

1. Drummond Group is responsible for the overall coordination of the test as well as documenting and distributing the test results.

2. Internal allocation of resources for each test participant must be sufficient to complete the testing in a timely manner as determined by DGI.

3. Coordination of the project will come primarily from a daily conference call – 10:00 AM CDT – to be held throughout the test period. Attendance at these calls is mandatory.

4. Communication will also occur through an email list server, which allows any participant to simultaneously send to all other participants.

5. Participants will be responsible for testing their respective Data Pools over the Internet, although there may be some special arrangements at a specified location to facilitate testing.

6. Participants found to be doing performance testing against other test group participants or the global registry will be removed from the Test Event.

7. Within each Phase of testing, participants have to provide a copy of the XML payloads from messages they have sent and received, screen shots and other material per DGI request confirming test instance success.

8. All tests as described in this document should be conducted with all participants in a timely manner. DGI will provide direction on when test cases are schedule and as appropriate with whom.

Test Etiquette

DGI reserves the right to remove anyone from the testing process who is unsupportive of this Interoperable Testing Environment. This may include but is not limited to:

• Unresponsiveness to request for error resolution.

• Excessive delays in completing testing requirements and error resolution.

• Lack of participation in required conference calls.

• Hostility towards other participants and/or companies.

• Lack of support for DGI resolution of issues.

• Benchmarking of performance against other Data Pools in the test group is not allowed.

• Using information gained from another Data Pools in the test group in the test in a market negative manner.

In some cases, participants will receive a DGI Interoperability Alert requiring corrective action on their part for a violation of test etiquette. If a participant does not meet the stated responsibilities in the time frame specified in the DGI Interoperability Alert, they will be removed from the test event.

If confidential information is to be revealed during the course of testing, companies should identify such information in writing along with a written notice of the confidential nature of the information. This marked information is not be utilized outside of the test.

Test Data

DGI will provide the item data and other necessary information to complete the Test Criteria. Data Pools will be required to supply GLN and party information for their data source and data recipient trading partners which are necessary to complete testing.

Test-Criteria

The Test Criteria will consist of testing the Use Cases as described in the GDSN BMS documents. The Use Cases will be tested in scenarios called Test Tasks which reflect sequential actions taken by the Data Pools and the GS1 Global Registry.

GDSN Test Tasks Description

Each GDSN Test Tasks contains the actions and responsibilities required by the Data Pool participant. The Test Task covers requirements set by the GDSN standards for the minimum functionality needed to support full data pool to data pool interoperability and certification.

Each Test Task contains “Test Steps” which describe the actions required to complete the Test Task. The “Description” sub-section describes the goal of the Test Step including the type of GDSN message is to be sent and/or received or action to be performed. “Confirm” indicates what the Data Pool must check and confirm to verify the Test Step was done. The “Verify” sub-section details the information which the Data Pool must provide to DGI corroborating the result expected in the “Confirm” step. Where you see DGI-GDSN-Support, please interpret as a request to email to GDSNSupport@. Messages submitted to the Drummond Group will be used for message verification purposes and archival documentation of certification steps executed. The messages in reference are to be the XML payload only. The actual AS2/HTTP message and MDN is not needed, but only the XML payload.

Definitions of Acronyms

The following defines acronyms used throughout the Test Tasks:

DGI Drummond Group, Inc.

RDP Recipient Data Pool

SDP Source Data Pool

DS Data Source trading partner of the SDP

DR Data Recipient trading partner of the RDP

RCI Register Catalogue Item

CIN Catalogue Item Notification

CIC Catalogue Item Confirmation

CIS Catalogue Item Subscription

CIRR Catalogue Item Registration Response

RFCIN Request For Catalogue Item Notification

GDSN Global Data Synchronization Network

GR GS1 Global Registry

GTIN Global Trade Identification Number

GLN Global Location Number

GDSN AS2 Messaging Requirements

All GDSN messages, both between Data Pools and Global Registry and Data Pool–to–Data Pool, require a valid MDN to be returned. A GDSN message is not complete unless a valid MDN is returned. A valid MDN is one that is signed and contains the proper MIC value in the Received-Content–MIC header.

For Data Pool–to–Global Registry and Data Pool–to–Data Pool GDSN messages, a valid EAN.UCC response must be returned. If a valid EAN.UCC response is not returned or a response with an EAN.UCC error code is returned, the test step is not successful. An EAN.UCC response is not required for by the data pool on Global Registry–to–Data Pool messages. For an EAN.UCC response message, an MDN must be returned for it to be considered sent and successful.

The following AS2 messaging security is required on all messages:

• Every message must request a synchronous MDN.

•

• Messages and MDNs must be signed.

• S/MIME encryption must be used.

• Compression must not be used.

These requirements are only for interoperability certification testing and are not GDSN production environment guidelines.

GDSN Test Task Conformance Requirements

Data Pools will be required to create messages which correspond to the GDSN Validation Rules documentation. Messages submitted by the data pools to DGI will be checked and verified by DGI for conformance to these validation rules. Also, data pools should verify messages themselves and if a problem is found, notify by DGI and the other data pool. If a validation rule is violated in a message required by a test step, that test step is not considered successfully completed by the data pools involved with the message.

These validation rules are found in the BRD for Validation Rules of GDSN, version 0.0.6., and data pool participants should refer to the GDSN validation document itself for more details. If these rules are violated, an appropriate exception message must be generated.

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

Test Step 1.2:

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.

Test Step 1.3:

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

Test Step 1.4:

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.

GDSN Test Task #2

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.

Test Step 2.1:

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 response. with .

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

Test Step 2.2:

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.

GDSN Test Task #3

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.

Test Step 3.1:

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.

Test Step 3.2:

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.

Test Step 3.3:

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.

Confirm: GR returns a EAN.UCC message with .

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

Verify: GR confirms to DGI that subscriptions were received.

GDSN Test Task #4

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.

Test Step 4.1:

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.

Test Step 4.2:

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

Confirm: RDP confirms CIN matches expected item data.

Confirm: CIN message must have and .

Confirm: RDP returns EAN.UCC messages with for each CIN message received.

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

Test Step 4.3: 

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

Test Step 4.4: 

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.

GDSN Test Task #5

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.

Prerequisite Condition: Task 4 is complete.

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

Test Step 5.1: 

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.

Test Step 5.2: 

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.

Test Step 5.3: 

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.

Test Step 5.4:

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.

Test Step 5.5: 

Description: Each data source/source data pool will send a CIN with and for the item to their sync list trading partners.

Confirm: SDP receives EAN.UCC message with .

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".

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

Test Step 5.6: 

Description: RDP will receive a CIN with and 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 corrected, cancelled item from the respective SDP, and CIN contains a correctly populated "cancelDate".

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

GDSN Test Task #6

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.

Prerequisite Condition: Task 4 is complete.

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

Test Step 6.1: 

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 returns a CIRR message with .

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.

Test Step 6.2: 

Description: Each DS/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 discontinued item to RDPs according to the sync list, and CIN contains a populated "discontinueDate" to todays' date.

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

Test Step 6.3: 

Description: RDP 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 discontinued item from the respective SDP with the correct "discontinueDate" expected in test step 6.2

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

Test Step 6.4:

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.

Confirm: GR returns a CIRR message with .

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

Test Step 6.5: 

Description: SDP sends a CIN with and for the item to their sync list trading partners.

Confirm: SDP receives EAN.UCC message with .

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".

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

Test Step 6.6: 

Description: RDP receives a CIN with and 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 corrected, discontinued item from the respective SDP, and CIN contains a correctly populated "discontinueDate".

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

GDSN Test Task #7

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: Test Task 4 is complete. Some items currently synchronized and some items currently rejected.

Testing Procedure:

Test Step 7.1:

Description: RDP sends RFCIN to GR with isReload flag set to "true" using criteria assigned by DGI at test time using GLN and GPC criteria.

Confirm: GR returns a EAN.UCC message with .

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

Test Step 7.2:

Description: GR distributes RFCIN to all SDPs. With "isReload=true", sync lists 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 RFCIN subscription criteria is what is expected.

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 emails RFCIN messages received from GR to DGI-GDSN-Support.

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

Test Step 7.3:

Description: RDP receives CINs matching sync list.

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 .

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

Test Step 7.4:

Description: Change_by_refresh on item(s) previously rejected in Test Task 4 which match the RFCIN criteria from 7.1. Item(s) will be selected by DGI.

Confirm: CINs are NOT generated because sync list has not been reset.

Test Step 7.5:

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.

Test Step 7.6:

Description: GR distributes RFCIN to all SDPs. With "isReload=false", sync lists are reset and SDP sends all matching item information to RDPs, including those which were previously rejected.

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

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 RFCIN message received from GR to DGI-GDSN-Support.

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

Test Step 7.7:

Description: RDP receives CINs matching criteria from Step 8.5.

Confirm: CINs are received for all matching items, and CIN values documentStatus="Original", isReload="false", commandType="Add" are set.

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

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

Test Step 7.8:

Description: Change by refresh on item(s) previously rejected in Test Task 4. Items will be selected by DGI.

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

GDSN Test Task #8

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.1

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 returns a EAN.UCC message with .

Confirm: No RDP receives a CIN message.

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

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).

Test Step 8.3

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.

Confirm: CIN message must have and .

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

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

Test Step 8.4:

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

Confirm: RDP confirms CIN messages contains Item Hierarchy 1.

Confirm: CIN message must have and .

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

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

Test Step 8.5: 

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

Test Step 8.6: 

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.

GDSN Test Task #9

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.

Test Step 9.1

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 20 (Case Unit) linked to Item 19 (Consumer Unit).

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

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

Test Step 9.2

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.

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

Test Step 9.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).

Confirm: SDP confirms CIC response matches expected state.

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

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

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

Test Step 9.4:

Description: SDP issues Change by Refresh on Item 19 (Each) per DGI’s Instructions. A new CIN generated on Item 22 (Pallet) only.

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

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

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

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

Test Step 9.5:

Description: RDP receives CIN on Item 22 only.

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

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

GDSN Test Task #10

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.

Test Step 10.1

Description: SDP creates Hierarchy 4 using the assigned items.

Hierarchy 4

|Hierarchy 4 |

|Item 25 |Pallet |

|↓↓↓ | |

|Item 24 |Case |

|↓↓↓ | |

|Item 23 |Each |

Item 24 (Case Unit) linked to Item 23 (Consumer Unit).

Item 25 (Pallet Unit) linked to Item 24 (Case Unit).

Test Step 10.2:

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).

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

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

Test Step 10.3:

Description: All Recipient Data Pools send CIC message for received CIN messages. CIC of “SYCHRONISED” issued for Item 25.

Confirm: SDP confirms CIC response matches expected state.

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

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

Test Step 10.4:

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 |

Item 24 (Case Unit) linked to Item 23 (Consumer Unit).

Item 25 (Pallet Unit) linked to Item 24 (Case Unit).

Hierarchy 5

|Hierarchy 5 |

|Item 24 |Case |

|↓↓↓ | |

|Item 23 |Each |

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

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

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

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

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

Test Step 10.5:

Description: All RDPs send CIC message for received CIN messages. CIC of “Synchronized” issued for Item 24 (Case).

Confirm: SDP confirms CIC response matches expected state.

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

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

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

Test Step 10.6:

Description: SDP issues Change by Refresh 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 "CHANGE_BY_REFRESH" and state must be "REGISTERED".

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

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

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

Test Step 10.7:

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).

Confirm: SDP confirms received CIC response matches expected state.

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

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

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

Test Step 10.8:

Description: SDP issues Change by Refresh 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.

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

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

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

GDSN Test Task #11

Overview: RDP issues CIS Delete

GS1 Use Cases Covered: Catalogue Sync: UC-35

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.

Test Step 11.1:

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 returns a EAN.UCC message with .

Confirm: GR confirms Subscriptions Delete messages received and delivered.

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

Test Step 11.2:

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

Test Step 11.3:

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.

Test Step 11.4:

Description: DS of the SDP does a CHANGE BY REFRESH 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 "CHANGE_BY_REFRESH" and state must be "REGISTERED".

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

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.

GDSN Test Task #12

Overview: Publication Delete

GS1 Use Cases Covered: Catalogue Sync: UC-34

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:

Test Step 12.1:

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.

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

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

Test Step 12.2:

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.

Test Step 12.3:

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 .

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

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

Test Step 12.4:

Description: DRs/RDPs not removed from sync list receive CIN with for the item from Test Step 12.3.

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

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

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 or email: info@.

-----------------------

[pic]

................
................

In order to avoid copyright disputes, this page is only a partial summary.

Google Online Preview   Download