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!

It’s a recommendation – not a standard!

Experiences with GS1 Standards for Data Exchange in Germany for Healthcare Industry

Like your navigation system in the car warning you to stick to traffic regulations and not follow the instructions blindly, the same applies if you enter unknown territories in IT. In our MDM world I was asked to cross an “unknown territory”, namely doing GS1 GDSN compliant item data transformation for healthcare industry.

Starting with that it looked pretty straightforward: The data provided was CSV, the result expected GS1 XML item messages. The customer told me there’s a GS1 Germany “Healthcare Implementation Recommendation on Item Data Exchange”. Good, well documented area.

But stop: The document is based on version GS1 XML version 2.3. Version 2.3? That was issued in 2008 – meanwhile we’re five versions ahead at 2.8! Lucky I was – only a few uncritical attributes seemed to be missing. No problem, for such cases GDSN defines some kind of backdoor to the highly standardized data model, so called “attribute/value pairs” to transport individual data.

But stop again: Where is this attribute value pair structure described in the “Healthcare Implementation Recommendation”? Nowhere! So, no backdoor, no attributes – the customer dropped them from his data model mapping requirement list.

I continued mapping the data: Healthcare industry uses eCl@ss classification extensively to categorize products and add additional attributes. Categorization is ok – GDSN allows for lots of additional classifications. But again, more attributes to transport – having the missing attribute/value structure still in mind? The “Healthcare Implementation Recommendation” gives a helping hand, the solution described is creative: The GDSN “Classification Description” field is used to transport the eCl@ss attributes. As repeated structure. Defining a CSV usage style for this misused “Classification Description” attribute. What?

There are two comments on that: 1) My personal preference: We’re in a XML world – I don’t like mixing that up with CSV-style values. 2) The hard fact: GDSN validation rule 108 (“For each supported classification agency a GTIN may only have one classification code”) would disallow such item data to go into a GDSN pool.

Stop again: The customer required this eCl@ss data to be transported. That was put on the issue list – maybe the GDSN data pool provider de-activates validation rule 108 to get that data stored in the data pool…

Some first tests against a GDSN data pool with transformed single items showed another smaller problem: The recommendation does not define any date or timestamp related to the item. GDSN defines four mandatory dates and timestamps. Remained stuck again. However, this hurdle was taken pragmatically by adding some generated dates and timestamps, the date of transformation will do!

With the data model mapping done, the final step was assembling the item hierarchies. Another look into the “Healthcare Implementation Recommendation” explained that as “…Due to the fact there’s no hierarchy being built, the CIN should contain the base item and then the next higher level.” Did I say “What?” before? Think so! The GDSN standard defines item hierarchies always being set up top-down: Starting e.g. with a pallet and then “unpacking” the contained items until the base item is reached. With the recommendation implemented, the hierarchy is set up vice versa. A first test against a GDSN data pool resulted in weird error messages: It looked like no one on the pool provider side expected data suppliers to send hierarchies turned around.

Final stop for this blog post: I added the wrong hierarchy to the issue list where the eCl@ss problem already resided… this needs to be sorted out with the customer and GS1 as this blows pragmatic solutions. Keep posted for an update on this.

So, be careful, if the standard travel guide describes a bridge to be used, but your navigation system recommends using a rowing boat ferry where your car can be transported upside down easily.

Predictions on GDSN and MDM for 2013

Do you remember my last years posting "9 Predictions on GDSN and MDM for 2012"? In the following I will try to see where we are and what I am personally expecting from 2013 ...

1. GDSN will overcome the national Data Synchronization standards and become the real global Datasync standard
Has this already happened in 2012? It depends on your view - for sure GDSN is not yet fully established in whole europe but the european communities are all working on this. In Germany industry and retail is working hard on migrating from SINFOS to GDSN (see here). Austria is starting a complete new initiative to launch GDSN (have a look here). GS1 Finland is preparing to switch from SINFOS to GDSN (see here). GS1 Denmark too. France, Italy and Spain are already on GDSN. Even GS1 UK is pushing hard for GDSN even though the major UK retailers are still not beyond pilot. So the majority of europe is at least working seriously to adopt GDSN.

For sure it will take some more time until whole europe will show reasonable adoption of the GDSN. In germany the official goal is to have the whole migration to GDSN finished by the end of 2013. I would not be surprised if it will take until mid or end 2014. But then it will be accomplished.

2. Master Data Management also gets implemented by European retailers
What are twelve month for such an important business decision? European retailers definitely have the awareness that there is a huge business need to introduce Master Data Management as a new business process ... At least that is my perception when I am talking to european retailers. To support my perception I just tried to find some publications on the internet on the topic - but looks quite difficult. There is not much published out there. What I found was some success stories like Heiler on EDEKA or Imperia on METRO, and a very old blog post from Gartner here. But some more general information or survey? Nothing right now ... So in 2013 I definitely have to collect some more information on that topic, help always welcome ;-)

3. Retailers build their own portals to gather item master data on top of GDSN to have a free solution for suppliers and to collect data beyond the standards – and this will burst the usage of GDSN
At least Casino, Edeka, Metro Group, Praktiker and REWE Group (not sure whether this is a complete list) are using the 1WorldSync service to offer their suppliers a free portal to provide their master data to them. Other retailers choose other solutions (eg. Tesco uses a service from Brandbank) and I am pretty sure that there are also other retailers out there who have build their own supplier portals offering options to let suppliers provide them their product information.

How this helps GDSN adoption? Retailers who are offering their suppliers a free channel to provide their item master data to them as an alternative to GDSN are able to rollout this to their suppliers very quickly and thereby they are getting their ROI for the electronic data sync process much quicker then if they would only rely on GDSN. And this is what counts.

4. E-Commerce in Europe becomes the driver for MDM and GDSN in retailers &
5. B2C item information will become integral part of GDSN
EU Food Information Regulation (1169/2011) obviously became in 2012 a driver for suppliers and retailers in grocery to think about how they can get this information into the online shops. A good impact analysis of this regulation can be found here. As this regulation will take effect in December 2014, industry and retail will be busy in 2013 and 2014 to solve the challenges.

GS1 is pushing here with their "B2B2C"-Initiative a lot to solve those challenges based on the current GDSN infrastructure. This approach from my perspective is very reasonable and gives retailers the benefit of only having to implement one interface (MDM at a retailer is then a prerequisite) and suppliers the freedom either to also implement MDM and GDSN or to just use a data capture service provider to fulfill the requirements of retailers.

The risk for this approach is that retailers really have to implement it now (in 2013). Otherwise they might be tempted in 2014 to take a shortcut and favor a model like in UK where retailers are mandating that B2C data has to be captured by Brandbank. This is a free service to retailers but has to be paid by industry. And retailers might be tempted even not to touch their IT infrastructure but simply feed that data only directly into their online-shop and not getting any other benefits out of this data. 

6. Stationary retailers will learn from Amazon that the electronic supply-chain is key for success
Hmmm, any update on this? I do not know ... just a personal note - I learned that grocery online shopping is different from shopping other goods online. I never did grocery online shopping until REWE started their home delivery service here in cologne. Even though the online shop is not yet as good as you would expect it today (product information, images, search, ... - Amazon sets the bar quite high) the whole service is great! Why? It is home delivery! Since they started their service back in October 2012 I have never been again in a supermarket!

7. The GS1 system demands an integrated solution for supplier data, item master data and transactional data
I have not seen anything happing in that area. Did you?

8. Gepir will be abandoned
I have not seen anything happing in that area. Did you?

9. GDSN at the tipping point - Not for profit vs. commercial services
2012 was the tipping point - with the merger of 1SYNC and SA2 Worldsync there is only one real global data pool left and that is owned by GS1 US and GS1 Germany. Now most of the GDSN is controlled by a not for profit organisation. This should remove all the barriers and politics within the network and hopefully help to make data synchronisation a lot easier. Looking forward to 2013!

2013 will become again very interesting in the areas of MDM and GDSN!

Happy New Year!