Heated discussions concerning the allocation of new GTINs due to the REGULATION (EU) No 1169/2011 have ensued!

The regulation on the provision of food information to consumers, coming into effect in December, poses various challenges. One of them is the procurement and maintenance of information that is subject to declaration. Another concerns the procedure when this information is being changed. In the following, I would like to comment on this currently hotly debated topic of change.

The problem, in brief

The unambiguous identification of an article is guaranteed via its GTIN. The article information is printed on the product label. At the store, the customer picks up the article and studies the label. If information changes, the label is adjusted. The customer can look at both articles at the store and compare the changes - even if they have an identical GTIN. No problem so far.

The regulation yet also refers explicitly to distance selling. Article 14 explains: "[...] mandatory food information [...] shall be available before the purchase is concluded and shall appear on the material supporting the distance selling [...]".

Here comes the problem: The unambiguous identification of the article takes place via its GTIN. If information concerning the article changes (for example if ingredients are changed), a new article with a new GTIN must be created so that both articles (with old and new ingredients list) are distinguishable.

Otherwise, the information of the article under the previous GTIN would change. Yet what isn't a problem in the store, does not work for the online shop. Here every distinguishable article requires its own, separate GTIN.

This evidently draws a rat-tail of consequences behind it:

An article with a new GTIN requires a new packaging hierarchy. New article variants have to be created in the master data systems, ordered, stored and shipped. An overview of this is offered in the "Position paper about the identification of products with different labeling at distance selling in the context of the Food Information Regulation (FIR)", published by GS1 Germany. It can be found on their website under http://www.gs1-germany.de/lebensmitteltransparenz/. It also details the perspective of a possible future solution called GTIN+X, namely the GTIN with additional variant identification (+X).

Due to such changes, there could be an inflation in the allocation of new GTINs. No wonder it is hotly debated under which circumstances a change is relevant for the allocation of a new GTIN if one looks at the necessary effort and time as well as the procedural consequences.

There are two points of view in this discussion:

a) Minimal changes of the foodstuff, as for example in the nutrition facts, do not require new GTIN, since foodstuff can not always contain exactly the specified nutritional value due to natural fluctuations and changes in production and storage.

This view can be supported by a manual of the EU: "GUIDANCE DOCUMENT FOR COMPETENT AUTHORITIES FOR THE CONTROL OF COMPLIANCE WITH EU LEGISLATION ON [ ... ] in relation to the establishment of tolerances for nutrition facts indicated on the label" (Source: http://ec.europa.eu/food/food/labellingnutrition/nutritionlabel/guidance_tolerances_december_2012.pdf). This manual, referring to the Food Information Regulation 1169/2011 and various directives, implies and explains the tolerances in the determination of nutrition facts. It also translates the otherwise ambiguous "minimal" into definable numbers. Already on its first page, the manual includes a notable restriction though: "IMPORTANT DISCLAIMER. This Document has no formal legal status and, in the event of a dispute, ultimate responsibility for the interpretation of the law lies with the Court of Justice of the European Union".

Which leads us to the alternative point of view in the discussion:

b) If the declarable information changes, the product has to be re-labeled according to the Food Information Regulation 1169/2011, namely get a new GTIN. (Source: http://www.gs1-germany.de/fileadmin/gs1/best_practices/GS1_LMIV_Kompaktes_Wissen.pdf). This approach avoids possible conflicts and points of attack concerning tolerances or the interpretation of the term "minimal change" by referring back to the description level.

Take the following example: A change of the nutritional value of "Sugar 8.5g" to "Sugar 8g" is within the tolerance of the nutrition facts - but since the text of the declarable specification itself changes, the article will be allocated a new GTIN.

It will be fascinating to watch which procedure will emerge from the discussion. This will certainly also depend on how the topic is treated by government agencies, consumer advocates and lawyers on behalf of competitors. Government agencies could consider version a) acceptable (the guidance document on tolerances may point that way). Meanwhile the procedure of version b) may be the safer way to go to fend of cost-intensive legal warnings.

We will follow the developments to come.

Another enthralling topic of the Food Information Regulation 1169/2011: "exceptions", such as for example in Annex V, point 19: "Food, including handcrafted food, directly supplied by the manufacturer of small quantities of products to the final consumer or to local retail establishments directly supplying the final consumer."

Here again the field is open for individual interpretation!

Automatic Classification According to eCl@ss

The product classification system eCl@ss has established itself in many industries as the preferred standard. Initiated and funded by Germany's major companies and later adapted by the federal procurement and some of the federal states, eCl@ss today plays an increasingly leading role in the implementation of electronic commerce for SME (small and medium-sized enterprises). This being said, the classification of product master data via eCl@ss is by no means trivial. eCl@ss is more than just a product group structure and the classification of items in product groups may be itself already an endeavor hardly manageable without automation, particularly with data sets that go into the hundred thousands or even millions.

Yet whoever wants to classify product master data entirely via eCl@ss has to consider the so-called feature lists on top. Also, there is no operating eCl@ss correctly and consistently without supplying all articles with a customs tariff number. We'll come to that in a later blog post.

Classifying on the "green field"

Naturally, here as elsewhere applies: Every journey begins with the first step. Every eCl@ss introduction should start with a product category assignment. On the one hand, it can be quite useful for the eCl@ss introduction if another product group system (a company-owned in-house one, for example) is already in place. On the other hand, as a point of departure this can tempt into going the wrong route, namely, into trying to map the eCl@ss category from the existing product group. At first, this approach appears obvious and sensible, as it makes use of already available information. In the long run though often entire departments become occupied with the creation of mapping tables intended to map the product groups onto each other. At the end it typically turns out that such a mapping can hardly or not be defined at all, unless the granularity of the two product group systems are incidentally identical up to the last detail.

Let's illustrate this with a specific example.
Assuming, a company’s product master data were classified according to an internal product group system. This system would, for example, separate flow pumps into axial, diagonal and radial pumps. Such product grouping may well occur in industrial practice.

eCl@ss, however, offers very different categories:

• Submersible pump
• Circulation accelerator pump
• Ship lift (pressure increase)
• Centrifugal pump with shaft seal
• Centrifugal pump with canned motor
• Centrifugal pump with magnetic coupling
• Other unspecified centrifugal pump

Obviously, there is no correlation between the two systems. The product group in eCl@ss is significantly determined by the sealing system (shaft seal, magnetic coupling , ...) of the centrifugal pump, while the design (axial, diagonal or radial) is only laid out as an additional feature. In our assumed example however, the design is crucial for the definition of the product group itself. No matter how you look at it: the eCl@ss category can not be derived, at least not as long as one only considers the internally classified product group. Unfortunately, in practice this often leads to "pragmatically" attributing a shaft seal to each and every pump. Alternatively and even worse, all pumps may straight away be subsumed under "Other unspecified centrifugal pump". It should be clear, that this "solution" is far from being pragmatic, actually even more than botchy.

The answer to this problem is relatively simple though. As well as considering the internal product category, all available information about the article needs to be evaluated. If for example the article description includes the terms "magnetically coupled", then this information should obviously be employed instead of being ignored. To effectively implement this approach, a software is needed that can utilize existing master data for automatic classification using machine learning algorithms. Roughly speaking, this principle uses known examples (learning set) to calculate how the occurrence of the term "magnetically coupled" as part of the article description affects the (conditional) probability, that the article in question is indeed a "centrifugal pump with magnetic coupling". The calculated value is then used to predict the remaining, as yet unclassified articles. In fact, algorithms for automatic classification work even quite satisfyingly if there hasn't been an internal product group in use prior to the introduction of eCl@ss.

The next blog post will discuss how methods of automatic classification can optimize master data quality.

Holger Joest

The EU Regulation 1169/2011 on Food Information for Consumers vs. GDSN - A Closer Look into Nutrition Declaration

In this article of our blog series on the European regulation 1169/2011 on the provision of food information to consumers, I want to discuss the nutrition declaration in closer detail with reference to some actual examples.

What does the new EU regulation say about nutrition declaration?

Here are two excerpts from the introductory statement:

• "(35 ) To facilitate the comparison of products in different package sizes, it is appropriate to retain the requirement that the mandatory nutrition declaration should refer to 100 g or 100 ml amounts and, if appropriate, to allow additional portion-based declarations. Therefore, where food is prepacked and individual portions or consumption units are identified, a nutrition declaration per portion or per consumption unit, in addition to the expression per 100 g or per 100 ml, should be allowed. ... "
• "(41) To appeal to the average consumer and to serve the informative purpose for which it is introduced, and given the current level of knowledge on the subject of nutrition, the nutrition information provided should be simple and easily understood. ..."

In the subsequent articles the mandatory information is explained in more detail. The following is a very abbreviated summary:

• Article 30 defines the mandatory content of the nutrition declaration. These mandatory data are called "BIG 7" (the nutrition declaration with the additional specification of fiber is called "BIG 8"):
  "... The mandatory nutrition declaration shall include the following:
  (a) energy value; and 
  (b) the amounts of fat, saturates, carbohydrate, sugars, protein and salt.  ..."
• Article 32 defines the amount to which the mandatory nutrition declaration must refer: "...Expression per 100g or per 100 ml
  (1) The energy value and the amount of nutrients referred to in Article 30 (1)-(5) shall be expressed using the measurement units listed in Annex XV.
  (2) The energy value and the amount of nutrients referred to in Article 30 (1)-(5) shall be expressed per 100g or per 100ml. ..."
• Article 33 defines optional additional nutrition declaration per unit of consumption: 
  "... Expression on a per portion basis or per consumption unit. 
  (1) In the following cases, the energy value and the amounts of nutrients referred to in Article 30 (1)-(5) may be expressed per portion and/or per consumption unit, easily recognisable by the consumer, provided that the portion or the unit used is quantified on the label and that the number of portions or units contained in the package is stated:
  (a) in addition to the form of expression per 100 g or per 100 ml referred to in Article 32 (2); ..."
• Article 34 defines the presentation. " ... (1) The particulars referred to in Article 30 (1) and (2) shall be included in the same field of vision. They shall be presented together in a clear format and, where appropriate, in the order of presentation provided for in Annex XV.
  (2) The particulars referred to in Article 30 (1) and (2) shall be presented, if space permits, in tabular format with the numbers aligned. ..."
  The nutritional information is to be presented as follows (according to Annex XV "EXPRESSION AND PRESENTATION OF NUTRITION DECLARATION " ): " ... The units of measurement to be used in the nutrition declaration for energy (kilojoules (kJ) and kilocalories (kcal)) and mass (grams (g), milligrams (mg) or micrograms (µg)) and the order of presentation of the information, as appropriate, shall be the following:"
  - energy (kJ/kcal), mandatory ("BIG7")
  - fat (g), mandatory ("BIG7")
  of which:
    - saturates (g), mandatory ("BIG7")
    - mono-unsaturates (g), optional
    - polyunsaturates (g), optional
  - carbohydrate (g), mandatory ("BIG7")
  of which:
    - sugar (g), mandatory ("BIG7")
    - polyols (g), optional
    - starch (g), optional
  - fibre (g), optional (additional information of the "BIG8")
  - protein (g), mandatory ("BIG7")
  - salt (g), mandatory ("BIG7")
• For the nutrition information on "salt", the regulation defines:
  " ... ( 37) Since one of the objectives pursued by this Regulation is to provide a basis to the final consumer for making informed choices, it is important to ensure in this respect that the final consumer easily understands the information provided on the labelling. Therefore it is appropriate to use on the labelling the term 'salt' instead of the corresponding term of the nutrient 'sodium'. ..."
  Annex I "Specific definitions" defines how the value for salt is calculated based on sodium: 'salt' means the salt equivalent content calculated using the formula: salt = sodium × 2,5".

When does the nutrition declaration become effective?

The nutrition declaration is mandatory from 13/12/2016 onwards. If voluntary declarations are being provided before this date, they have to correspond to the regulation from 13/12/2014 onwards.

Product examples and their mapping in GDSN

Looking at product examples today, the format and presentation of nutritional values can be more or less divided into three classes:

1. "single-column" - the strictly mandatory declaration, i.e. the nutritional information per 100 g or 100 ml
2. "double column" - in addition to the mandatory declaration, information is provided for every individual portion size
3. c. "triple column" - the mandatory declaration, the portion size and an additional percentaged quantity, based on a daily intake standard (reference standards for the daily intake are listed in annex XIII of the regulation). On these products, the "1+4 model", developed by the German Federal Ministry of Food, Agriculture and Consumer Protection, is often additionally applied. This model declares the energy content and the amounts of fat, saturates, sugar and salt per serving as well as the percentage of its calories and nutrients in relation to the recommended daily intake.

Additionally, the "Representation in the GDSN data model" shows how these informations are transported throughout the GDSN. It also illustrates how much interpretative and processing work is needed for a representation apart from just the data transfer task.

Product example 1 and representation in the GDSN data model

"Single-column", Big 8 complete, sequence standards according to the EU regulation not met, lists sodium instead of salt.

Product example 2 and representation in the GDSN data model

"Single-column", Big 8 complete, sequence standards according to the EU regulation not met, lists sodium instead of salt, plus the "1+4 model". 

Portion size is one 250ml serving.

Product example 3 and representation in the GDSN data model

"Double column", Big 8 complete, sequence standards according to the EU regulation not met, lists sodium instead of salt. 

Portion size is one biscuit (24g).

Product example 4 and representation in the GDSN data model

"Double column", Big 8 complete, sequence standards according to the EU regulation not met, lists sodium instead of salt.

Additionally, vitamin and trace element information are being listed as well as their percentage in relation to the recommended daily intake.

Vitamin B1 is not specified on the GDSN UNInfoods list.

The "1+4 model" is located on the front of the packaging.

The portion size is based on a prepared serving of cereal with milk.

Product example 5 and representation in the GDSN data model

"Double column", Big 8 complete, sequence standards according to the EU regulation not met, lists sodium instead of salt, plus the "1+4 model". 

Portion size is one 25g waffle.

Product example 6 and representation in the GDSN data model

"Triple column", Big 8 complete, sequence standards according to the EU regulation not met, lists sodium instead of salt. 

Portion size contains five biscuits (ca. 34g).

EU regulation conformity of the product examples

It is striking that none of the considered examples is EU regulation compliant yet. On all products the voluntary nutrition declaration according to directive 90/496/EEC in form of the "Big 8" (energy value, protein, carbohydrates, sugar, fat, saturated fat, fiber, sodium) is supplied. However, their sequence is changed in the new table according to the EU  regulation: Fiber becomes optional and salt is no longer listed as sodium.

Nutritional value coding in the GDSN data model

The nutritional values of the product examples were coded following  the GS1 recommended codes and attribute applications (see the following comment on salt). They therefore represent a "best practice" use of GDSN for the nutritional information.

Yet the example of "sodium" already indicates the band width of variations when it comes to data management. The EU regulation compliant information would be "salt" (code "SALTEQ"). A conversion (salt = 2,5 * sodium) on part of the data recipient would appear to be the most pragmatic solution. The EU regulation holds responsible whoever registers or changes the product information though.

Many product data will have been registered according to the GS1 recommendations for the use of GDSN alongside the new EU regulation data. But there will also be data suppliers who will provide product data that are EU regulation compliant, but depart from the GS1 recommendation. Next to different applications of attributes, codes for single nutrition values can also vary.

Here, for example, are the possible alternatives for protein declarations:

PRO-, protein, total; method of determination unknown or variable (the GS1 recommendation for protein coding)

Possible other codes:

PROA, protein, total; determined by direct analysis

PROANI, protein from animal sources

PROCNA, protein, total; calculated from amino

PROCNP, protein, total; calculated from protein

PROCNT, protein, total; calculated from total nitrogen

PROPLA, protein from plant sources

PROTAN, protein, animal

PROTPL, protein, plant

Conclusion

The new  regulation ensures that the up to now largely voluntary nutrition information on products will become obligatory for the entire European Union. Information will be more comprehensive, uniform and more intelligible and nutrition information will be made available for stationary as well as online trading. 
Until this is achieved by the end of the transition period in 2014 though, a lot of implementation efforts are still waiting.

The Mandatory Information of the EU Regulation 1169/2011 on Food Information for Consumers vs. GDSN

We are currently working on a project where GDSN product data, especially those relating to the new European regulation, are being received and edited into consumer-friendly formats for an online shop. I would like to highlight this challenge in the second article of our blog series on the EU regulation No 1169/2011.

What characterises the mandatory information of the new European  regulation in relation to a real product example?

Lets recall article 9, "List of mandatory particulars" (see also http://themdmblog.blogspot.de/2013/12/eu-regulation-11692011-on-provision-of.html ):

1. The name of the food ("Product Name" in the illustration: "Double-filled biscuits with cocoa cream filling 46%".
2. The list of ingredients ("Ingredients" in the illustration): "Ingredients: flour, sugar,..."
3. Any ingredient or processing aid causing allergies or intolerances ("Allergens" in the illustration): "May contain traces of: Soy". The additional nutritional information "Suitable for vegetarians" is no mandatory declaration according to the European  regulation.
4. The quantity of certain ingredients or categories of ingredients. The product example provides here no more detailed declaration in its list of ingredients 
5. The net quantity of the food: ("Net Content" in the illustration): "400 g".
6. The date of minimum durability or the 'use by 'date ("Best Before Date" in the illustration)
7. Any special storage conditions and/or conditions of use ("Storage Instructions"in the illustration): "Protect from heat. Store in dry conditions"
8. The name or business name and address of the food business operator as well as
9. The country of origin or place of provenance where provided for ("Origin / Manufacturer" in the illustration)
10. Instructions for use (if necessary) - not relevant in case of the product example
11. With respect to beverages containing more than 1,2 % by volume of alcohol, the actual alcoholic strength by volume - not relevant in case of the product example
12. A nutrition declaration (mandatory only from 13. December 2016) ("Nutrition Info" in the illustration)

Who will be affected by the European regulation?

European  regulation applies to industry and commerce, both stationary stores and online stores.

The product example is largely European regulation compliant and therefore meets its stationary trade standards: the customer can take the product into his hands and decide on the basis of the information printed on the package whether it fits his needs.

How does the online shop get the relevant data via GDSN though?

Let's look, for example, at the allergy information on the product example: "May contain traces of : Soy". The GS1 manual for the use of GDSN for the European  regulation makes the following recommendation:

In the GDSN data model, there is the repeatable attribute group "foodAndBeveragesAllergen" with which a lot of the allergens contained in a food product can be described. 

The attributes of this group are defined as follows:

• allergenSpecificationAgency - organisation that defines the allergen information 
• allergenSpecificationName - name and version of the definition informing the transmitted allergen information 
• allergenTypeCode - code that identifies the allergen contained 
• levelOfContainment - code that specifies the amount of the allergen contained 

Using our specific example, this will look as follows (attribute = value -> explanation)

• allergenSpecificationAgency = EU -> pre-defined default referring to the recommendation 
• allergenSpecificationName = 1169/2011 -> pre-defined default  referring to the recommendation 
• allergenTypeCode = AY -> GDSN code list code "allergenTypeCode"
• levelOfContainment = MAY_CONTAIN -> GDSN code list code "Level of Containment Type Code"

In this example, the actually relevant allergen information is transmitted via the two codes "MAY_CONTAIN AY" contained in the pre-defined GDSN code lists. 
So what do these codes actually mean?
As a code of the "allergenTypeCode" code list, AY is defined as: "AY: Refers to the presence of soybeans and their derivatives in the product, as listed in as listed in the regulations specified in AllergenSpecificationAgency and AllergenSpecificationName". Or, to put it simple: "soy".

As a code of the "levelOfContainment" code list, MAY_CONTAIN is defined as: "The substance is not intentionally included, but due to shared production facilities or other reasons, the product may contain the substance". Or, to put it simple: "can contain".

How is this information contained in the GDSN Catalog Item Notification (CIN) message which any data recipient gets from the GDSN data pool? 

In our example it looks, in a highly abridged version, as follows:

What is necessary to format this for the online shop?

The task is now (in addition to the technical details of the GDSN data pool connection and transformation of the GDSN messages, which I will not look at in this article) to extract the consumer-friendly notice "Can contain traces of: soy" from the GDSN compliant product information "MAY_CONTAIN: AY".

This means that for the relevant codes of the GDSN code lists the desired text fragments must be deposited and mapped. In our example these would be text fragments for the notice if an allergen is contained ( "Level of Containment Type Code"):

• "MAY_CONTAIN" => "May contain traces of:" 
• "CONTAINS" => "Contains:"
• "FREE_FROM" => "Does not contain:"

As well as the text fragments or declarations for potentially allergy-causing substances ("Allergen Type Code") - here are some examples:

• "AX" => "gluten"
• "AY" => "soy"
• "AS" => "sesame"
• "SH" => "hazel"

Following this final text module mapping, the consumer-friendly text passages for display in the online shop can be extracted from the coded GDSN product information:

There are of course quite a few more delicacies regarding the mandatory product declarations according to the new European regulation - we will come back to them in our in our next article ...

EU Regulation 1169/2011 on Food Information for Consumers in Brief Overview

In response to different food scandals of younger history the EU issued the regulation 1169/2011 as a directive on the provision of food information to consumers.

This regulation states

• General goals, as in chapter II, article 3: “ The provision of food information shall pursue a high level of protection of consumers’ health and interests by providing a basis for final consumers to make informed choices and to make safe use of food, with particular regard to health, economic, environmental, social and ethical considerations.”.
• Basic requirements, as in chapter III, article 7: “(1) Food information shall not be misleading, … (2) Food information shall be accurate, clear and easy to understand for the consumer. …”.
• As well as responsibility for the supplied information.

         In addition the regulation contains a number of specific, detailed requirements on mandatory information, the presentation and placement on food packaging, guidelines for language used and labeling as like as lists of ingredients, additives, allergens which may cause intolerances or allergies etc.

List of mandatory particulars:

1. The name of the food;
2. The list of ingredients;
3. Any ingredient or processing aid listed in Annex II or derived from a substance or product listed in Annex II causing allergies or intolerances used in the manufacture or preparation of a food and still present in the finished product, even if in an altered form;
4. The quantity of certain ingredients or categories of ingredients;
5. The net quantity of the food;
6. The date of minimum durability or the ‘use by’ date;
7. Any special storage conditions and/or conditions of use;
8. The name or business name and address of the food business operator referred to in Article 8(1);
9. The country of origin or place of provenance where provided for in Article 26;
10. Instructions for use where it would be difficult to make appropriate use of the food in the absence of such instructions;
11. With respect to beverages containing more than 1,2 % by volume of alcohol, the actual alcoholic strength by volume;
12. A nutrition declaration (becoming mandatory on 13^th of December 2016).

This directive affects both manufacturers and retailers. It applies to food business operators at all stages of the food chain, where their activities concern the provision of food information to consumers. Stationary shops as like as online shops. 
It becomes effective 13^th of December 2014. Thus it is only 12 month time, to learn about the requirements and get the implementation done.

How GDSN may help with these requirements is part of upcoming blog articles.

Source: REGULATION (EU) No 1169/2011 OF THE EUROPEAN PARLIAMENT AND OF THE COUNCIL of 25 October 2011

Let’s proof “What are the Positives and Negatives of GDSN?”

Björn wrote this Blog article http://themdmblog.blogspot.de/2012/04/what-are-positives-and-negatives-of.html about one year ago.

As we have a global supplier as customer for a GDSN project I’ll pick up this topic and keep you posted. We’re currently in requirements analysis phase. Let’s start with a look at some of the mentioned “Positives” from this view point:

“1) GDSN is the only global infrastructure to exchange product information.” and “2) It is used by many global suppliers and retailers.”

The customer is a global company. It is already using GDSN (in its 1SYNC implementation) to ex­change product information in the US. Now Europe should follow, extending and leveraging the data pool connector implemented by the company’s global IT. So, the choice for GDSN to exchange product information makes sense.

“3) It has a lot flexibility build in with the extension concept and extensions like the AVP-Extension.”

The customer wants to transport quite a lot of textual information on its products. Plus some specific attributes which did not find their way into the extensive GDSN data model yet. Therefore the generic attribute name/value mechanism given by the AVP Extension provides the needed flexibility. However, I need to come back to this point looking at “Negatives”.

“4) There is a channel for communicating back from retailers to suppliers (the Catalog Item Confirmation message CIC).”

As a sensible supplement to 1) and 2) this is a clear decision point for GDSN. However it stands or falls with retailers using that mechanism to give their feedback.

A glance at some of the mentioned “Negatives”:

“1) Implementation is complex for suppliers and retailers”

Without a doubt: A project has to set up the GDSN data model with its attributes, code lists and validation rules, implement the message formats and message choreography plus the technical inter­face to connect to a GDSN data pool. Even choosing the right attributes from several hundred ones within GDSN core and various extension areas is a challenge.

But instead of starting from scratch the customer uses LANSA “Data Sync Direct” (http://www.lansa.com/pim/), a lightweight PIM with focus on GDSN connectivity, containing a pre­build, out-of-the-box GDSN data model, generating the XML data formats and following the needed message choreography. This reduces the project complexity to its essential core: Choose and con­figure the needed attributes, data sources and mappings.

“2) Although GDSN defines a message standard, this is only mandatory to be used between data pools. … MDM/PIM/tool provider has to build an extra interface for each and every data pool he wants to connect his tool to. ...”

This is another issue losing its effort with the use of LANSA “Data Sync Direct” containing prebuild interfaces to both, the 1SYNC and the 1Worldsync “WS2” GDSN data pool. In this project the customer’s global home data pool is going to be the US 1SYNC GDSN data pool. Any recipient connected to another GDSN data pool, e.g. the 1Worldsync “WS2” in Germany is going to receive the data via pool-to-pool communication done in the background by the GDSN.

“3) Typically GDSN does not cover all the requirements a retailer has regarding data synchronization. Therefore retailers are often asking for additional product information from suppliers on different ways. Very obvious is that GDSN today does not yet cover B2C data. …”

Even with hundreds of attributes, the current GDSN data model focuses on B2B data exchange. In this project the additional textual B2C product information is split apart several additional attribute name / value pair attributes. Even though this mechanism gives flexibility to transport arbitrary data across the GDS network, an attribute value is restricted to 255 characters, which makes it hard trans­porting longer text fragments. 

The GDSN data model offers more options to implement such requirements, like the “Trade Item External Information” attribute group, allowing to link to data being available externally (e.g. via URL).
However the B2C requirements are an area which GS1 needs to give answers on by extending its GDSN standards suitably. Otherwise different projects would use GDSN specifically to transport such data with the result of individual solutions within GDSN.

In summary, the positive aspects outweigh. All requirements – even the more tricky ones – could be mapped onto GDSN data model and obviously it allows implementing the “one point of entry principle” for a global company also. We’ll have a look at the system once all requirements are implemented and product information is synchronized with European retailers using the GDS network. I’ll keep you posted!