New Feature - Revision & Version Control

Well, the launch date is nearing and we’re delighted to now be able to reveal all about Revision & Version Control - a soon to be launched feature born directly out of user feedback, and answer some of the common questions around the subject...

Why are we introducing Revision & Version Control?

Our new Revision & Version Control feature came about from our users needing answers to the following questions:

• What version of a particular product is in my store?
• If a product has changed, what has changed, regarding the product, and why weren't we told about the change?
• The label on the product is different to the information on Erudus, why?

Before developing the feature, we wanted to understand how big an issue this was for our user base, and the first step in doing so was to establish the rate at which products were changing.

So we recorded and analysed every product change in our Data Pool over a 3 month period. Our findings were:

On average there were 146 changes a day. That’s 53k changes per annum. This was based on a Data Pool size of 58k products.

The next thing we wanted to know was how many attributes were altered when a product change occurred: The answer was on average 716 attributes a day - with 4.9 attributes affected per change.

53 out of the average 146 product changes per day were what GS1 standards define as a major change.

These are the major reasons a GTIN should be changed:

• If the product is new to market
• After a brand name change
• A new formulation - e.g. the product now contains nuts, or a nutritional panel change
• After a net content/pack size change e.g. 10 to 8 pieces or 680g to 794g
• When there are changes to dimensional or gross weight - 20% change to a physical dimension or gross weight
• After the addition or removal of a certification mark - for example Halal or Kosher certifications
• When there are changes to pack/case quantity - for example from 12 to 8 trade items (Inner)
• When there are changes to a multipack component - one or more components swapped out
• After a change to the price on pack - PMP changes from 99p to £1.10

When a major change occurs to a product the Barcode (GTIN) should be changed as per GS1 guidance which can be found here.

Of the 53 daily product changes, 2/3 of the product Barcodes were not changed.

When we explored this, our findings were as follows:

• Generally speaking, Manufacturers were aware of and follow GS1 standards
• Manufacturers in some cases knowingly ignore best practices when it comes to the changing of barcodes
• The idea of following standards vs operational reality can be very different
• Wholesaler/Retailer listing/re-listing fees are commonly cited as a reason for not following GS1 Standards
• The cost of reprinting packaging was another reason cited

A solution that would follow best practice whilst allowing for real world business practices was needed. A solution that would provide Erudus users with clear steps to product version and revision.

The Erudus Solution

Going forward, product specifications on Erudus will include product history, recorded using version stepping.

What is Version Stepping?

At Erudus we split out product changes into 2 categories, which are:

• Major changes - i.e. the product should have a new barcode. We refer to these as "versions"
• Minor changes - i.e a barcode change is not required. We refer to these as "revisions"

The first version of a product is known as 1.0. The first number relates to how many major changes have taken place and the second number refers to how many minor changes have taken place.

For example, if a minor change is made to the original product it moves a revision step and becomes 1.1.

If a major change is then made (e.g. nuts are added to the product recipe) it moves a version step to become 2.0.

If another minor change is made it moves another version step to become 2.1.

After each major step the second number will always reset back to 0 - so, if a major change is made to version 1.6 it will become 2.0.

The new Erudus Revision & Version Control

The new Revision & Version Control feature will record every change to a product, the attributes that have changed and the values “from” and “to”.

The system will automatically determine if it’s a major or minor change and create steps accordingly.

Every historical version/revision will be available to view, and Manufacturers entering the information can state what the change is for - i.e. a correction, revision or replacement. They can overlay the Erudus Version/Revision with their own version control reference if preferred.

This revision and version history will be visible via the “History” tab on the specification, meaning every version step is recorded and visible to our users.

At our last user forum back in September we asked for feedback on this new feature and the additions attendees would like to see.

Batch code, day code and effective date (as some changes are retrospective) were among the suggestions, and we’re working on adding these feature in preperation for launch.

Example of Revison & Version control

Here's a visual example of how Revision & Version control on Erudus will work...

Let's say we're a food Manufacturer called "The Erudus Crisp Company" and we manufacture "Chilli and Lime Crisps" as one of our products.

We enter the product information into Erudus and "Publish" the product to the Data Pool. This is the initial version of the product, and as such, it's recorded as version 1.0.

Due to this being the first and initial version of the product, there will be no changes to be seen in "Version History" and it will look like this:

A period of time passes and we make a change to the recipe - lets say it's a formulation change and we're reducing the amount of salt from 4g to 3.8g. We make the change to the product specification in Erudus and re-publish the product. As this is a "Minor Change" it's recorded as version 1.1 and looks like this in the "Version History":

You can see both version 1.0 and 1.1 are listed, and directly below version 1.1 you can see the attribute(s) and the value changes 'to' and 'from'.

Again, a period of time passes and we make another change to the product, this time we add some supplementary information for Vitamins.

We add values for both Calcium (5.9mg) and Potassium (330.4mg). We make the change to the product specification in Erudus and re-publish the product. As this is a "Minor Change" it's recorded as version 1.2 and looks like this in the "Version History":

You can see all 3 versions, 1.0, 1.1 and 1.2 listed, and directly below the version number heading you can see the attribute(s) and the value changes 'to' and 'from'.

Another period of time passes and we reformulate the recipe so it now includes a new ingredient, "Soya Flour". As Soya is one of the 14 Major Food Allergens its inclusion would trigger a "Major Change". We make the change to the product specification in Erudus and re-publish the product. As this is a "Major Change" it's recorded as version 2.0 and looks like this in the "Version History":

You can see all four versions, 1.0, 1.1, 1.2 and 2.0 listed, and directly below the version number heading you can see the attribute(s) and the value changes "to" and "from".

Every change is recorded clearly showing the revision history along with the detail of what and when changes occurred. We're sure you'll find this useful.

We'll be hosting a whole suite of webinars giving further information about our new features and advice about getting the most out of them, so be sure to keep an eye on our Events page for details.