Why do retailers change their MIGs and EDI specs?

by Mar 7, 2016Experts, Market, Retailers, Suppliers1 comment

Numerous colleagues here in the Sydney and Melbourne offices have worked in either supplier side or retail EDI departments, with EDI specs and maps (MIGs).  They have stories about 12-month point-to-point EDI connection projects, strings of failed orders that weren’t discovered for weeks or (in one case) months, and a poorly tested configuration that mapped the SKU to the item quantity field.  My favourite story – which may be apocryphal – is from an experienced colleague that worked at a major retailer in the mid 1990s, and swears that they found hundreds of original ‘Choose Life’ t-shirts, circa 1984, in an undocketed box.

A thought-provoking but entertaining conversation evolved last week, when ex-supplier and ex-retailer EDI department colleagues discussed their views on the frequency of retailer MIG or EDI spec changes.  The ex-supplier view was that retailers regularly modified their EDI specs because retailer EDI teams enjoy toying with supplier EDI teams.  The core complaint was the frequency of change rather than the fact of change. The ex-retailer EDI specialist did not disavow this allegation – but did discuss that there are important reasons for retailer changes to EDI specs … reasons that don’t include taking sadistic pleasure in giving their supplier-side counterparts more work!

A common reason for retailers to change their EDI specs is a change in ERP system – big changes, such as migrating to a new system or a significant version upgrade. During such migrations, it is common that some additional data point be required or desired for a business process – and if implemented at the retailer end, the suppliers must follow.  New documents are frequently introduced at this point, particularly the ASN or DESADV document (which has caused many a supplier EDI team to have sleepless nights).

When I was project lead for an enterprise SAP migration, numerous additional data points such as production time and delivery time (that was a collective ‘fulfilment time’ in the prior system) needed to be generated for the ERP to work correctly.  We also took the opportunity to add some fields we desired, particularly for ecommerce and extended product attributes.  We figured that we may as well do the voluntary changes together with the main requirements, and get it all out of the way together – and our suppliers bore the brunt of that decision.  We knew that it would affect them, but we had to get rid of our legacy system, before it fell over and threw us back into the stone age!

Another common time for EDI spec changes is when a retailer opens (or acquires) a new business unit.  New products in new categories and types typically means some EDI change, even if it is as simple as a product key expansion.  New attribute types need handling and sharing – all of which, again, requires the suppliers to make correlating changes in their system, even where they will be supplying the same product mix.

Similar to the above is when retailers implement a new internal business process; different origins but the same outcome.  The big push on this area is automation – the retailer may have automated returns, or freight forwarders, or introduced an ASN or DESADV document to automate and expedite speed to floor.  Drop ship fulfilment is – slowly – gaining traction in Australia, and is another major example of this style of change.  Other elements, such as a new DC entering the supply chain, or accounting process changes, can create the need for suppliers to update their EDI specs to match the retailer.


Retailers generally do consider their suppliers’ pain when they introduce new EDI documents or change EDI specifications – it’s just that they have a different set of priorities.  A small optimisation in warehousing efficiency can literally save retailers millions of dollars annually per DC or warehouse site.  Retailers’ timing is generally that they plan for projects to conclude – with a buffer – just before the end of the reporting period.  In Australia, that means major retailer ERP or WMS projects are generally timed to finish by the beginning of June (for the financial year).

SPS Commerce can help with this, of course – in fact, suppliers can avoid these challenges altogether by working with SPS. Our cloud-based model means we proactively maintain all retailer maps, at no additional charge to the supplier.  Essentially this means that if a retailer with 100 (or 1000) suppliers makes a change to EDI specs trading, SPS Commerce would automatically update the retailer maps, and the suppliers on our network would continue trading – most likely blissfully unaware that a change had even occurred.

Each supplier that wasn’t trading through us would need to individually remap and retest. Where suppliers go it alone, with an in-house EDI department and point-to-point retailer connections, it is recommended that a staff member be tasked with contacting those retailer customers every ~3 months, to investigate plans for EDI spec changes.  This quick ring-around can make the difference between lost orders or penalties and smooth continuity.

SPS Australia Blog Team

The Australian SPS blog team combines the experience and insights from dozens of colleagues to deliver news, how-to guides, reports, and more.
SPS Australia Blog Team