interop final report - gs1...gdsn certification event – gdsn kato, gs1 mexico and udex – had to...

GDSN Interoperability Test

Final Report Third Quarter 2006 (3Q06)

Dec. 13, 2006

Prepared & Facilitated By: DRUMMOND GROUP INC. www.drummondgroup.com

Copyright © Drummond Group Inc. 2006 GDSN 3Q06 Final Report page 1

http://www.drummondgroup.com/

Table of Contents Cover Letter .................................................................................................................................................. 3 Disclaimer ..................................................................................................................................................... 4 Interoperable Data Pools ............................................................................................................................ 5 Test History................................................................................................................................................... 7 Definitions ..................................................................................................................................................... 8 GDSN 3Q06 Interoperability Test Summary ......................................................................................... 10 DGI Interoperability Testing ..................................................................................................................... 12 Interoperability Caveats ............................................................................................................................ 13

isReload Flag in CIN ......................................................................................................................... 13 documentStatus in RFCIN................................................................................................................ 13 SBDH InstanceIdentifier vs. Message UniqueCreatorIdentification ........................................... 13 Accept A Reject Functionality .......................................................................................................... 13 Multiple Transactions ........................................................................................................................ 14 additionalClassificationAgencyName Code List............................................................................ 14 XML Namespace Prefixes ................................................................................................................ 14 CIC Response Codes ....................................................................................................................... 14 Optional Attributes ............................................................................................................................. 14

Test Criteria ................................................................................................................................................ 16 GDSN Test Task #1 .......................................................................................................................... 16 GDSN Test Task #2 .......................................................................................................................... 18 GDSN Test Task #3 .......................................................................................................................... 19 GDSN Test Task #4 .......................................................................................................................... 20 GDSN Test Task #5 .......................................................................................................................... 22 GDSN Test Task #6 .......................................................................................................................... 26 GDSN Test Task #7 .......................................................................................................................... 30 GDSN Test Task #8 .......................................................................................................................... 35 GDSN Test Task #9 .......................................................................................................................... 40 GDSN Test Task #10 ........................................................................................................................ 42

About Drummond Group Inc. ................................................................................................................... 46


Cover Letter DRUMMOND GROUP Inc. (DGI) is pleased to announce that the following Data Pools listed in this report have completed all certification requirements for the GDSN-3Q06 Interoperability Certification Test Event. This is the third interoperability certification by DGI of Data Pools using the Global Registry within GDSN. This test covered more functionality than previous GDSN certification events. DGI also worked with the Data Pools to reduce their manpower efforts during certification. The result was a certification event which accommodated an increase in the test scope while providing greater efficiency for the Data Pool participants. Please read this document carefully to fully understand what was involved with the completion of this certification event, specifically the “GDSN 2006 Interoperability Test Summary” section on page 10. Sincerely, Rik Drummond CEO, Drummond Group Inc.


Disclaimer Drummond Group Inc. (DGI) conducts interoperability and conformance testing in a neutral test environment for various companies and organizations ("Participant"). At the end of the testing process, DGI may list the name of the Participant in the final test report along with an indication that the Participant passed the test. The fact that the name of the Participant appears in the final report is not an endorsement of the Participant or its data pool service, and DGI therefore makes no warranties, either express or implied, regarding any facet of the business conducted by the Participant.


Interoperable Data Pools The Data Pools participants completed the Interoperability Test Event using GDSN standard 2.1 BMS against the GS1 Global Registry Release January 2007.

http://www.1sync.org/

1SYNC


1SYNC

Data Pool Name: 1SYNC Item Management Release 6.1

Data Pool Name: 1SYNC UCCnet v4.0

http://www.agentrics.com/

Agentrics

http://www.bighammer.com/

Big Hammer Data Services

Data Pool Name: Gensync v5.0 Data Pool Name: Product Registry v2.1

http://www.commport.com/

Commport Communications International, Inc.

http://www.gs1gdsn.org/

GDSN KATO

Data Pool Name: CGS datapool services v2.1 release 1.0

Data Pool Name: GDSN KATO v1.0

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

GS1 Argentina

http://www.gs1co.org/

GS1 Columbia

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




http://www.agentrics.com/

http://www.bighammer.com/

http://www.commport.com/

http://www.gs1gdsn.org/

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

http://www.gs1co.org/

http://www.gs1.fr/

GS1 France

http://www.gs1mexico.org.mx/

GS1 México

Data Pool Name: Parangon v2.1 Data Pool Name: Cat@logalo v2.4

http://www.gs1uk.org/

GS1 UK

http://www.gs1ve.org/

GS1 Venezuela

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

http://www.gxs.com/

GXS

http://www.sinfos.de/

SINFOS GmbH

Data Pool Name: Data Pool Manager v7.0 Data Pool Name: SINFOS GDSN v2.1

http://www.stercomm.com/

Sterling Commerce

http://www.udex.com/

UDEX

Data Pool Name: Sterling Data Pool v2.1 Data Pool Name: UDEX Data Pool v1.0


http://www.sterlingcommerce.com

http://www.gs1.fr/

http://www.gs1mexico.org.mx/

http://www.gs1uk.org/

http://www.gs1ve.org/

http://www.gxs.com/

http://www.sinfos.de/

http://www.stercomm.com/

http://www.udex.com/

Test History This is the third GDSN Interoperability Test administered by DGI.

GDSN 3Q06 Interoperability Test: September-November 2006

Previous test

GDSN 3Q05 Interoperability Test: June–September 2005 GDSN 4Q04 Interoperability Test: October–December 2004


Definitions Data Pool – Data Pool is both a company providing data synchronization within GDSN and the software itself which provides the functionality. For the purpose of a Test Round, Data Pool is described by a name, followed by a version, followed by a single digit release. The assumption is that version and release syntax is as: “VV.Rx…x,” where VV is the version numeral designator, R is the single digit release numeral designator and x is the sub-release multiple digit numeral designator. DGI assumes that any digits of less significance than the R place do not indicate code changes on the Data Pool-with-release tested in the Test Round. A Data Pool must identify its software as Data Pool name, followed by version digits followed by a decimal point followed by a single release designator digit before the Test Round is complete. Full-Matrix Testing – This is a test process in which all participants test with one another over the same test scope. For example, in a test with 16 participants and 20 test cases, each participant tests with the other 15 participants as both originator and recipient of each of the 20 test cases for a total of 600 test instances. Full-matrix testing emulates live supply-chain trading partner relationships. Interoperability Test Event – This is a test in which Data Pools successfully demonstrate interoperability amongst each other through full-matrix testing over the entire test criteria. Interoperability – A Data Pool is deemed interoperable with all other Data Pools and the Global Registry if and only if it demonstrates in a full-matrix manner exchange of data covering the test criteria of the Interoperability Test Event. A Data Pool is either interoperable or it is not interoperable. Waivers or exceptions are not given in demonstrating interoperability for the test criteria unless the entire Data Pool Test Group and DGI agree. Interoperable Data Pools – The group of Data Pools, from the Data Pool Test Group, which successfully completed the Test Criteria, in a full duplex manner with every other Data Pool Test Group participant in an Interoperability Test Round without any errors in the Final Test Phase. Data Pool Test Group or Test Group – A group of Data Pools involved in an interoperability or conformant Test Event. Also, the GS1 Global Registry is included in this group since its participation is mandatory.


Test Instance– An executed test case. Every time a test case is executed it is considered a test instance. Test Case or Test Step – This is a specific action that a Data Pool must fulfill, in addition to the response of the expected action. It is the most basic step to determining GDSN conformance and interoperability. Test Task – A set of collective test cases, often 10-20, representing specific GDSN function. Test Criteria – A set of individual Test Tasks, based on the GDSN standard specification, that is used to verify that a Data Pool is conformant to the specification(s) and interoperable amongst the Test Group.


GDSN 3Q06 Interoperability Test Summary The purpose of this test is to provide a venue for Data Pools to test and correct their GDSN software in a non-competitive environment. To accomplish this, each Data Pool interacts with the GS1 Global Registry and the other Data Pools in the Test Group sending and receiving specific GDSN messages and performing the necessary operations. Test cases involve GDSN messages and expected operations derived from “use cases” from within the 2.1 GDSN Standards and are approved by GDSN. The test cases cover GDSN functionality of party registration, item registration, item subscription, item notification, item confirmation, RFCIN messaging, item sync list capability, and handling of GDSN item attributes and extensions. The 2006 GDSN Certification Event required different responsibilities for Data Pools depending on previous certification status and the Test Tasks. Test Tasks 1, 2, 3, 9.1 and 9.2 involve interaction between all Data Pools and the Global Registry. Test Steps 8.9 and 8.10 were conformance checking test cases sent by DGI to all the Data Pools. All Data Pools were required to execute new test cases, which are test cases not present in the 2005 GDSN Certification Event, in a full-matrix manner. The new test cases are found in Test Tasks 6 and 8. Test Tasks 4, 5, 7, 9.3, 9.4 and 10 were performed in the 2005 GDSN Certification Event. Data Pools certified from the 2005 GDSN Certification Event have proven their interoperability over these Test Tasks amongst each other and were not required to execute these test cases again this year with previously certified Data Pools. However, the 3 Data Pools who did not participate in the 2005 GDSN Certification Event – GDSN KATO, GS1 Mexico and UDEX – had to execute all the test steps in Test Tasks 4, 5, 7, 9.3, 9.4 and 10 in a full-matrix fashion with all Data Pools. The result was that all Data Pools have proven through testing from the 2006 GDSN Certification Event and the 2005 GDSN Certification Event to be interoperable over all test cases listed in this report. Detail information about the Test Tasks can be found later in this report. The Interoperability Test Event began September 6, 2006 and ended November 30, 2006. Early in the process, the testing was


focused on finding and correcting interoperability errors. During the Final Run Phase, from November 16 through November 30, code changes were not allowed, and the Data Pools tested with each other without error. Results of the test cases were reported and verified by each of the Data Pools through status reports, GDSN message transmissions and Global Registry reports. This final version of code from each Data Pool has been deemed interoperable amongst the Data Pool Test Group. All Data Pools listed in the previous section, “Interoperable Data Pools,” were successful in the testing without exception and were interoperable over all the test cases. No warranty of Data Pool interoperability is implied over and above the publishing of this test round’s final report.


DGI Interoperability Testing A Data Pool is deemed interoperable with the Test Group in the Interoperability Test Event if it completes the required test cases of the Test Criteria. A Data Pool is either interoperable or it is not interoperable with members of the Test Group passing the Final Run. Waivers or exceptions are not given in demonstrating interoperability for the Test Criteria unless the entire Test group and DGI agree. DGI engenders a neutral testing environment to facilitate interoperability and conformance testing. It is DGI’s purpose to facilitate interoperability among the largest group of Data Pools in the Test group in an objective manner. A DGI Interoperability Test Event has three progressively more stringent phases. The phases include: 1. Debug Phase, 2. Dry Run Phase 3. Final Run Phase Each phase becomes more and more stringent with respect to testing requirements and pass/fail criteria. The Debug Phase is for the purpose of debugging Data Pools and enhancing stability in preparation of the Dry Run phase. Code changes and retesting of the test instances are frequent and necessary to create a stable and interoperable test group. The Dry Run Phase is composed of single or multiple practice periods. The Dry Run duplicates the subsequent Final Run phase. Data pools not demonstrating interoperability over the test cases with all members of the Test Group by the end of this phase may not participate in the Final Run Phase. The Final Run Phase is the Phase where Data Pools that have successfully completed the Debug and Dry Run Phases demonstrate interoperability in executing all test cases through full-matrix testing. In this phase, no error in any test instances may occur without all parties involved being declared administratively failed until further investigation by DGI. Completion of this phase creates the certified interoperable Data Pools.


Interoperability Caveats During the Interoperability Test Event, technical and standards issues were encountered which were confusing or not addressed in the GDSN standards and required discussion amongst the Data Pool Test Group, GSMP and the GDSN Architecture Group to achieve resolution. As these issues were resolved, they were considered consensus issues as the whole Data Pool Test Group, GSMP and GDSN were in agreement with the final decision and future implementation. These decisions are reflected in the GDSN BMS 2.1 or GDSN Operations Manual 2.0 standards.

isReload Flag in CIN While not a functional change, two BMS Business Requirements have been rewritten to clarify the distinction between new item notification verses initial load item notification. BR-180: The CIN Message Must distinguish between an item already in trade as data synchronization is begun between Data Source and Data Recipient through the isReload flag equal to TRUE. BR-181: The CIN Must distinguish a new item being introduced into the supply chain through the isReload flag equal to FALSE.

documentStatus in RFCIN Verbally clarified BMS Business Requirement 168 regarding Document Status in RFCIN. Document Status can be ignored in terms of its impact upon the sync list, and thus, can be the value of either COPY or ORIGINAL.

SBDH InstanceIdentifier vs. Message UniqueCreatorIdentification These identifiers values MAY be the same value. Data Pools will use just 1 Message envelope per GDSN message thus preserving the 1–to–1 number of SBDH header and Message envelope. This has been updated in the GDSN Operations Manual.

Accept A Reject Functionality When a CIC with a non-REJECTED state is received by a SDP for an item sync list entry which was previously REJECTED, a CIN is to be generated to the RDP. It is left to the implementation of SDP and trading partner agreement with DS user on whether to query the DS for the latest item information or use what is current at the SDP. CIN is to use command of ADD and document status of ORIGINAL but isReload may be true or false.


Multiple Transactions

When receiving GDSN messages with multiple transactions, the corresponding EANUCC Responses may be multiple GDSN Response messages or in a single GDSN Response message.

additionalClassificationAgencyName Code List A GDSN Change Request has been submitted for the additionalClassificationAgencyName code list be amended to add a seventh value of "Supplier Defined" as some suppliers use their own agency code list.

XML Namespace Prefixes For GDSN messages, there are no required namespace prefixes to be used – receiving DP must accept any well–formed XML namespace prefixes – and namespaces listed in GDSN messages must only be those used within the message.

CIC Response Codes CIC Response codes can appear at any component level of a hierarchy and SDP must be able to accept any combination. The GDSN BRG Group is investigating the issue to determine if further clarification is needed.

Optional Attributes Test Step 8.1 required Data Pools to send CINs with non-mandatory item attributes in order to reflect more realistic data models. These item attributes are listed in Test Step 8.1 on page 35. Some Data Pools did not support all of these non-mandatory item attributes due to business reasons in their region. The Data Pools and the attributes not supported are listed below. CABASnet

classOfDangerousGoods dangerousGoodsRegulationCode dangerousGoodsShippingName dangerousGoodsTechnicalName dangerousGoodsPackingGroup dangerousGoodsHazardousCode dangerousGoodsAMarginNumber unitedNationsDangerousGoodsNumber flashPointTemperature isPackagingMarkedReturnable packagingMarkedRecyclableScheme minimumTradeItemLifespanFromTimeOfArrival


barCodeType importClassificationType importClassificationValue

Parangon packagingMarkedRecyclableScheme additionalClassificationCategoryDescription additionalClassificationCategoryCode suggestedRetailPrice tradeItemFinishDescription


Test Criteria GDSN Test Task #1

Overview: Basic PartySync GS1 Use Case Covered: Party Sync: UC-1, UC-2, UC-4 Purpose: This test task confirms basic party synchronization between Data Pools and the Global

Registry

Prerequisite Condition: SDP has created a DS trading partner and the RDP has recreated a DR trading partner and shared its information with the test group. Data Pool participants are required to supply the necessary GLNs.

Testing Procedure: For this test, all data pools will execute Party Registration on both Source and Recipient Data Pools.

Test Step 1.1:

Description: Both DS and DR trading partners of the Data Pool load their party data with the Data Pool. Data Pool then registers the party data with the GR with partyRegisteration message with <documentCommandHeader type="ADD">.

Party Role should clearly distinguish between suppliers and retailers. Supplier and Retailer MUST be different party roles.

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 <documentCommandHeader type="CHANGE_BY_REFRESH"> 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 all assigned items. SDP sends a RCI message with <documentCommandHeader type="ADD"> for items which are assigned to them. Items are not published. Item information will be provided by DGI at test time.

Confirm: No RDP receives a CIN message.

Confirm: GR sends CIRR with <responseStatus="ACCEPTED">.

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. Also, persistence of subscriptions is demonstrated by Global Registry.

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 <documentCommandHeader type="ADD"> messages. The subscription criteria will be provided at a later date.

Confirm: GR returns a EAN.UCC message with <responseStatus="ACCEPTED">.

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: Assigned SDPs receive CIS from GS1 from 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: DGI sends or Data Pools send CIS–Add messages for each possible combination of GTIN, GLN, GPC and TM subscriptions which do not match any items currently in the Registry are sent to the GR. Then items are registered matching these subscriptions. Global Registry generates matching CISN–Add messages.

Confirm: GR persists the subscriptions.

Confirm: GR generates proper matching CISN–Add messages.

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 <documentCommandHeader type="ADD"> and <catalogueItemState state="REGISTERED"/>.

Confirm: SDP receives EAN.UCC messages with <responseStatus="ACCEPTED"> for each CIN message sent.

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

Test Step 4.2:

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

Confirm: RDP confirms CIN matches expected item data.


Confirm: RDP returns EAN.UCC messages with <responseStatus="ACCEPTED"> for each CIN message received.

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


Test Step 4.3:

Description: Assigned 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", "SYNCHRONISED" 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 <responseStatus="ACCEPTED"> for each CIC message sent.

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

Test Step 4.4:

Description: Assigned 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 <responseStatus="ACCEPTED"> 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: RDP issues RFCIN GS1 Use Cases Covered: Catalogue Sync: UC-6, UC-7, UC-20, UC-22, UC-29 Purpose: This test task confirms basic interoperability with the GS1 Global Registry through an

RFCIN with each participating data pool.

Prerequisite Condition: New items are registered and published and CIS sent and received.

Testing Procedure:

Test Step 5.1:

Description: RDP sends RFCIN to GR with isReload flag set to "true" using criteria assigned by DGI.


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

Test Step 5.2:

Description: GR distributes RFCIN to assigned SDPs.

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

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

Test Step 5.3:

Description: With "isReload=true" in RFCIN, sync lists entries are not reset and item information is resent to RDPs according to the sync list which resolves for items not previously rejected.

Confirm: SDP confirm sync list is not reset, and CIN messages are sent to correct DRs with attributes of documentStatus value="COPY", isReload="true", commandType="ADD" are set in the CIN messages.

Confirm: SDP receives EAN.UCC message to each CIN sent with <responseStatus="ACCEPTED">.

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


Test Step 5.4:

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

Confirm: CINs are received for items not previously rejected, and the CIN values DocumentStatus=copy, isReload=true, commandType=add are set.

Confirm: RDP returns EAN.UCC message to each CIN message with <responseStatus="ACCEPTED">.

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

Test Step 5.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 <responseStatus="ACCEPTED">.

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

Test Step 5.6:

Description: GR distributes RFCIN to assigned SDPs.

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

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

Test Step 5.7:

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

Confirm: Sync list is reset to default value, 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 <responseStatus="ACCEPTED">.

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


Test Step 5.8:

Description: RDP receives CINs matching criteria from Step 5.7.

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

Confirm: RDP receives EAN.UCC messages for CIN messages with <responseStatus="ACCEPTED">.


Test Step 5.9:

Description: Each SDP will change an item by populating the "cancelDate" to the a month in the future from current date of test execution. Also, each SDP will change an item by populating the "discontinuedDate" to the a month in the future from current date of test execution. They will then send a RCI with <documentCommandHeader type="CHANGE_BY_REFRESH"> to GR. The item to use will be determined at test time by DGI.

Confirm: GR returns a CIRR message with <responseStatus="ACCEPTED">.

Confirm: GR populates "cancelDate" to the specified date and "deletionDate" to 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.

Confirm: GR populates "discontinuedDate" to the specified date and populates "deletionDate" to 30 or 48 months later depending on the GPC Brick codes. 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.

Confirm: GR returns EAN.UCC response message.

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


Test Step 5.10:

Description: Each SDP will send a CIN with <documentCommandHeader type="CHANGE_BY_REFRESH"> with <catalogueItemState state= "REGISTERED"> for the item to their sync list trading partners. Each DS/SDP will send a CIN with <documentCommandHeader type="CHANGE_BY_REFRESH"> with <catalogueItemState state="REGISTERED"/> for the item to their sync list trading partners.

Confirm: SDP receives EAN.UCC message with <responseStatus="ACCEPTED">.

Confirm: SDP sends the CIN for the cancelled item to RDPs according to the sync list and CIN contains a correctly populated "cancelDate".

Confirm: SDP sends the CIN for the discontinued item to RDPs according to the sync list and CIN contains a correctly populated "discontinueDate".

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

Test Step 5.11:

Description: RDP receives a CIN with <documentCommandHeader type="CHANGE_BY_REFRESH"> with <catalogueItemState state="REGISTERED"/> for the item if they have been added to the sync list. RDP will receive a CIN with <documentCommandHeader type="CHANGE_BY_REFRESH"> with <catalogueItemState state="REGISTERED"/> for the item if they have been added to the sync list.

Confirm: RDP sends EAN.UCC message with <responseStatus="ACCEPTED">.

Confirm: RDP receives the CIN for the cancelled item from the respective SDP with the correct "cancelDate".

Confirm: RDP receives the CIN for the discontinued item from the respective SDP with the correct "discontinueDate".



GDSN Test Task #6

Overview: Multiple, independent hierarchies; CIC Reason Code; Accept a Reject GS1 Use Cases Covered: Catalogue Item Sync: UC–26, UC-38

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

Prerequisite Condition: Test Task 3 completed. Items have been added to SDP and registered with GR.

Test Step 6.1

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

Hierarchy 2 & 3

Hierarchy 2 Hierarchy 3

Pallet Item A Item B Pallet

↓↓↓ ↓↓↓

Case Item C

↓↓↓

Each Item D

Detailed item information on Items A, B, C and D will be provided at test time.

Test Step 6.2

Description: DS publishes Item A (Pallet) and Item B (Pallet) to assigned DRs. SDP issues CINs for full hierarchy (Pallet-Case-Each) for Pallet Items A and B, which where previously subscribed to in Test Task 3, to assigned 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 <responseStatus="ACCEPTED">.

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

Test Step 6.3

Description: Assigned RDPs receive CINs for the item hierarchies from Test Step 6.2.

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



Confirm: RDP sends EAN.UCC messages for CIN messages with <responseStatus="ACCEPTED">.


Test Step 6.4:

Description: Assigned Recipient Data Pools send CIC message for received CIN messages. CIC of “REJECT” issued for received Item A (Pallet) and CIC of “REVIEW” issued for Item B (Pallet). While the CIC State, such as REJECTED, occurs at the highest level of the published hierarchy, CIC Response codes can appear at any component level of a hierarchy and SDP must be able to accept any combination. For TS 6.4, RDP are required to return the CIC with the assigned CIC fields below at the component level of their choosing.

ConfirmationStatusCode

ConfirmationStatusCodeDescription

AdditionalConfirmationStatusDescription (OPTIONAL)

CorrectiveAction (OPTIONAL)

ExpectedCorrectedInformation (OPTIONAL)

The CIC messages states, field values and RDP destination are provided by DGI at test time.

Confirm: RDP confirms CIC response matches expected state.


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

Test Step 6.5:

Description: Assigned SDPs receive CIC messages in accordance with the Test Step 6.4 including the CIC Response fields as specified by DGI.

Confirm: CIC state matches expected value from Test Step 6.4

Confirm: SDP sends EAN.UCC messages for CIC messages with <responseStatus="ACCEPTED">.

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

Test Step 6.6:

Description: SDP issues a Correct on Item D (Each) per DGI’s Instructions. A new CIN generated on Item B (Pallet) only.

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

Confirm: CIN generated for Item B but NOT Item A.



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

Test Step 6.7:

Description: RDP receives CIN on Item B only.


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

Test Step 6.8:

Description: RDP send CIC message with a state of "ACCEPTED" for Item A (Pallet).

Confirm: RDP confirms CIC expected state.

Confirm: RDP receives EAN.UCC messages with <responseStatus="ACCEPTED"> for each CIC message sent.

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

Test Step 6.9:

Description: SDP receives CIC message with a state of "ACCEPTED".

Confirm: SDP confirms CIC expected state.

Confirm: SDP resets the CIC GTIN item in its sync list.

Confirm: SDP sends EAN.UCC messages with <responseStatus="ACCEPTED"> for each CIC message sent.

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


Test Step 6.10:

Description: Depending upon trading partner agreement, SDP sends CIN–ADD on Item A from 6.9 to prove sync list entry has been updated to ACCEPTED. Command value must be "ADD" and documentStatus value must be "ORIGINAL". The isReload value may be "TRUE" or "FALSE" depending upon trading partner agreement and data pool implementation.

NOTE: SDP may choose to send CIN with current information or query DS to retrieve their current information.

Confirm: SDP sends proper CIN–ADD and documentStatus=ORIGINAL.

Confirm: SDP receives EAN.UCC messages with <responseStatus="ACCEPTED"> for each CIN message sent.

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

Test Step 6.11:

Description: RDP receives Item A from 6.10 to prove sync list has been reset. Command value must be "ADD" and documentStatus value must be "ORIGINAL". The isReload value may be "TRUE" or "FALSE" depending upon SDP agreement with its supplier and SDP implementation. RDP must accept either isReload value without generating exception.

Confirm: RDP receives proper CIN–ADD and documentStatus=ORIGINAL.

Confirm: RDP sends EAN.UCC messages with <responseStatus="ACCEPTED"> for each CIN message sent.

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


GDSN Test Task #7

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 Task 3 and the following Hierarchy is created

Description: SDP creates Hierarchy 4 using the assigned items.

Hierarchy 4

Hierarchy 4

Item E Pallet

↓↓↓

Item F Case

↓↓↓

Item G Each

Detailed item information on Items E, F and G will be provided at test time.

Test Step 7.1:

Description: Data Source publishes Item E (Pallet) matching subscription from Test Task 3. SDP issues CIN for Item E (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 E (Pallet), Item F (Case) and Item G (Each).


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


Test Step 7.2:

Description: RDP receive CIN for Hierarchy 4.

Confirm: RDP confirms CIN hierarchy matches 7.1.


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

Test Step 7.3:

Description: RDP send CIC message for received CIN messages. CIC of “SYNCHRONISED” issued for Item E.


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

Test Step 7.4:

Description: SDP receive CIC message of “SYNCHRONISED” issued for Item E.

Confirm: SDP confirms CIC response matches expected state.

Confirm: SDP sends EAN.UCC messages for CIN messages with <responseStatus="ACCEPTED">.

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

Test Step 7.5:

Description: DS publishes Item F (Case) matching subscription from Test Task 3. SDP issues CIN for Item F (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 E Pallet

↓↓↓

Item F Case

↓↓↓

Item G Each

Hierarchy 5

Hierarchy 5


Item F Case

↓↓↓

Item G Each


Confirm: Each CIN must contain only Item F (Case) and Item G (Each).



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

Test Step 7.6:

Description: RDPs receive CIN from 7.6.


Confirm: Each CIN must contain only Item F (Case) and Item G (Each).


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

Test Step 7.7:

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


Confirm: RDP receives EAN.UCC messages for CIC messages with <responseStatus="ACCEPTED">.

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

Test Step 7.8:

Description: SDPs receive CIC message for received CIN messages. CIC of “Synchronized” issued for Item F (Case).



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

Test Step 7.9:


Description: SDP issues Correct on Item G (Each) per DGI’s Instructions. A CIN for Item E (Pallet level hierarchy, Hierarchy 4) and a CIN for Item F (Case level hierarchy, Hierarchy 5) is generated to RDPs according to synchronization list.

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


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

Test Step 7.10:

Description: RDP receives a CIN for Item E (Pallet level hierarchy, Hierarchy 4) and a CIN for Item F (Case level hierarchy, Hierarchy 5).

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


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

Test Step 7.11:

Description: RDP send CIC message for received CIN messages. CIC of “SYNCHRONISED” issued for CIN of Item E (Pallet). CIC of “REJECT” issued for CIN Item F (Case).

Confirm: RDP receives EAN.UCC messages for CIC messages with <responseStatus="ACCEPTED">.

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

Test Step 7.12:

Description: SDP receives CIC of “SYNCHRONISED” issued for CIN of Item E (Pallet). CIC of “REJECT” issued for CIN Item F (Case).

Confirm: SDP confirms received CIC response matches expected state.


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

Test Step 7.13:

Description: SDP issues Correction on Item G (Each Level) per DGI’s Instructions. A new CIN is generated for Item E (Pallet level hierarchy, Hierarchy 4) only. Item F (Case level hierarchy, Hierarchy 5) is not generated because it was previously REJECTED.


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


Test Step 7.14:

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


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


GDSN Test Task #8

Overview: Item Extension and Expanded Attribute Data GS1 Use Cases Covered: Catalogue Sync: UC-37, UC-43

Purpose: This test process confirms ability for SDP to generate CINs using attributes above only mandatory. Also, confirms ability for SDP to generate CIN with extension and RDP to accept CIN with extension.

Prerequisite Condition: Task 4 has been completed but Task 8 has not been completed.

Testing Procedure:

Test Step 8.1:

Description: SDP sends CINs on two items containing expanded list of GDSN Item Attributes. Item and list of assigned attributes are contained in spreadsheet provided by DGI.

The attributes used in 8.1 are:

tradeItemUnitDescriptor informationProvider isTradeItemABaseUnit isTradeItemAConsumerUnit isTradeItemADespatchUnit isTradeItemAnOrderableUnit isTradeItemAninvoiceUnit isTradeItemAVariableUnit orderQuantityMultiple orderQuantityMinimum orderQuantityMaximum orderingLeadTime brandOwner nameOfBrandOwner manufactor nameOfManufactor netContent height width depth grossWeight netWeight lastChangeDateTime publicationDate startAvailabilityDateTime endAvailabilityDateTime classOfDangerousGoods dangerousGoodsRegulationCode dangerousGoodsShippingName dangerousGoodsTechnicalName dangerousGoodsPackingGroup dangerousGoodsHazardousCode dangerousGoodsAMarginNumber unitedNationsDangerousGoodsNumber flashPointTemperature storageHandlingTemperatureMaximum storageHandlingTemperatureMinimum functionalName variant colorCodeValue colorDescription colorCodeListAgency suggestedRetailPrice retailPriceOnTradeItem isPackagingMarkedReturnable packagingMarkedRecyclableScheme minimumTradeItemLifespanFromTimeOfArrival effectiveStartDate brandName additionalClassificationCategoryCode additionalClassificationCategoryDescription barCodeType tradeItemDescription additionalTradeItemDescription tradeItemFinishDescription importClassificationType importClassificationValue descriptionShort tradeItemCountryOfOrigin sizeCodeListAgency sizeCodeValue descriptiveSize


Confirm: Assigned attributes are in CIN and properly



Test Step 8.2:

Description: RDP receives two CINs containing expanded list of GDSN Item Attributes. Item and list of assigned attributes are contained in spreadsheet provided by DGI.

Confirm: Assigned attributes are in CIN and properly




Test Step 8.3:

Description: SDP issues CHANGE_BY_REFRESH on each items from 8.1 populating cancelDate and discontinueDate to tomorrow's date. State must still be "REGISTERED".

Confirm: SDP sends RCI to Global Registry populating cancelDate and discontinueDate.

Confirm: SDP sends CIN with state "REGISTERED."



Test Step 8.4:

Description: RDP receives CINs on items from 8.1 populating cancelDate and discontinueDate to tomorrow's date.

Confirm: RDP receives CIN with state "REGISTERED."



Test Step 8.5:

Description: Once cancelDate and discontinueDate times are reached, item states move to "CANCELED" and "DISCONTINUED", respectively. Items are corrected by changing OrderQuantityMinimum (any value as long as it is different). CINs are sent to RDPs with states of "CANCELED" and "DISCONTINUED".

Confirm: SDP sends two CINs states of "CANCELED" and "DISCONTINUED".

Confirm: OrderQuantityMinimum value is different.




Test Step 8.6:

Description: RDP receives two items with states of "CANCELED" and "DISCONTINUED", respectively.

Confirm: RDP receives two CINs with states of "CANCELED" and "DISCONTINUED".




Test Step 8.7:

Description: SDP creates a properly extended CIN on item assigned by DGI. Extension is chosen by DP.

Confirm: CIN contains a well–formed extension.

Confirm: If extension is GDSN approved, extension is schematically valid.



Test Step 8.8:

Description: RDP receives a properly extended CIN.

Confirm: CIN contains a well–formed extension.

Confirm: If extension is GDSN approved, extension is schematically valid.




Test Step 8.9:

Description: DGI, acting as a SDP, sends CIN with non–GDSN approved extension but schematically valid extension to RDP. RDP must accept it by responding with EAN.UCC Response.

Confirm: CIN contains an extension.

Confirm: Extension does not fail CIN.



Test Step 8.10:

Description: DGI, acting as a SDP, sends CIN with non–GDSN approved extension and unknown schema but well–formed XML extension to RDP. RDP must accept it by responding with EAN.UCC Response.

Confirm: CIN contains an extension.

Confirm: Extension does not fail CIN.




GDSN Test Task #9

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 9.1:

Description: Assigned RDPs send CIS with <documentCommandHeader type="DELETE"> to GR. GR will distribute CIS–Delete messages to SDPs. The subscription criteria will be supplied by DGI at test time.


Confirm: GR confirms Subscriptions Delete messages received and delivered.

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

Test Step 9.2:

Description: Assigned SDPs receive CIS Delete from Global Registry.

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

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

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

Description: DS of the SDP does a CORRECT on an item in the sync list which is not previously rejected. CIN will be generated from the sync list.

Confirm: CIN is sent according to the sync list, and each CIN command must be "CORRECT" and state must be "REGISTERED".


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

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

NOTE: This test step verifies the sync list functionality. While the item was added to the sync list after a publish on a subscription match, the subscription no longer is needed for the item to remain on the sync list. Even after the subscription is deleted, the item will continue to be published. This conforms with Business Rule# 141 in the CIS BMS.


GDSN Test Task #10

Overview: Publication Delete GS1 Use Cases Covered: Catalogue Sync: UC-6, UC-7, UC-20, UC-29, UC-34

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

Prerequisite Condition: Task 9 has been completed.

Testing Procedure:

Test Step 10.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 <documentCommandHeader type="DELETE"> to the data recipient(s). The CIN has the same item state as in the GR. After removing the publication, the SDP will either physically or logically delete the entry from the sync list. By logically deleting this entry, SDP will mark the sync list entry as deleted and block future notifications generated on this item from the sync list.

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


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

Test Step 10.2:

Description: RDP receives CIN with <documentCommandHeader type="DELETE">. RDP notifies its data recipient of Publication Delete for the item.

Confirm: RDP sends a EAN.UCC message with <responseStatus="ACCEPTED">.

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 10.3:

Description: SDP corrects the "cancelDate" on the item from Test Step 10.1 to the new value of tomorrow's date. SDP corrects the "discontinueDate" on the item from Test Step 10.1 to the new value of tomorrow's date. RCI will have <documentCommandHeader type="CORRECT"> with <catalogueItemState state="REGISTERED"/>

Confirm: GR returns CIRR message with <responseStatus="ACCEPTED">.

Confirm: RCI message contains <documentCommandHeader type="CORRECT"> with <catalogueItemState state="REGISTERED"/>.

Confirm: GR correctly populates the "cancelDate" and "discontinueDate".

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

Test Step 10.4:

Description: Each DS/SDP will send a CIN with <documentCommandHeader type="CORRECT"> and <catalogueItemState state=" REGISTERED"/> for the items from Test Step 10.3. DRs which have the publication deleted will not receive CIN but other DRs still within the sync list will receive CIN.

Confirm: SDP sends the CIN with <documentCommandHeader type=" CORRECT"> for the corrected, cancelled item to ONLY DR/RDP still on sync list.

Confirm: SDP sends the CIN for the corrected, discontinued item to RDPs according to the sync list and CIN contains a correctly populated "cancelDate".

Confirm: SDP sends the CIN for the corrected, discontinued item to RDPs according to the sync list and CIN contains a correctly populated "discontinueDate".




Test Step 10.5:

Description: DRs/RDPs not removed from sync list receive a CIN with <documentCommandHeader type="CORRECT"> and <catalogueItemState state=" REGISTERED "/> for the item from Test Step 10.3.


Confirm: CIN received ONLY by DR/RDP still on sync list with <documentCommandHeader type="CORRECT">.

Confirm: RDP receives the CIN for the corrected, cancelled item from the respective SDP, and CIN contains a correctly populated "cancelDate".

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 received to DGI-GDSN-Support.


Test Step 10.6:

Description: Once cancelDate and discontinueDate times are reached, item states move to "CANCELED" and "DISCONTINUED", respectively. Items are corrected by changing OrderQuantityMinimum (any value as long as it is different). CINs are sent to RDPs with states of "CANCELED" and "DISCONTINUED".

Confirm: SDP sends two CINs states of "CANCELED" and "DISCONTINUED".




Test Step 10.7:

Description: RDP receives two items with states of "CANCELED" and "DISCONTINUED", respectively.

Confirm: RDP receives two CINs with states of "CANCELED" and "DISCONTINUED".





About Drummond Group Inc. Drummond Group Inc. (DGI) is an independent, privately held company that works with software vendors, vertical industries and the standards community to drive adoption for standards by conducting interoperability and conformance testing, publishing related strategic research and developing vertical industry strategies. Founded in 1999, DGI represents best-of-breed in the industry on linking horizontal infrastructure technologies, standards and interoperability issues with the needs of vertical industries such as retail, grocery, health care, transportation, government and automotive. For more information, please visit www.drummondgroup.com or email: [email protected].


http://www.drummondgroup.com/

mailto:[email protected]

interop final report - gs1...gdsn certification event – gdsn kato, gs1 mexico and udex – had to...

Documents