GS1 GDSN 2016 Major Release Implementation Guideline & Business Rules

GDSN MjR Data Migration Implementation Decisions

February 18, 2014

GS1 Global Office

Avenue Louise 326, bte 10

B-1050 Brussels, Belgium

Document Summary

Document Item / Current Value /
Document Title / GS1 GDSN MjR Data Migration Implementation Decisions & Business Rules
Date Last Modified / · September 30, 2014
· October 13, 2014 – updated with notes from Rome GDS UG Meeting
· December 10, 2014 – updated annotations based on decisions made and indicated in other documentation
· February 18, 2015 – revised with Steve Robba
Current Document Issue
Status
Document Description

Table of Contents

1. Introduction 4

1.1. Purpose of this Document 4

1.2. Who Will Use this Document? 4

2. Deployment and Migration 4

3. Data Migration Implementation Decision Points 4

3.1. General Guidance on Data Migration 4

3.2. AVP Data Migration 5

3.3. Trade Item Unit Descriptor 5

3.4. Unit of Measure: UNREC 20 6

3.5. Platform Type Code 8

3.6. Nutritional Claim Code 8

3.7. Packaging / Accreditation Labels 9

3.8. Packaging Material Type – pending decision by GDSN MSWG 9

3.9. Packaging Type Code 9

3.10. Stacking Factor 10

4. Ingredient Sequence (Sub Ingredients) 10

5. Data Carrier 10

6. Business Rules 11

7. Final XML Schemas and BMS for MjR 11

1. Introduction

This document will be updated over time as the GDSN User and OTAG groups continue their review of the GDS Major Release impact on attributes and code lists.

1.1. Purpose of this Document

This document describes two important elements of the GDSN Major Release 3.1:

· Data Migration decision points where the network participants aligned on migration activities that can be executed prior to the MjR production deployment as well as those that will be executed post the MjR production deployment

· Intermediate actions that will lead to final implementation decisions related to data migration for the MjR

All final data migration implementation information is posted in a fully consolidated Excel sheet titled “name’ that will be posted on the GDSN MjR web page.

1.2. Who Will Use this Document?

All participants in the Global Data Synchronization Network.

2. Deployment and Migration

Decision:

May 6, 2016 is date that deployment of the GDS MjR 3.x will begin in the network. The deployment will occur over a 6 day.

Contingency:

May 12, 2016 is the backup date for MjR deployment; the beginning of the 6 day downtime for deployment.

Decision:

GDS Network will be down for 6 business days; 2 days of these 6 will be used to migrate the GDS GR to 3.x.

Decision: Recipients will not get previously synced data that has been updated during the data migration period. NOTE: Data Pools will need to analyze their customer’s data down to the GTIN level including Code Lists to understand data migration impacts to their communities.

3. Data Migration Implementation Decision Points

3.1. General Guidance on Data Migration

In case you have a code value in a code list which maps to:

· Other

· Unspecified

· …or something similar

· DIRECTION: talk to your data pool for assistance on use of this code or selection of a more appropriate code within any Code List

3.2. AVP Data Migration

The current Fast Track list for AVP’s provides data migration direction on how AVP’s will be managed either as part of MjR3 and / or post MjR3. This spreadsheet (GDDFastTrack_approved) maps all 2.8 Fast Track AVPs that will be incorporated into Major Release to a 3.x attribute where applicable.

All remaining AVPs that are not assigned to a 3.x attribute are mapped to and will be passed at the Trade Item level of the Trade Item Synchronization message at the avpList point.

Post the GDS MjR the process for assigning a point location for an AVP (either at the Trade Item level or at a class level within a module) will occur in concert with ECL and GPC releases that are scheduled every 6 months. Unless the AVP forms part of a cluster of attributes requiring repetition or dependency it will be assigned at the ‘Trade Item Level’ of the GDS Trade Item Synchronization message. The discussions for assignment will occur within the Global Master Data (GDS) SMG group calls.
Please refer to the GS1 MjR Data Migration website for the latest official version of the AVP spreadsheet.

· Current AVP’s are all simple

· MjR 3 allows for AVP’s at Module level and also supports the 2.8 simple AVP structure

3.3. Trade Item Unit Descriptor

All final recommendations / decisions on the migration path for TIUD for the GDS MjR will be posted on the GDSN MjR web page within the PPT titled ‘Trade Item Unit Descriptor Data Migration’.

Communication of which item level is a display is supported by a new attribute displayTypecode which indicates if the item is a display

• New attribute – displayTypeCode – indicates if item is display

The number of unique next lower level items is communicated in the attribute

quantityOfChildren which indicates the number of unique next lower level items.

3.4. Unit of Measure: UNREC 20

All recommendations / decisions are noted in the Excel sheet located on the GDS MjR web page within the document titled ‘Unit of Measure Data Migration’.

NOTES FOR MIGRATION PATH:

· The UoM code list for the GDS MjR is a GS1 GO ‘constrained’ version of the full UN Rec20 list. This means that the GS1 UoM Code List is a ‘subset’ version of the full UN Rec20 UoM Code List that is ‘extended’ with some GS1 specific codes to meet our Member needs. The codes that are added by GS1 are indicated with a leading lower case x; example

o x_PRS

o x_ MEQ

· UN as the Agency for the Rec20 Code List is modifying this code list over time. GS1 will ‘align’ to this source list in an Efficient Code List (ECL) deployment in December of 2015. GS1 Modelers will compare the GS1 list with the UN Rec20 looking for codes in the UN Rec20 list and update the appropriate BMS documents and the GDD indicating:

· Delete

· New

· Reinstatements (of codes formerly deleted)

· Please access the UoM codes only from the GS1 Global Data Dictionary (GDD) or BMS documentation.

Migration Path:

1. Use codes from this GS1 constrained version of the UN Rec20 Code List and migrate to codes that are not marked ‘deleted’.

2. If a Data Pools or its member has already migrated to a UN Rec20 code from the GS1 constrained version of the UN Rec20 Code List that is marked as ‘Deleted’ in the GS1 GO GDD the Data Pool can provide mapping choices as a ‘value-added’ service.

Decisions:

· For example, ‘Actual Ton’ can be migrated based upon target market:

· Where UN Rec20 is UK a DP would send UK/metric

· Where UN Rec20 is US DP would send the US/imperial code

· The recommendation decision information above will be Included in TIIG the UoM Categories and their mapping to the attribute that is found in the BRAD since they are not in the Standard

3.5. Platform Type Code

All recommendations / decisions are noted in the Excel sheet located on the GDS MjR web page within the document titled ‘Platform Type Code Data Migration’.

NOTES FOR MIGRATION PATH:

Review of this code list found issues with population of the planned Dimension Class which required height along with width and depth. This presents an issue platforms for which height is generally known. A new Dimension Class specific for Packaging Dimensions where height is optional only if width and depth are populated and platform type code is not populated then height is mandatory. This becomes a new VR within GDSN MjR.

GSMP Work Request #14-161 MAJOR RELEASE CODE LIST MIGRATION Impact was opened and modified definitions in the platformTypeCodeList were made to remove EPAL as it is a branded pallet company similar to CHEP in the US. This information in the definition was confusing as to whether the pallet needed to be an EPAL pallet.

3.6. Nutritional Claim Code

All recommendations / decisions are noted in the Excel sheet located on the GDS MjR web page within the document titled ‘Nutritional Claim Data Migration’.

NOTES FOR MIGRATION PATH:

Background:

Split into ‘claim’ versus ‘nutrient’

· nutritionalClaimTypeCode

· nutritionalClaimNutrientElementCode

Is a repeatable grouping of both attributes; not language enabled

· can have multiple codes per nutrient type

· can populate the nutritionalClaimTypeCode only and leave the nutritionalClaimNutrientElementcode blank; example light/lite, natural and unsweetened

3.7. Packaging / Accreditation Labels

All recommendations / decisions are noted in the Excel sheet located on the GDS MjR web page within the document titled ‘Package Labels Accreditation Data Migration’.

NOTES FOR MIGRATION PATH:

Background:

The MjR provides a single attribute for all ‘accreditation labels’.

Decision:

Codes ‘EXTREMELY_CLEAN’ and ‘STERILE’ were moved to tradeItemFeature code attribute code list.

Decision:

· Can send today prior to major release in packagingMarkedLabelAccreditationCode List as AVP’s in current 2.8 release

3.8. Packaging Material Type

All recommendations / decisions are noted in the Excel sheet located on the GDS MjR DM webpage within the document titled ‘Packaging Material Type Code Data Migration’.

3.9. Packaging Type Code

All recommendations / decisions are noted in the Excel sheet located on the GDS MjR web page within the document titled ‘Packaging Type Data Migration’.

NOTES FOR MIGRATION PATH:

In GDSN 2.8, PackagingTypeCodeList is a GDSN created codelist. In Major Release 3, PackageTypeCodeList is based on UN/CEFACT Rec 21, but, this list has been extended and restricted to cater for GDSN needs. Also note that PackageTypeCode is mandatory in MjR.

See the Data Migration decisions in this Excel sheet (Packaging Type Code v2 DM) posted on the GDSN MjR web page.

· IMPLEMENTATION DIRECTION:

Cage and Card change between 2.8 and 3.1

o In 2.8: CAG = Cage / CG = Card

o In 3.1: CG = Cage / CM = Card

Data Migration Path Decisions:

o The CG and CM 3.1 codes CANNOT be implemented ahead of the MjR; they must be implemented after the MjR deployment for all items previously synchronized using 2.8 codes CAG = Cage / CG = Card

o There is a specific sequence of migration required when migration does occur AFTER deployment of the MjR

§ FIRST change CG (card) to CM (card)

§ THEN change CAG (cage) to CG (cage)

o Several 2.8 codes have no mapping equivalent in MjR 3.x release. The DM recommendation for these is to use ‘PUG’ which indicates that the packaging type is unspecified. This is because these 2.8 codes were not really packaging types thus there is no equivalent. Follow the data migration instruction in Column L of the posted Excel document which direct you to use of either attributes of other Code Lists. Additionally you can populate PUG in the Packaging Type Code List and use that to ‘trigger’ an internal application to look at these recommendation since the data you need is no longer in Packaging Type but in other attributes of other Code Lists.

3.10. Stacking Factor

MIGRATION PATH DECISION:

· STORAGE_UNSPECIFIED - Applicable for goods in storage, irrespective of type of storage.

4. Ingredient Sequence (Sub Ingredients)

Examples of this proposal are posted on the GDS MjR web page in an Excel file titled ‘Ingredient Sequence Examples.’

NOTES FOR MIGRATION PATH:

The MjR XML Schema is currently modelled as a string with a simple sequenced structure methodology:

· Only mandatory elements are 1). the sequence number itself that indicates the ingredient relationships for main ingredients ‘n’ and their sub-ingredients ‘n.1’ and 2) ingredient name

5. Data Carrier

All final recommendations / decisions on the migration path for Data Carrier in the GDS MjR are posted on the GDSN MjR web page documented within a PPT titled ‘Data Carrier Data Migration’.

NOTES FOR MIGRATION PATH:

Updating and migrating existing Bar Code Attributes to the new Data Carrier attributes with mapping agreements aligned among the full GDSN Community.

· Action (Gina T, Milan V., Nadine R.): Create an example with various scenarios of items where different level barcodes are visible – several examples have already been started

· Action (Staffan O.): WR to add No_Barcode DATA CARRIER FAMILY CODE to Data carrier type check PPT to see if these 2 updates were made

6. Final XML Schemas and BMS for MjR

Final Schema for Major Release published on 15 December 2014 and posted at the following link: http://www.gs1.org/gsmp/kc/gdsn/xml/xml_v_3